imported>Invisigoth67: typo

2024-10-22T07:33:28Z

typo

Neue Seite

{{Netzwerk-TCP-IP-Anwendungsprotokoll|BEEP}}

'''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 [[Duplex (Nachrichtentechnik)|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 (Informatik)|Pipe]]. Ein Frame-Mechanismus ermöglicht eine gleichzeitige und unabhängige Kommunikation zwischen [[Peer (Informatik)|Peers]].

BEEP ist in <nowiki>RFC 3080</nowiki><ref name="RFC3080" /> unabhängig vom Transport-Mechanismus definiert. Wie BEEP auf unterschiedlichen Transport-Mechanismen aufsetzt, wird in anderen Dokumenten beschrieben.

== Überblick ==

BEEP verwendet Profile, Kanäle und einen Frame-Mechanismus, um verschiedene Arten von Nachrichten auszutauschen. Für Inhaltstyp und [[Zeichenkodierung|Kodierung]] wird die Voreinstellung durch die BEEP-Spezifikation vorgegeben. Der Protokoll-Designer legt fest, ob entweder ein [[Binärdatei|binäres]] oder ein beliebiges [[Textdatei|textbasiertes]] Nachrichtenformat verwendet wird. Profile definieren [[Syntax]] und [[Semantik]] des Nachrichtenformats und bestimmen die Funktionalität des [[Netzwerkprotokoll|Protokolls]]. Kanäle sind [[Vollduplex]]-[[Pipe (Informatik)|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 [[Transport Layer Security|TLS]] für [[Verschlüsselung]] und [[Simple Authentication and Security Layer|SASL]] für [[Authentifizierung]] zur Verfügung.

== Geschichte ==

Marshall T. Rose, der ebenfalls an Protokollen wie [[POP3]], [[Simple Mail Transfer Protocol|SMTP]], und [[Simple Network Management Protocol|SNMP]] mitgearbeitet hat,<ref>{{Internetquelle |autor=Carolyn Duffy Marsan |url=http://www.computerworld.com.au/article/85987/_http_steroids_ease_protocol_work/ |titel=‘HTTP on steroids’ to ease protocol work |werk=Computer World |datum=2000-06-26 |sprache=en |abruf=2014-10-31}}</ref> 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]] ([[Internet Engineering Task Force|IETF]]) zur Bearbeitung. Die [[Internet Engineering Task Force|IETF]] veröffentlichte 2001 BEEP (<nowiki>RFC 3080</nowiki><ref name="RFC3080" />) und BEEP über [[Transmission Control Protocol|TCP]] (<nowiki>RFC 3081</nowiki><ref name="RFC3081" />) mit einigen Erweiterungen gegenüber BXXP. Drei der Erweiterungen sind:

* Verwendung von <code style="white-space:nowrap">application/octet-stream</code> als Voreinstellung für <code style="white-space:nowrap">Content-Type</code>.
* Unterstützung von mehreren Antworten auf eine Anfrage (multi-reply) für Nachrichten.
* Der Name wurde von BXXP in BEEP geändert.

== BEEP Session ==
[[Datei:BEEP Profiles and Channels.jpg|mini|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:

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

== Profile ==

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]] ([[Uniform Resource Identifier|URI]]) oder eines [[Uniform Resource Name]] ([[Uniform Resource Name|URN]]). In der Vergangenheit führte das [[Uniform Resource Identifier|URI]]-Format, wegen seiner Ähnlichkeit zu einer Internetadresse, zu Verwirrung. Um Missverständnisse zu vermeiden, sollten neue Profile das [[Uniform Resource Name|URN]]-Format verwenden.

Beispiele für Profil-IDs:

{| class="wikitable"
|-
| <code><nowiki>urn:ietf:params:xml:ns:geopriv:held:beep</nowiki></code>
| Eine BEEP Version des HELD Protokolls
|-
| <code><nowiki>http://iana.org/beep/xmlrpc</nowiki></code>
| <nowiki>RFC 3529</nowiki> [[XML-RPC]] über BEEP<ref>{{RFC-Internet |RFC=3529 |Titel=Using Extensible Markup Language-Remote Procedure Calling (XML-RPC) in Blocks Extensible Exchange Protocol (BEEP) |Datum=2003-04}}</ref>
|}

== Nachrichten und Frames ==
Für BEEP-Nachrichten wird das [[Multipurpose Internet Mail Extensions|MIME]]-Format verwendet. Nachrichten transportieren einen Inhalt, dessen Format vom Profil-Designer festgelegt wird. Textbasierte Formate wie [[JavaScript Object Notation|JSON]] oder [[Extensible Markup Language|XML]] wie auch binäre Formate sind möglich. Die Kanalverwaltung über Channel 0 und das [[Transport Layer Security|TLS]]-Profil verwenden eine Untermenge von [[Extensible Markup Language|XML]], die für den Profil-Designer transparent ist.

Beispiel aus <nowiki>RFC 3080</nowiki><ref name="RFC3080" /> – Schließen eines BEEP-Kanals:

<pre>
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
</pre>

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

=== Nachrichten-Typen ===

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

{| class="wikitable"
|-
| 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 ===

Für die Flusssteuerung in Kanälen verwendet BEEP Sequenz-Frames (SEQ). Sequenz-Frames sind in <nowiki>RFC 3081</nowiki>, Abschnitt 3.1 beschrieben.<ref>{{RFC-Internet |RFC=3081 |Titel=Mapping the BEEP Core onto TCP |Datum= |Abschnitt=3.1}}</ref> Für die gesamte Verbindung wird vom [[Transmission Control Protocol]] ([[Transmission Control Protocol|TCP]]) ebenfalls einen Sequenz-Mechanismus zur [[Transmission Control Protocol#Flusssteuerung|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]] ([[Quality of Service|QoS]]) und zur Staukontrolle verwendet<ref>{{Internetquelle |autor=Francis Brosnan |url=http://www.beepcore.org/seq_frames.html |titel=Understanding SEQ frames: BEEP flow control and bandwidth management |datum=2006-01-30 |sprache=en |abruf=2014-10-31}}</ref>.

== Weblinks ==
* [http://beepcore.org/ BEEPcore.org] Offizielle Website
* {{RFC-Internet |RFC=3080 |Titel=The Blocks Extensible Exchange Protocol Core |Datum=}}
* {{RFC-Internet |RFC=3081 |Titel=Mapping the BEEP Core onto TCP |Datum=}}
* {{RFC-Internet |RFC=3117 |Titel=On the Design of Application Protocols |Datum= |Kommentar=design considerations of the BXXP protocol as told by its creators}}
* {{RFC-Internet |RFC=3195 |Titel=Reliable Delivery for syslog – BEEP Profile |Datum=}}
* {{RFC-Internet |RFC=3529 |Titel=XML-RPC Profile for BEEP |Datum=}}
* {{RFC-Internet |RFC=4227 |Titel=Using SOAP in BEEP |Datum=}}
* {{RFC-Internet |RFC=3620 |Titel=The TUNNEL Profile |Datum=}}
* [https://www.iana.org/assignments/beep-parameters/beep-parameters.xhtml iana.org/assignments/beep-parameters] Standard track BEEP profiles registry. IANA.
* [https://www.ibm.com/developerworks/library/x-beep/ ''Introduction to BEEP''.] IBM.com

== Einzelnachweise ==
<references>
<ref name="RFC3080">
{{RFC-Internet |RFC=3080 |Titel=The Blocks Extensible Exchange Protocol Core |Datum=}}
</ref>
<ref name="RFC3081">
{{RFC-Internet |RFC=3081 |Titel=Mapping the BEEP Core onto TCP |Datum=}}
</ref>
</references>

[[Kategorie:Internet-Anwendungsprotokoll]]

Blocks Extensible Exchange Protocol - Versionsgeschichte

imported>Invisigoth67: typo