Blocks Extensible Exchange Protocol - Versionsgeschichte

Invisigoth67: typo

2024-10-22T07:33:28Z

typo

← Nächstältere Version		Version vom 22. Oktober 2024, 09:33 Uhr
Zeile 51:		Zeile 51:
	== Profile ==		== 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.		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:		Beispiele für Profil-IDs:

Invisigoth67: Website ≠ Webseite

2024-05-19T15:36:53Z

Website ≠ Webseite

← Nächstältere Version		Version vom 19. Mai 2024, 17:36 Uhr
Zeile 122:		Zeile 122:

	== Weblinks ==		== Weblinks ==
	* [http://beepcore.org/ BEEPcore.org] Offizielle ~~Webseite~~		* [http://beepcore.org/ BEEPcore.org] Offizielle Website
	* {{RFC-Internet \|RFC=3080 \|Titel=The Blocks Extensible Exchange Protocol Core \|Datum=}}		* {{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=3081 \|Titel=Mapping the BEEP Core onto TCP \|Datum=}}

PerfektesChaos: tk k

2023-07-03T07:45:11Z

tk k

Änderungen zeigen

Starkiller3010: Code formatiert

2019-01-28T21:31:21Z

Code formatiert

← Nächstältere Version		Version vom 28. Januar 2019, 23:31 Uhr
Zeile 38:		Zeile 38:
	<code>L:</code><br />		<code>L:</code><br />
	<code>L: <greeting></code><br />		<code>L: <greeting></code><br />
	<code>L: <profile uri='http://iana.org/beep/TLS' /></code><br />		<code><nowiki>L: <profile uri='http://iana.org/beep/TLS' /></nowiki></code><br />
	<code>L: </greeting></code><br />		<code>L: </greeting></code><br />
	<code>L: END</code><br />		<code>L: END</code><br />

CommonsDelinker: Ersetze BEEP_Profiles_amd_Channels.jpg durch BEEP_Profiles_and_Channels.jpg (von CommonsDelinker angeordnet: File renamed: Criterion 3 (obvio

2018-12-15T12:31:04Z

Ersetze BEEP_Profiles_amd_Channels.jpg durch BEEP_Profiles_and_Channels.jpg (von CommonsDelinker angeordnet: File renamed: Criterion 3 (obvio

← Nächstältere Version		Version vom 15. Dezember 2018, 14:31 Uhr
Zeile 22:		Zeile 22:

	== BEEP Session ==		== BEEP Session ==
	[[Datei:BEEP Profiles ~~amd~~ Channels.jpg\|mini\|BEEP Kanäle erlauben den Zugriff auf mehrere Profile innerhalb einer 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:		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:

Girus: br

2018-11-19T06:55:58Z

← Nächstältere Version		Version vom 19. November 2018, 08:55 Uhr
Zeile 32:		Zeile 32:
	Ein Beispiel für den Austausch von Begrüßungen:		Ein Beispiel für den Austausch von Begrüßungen:

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

	== Profile ==		== Profile ==
Zeile 67:		Zeile 67:
	Beispiel aus RFC 3080: Schließen eines BEEP-Kanals:		Beispiel aus RFC 3080: Schließen eines BEEP-Kanals:

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

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

Muellersmattes: Weblink aus Fließtext entfernt

2018-11-12T14:48:29Z

Weblink aus Fließtext entfernt

← Nächstältere Version		Version vom 12. November 2018, 16:48 Uhr
Zeile 51:		Zeile 51:
	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.		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:		Beispiele für Profil-IDs:

	{\| class="wikitable"		{\| class="wikitable"
Zeile 63:		Zeile 63:

	== Nachrichten und Frames ==		== 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.		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 RFC 3080: Schließen eines BEEP Kanals:		Beispiel aus RFC 3080: Schließen eines BEEP-Kanals:

	<code>C: MSG 0 2 . 235 71</code></br>		<code>C: MSG 0 2 . 235 71</code></br>
Zeile 107:		Zeile 107:
	\|}		\|}

	Einige der häufigsten ~~Protokoll Muster~~ werden wie folgt implementiert:		Einige der häufigsten Protokollmuster werden wie folgt implementiert:

	* '''Request-reply''' Eine MSG-Nachricht wird mit jeweils einem RPY oder ERR beantwortet.		* '''Request-reply''' Eine MSG-Nachricht wird mit jeweils einem RPY oder ERR beantwortet.
Zeile 115:		Zeile 115:
	=== Flusskontrolle ===		=== Flusskontrolle ===

	Für die Flusssteuerung in Kanälen verwendet BEEP Sequenz-Frames (SEQ). Sequenz-Frames sind in [~~https~~:~~//tools.ietf.org/html/rfc793#section-3.3~~ RFC 3081 ~~section~~ 3.3] beschrieben. 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>{{ cite web \| url = http://www.beepcore.org/seq_frames.html \| title = 'Understanding SEQ frames: BEEP flow control and bandwidth management \| author = Francis Brosnan \| date = 2006-01-30 \| accessdate = 2014-10-31 }}</ref>.		Für die Flusssteuerung in Kanälen verwendet BEEP Sequenz-Frames (SEQ). Sequenz-Frames sind in [[RFC:3081\|RFC 3081]], Abschnitt 3.1 beschrieben. 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>{{ cite web \| url = http://www.beepcore.org/seq_frames.html \| title = 'Understanding SEQ frames: BEEP flow control and bandwidth management \| author = Francis Brosnan \| date = 2006-01-30 \| accessdate = 2014-10-31 }}</ref>.

	== Weblinks ==		== Weblinks ==

Fomafix: ß → ss, Bindestriche eingefügt. Weblinks aktualisiert.

2016-02-07T15:34:17Z

ß → ss, Bindestriche eingefügt. Weblinks aktualisiert.

Änderungen zeigen

GeorgDerReisende: Auszeichnungsfehler korrigiert | Helfer gesucht

2015-11-30T21:06:59Z

Auszeichnungsfehler korrigiert | Helfer gesucht

← Nächstältere Version		Version vom 30. November 2015, 23:06 Uhr
Zeile 123:		Zeile 123:
	*[[RFC:3081\|RFC 3081]]: ''Mapping the BEEP Core onto TCP''		*[[RFC:3081\|RFC 3081]]: ''Mapping the BEEP Core onto TCP''
	*[[RFC:3117\|RFC 3117]]: ''On the Design of Application Protocols'', design considerations of the BXXP protocol as told by its creators		*[[RFC:3117\|RFC 3117]]: ''On the Design of Application Protocols'', design considerations of the BXXP protocol as told by its creators
	*[[RFC:3195\|RFC 3195]]: ''Reliable Delivery for syslog - BEEP Profile		*[[RFC:3195\|RFC 3195]]: ''Reliable Delivery for syslog - BEEP Profile''
	*[[RFC:3529\|RFC 3529]]: ''XML-RPC Profile for BEEP		*[[RFC:3529\|RFC 3529]]: ''XML-RPC Profile for BEEP''
	*[[RFC:4227\|RFC 4227]]: ''Using SOAP in BEEP		*[[RFC:4227\|RFC 4227]]: ''Using SOAP in BEEP''
	*[[RFC:3620\|RFC 3620]]: ''The TUNNEL Profile		*[[RFC:3620\|RFC 3620]]: ''The TUNNEL Profile''
	*[http://www.iana.org/assignments/beep-parameters iana.org/assignments/beep-parameters] Standard track BEEP profiles registry		*[http://www.iana.org/assignments/beep-parameters iana.org/assignments/beep-parameters] Standard track BEEP profiles registry
	*''[http://www.ibm.com/developerworks/library/x-beep/ Introduction to BEEP]'' auf IBM.com		*''[http://www.ibm.com/developerworks/library/x-beep/ Introduction to BEEP]'' auf IBM.com

StephanGruhne: Tippfehler entfernt

2014-11-12T22:10:48Z

Tippfehler entfernt

← Nächstältere Version		Version vom 13. November 2014, 00:10 Uhr
Zeile 9:		Zeile 9:
	== Überblick ==		== Ü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 [[Duplex (Nachrichtentechnik)\|Vollduplex]] [[Pipe (Informatik)\|Pipes]], die mit einem Profil verbunden sind. Nachrichten, die über verschiedene Kanäle gesendet werden, sind ~~unabängig~~ voneinander (asynchron). Es können beliebig viele Kanäle mit einem Profil verbunden werden.		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 [[Duplex (Nachrichtentechnik)\|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.		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.
Zeile 15:		Zeile 15:
	== Geschichte ==		== Geschichte ==

	Marshall T. Rose, der ebenfalls an Protokollen wie [[POP3]], [[SMTP]], und [[SNMP]] mitgearbeitet hat<ref>{{ cite web \| url = http://www.computerworld.com.au/article/85987/_http_steroids_ease_protocol_work/ \| title = 'HTTP on steroids' to ease protocol work \| author = Carolyn Duffy Marsan \| publisher = Computer World \| date = 2000-06-26 \| accessdate = 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 ~~Berarbeitung~~. Die [[Internet Engineering Task Force\|IETF]] veröffentlichte 2001 BEEP (RFC 3080) und BEEP über [[Transmission Control Protocol\|TCP]] (RFC 3081) mit einigen Erweiterungen gegenüber BXXP. Drei der Erweiterungen sind:		Marshall T. Rose, der ebenfalls an Protokollen wie [[POP3]], [[SMTP]], und [[SNMP]] mitgearbeitet hat<ref>{{ cite web \| url = http://www.computerworld.com.au/article/85987/_http_steroids_ease_protocol_work/ \| title = 'HTTP on steroids' to ease protocol work \| author = Carolyn Duffy Marsan \| publisher = Computer World \| date = 2000-06-26 \| accessdate = 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 (RFC 3080) und BEEP über [[Transmission Control Protocol\|TCP]] (RFC 3081) mit einigen Erweiterungen gegenüber BXXP. Drei der Erweiterungen sind:

	* Verwendung von application/octet-stream als Voreinstellung für "Content-Type".		* Verwendung von application/octet-stream als Voreinstellung für "Content-Type".
Zeile 49:		Zeile 49:
	== Profile ==		== 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 ~~Internetaddresse~~, zu Verwirrung. Um ~~Mißverständnisse~~ zu vermeiden sollten neue Profile das [[Uniform Resource Name\|URN]] Format verwenden.		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:		Beispiele für Profil IDs:
Zeile 115:		Zeile 115:
	=== Flußkontrolle ===		=== Flußkontrolle ===

	Für die Flußsteuerung in Kanälen verwendet BEEP Sequenz-Frames (SEQ). Sequenz-Frames sind in [https://tools.ietf.org/html/rfc793#section-3.3 RFC 3081 section 3.3] beschrieben. Für die gesamte Verbindung wird vom [[Transmission Control Protocol]] ([[Transmission Control Protocol\|TCP]]) ebenfalls einen Sequenz-Mechanismus zur [[Transmission_Control_Protocol#Flusssteuerung\|Flußsteuerung]] verwendet. Damit jedoch ein Kanal oder eine große Nachricht nicht die gesamte Bandbreite beansprucht, wird eine Flußkontrolle für ~~einzelene~~ 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>{{ cite web \| url = http://www.beepcore.org/seq_frames.html \| title = 'Understanding SEQ frames: BEEP flow control and bandwidth management \| author = Francis Brosnan \| date = 2006-01-30 \| accessdate = 2014-10-31 }}</ref>..		Für die Flußsteuerung in Kanälen verwendet BEEP Sequenz-Frames (SEQ). Sequenz-Frames sind in [https://tools.ietf.org/html/rfc793#section-3.3 RFC 3081 section 3.3] beschrieben. Für die gesamte Verbindung wird vom [[Transmission Control Protocol]] ([[Transmission Control Protocol\|TCP]]) ebenfalls einen Sequenz-Mechanismus zur [[Transmission_Control_Protocol#Flusssteuerung\|Flußsteuerung]] verwendet. Damit jedoch ein Kanal oder eine große Nachricht nicht die gesamte Bandbreite beansprucht, wird eine Flußkontrolle 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>{{ cite web \| url = http://www.beepcore.org/seq_frames.html \| title = 'Understanding SEQ frames: BEEP flow control and bandwidth management \| author = Francis Brosnan \| date = 2006-01-30 \| accessdate = 2014-10-31 }}</ref>..

	== Weblinks ==		== Weblinks ==

← Nächstältere Version		Version vom 30. November 2015, 23:06 Uhr
Zeile 123:		Zeile 123:
	*[[RFC:3081\|RFC 3081]]: ''Mapping the BEEP Core onto TCP''		*[[RFC:3081\|RFC 3081]]: ''Mapping the BEEP Core onto TCP''
	*[[RFC:3117\|RFC 3117]]: ''On the Design of Application Protocols'', design considerations of the BXXP protocol as told by its creators		*[[RFC:3117\|RFC 3117]]: ''On the Design of Application Protocols'', design considerations of the BXXP protocol as told by its creators
	*[[RFC:3195\|RFC 3195]]: ''Reliable Delivery for syslog - BEEP Profile		*[[RFC:3195\|RFC 3195]]: ''Reliable Delivery for syslog - BEEP Profile''
	*[[RFC:3529\|RFC 3529]]: ''XML-RPC Profile for BEEP		*[[RFC:3529\|RFC 3529]]: ''XML-RPC Profile for BEEP''
	*[[RFC:4227\|RFC 4227]]: ''Using SOAP in BEEP		*[[RFC:4227\|RFC 4227]]: ''Using SOAP in BEEP''
	*[[RFC:3620\|RFC 3620]]: ''The TUNNEL Profile		*[[RFC:3620\|RFC 3620]]: ''The TUNNEL Profile''
	*[http://www.iana.org/assignments/beep-parameters iana.org/assignments/beep-parameters] Standard track BEEP profiles registry		*[http://www.iana.org/assignments/beep-parameters iana.org/assignments/beep-parameters] Standard track BEEP profiles registry
	*''[http://www.ibm.com/developerworks/library/x-beep/ Introduction to BEEP]'' auf IBM.com		*''[http://www.ibm.com/developerworks/library/x-beep/ Introduction to BEEP]'' auf IBM.com