Resumo

  • O RFC 1080 permitia pedir que outro processo Telnet ligasse ou desligasse o controle de fluxo por software, mas apenas depois do acordo DO/WILL.
  • A opção atingia a saída local entre o Telnet do usuário e o terminal conectado; não pausava TCP, a aplicação remota ou a rede inteira, nem confirmava a aplicação pelo driver.
  • O acordo criava um estado inicial conhecido, com fluxo habilitado; a revogação encerrava os comandos e podia devolver o cliente a um padrão definido pela implementação.

A tecla podia desaparecer antes da rede

O teclado do NVT de RFC 854 podia gerar todos os 128 códigos US-ASCII. Um programa remoto podia atribuir função real a Control-S ou Control-Q e esperar recebê-los.

No controle de fluxo por software, o driver local dava outro destino aos mesmos valores. XOFF, normalmente Control-S, suspendia a saída; XON, normalmente Control-Q, retomava. O driver consumia a tecla, que não chegava ao programa.

Essa interceptação ajudava quando a tela ou a pessoa não acompanhava a saída. Em um editor que usava Control-S como comando, ela destruía informação. O conflito estava no lugar de interpretação e em quem podia mudar o modo.

Publicado em novembro de 1988, o RFC 1080 atribuiu o código 33 a TOGGLE-FLOW-CONTROL. A delegação era pequena: pedir uma mudança em um mecanismo do cliente, não assumir o terminal.

O direito de pedir vinha antes do pedido

O RFC 855 separava acordo e subnegociação. Primeiro DO e WILL estabeleciam que a opção podia operar; só depois os parâmetros circulavam.

No desenho normal, o host enviava DO e o Telnet de usuário ligado ao terminal respondia WILL. O host aceitava emitir pedidos; o cliente aceitava alterar seu fluxo local. DONT e WONT recusavam esses papéis, sem afirmar se o controle estava ligado ou desligado por política própria.

Enviar ON ou OFF antes do acordo era proibido. Depois de uma revogação, também. A ordem não carregava consigo a autoridade que a tornava válida.

Embora o protocolo pudesse ser bidirecional, a assimetria fazia sentido. A aplicação remota sabia quando precisava de caracteres literais; o cliente local controlava o caminho físico e lógico até a tela.

O acordo criava um começo verificável

Assim que DO e WILL eram trocados, o emissor de WILL precisava habilitar o controle de fluxo. A opção começava, portanto, em estado conhecido. Não era necessário um ON adicional para definir a primeira posição.

Depois disso, o emissor de DO podia solicitar OFF ou ON. O efeito pretendido ficava entre o processo Telnet do usuário e o terminal. Não alterava a janela TCP, o congestionamento da rota ou a execução do servidor.

O protocolo não fornecia confirmação de cada mudança. Um pacote OFF era evidência de uma solicitação autorizada, não de que o driver a aplicou, a tecla passou ou a tela se comportou como esperado.

Códigos desconhecidos eram ignorados. Isso permitia evolução, mas tornava impossível usar o silêncio como prova de suporte.

Revogar era devolver o padrão ao cliente

Qualquer lado podia terminar a opção com DONT ou WONT. Nenhuma nova subnegociação seria válida até outro acordo.

O estado local podia voltar a um padrão da implementação. A última solicitação não era uma configuração durável. Um sistema que registrasse apenas o último ON ou OFF erraria depois de desconexão, revogação ou reinício.

Essa regra preservava a soberania do ponto de execução. O servidor recebia uma permissão temporária dentro de uma sessão; quando o vínculo terminava, a política local retomava a decisão.

Fluxo de tela não era fluxo de transporte

O RFC 1080 tratava somente da saída do processo Telnet do usuário para o terminal. O sentido de entrada poderia ter regras próprias. Controle por hardware poderia usar sinais dedicados sem sequestrar caracteres.

Também não era controle de congestionamento. TCP podia continuar aceitando bytes, o servidor podia continuar produzindo saída e buffers podiam crescer. Uma tela parada não demonstrava uma rede parada.

É preciso nomear direção e observador: tecla pressionada, XOFF consumido no driver, OFF capturado no enlace e pausa visível são fatos diferentes.

Linemode deixou o fluxo em sua própria máquina de estados

O RFC 1184 transferiu edição de linha e sinais para o cliente. Em redes de alta latência, o usuário ganhava resposta local e enviava linhas completas.

Apesar da proximidade, o documento manteve o fluxo na opção separada TOGGLE-FLOW-CONTROL. Um novo mapa de modos não deveria reescrever um mecanismo existente.

Para investigação, isso exige seguir teclado, driver, cliente Telnet e aplicação. Cada estágio pode consumir ou transformar o caractere; nenhum log isolado prova toda a cadeia.

O RFC 1372 acrescentou uma incerteza sem resposta

O RFC 1372 substituiu o RFC 1080 em 1992. Acrescentou RESTART-XON, retomada apenas com XON, e RESTART-ANY, retomada com qualquer caractere exceto novo XOFF.

O fluxo habilitado continuava conhecido após o acordo, mas a regra de retomada começava em estado dependente do sistema. O servidor precisava pedir a variante desejada.

Um cliente incapaz de oferecer ambas podia ignorar o pedido. O servidor não recebia uma notificação dessa limitação. A mensagem mostrava intenção; não confirmava capacidade local.

Drivers comuns consumiam XON e XOFF. No modo de retomada por qualquer tecla, o caractere que reabria a saída ainda podia seguir para a aplicação. Retomar e entregar não eram o mesmo evento.

Porta serial e sessão eram outros objetos

O RFC 2217 definiu depois ajustes de fluxo para portas seriais e FLOWCONTROL-SUSPEND/RESUME para suspender dados e comandos da sessão Telnet.

Configurar o dispositivo, parar a sessão e interceptar XON/XOFF localmente são superfícies distintas. O nome “flow control” não autoriza trocar as evidências.

O registro IANA de opções Telnet mantém Remote Flow Control no código 33 e aponta para o RFC 1372. É continuidade de coordenação, não prova de uso atual.

Cinco estados que um painel não deve fundir

O registro correto separa: consentimento da sessão; pedido enviado; estado aplicado pelo cliente; destino do caractere; resultado observado na tela e no aplicativo.

O RFC 1080 padronizou os dois primeiros e o estado inicial. As demais camadas exigiam observação local ou ponta a ponta.

Sua lição não é a conquista remota de um terminal. É a utilidade de uma delegação limitada, recusável e revogável. Control-S só era comando enquanto o acordo e o mecanismo local sustentavam esse significado.

Fontes e limites

RFC 854 fornece o NVT; RFC 855, a gramática de acordo; RFC 1080, a opção original; RFC 1184, Linemode; RFC 1372, as regras de retomada; RFC 2217, o controle serial e de sessão; IANA, o registro. Eles não provam adoção atual, identidade, autorização geral, estado aplicado, incidente real ou resultado do usuário.