BEEP

BEEP

Els canals BEEP poden accedir a diversos perfils en una sola sessió.
Tipus	protocol de xarxa d'ordinadors
Més informació
Lloc web	beepcore.org (anglès)

El Blocks Extensible Exchange Protocol (BEEP) és un marc per crear protocols d'aplicacions de xarxa. BEEP inclou blocs de construcció com el marc, la canalització, la multiplexació, la generació d'informes i l'autenticació per a la connexió i els protocols d'igual a igual (P2P) orientats a missatges amb suport de comunicació full-duplex asíncrona.

La sintaxi i la semàntica dels missatges es defineixen amb perfils BEEP associats a un o més canals BEEP, on cada canal és una canonada full-duplex. Un mecanisme d'enquadrament permet una comunicació simultània i independent entre iguals.

BEEP es defineix independentment del mecanisme de transport subjacent. L'assignació de BEEP a un servei de transport concret es defineix en una sèrie de documents separats.

Visió general

A BEEP s'utilitzen perfils, canals i un mecanisme d'enquadrament per intercanviar diferents tipus de missatges. Només el tipus de contingut i la codificació són predeterminats per l'especificació, deixant oberta al dissenyador del protocol tota la flexibilitat d'usar un format binari o textual. Els perfils defineixen la funcionalitat del protocol i la sintaxi i la semàntica del missatge. Els canals són canonades full-duplex connectades a un perfil determinat. Els missatges enviats per diferents canals són independents els uns dels altres (asíncrons). Diversos canals poden fer servir el mateix perfil mitjançant una connexió.

BEEP també inclou TLS per a l'⁣encriptació i SASL per a l'autenticació.

Història

El 1998 Marshall T. Rose, que també va treballar en els protocols POP3, SMTP i SNMP,^[1] va dissenyar el protocol BXXP i posteriorment el va lliurar al grup de treball de l'⁣Internet Engineering Task Force (IETF) l'estiu de 2000. L'any 2001 l'⁣IETF va publicar BEEP ( RFC 3080) i BEEP a TCP (RFC 3081) amb algunes millores a BXXP. Els tres més destacats són:

• Utilitzant l'aplicació/octet-stream com a "Tipus de contingut" per defecte.
• Admet la resposta múltiple per als missatges.
• Canviant el nom de BXXP a BEEP

Sessió BEEP

Per iniciar una sessió de BEEP, un parell iniciador es connecta amb l'igual que escolta. Els dos companys estan enviant una resposta positiva que conté un element de salutació de manera immediata i simultània. La salutació conté fins a tres elements diferents:

• features fitxes de funció de perfil de gestió de canals opcionals admeses pel parell.
• localize les etiquetes d'idioma preferit opcionals per als informes i els missatges.
• localize perfils suportats pel node.

Exemple de salutació i resposta:

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

Perfils

Els perfils defineixen la sintaxi i la semàntica dels missatges i la funcionalitat del protocol basat en BEEP. Una única sessió BEEP pot proporcionar accés a diversos perfils. Per identificar un perfil se li assigna una cadena única. Aquest identificador de perfil té el format d'un identificador uniforme de recursos (URI) o un nom de recurs uniforme (URN). En el passat, el format URI de l'identificador de perfil provocava confusió, perquè és semblant a una adreça web. Per evitar malentesos, els perfils més nous haurien d'utilitzar el format URN .

Exemple d'identificador de perfil:

urn:ietf:params:xml:ns:geopriv:held:beep	Un BEEP vinculant per al protocol HELD
{{format ref}} http://iana.org/beep/xmlrpc	XML-RPC en BEEP

Missatges i marcs

Els missatges BEEP s'estructuren segons l'estàndard MIME. De vegades hi ha malentesos sobre l'ús de BEEP en els missatges XML, però el canal 0 només utilitza un petit subconjunt d'XML i és transparent per al dissenyador del perfil (usuari de BEEP). Depèn del dissenyador del perfil quin format de contingut del missatge s'utilitza. Pot ser qualsevol format de text com JSON o XML, així com dades binàries. XML s'usa en la gestió de canals i el perfil estàndard TLS definit amb BEEP.

Exemple d'un intercanvi de missatges de tancament de canal amb èxit de RFC3080.

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

Els missatges més grans es divideixen en diverses parts i es distribueixen en una sèrie de trames de seqüència.

Tipus d'intercanvi

BEEP defineix 5 tipus de missatges per permetre la majoria dels patrons de protocols d'aplicació necessaris. Són els següents:

Missatge	MSG	Un missatge d'un parell a un altre que conté un contingut.
Resposta	RPY	Una única resposta a un missatge rebut que conté un contingut (intercanvi d'un a un).
Error	ERR	Una única resposta a un missatge rebut que conté un contingut (intercanvi d'un a un) amb error semàntic.
Resposta	ANS	Una resposta a un missatge rebut que conté un contingut. Pot haver-hi de 0 a n respostes per a un missatge (intercanvi d'un a molts).
Nul	NUL	Una resposta de terminal a un missatge sense contingut per indicar a l'igual que actua com a client el final d'un intercanvi de missatges amb 0 o més respostes.

Alguns dels patrons de protocol d'aplicació més comuns s'implementen de la manera següent:

• Sol·licitud-resposta utilitzant MSG per a la sol·licitud i RPY i ERR per a les respostes
• Sol·licitud única: respostes múltiples amb MSG i una sèrie de respostes ANS acabades amb un marc NUL
• Notificació no reconeguda mitjançant MSG sense cap resposta

Control de flux

BEEP admet trames de seqüència (SEQ) per implementar el control de flux a nivell de canal. Les trames de seqüència es defineixen a [[rfc:793#section-3.3|la secció 3.3 de la RFC 3081]]. El protocol de control de transmissió (TCP) defineix un mecanisme de seqüència a nivell de capa de transport i admet el control de flux relacionat amb la connexió. El control de flux a nivell de canal a BEEP és necessari per garantir que cap canal o missatge gran monopolitzi tota la connexió. En aquest sentit, els marcs de seqüència s'utilitzen per donar suport a la qualitat de servei (QoS) i per evitar la fam i el bloqueig.^[2]

Referències

1. Carolyn Duffy Marsan. «'HTTP on steroids' to ease protocol work». Computer World, 26-06-2000. [Consulta: 31 octubre 2014].
2. Francis Brosnan. «'Understanding SEQ frames: BEEP flow control and bandwidth management», 30-01-2006. [Consulta: 31 octubre 2014].

Enllaços externs

• BEEP - Lloc web oficial