Resumo

  • A RFC 3081 mapeou uma sessão BEEP para uma conexão TCP, mas não tratou o controle de fluxo da conexão como garantia de progresso para cada canal multiplexado.
  • Todo canal começava com 4096 octetos de crédito. Quadros SEQ atualizavam o limite local com prioridade, e o serviço round-robin reduzia o risco de um canal ocupado tomar todos os turnos.

Entrega correta não era serviço justo

Quatro canais usam o mesmo TCP. Três aplicações leem depressa. A quarta lê devagar e seu emissor possui uma resposta enorme. TCP pode ordenar octetos, recuperar perdas e manter a conexão saudável. Ainda assim, os três trabalhos curtos podem ficar atrás do quarto.

Não há falha de confiabilidade. Há disputa por admissão e serviço dentro de um transportador confiável.

Publicada em março de 2001 na trilha de padrões, a RFC 3081 definiu o mapeamento de BEEP sobre TCP. Uma sessão ocupava uma conexão estabelecida, e os quadros BEEP viravam octetos desse fluxo. A simplicidade não escondia o custo do compartilhamento: o documento apontava fome e deadlock quando vários canais lógicos dependiam apenas do controle de fluxo único de TCP.

TCP mantinha uma conta para a conexão

TCP não reconhece que certos octetos são controle de sessão, outros uma consulta pequena e outros uma resposta em massa. Esses limites pertencem a BEEP. Por isso, a RFC 3081 deu uma janela deslizante independente a cada canal.

Ao nascer, o canal podia enviar 4096 octetos de payload. O receptor transmitia depois um quadro SEQ com o próximo número de sequência esperado e o tamanho da janela aceita. Os dois valores estabeleciam o teto local. Ao alcançá-lo, o emissor parava aquele canal, mesmo que o buffer TCP continuasse recebendo escritas.

Não era outra retransmissão. TCP já cuidava de ordem e recuperação. A janela BEEP respondia a uma pergunta diferente: quanto material adicional esta conversa pode introduzir no recurso compartilhado?

Como os contadores dão a volta, a comparação precisava permanecer inequívoca. A RFC 3081 recorreu à aritmética serial da RFC 1982 e limitou o tamanho das janelas. Assim, uma posição antiga não reapareceria depois da volta como nova autorização.

A mensagem que abria espaço precisava escapar

Crédito só funciona quando chega ao emissor. Se SEQ ficar atrás do payload que pretende liberar, a realimentação pode parar. A especificação deu a esse quadro prioridade sobre o tráfego comum.

Não era uma declaração de que controle valia mais do que conteúdo. Era uma ordem causal: o receptor precisava informar espaço antes que o emissor pudesse admitir mais dados naquele canal. Sem saída protegida, o próprio controle de fluxo produziria o bloqueio.

Para canais com a mesma prioridade, a RFC recomendou round-robin. A regra não prometia latência idêntica nem justiça matemática através de todos os buffers do sistema. Ela fixava o mínimo: um canal permanentemente cheio não deveria ser drenado sem fim enquanto vizinhos prontos jamais recebiam um turno.

O leitor lento permanecia acima do protocolo

Chegada em TCP, aceitação na janela BEEP, entrega à aplicação e efeito externo eram quatro recibos. A RFC 1122 já descrevia TCP como fluxo confiável, não como conclusão de transação; a RFC 9293 preserva essa fronteira.

Perfis posteriores mostram por que isso importava. A RFC 3195 colocou syslog confiável em BEEP, e a RFC 4744 transportou NETCONF. Avanço de sequência não provava armazenamento do log; crédito novo não provava aplicação de configuração. Só a aplicação dona da semântica podia verificar o efeito.

A janela era autorização limitada

O receptor controlava a capacidade anunciada porque pagava por memória e entrega. O emissor escolhia entre canais elegíveis, respeitando crédito e prioridade. TCP controlava confiabilidade e congestionamento da conexão. A aplicação decidia quando o trabalho tinha valor.

Esses poderes eram adjacentes, não substitutos. Espaço em TCP não era permissão BEEP. Recepção BEEP não era conclusão da aplicação. Um turno oferecido não era efeito comprovado.

A contribuição durável da RFC 3081 está aí. Dar nomes a vias não cria independência. São necessários orçamentos separados, retorno que não fique enterrado pelo tráfego governado e serviço observável para impedir que um usuário legítimo vire silenciosamente dono de toda a infraestrutura comum.

Fontes

  1. https://www.rfc-editor.org/info/rfc3081
  2. https://www.rfc-editor.org/rfc/rfc3081.html
  3. https://datatracker.ietf.org/doc/rfc3081/
  4. https://www.rfc-editor.org/rfc/rfc3080.html
  5. https://www.rfc-editor.org/rfc/rfc1982.html
  6. https://www.rfc-editor.org/rfc/rfc1122.html
  7. https://www.rfc-editor.org/rfc/rfc9293.html
  8. https://www.rfc-editor.org/rfc/rfc3195.html
  9. https://www.rfc-editor.org/rfc/rfc4744.html
  10. https://heng.lu/running-code-primary-the-patch-needed-to-preserve-the-internet-original-design/
  11. https://heng.lu/minimum-initial-specification-localized-future-decision-voluntary-adoption-internet-coordination-system/
  12. https://heng.lu/on-reality-layers-symbolic-power-and-why-clarity-feels-so-hostile/