BIP - BEEP
O protocolo de troca extensível de blocos ( BEEP ) é uma estrutura para a criação de protocolos de aplicativos de rede. O BEEP inclui blocos de construção como enquadramento, pipelining , multiplexação, relatórios e autenticação para conexão e protocolos ponto a ponto orientados por mensagem (P2P) com suporte de comunicação full-duplex assíncrona .
A sintaxe e a semântica da mensagem são definidas com perfis BEEP associados a um ou mais canais BEEP, em que cada canal é um pipe full-duplex . Um mecanismo de enquadramento permite a comunicação simultânea e independente entre pares.
O BEEP é definido no RFC 3080 independentemente do mecanismo de transporte subjacente. O mapeamento do BEEP em um serviço de transporte específico é definido em uma série separada de documentos.
Visão geral
Perfis, canais e um mecanismo de enquadramento são usados no BEEP para trocar diferentes tipos de mensagens. Apenas o tipo de conteúdo e a codificação são padronizados pela especificação, deixando a flexibilidade total de usar um formato binário ou textual aberto ao designer de protocolo. Os perfis definem a funcionalidade do protocolo e a sintaxe e semântica da mensagem. Os canais são tubos full-duplex conectados a um perfil específico. As mensagens enviadas por diferentes canais são independentes umas das outras (assíncronas). Vários canais podem usar o mesmo perfil por meio de uma conexão.
O BEEP também inclui TLS para criptografia e SASL para autenticação .
História
Em 1998, Marshall T. Rose , que também trabalhou nos protocolos POP3 , SMTP e SNMP , projetou o protocolo BXXP e posteriormente o entregou ao grupo de trabalho da Força-Tarefa de Engenharia da Internet ( IETF ) no verão de 2000. Em 2001, a IETF publicou o BEEP ( RFC 3080 ) e BEEP no TCP ( RFC 3081 ) com alguns aprimoramentos para BXXP. Os três mais notáveis são:
- Usando application / octet-stream como "Content-Type" padrão.
- Suporta múltiplas respostas para mensagens.
- Alterando o nome de BXXP para BEEP
Sessão BEEP
Para iniciar uma sessão BEEP, um par de iniciação se conecta ao par de escuta. Ambos os pares estão enviando uma resposta positiva contendo um elemento de saudação imediatamente e simultaneamente. A saudação contém até três elementos diferentes:
- apresenta tokens de recurso de perfil de gerenciamento de canal opcionais suportados pelo par.
- localize tags de idioma preferencial opcionais para relatórios e mensagens.
- perfis de perfil suportados pelo par.
Exemplo de saudação e 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
Perfis
Os perfis definem a sintaxe e a semântica das mensagens e a funcionalidade do protocolo com base no BEEP. Uma única sessão BEEP pode fornecer acesso a vários perfis. Para identificar um perfil, uma string exclusiva é atribuída a ele. Este identificador de perfil tem o formato de um Uniform Resource Identifier ( URI ) ou Uniform Resource Name ( URN ). No passado, o formato URI do identificador de perfil gerava confusão, porque é semelhante a um endereço da web. Para evitar mal-entendidos, os perfis mais recentes devem usar o formato URN .
Identificador de perfil de exemplo:
urn:ietf:params:xml:ns:geopriv:held:beep
|
Uma ligação BEEP para o protocolo HELD |
http://iana.org/beep/xmlrpc
|
RFC 3529 XML-RPC em BEEP |
Mensagens e Molduras
As mensagens BEEP são estruturadas de acordo com o padrão MIME . Às vezes, há mal-entendidos sobre o BEEP usando XML em mensagens, mas apenas um pequeno subconjunto de XML é usado pelo canal 0 e é transparente para o designer de perfil (usuário do BEEP). Cabe ao designer de perfil qual formato de conteúdo de mensagem é usado. Pode ser qualquer formato textual como JSON ou XML , bem como dados binários. XML é usado no gerenciamento de canal e no perfil padrão TLS definido com BEEP.
Exemplo de uma troca de mensagens de fechamento de canal bem-sucedida 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
Mensagens maiores são divididas em várias partes e distribuídas em vários quadros de sequência.
Tipos de troca
O BEEP define 5 tipos de mensagem para permitir a maioria dos padrões de protocolos de aplicativos necessários. Eles são os seguintes:
Mensagem | MSG | Uma mensagem de um par para outro contendo um conteúdo. |
Responder | RPY | Uma única resposta a uma mensagem recebida contendo um conteúdo (troca um para um). |
Erro | ERRAR | Uma única resposta a uma mensagem recebida contendo um conteúdo (troca um para um) com semântica de erro. |
Responder | ANS | Uma resposta a uma mensagem recebida contendo um conteúdo. Pode haver 0 an respostas para uma mensagem (troca um para muitos). |
Nul | NUL | Um terminal responde a uma mensagem sem um conteúdo para sinalizar para o par que está agindo atualmente como o cliente o fim de uma troca de mensagens com 0 ou mais respostas. |
Alguns dos padrões de protocolo de aplicativo mais comuns são implementados da seguinte forma:
- Solicitação-resposta usando MSG para solicitação e RPY e ERR para respostas
- Solicitação única - várias respostas usando MSG e uma série de respostas ANS terminadas por um quadro NUL
- Notificação não reconhecida usando MSG sem qualquer resposta
Controle de fluxo
O BEEP oferece suporte a quadros de sequência (SEQ) para implementar o controle de fluxo no nível do canal. Os quadros de sequência são definidos na RFC 3081 seção 3.3 . O Transmission Control Protocol ( TCP ) define um mecanismo de sequência no nível da camada de transporte e oferece suporte ao controle de fluxo relacionado à conexão. O controle de fluxo no nível do canal no BEEP é necessário para garantir que nenhum canal ou grande mensagem monopolize toda a conexão. Para tanto, os quadros de sequência são usados para dar suporte à qualidade de serviço (QoS) e para evitar privação e deadlock.
links externos
- BEEPcore.org Site oficial
- RFC 3080 : The Blocks Extensible Exchange Protocol Core
- RFC 3081 : Mapeando o BEEP Core para TCP
- RFC 3117 : No projeto de protocolos de aplicativos , considerações de projeto do protocolo BXXP contadas por seus criadores
- RFC 3195 : Entrega confiável para syslog - Perfil BEEP
- RFC 3529 : Perfil XML-RPC para BEEP
- RFC 4227 : Usando SOAP no BEEP
- RFC 3620 : O Perfil TUNNEL
- iana.org/assignments/beep-parameters Registro de perfis BEEP de faixa padrão
- Introdução ao BEEP em IBM.com