Wikipedia

Blocks Extensible Exchange Protocol

BEEP im TCP/IP-Protokollstapel:
Anwendung BEEP
Transport TCP
Internet IP (IPv4, IPv6)
Netzzugang Ethernet Token
Bus 		Token
Ring 		FDDI …

Blocks Extensible Exchange Protocol (BEEP) (davor BXXP) ist ein generisches Netzwerkprotokoll. BEEP bietet grundlegende Funktionen für verbindungs- und nachrichtenorientierte Peer-to-Peer (P2P) Protokolle und unterstützt asynchrone Vollduplex-Kommunikation.

BEEP-Profile definieren Syntax und Semantik von Nachrichten und können innerhalb einer Session mit einem oder mehreren Kanälen verbunden werden. Jeder BEEP-Kanal verhält sich dabei wie eine Vollduplex-Pipe. Ein Frame-Mechanismus ermöglicht eine gleichzeitige und unabhängige Kommunikation zwischen Peers.

BEEP ist in RFC 3080[1] unabhängig vom Transport-Mechanismus definiert. Wie BEEP auf unterschiedlichen Transport-Mechanismen aufsetzt, wird in anderen Dokumenten beschrieben.

Überblick Bearbeiten

BEEP verwendet Profile, Kanäle und einen Frame-Mechanismus, um verschiedene Arten von Nachrichten auszutauschen. Für Inhaltstyp und Kodierung wird die Voreinstellung durch die BEEP-Spezifikation vorgegeben. Der Protokoll-Designer legt fest, ob entweder ein binäres oder ein beliebiges textbasiertes Nachrichtenformat verwendet wird. Profile definieren Syntax und Semantik des Nachrichtenformats und bestimmen die Funktionalität des Protokolls. Kanäle sind Vollduplex-Pipes, die mit einem Profil verbunden sind. Nachrichten, die über verschiedene Kanäle gesendet werden, sind unabhängig voneinander (asynchron). Es können beliebig viele Kanäle mit einem Profil verbunden werden.

BEEP stellt darüber hinaus TLS für Verschlüsselung und SASL für Authentifizierung zur Verfügung.

Geschichte Bearbeiten

Marshall T. Rose, der ebenfalls an Protokollen wie POP3, SMTP, und SNMP mitgearbeitet hat,[2] begann 1998 mit der Arbeit an BXXP, dem Vorgänger von BEEP, und übergab die Spezifikation im Sommer 2000 an eine Arbeitsgruppe der Internet Engineering Task Force (IETF) zur Bearbeitung. Die IETF veröffentlichte 2001 BEEP (RFC 3080[1]) und BEEP über TCP (RFC 3081[3]) mit einigen Erweiterungen gegenüber BXXP. Drei der Erweiterungen sind:

  • Verwendung von application/octet-stream als Voreinstellung für Content-Type.
  • Unterstützung von mehreren Antworten auf eine Anfrage (multi-reply) für Nachrichten.
  • Der Name wurde von BXXP in BEEP geändert.

BEEP Session Bearbeiten

 
BEEP Kanäle erlauben den Zugriff auf mehrere Profile innerhalb einer Session.

Eine BEEP-Session wird gestartet, wenn sich ein Peer (Initiator) mit einem anderen (Listener) verbindet. Beide Peers schicken sofort und gleichzeitig eine Nachricht (RPY) mit einer Begrüßung (greeting). Das greeting-Element kann bis zu drei Elemente enthalten:

  • features optional: Funktionen für die Kanalverwaltung, die der Peer unterstützt.
  • localize optional: Bevorzugte Sprache für Fehlermeldungen und Nachrichten.
  • profile notwendig: Profile, die der Peer unterstützt.

Ein Beispiel für den Austausch von Begrüßungen: 

L: <wait for incoming connection>
I: <open connection>
L: RPY 0 0 . 0 110
L: Content-Type: application/beep+xml
L:
L: <greeting>
L:    <profile uri='http://iana.org/beep/TLS' />
L: </greeting>
L: END
I: RPY 0 0 . 0 52
I: Content-Type: application/beep+xml
I:
I: <greeting />
I: END

Profile Bearbeiten

Profile legen das Nachrichtenformat fest und definieren die Funktionalität des BEEP basierten Protokolls. Eine BEEP-Session kann mehrere Profile gleichzeitig zur Verfügung stellen. Um ein Profil eindeutig identifizieren zu können, wird jedem eine Zeichenkette (Profil ID) zugewiesen. Die Profil ID hat das Format eines Uniform Resource Identifier (URI) oder eines Uniform Resource Name (URN). In der Vergangenheit führte das URI-Format, wegen seiner Ähnlichkeit zu einer Internetadresse, zu Verwirrung. Um Missverständnisse zu vermeiden sollten neue Profile das URN-Format verwenden.

Beispiele für Profil-IDs:

urn:ietf:params:xml:ns:geopriv:held:beep Eine BEEP Version des HELD Protokolls
http://iana.org/beep/xmlrpc RFC 3529 XML-RPC über BEEP[4]

Nachrichten und Frames Bearbeiten

Für BEEP-Nachrichten wird das MIME-Format verwendet. Nachrichten transportieren einen Inhalt, dessen Format vom Profil-Designer festgelegt wird. Textbasierte Formate wie JSON oder XML wie auch binäre Formate sind möglich. Die Kanalverwaltung über Channel 0 und das TLS-Profil verwenden eine Untermenge von XML, die für den Profil-Designer transparent ist.

Beispiel aus RFC 3080[1] – Schließen eines BEEP-Kanals: 

C: MSG 0 2 . 235 71
C: Content-Type: application/beep+xml
C:
C: <close number='1' code='200' />
C: END
S: RPY 0 2 . 392 46
S: Content-Type: application/beep+xml
S:
S: <ok />
S: END

Größere Nachrichten werden über mehrere Frames (Sequence Frames) verteilt.

Nachrichten-Typen Bearbeiten

BEEP definiert 5 Nachrichtentypen für die häufigsten Muster in Anwendungsprotokollen:

Message MSG Eine Nachricht mit Inhalt.
Reply RPY Eine einzelne Antwort auf eine empfangene Nachricht mit Inhalt.
Error ERR Eine einzelne Antwort auf eine empfangene Nachricht mit Inhalt und Fehlerbeschreibung.
Answer ANS Eine Antwort auf eine empfangene Nachricht mit Inhalt. Es können 0 bis n Antworten auf eine Nachricht gesendet werden.
Nul NUL Eine abschließende Antwort auf eine empfangene Nachricht ohne Inhalt, um das Ende eines Nachrichtenaustauschs mit mehreren Antworten zu signalisieren.

Einige der häufigsten Protokollmuster werden wie folgt implementiert:

  • Request-reply Eine MSG-Nachricht wird mit jeweils einem RPY oder ERR beantwortet.
  • Single request-multiple replies Eine MSG-Nachricht wird mit keiner, einer oder mehreren ANS-Nachrichten beantwortet und mit NUL oder ERR abgeschlossen.
  • Unacknowledged notification Es werden MSG-Nachrichten gesendet die keine Antwort erwarten.

Flusskontrolle Bearbeiten

Für die Flusssteuerung in Kanälen verwendet BEEP Sequenz-Frames (SEQ). Sequenz-Frames sind in RFC 3081, Abschnitt 3.1 beschrieben.[5] Für die gesamte Verbindung wird vom Transmission Control Protocol (TCP) ebenfalls einen Sequenz-Mechanismus zur Flusssteuerung verwendet. Damit jedoch ein Kanal oder eine große Nachricht nicht die gesamte Bandbreite beansprucht, wird eine Flusskontrolle für einzelne BEEP-Kanäle benötigt. Sequenz-Frames werden für die Unterstützung von Quality of Service (QoS) und zur Staukontrolle verwendet[6].

Weblinks Bearbeiten

  • BEEPcore.org Offizielle Webseite
  • RFC 3080 – The Blocks Extensible Exchange Protocol Core. (englisch).
  • RFC 3081 – Mapping the BEEP Core onto TCP. (englisch).
  • RFC 3117 – On the Design of Application Protocols. (design considerations of the BXXP protocol as told by its creators, englisch).
  • RFC 3195 – Reliable Delivery for syslog – BEEP Profile. (englisch).
  • RFC 3529 – XML-RPC Profile for BEEP. (englisch).
  • RFC 4227 – Using SOAP in BEEP. (englisch).
  • RFC 3620 – The TUNNEL Profile. (englisch).
  • iana.org/assignments/beep-parameters Standard track BEEP profiles registry. IANA.
  • Introduction to BEEP. IBM.com

Einzelnachweise Bearbeiten

  1. ↑ a b c RFC 3080 – The Blocks Extensible Exchange Protocol Core. (englisch).
  2. ↑ Carolyn Duffy Marsan: ‘HTTP on steroids’ to ease protocol work. In: Computer World. 26. Juni 2000, abgerufen am 31. Oktober 2014 (englisch).
  3. ↑ RFC 3081 – Mapping the BEEP Core onto TCP. (englisch).
  4. ↑ RFC 3529 – Using Extensible Markup Language-Remote Procedure Calling (XML-RPC) in Blocks Extensible Exchange Protocol (BEEP). April 2003 (englisch).
  5. ↑ RFC 3081 – Mapping the BEEP Core onto TCP. Abschnitt 3.1 (englisch).
  6. ↑ Francis Brosnan: Understanding SEQ frames: BEEP flow control and bandwidth management. 30. Januar 2006, abgerufen am 31. Oktober 2014 (englisch).
Abgerufen von „https://de.wikipedia.org/w/index.php?title=Blocks_Extensible_Exchange_Protocol&oldid=235139788“