Hispanopedia Wiki
El protocolo de intercambio extensible por bloques ( BEEP ) es un marco de trabajo para la creación de protocolos de aplicaciones de red. BEEP incluye bloques de construcción como tramas, segmentación , multiplexación, informes y autenticación para protocolos peer-to-peer (P2P) orientados a la conexión y a los mensajes, con soporte para comunicación asíncrona full-duplex .
La sintaxis y la semántica de los mensajes se definen mediante perfiles BEEP asociados a uno o más canales BEEP, donde cada canal es una tubería dúplex completa . Un mecanismo de trama permite la comunicación simultánea e independiente entre pares.
BEEP se define en la RFC 3080 independientemente del mecanismo de transporte subyacente. La asignación de BEEP a un servicio de transporte específico se define en una serie de documentos aparte.
Descripción general
En BEEP se utilizan perfiles, canales y un mecanismo de tramas para intercambiar distintos tipos de mensajes. La especificación solo define por defecto el tipo de contenido y la codificación, dejando al diseñador del protocolo total flexibilidad para usar un formato binario o textual. Los perfiles definen la funcionalidad del protocolo, así como la sintaxis y la semántica de los mensajes. Los canales son tuberías dúplex completas conectadas a un perfil específico. Los mensajes enviados a través de diferentes canales son independientes entre sí (asíncronos). Varios canales pueden usar el mismo perfil a través de una sola conexión.
BEEP también incluye TLS para el cifrado y SASL para la autenticación .
Historia
En 1998, Marshall T. Rose , quien también trabajó en los protocolos POP3 , SMTP y SNMP , [ 1 ] diseñó el protocolo BXXP y posteriormente lo entregó al grupo de trabajo del Grupo de Trabajo de Ingeniería de Internet ( IETF ) en el verano de 2000. En 2001, el IETF publicó BEEP ( RFC 3080 ) y BEEP sobre TCP ( RFC 3081 ) con algunas mejoras a BXXP. Las tres más notables son:
- Utilizar application/octet-stream como "Content-Type" predeterminado.
- Admite múltiples respuestas para los mensajes.
- Cambiar el nombre de BXXP a BEEP
Sesión BEEP
Para iniciar una sesión BEEP, un par iniciador se conecta con el par receptor. Cada par envía una respuesta que contiene un elemento de saludo. El saludo contiene hasta tres elementos diferentes:
- Características : tokens de función de perfil de gestión de canal opcionales compatibles con el par.
- localize : etiquetas de idioma preferidas opcionales para informes y mensajes.
- perfil : perfiles respaldados por el par.
Ejemplo de saludo y respuesta:
L: <esperar conexión entrante > I : <abrir conexión > L: RPY 0 0 . 0 110 L: Content-Type: application/beep+xml L: L: <saludo> L: <perfil uri= 'http://iana.org/beep/TLS' /> L: </saludo> L: FIN Yo: RPY 0 0 . 0 52 I: Content-Type: application/beep+xml Yo: Yo: <saludo /> Yo: FIN Perfiles
Los perfiles definen la sintaxis y la semántica de los mensajes, así como la funcionalidad del protocolo BEEP. Una única sesión BEEP permite el acceso a varios perfiles. Para identificar un perfil, se le asigna una cadena única. Este identificador de perfil tiene el formato de un Identificador Uniforme de Recursos ( URI ) o un Nombre Uniforme de Recursos ( URN ). Anteriormente, el formato URI del identificador de perfil generaba confusión, ya que era similar a una dirección web. Para evitar malentendidos, los perfiles más recientes deberían utilizar el formato URN .
Ejemplo de identificador de perfil:
Mensajes y marcos
Los mensajes BEEP se estructuran según el estándar MIME . A veces surgen malentendidos sobre el uso de XML en los mensajes BEEP, pero el canal 0 solo utiliza un subconjunto reducido de XML, lo cual es transparente para el diseñador del perfil (usuario BEEP). El diseñador del perfil decide qué formato de contenido de mensaje se utiliza. Este puede ser cualquier formato de texto, como JSON o XML , así como datos binarios. XML se utiliza en la gestión del canal y en el perfil estándar TLS definido con BEEP.
Ejemplo de un intercambio exitoso de mensajes de cierre de canal según RFC3080.
C: MSG 0 2 . 235 71 C: Content-Type: application/beep+xml C: C: <close number= '1' code= '200' /> C: FIN S: RPY 0 2 . 392 46 S: Content-Type: application/beep+xml S: S: <ok /> S: FIN Los mensajes más largos se dividen en varias partes y se distribuyen a lo largo de varios fotogramas de la secuencia.
Tipos de intercambio
BEEP define 5 tipos de mensajes para permitir la mayoría de los patrones de protocolo de aplicación necesarios:
Algunos de los patrones de protocolo de aplicación más comunes se implementan de la siguiente manera:
- Sistema de solicitud-respuesta que utiliza MSG para la solicitud y RPY y ERR para las respuestas.
- Solicitud única con múltiples respuestas mediante MSG y una serie de respuestas ANS que finalizan con una trama NUL.
- Notificación no confirmada mediante MSG sin respuesta.
Control de flujo
BEEP admite tramas de secuencia (SEQ) para implementar el control de flujo a nivel de canal. Las tramas de secuencia se definen en la sección 3.3 de la RFC 3081. El Protocolo de Control de Transmisión ( TCP ) define un mecanismo de secuencia en la capa de transporte y admite el control de flujo relacionado con la conexión. BEEP necesita control de flujo a nivel de canal para asegurar que ningún canal o mensaje grande monopolice la conexión. Para ello, se utilizan tramas de secuencia para admitir la calidad de servicio (QoS) y evitar la inanición y el interbloqueo. [ 2 ]
Referencias
- ↑ Carolyn Duffy Marsan (26-06-2000) ."HTTP potenciado" para facilitar el trabajo con protocolos . Computer World . Consultado el 31 de octubre de 2014 .
- ↑ Francis Brosnan (30-01-2006) .'Comprensión de las tramas SEQ: control de flujo BEEP y gestión del ancho de banda' . Consultado el 31 de octubre de 2014 .
Enlaces externos
- Sitio web oficial de BEEPcore.org
- RFC 3080 : El núcleo del protocolo de intercambio extensible de bloques
- RFC 3081 : Mapeo del núcleo BEEP a TCP
- RFC 3117 : Sobre el diseño de protocolos de aplicación , consideraciones de diseño del protocolo BXXP según sus creadores.
- RFC 3195 : Entrega confiable para syslog - Perfil BEEP
- RFC 3529 : Perfil XML-RPC para BEEP
- RFC 4227 : Uso de SOAP en BEEP
- RFC 3620 : El perfil TUNNEL
- iana.org/assignments/beep-parameters Registro de perfiles BEEP de pista estándar
- Introducción a BEEP en IBM.com