Seite 2: Kommunikationsarten

Inhaltsverzeichnis

Eine Klasse für sich

Je spezifischer ein Protokoll für einen bestimmten Zweck entwickelt wurde, desto weniger Möglichkeiten sind vorhanden, es an einen anderen Anwendungsfall anzupassen. FTP ist beispielsweise für die Übertragung von Dateien gut geeignet. Dafür wurde es entwickelt. Ein festgelegter Befehlssatz ist für diesen speziellen Zweck vorhanden. Anwendungen, die FTP verwenden, können daher problemlos miteinander kommunizieren.

Jedes spezialisierte, nicht erweiterbare Protokoll bildet eine Klasse für sich und lässt sich für einen genau festgelegten Fall verwenden. Meist liegt es auf der Hand, welches Standardprotokoll zum Problem passt.

Schwieriger gestaltet es sich, ein geeignetes, nachrichtenorientiertes Protokoll zu finden, das Entwickler für wachsende Anforderungen im Laufe eines Projekts erweitern können.

Kommunikationsmuster unter der Lupe

Ein grundlegendes Kommunikationsmuster für den Austausch von Nachrichten in Anwendungsprotokollen ist das Anfrage/Antwort-Muster (request/reply). Ein Netzknoten sendet eine Anfrage an einen anderen und erhält eine Antwort. Bleibt sie aus, kommt es zu einem Fehler. In modernen Anwendungen reicht ein derartiger Mechanismus jedoch oft nicht aus, weshalb Abwandlungen nötig sind.

• Single Call, Multiple Answer: Eine Anfrage erlaubt mehr als eine Antwort. Beispielsweise lassen sich, während die Anfrage bearbeitet wird, Statusmeldungen an den Aufrufer senden. Anfragen, deren Bearbeitungszeiten unbekannt sind, können so den Timeout des Aufrufers zurücksetzen. Dem Nutzer ermöglicht eine Visualisierung des Status einen besseren Überblick.
• Unacknowledged Message: Nachrichten werden gesendet, ohne dass der Sender eine Bestätigung erwartet. Die Methode reduziert den Kommunikations-Overhead und erhöht den Durchsatz. Sie wird häufig verwendet, um Datenänderungen auf einem Server anzuzeigen. Es ist jedoch nicht sicher, ob die Informationen den Empfänger erreichen.
• Multicast: UDP als Grundlage nehmende Protokolle erlauben den gleichzeitigen Transport von Nachrichten an eine Gruppe von Empfängern, die am Sender registriert sind. Die Registrierung unterscheidet den Multicast vom Broadcast, dessen Nachrichten für beliebige Empfänger bestimmt sind.

Der Austausch von Nachrichten kann in einem verteilten System im Netzwerk auf die unterschiedlichsten Arten erfolgen. Diese systematischen Kommunikationsmuster bilden, wenn die Entscheidung für eine nachrichtenorientierte Kommunikation gefallen ist, das wichtigste Kriterium für ein geeignetes Protokoll.

• Peer to Peer: Sind beide Knoten beim Austausch von Nachrichten gleichberichtigt, handelt es sich um eine Peer-to-Peer-Kommunikation. Wie bei TCP (siehe Teil 1) können Sender und Empfänger ihre Rollen tauschen. Bevor eine Verbindung besteht, werden der Knoten, der auf eine Verbindung wartet, Listener und der sich verbindende Knoten Initiator genannt. Ein Peer-to-Peer-Protokoll lässt sich für die Implementierung der meisten spezielleren Kommunikationsmuster verwenden.
• Client/Server: Bei Client/Server-Protokollen ist eine Kommunikation nur in eine Richtung möglich. Der Server nimmt Anfragen vom Client entgegen und beantwortet sie.
• Distributed Client/Server: Die Kommunikation mit diesem Protokoll entspricht der beim Einsatz des Client/Server-Protokolls, jedoch ist ein Austausch von Informationen zwischen den Servern vorgesehen.
• Publish/Subscribe: Der Subscriber teilt dem Publisher sein Interesse an bestimmten Informationen mit, die dieser ihm im Anschluss aktiv sendet. Die Methode ähnelt der Push-Technik, die jedoch eine Registrierung für bestimmte Daten nicht zwingend vorsieht.

Nicht immer ist es sinnvoll oder möglich, Nachrichten direkt von einem Knoten zum anderen zu schicken. Ein Message Broker übernimmt in dem Fall die Aufgabe des Vermittlers. Verwenden Netzwerkknoten beispielsweise ein anderes Protokoll oder eine andere Netzwerktechnik wie Bluetooth, sammeln und organisieren Message Broker Daten und leiten sie weiter. Das funktioniert prinzipiell in jede Richtung. Kommunikationsmuster finden dann zwischen Broker zu Knoten und Knoten zu Knoten Anwendung.

Synchron oder asynchron

Dynamische Eigenschaften des Nachrichtenaustauschs werden bei der Entscheidung für ein Protokoll häufig vernachlässigt. Steigen im Laufe des Projekts die Anforderungen an Geschwindigkeit und Skalierbarkeit, können Probleme wie Datenstau und Blocking-Effekte auftreten.

Im einfachsten Fall wird eine Nachricht synchron bearbeitet. Ein Sender überträgt dabei die komplette Nachricht und wartet die Antwort des Empfängers ab, bevor er die nächste Nachricht schickt. Diese Zeitspanne umfasst nicht nur die Bearbeitungszeit, sondern auch die Übertragungszeit der Daten durch das Netz.

Werden mehrere Nachrichten vom Sender an den Empfänger geschickt, ohne die Antwort abzuwarten, spricht man von Pipelining. Der Empfänger arbeitet dabei eine Nachricht nach der anderen ab und beantwortet sie in der Reihenfolge des Empfangs. Er muss die Bearbeitung nicht mehr unterbrechen, bis der Sender die nächste Nachricht übertragen hat, was zu schnelleren Antwortzeiten führt.

In beiden Fällen lassen sich Nachrichten nur in der durch den Sendezeitpunkt festgelegten Reihenfolge bearbeiten. Es entsteht ein Effekt, der als Head-of-line Blocking bezeichnet wird. Große Nachrichten oder Nachrichten mit einer langen Bearbeitungszeit blockieren dabei nachfolgende Anfragen. Eine asynchrone Kommunikation erlaubt es, Nachrichten unabhängig voneinander zu schicken und zu bearbeiten. Die Bearbeitung lässt sich parallel durchführen, was zu einer besseren Ausnutzung von Multicore-CPUs führt. Abbildung 2 stellt asynchronen Nachrichtenaustausch dem synchronen und Pipelining gegenüber.

Ein weiterer Vorteil asynchroner Kommunikation ist die Option, Nachrichten zu priorisieren. Eine gezielte Steuerung der Bandbreite innerhalb einer einzigen Verbindung ist so möglich (Quality of Service).

Ein möglicher Weg, Pipelining und asynchrone Kommunikation in einem Protokoll parallel zu verwenden, sind Kanäle. Ein Kanal verhält sich wie eine Vollduplex-Pipe, während Nachrichten, die über verschiedene Kanäle transportiert werden, asynchron sind. Anwendungen öffnen und schließen Kanäle nach Belieben und verwenden dabei die gleiche Transportverbindung. Die Nachteile kurzlebiger TCP-Verbindungen werden so vermieden (siehe "Internet-Protokolle, Teil 1: TCP/IP, der Grundstein für Anwendungsprotokolle").

Die Datenschicht

Protokolle legen neben dem Transport auch die Syntax und Semantik von Nachrichten fest. Die Bandbreite erstreckt sich dabei von festgelegten Datenfeldern mit einer bestimmten Bedeutung über Standardformate wie JSON oder XML bis zu Nachrichten, die aus einer Payload, also einer frei verwendbaren Menge an Bytes, bestehen. Eine genaue Betrachtung der Möglichkeiten und Einschränkungen unterschiedlicher Datenformate lohnt sich.

Für Anwendungen mit Knoten im Netz, die über geringe Ressourcen wie Rechenleistung und Speicher verfügen, ist ein Blick auf binäre Austauschformate wie MessagePack oder CBOR zu empfehlen. Auf jeden Fall ist das Datenformat ein wichtiges Kriterium für die Auswahl eines Anwendungsprotokolls.