Resumo

  • A RFC 1116 levou a edição de linha e parte do tratamento de sinais para o cliente. Assim, reduziu o tráfego de pacotes por tecla e ofereceu resposta local em redes demoradas ou cobradas por pacote.
  • O acordo DO/WILL, o MODE_ACK e o SLC_ACK encerravam negociações diferentes de configuração. Nenhum deles confirmava que uma linha chegara ao aplicativo, fora autorizada, executada ou produzira resultado.
  • Com EDIT ativo, o cliente guardava um buffer editável até um terminador ou outra condição de encaminhamento. Depois do envio, aquele prefixo já não podia ser corrigido localmente, mas ainda precisava atravessar transporte, interpretação Telnet e decisões do processo remoto.

A sensação de rapidez foi produzida deste lado

A RFC 1116 descreveu a distância em termos bem concretos. No Telnet caractere a caractere, uma única tecla podia gerar um par de pacotes. Com edição local, a ambição do Linemode era gastar algo parecido por linha de comando. Em um enlace de alta latência, o usuário via letras, apagamentos e correções imediatamente; a espera da rede ficava concentrada no momento de enviar a linha. Em redes tarifadas por pacote havia ainda uma economia direta, e o processamento na ponta evitava que computadores remotos caros fossem interrompidos a cada caractere.

Não se tratava apenas de agrupar bytes. A responsabilidade mudava de lugar. O terminal do cliente podia apagar um caractere ou uma linha, reconhecer certos sinais e montar uma unidade coerente antes que o servidor observasse essa unidade. A interface parecia mais viva justamente porque aquilo que o usuário via deixava de ser uma observação contínua do processo remoto.

O registro da RFC 1116 no RFC Editor conserva a proposta de agosto de 1989 e informa que ela foi substituída. O Datatracker do IETF preserva o histórico documental. Em outubro de 1990, a RFC 1184 substituiu o texto anterior, ampliou os bits de modo e os caracteres de edição visual, mas manteve o desenho básico de edição no cliente. É a essa sequência histórica que a análise se refere, não a uma afirmação sobre o uso atual do protocolo.

Autorizar a conversa não escolhia o modo

Linemode recebeu a opção Telnet 34. A gramática geral de opções da RFC 855 separava duas decisões. Primeiro, DO e WILL permitiam que os dois lados negociassem uma opção. Só então a subnegociação podia definir seus parâmetros. DONT ou WONT revogavam a permissão.

Na RFC 1116, o estado inicial era WONT LINEMODE e DONT LINEMODE. Portanto, uma conexão TCP, uma saudação Telnet ou a simples presença do número 34 em um registro não demonstravam edição local ativa. Até um par DO/WILL bem-sucedido dizia apenas que os participantes aceitavam discutir o estado de edição e de sinais.

MODE vinha depois. Normalmente, o servidor propunha uma máscara e o cliente a confirmava. EDIT indicava onde a edição de linha ocorreria; TRAPSIG indicava onde seriam interpretados caracteres ligados a interrupção, break, abort, fim de arquivo ou suspensão. MODE_ACK fechava o acordo entre os dois processos Telnet sobre aquela máscara. Não falava da próxima linha do usuário nem podia atestar a atividade do aplicativo ligado ao servidor.

Por isso, registros como “Linemode aceito”, “EDIT ativo” e “comando remoto concluído” não são versões progressivamente mais detalhadas do mesmo fato. Cada um pertence a uma autoridade e a uma máquina de estados diferente.

Uma linha completa continuava sendo um objeto local

Com EDIT ativo, o cliente processava a entrada e enviava linhas completas. A RFC 1184 descreveu a fronteira habitual: depois da edição local, CR LF ou outro caractere especial liberava os dados editados. Até esse instante, o usuário ainda podia alterar o buffer sem pedir ao host remoto que desfizesse coisa alguma.

FORWARDMASK tornava essa fronteira menos simples. O servidor podia pedir que o cliente soltasse a entrada acumulada ao encontrar determinados caracteres ASCII. SLC_FORW1 e SLC_FORW2 acrescentavam outros dois caracteres de encaminhamento. Se o driver de terminal não conseguisse expressar exatamente o conjunto pedido, o cliente podia aceitar um conjunto mais amplo de caracteres de controle e encaminhar ao encontrar qualquer um deles.

Havia, assim, discricionariedade local dentro de um acordo. O fim da linha não era a única fronteira, e a máscara solicitada pelo servidor nem sempre revelava todos os pontos efetivos de liberação do cliente. A RFC 1184 registrou a consequência irreversível: uma vez encaminhada, a parte já enviada não podia mais ser editada.

Irreversível no cliente não queria dizer eficaz no destino. Os bytes ainda precisavam sair, atravessar TCP, chegar ao receptor Telnet, sobreviver à separação entre dados e controles, entrar no processo anexado, atender à sua sintaxe e à sua política e, por fim, gerar saída. O editor local não tinha autoridade sobre nenhuma dessas observações posteriores.

Confirmar o mapa de caracteres não confirmava o efeito

A subopção Set Local Characters, ou SLC, negociava trincas: uma função, modificadores e o caractere ASCII associado. O nível declarava se a função não era suportada, era suportada mas imutável, tinha valor explícito ou usava o padrão. SLC_ACK indicava que o receptor concordava com a configuração.

Esse ACK era tentadoramente fácil de ampliar. Ele resolvia uma divergência sobre qual caractere local representava uma função. Não dizia que o usuário o pressionara. Se o pressionasse, não provava que o comando Telnet correspondente chegara. Se chegasse, ainda não demonstrava que o sistema anexado apoiava ou concluíra a ação.

A RFC 1184 expôs o limite com clareza. ABORT e IP podiam ter o mesmo efeito em um sistema com um único mecanismo de interrupção. Funções não suportadas de ABORT, EOF ou SUSP podiam ser ignoradas. SLC_FLUSHIN e SLC_FLUSHOUT eram recomendações, e a interface podia sobrepor o comportamento sugerido de descarte. O nome de um sinal descrevia uma solicitação no contexto do protocolo; não constituía prova durável de que um processo parou ou de que dados desapareceram.

Eco e controle de fluxo conservaram autoridades próprias

A RFC 857 ajuda a entender por que ver um caractere na tela oferece pouca evidência sobre o outro lado. A opção Echo coordena se um participante ecoa em nome do outro; ela não decide se um sistema ecoa para si mesmo. O Linemode podia, portanto, oferecer resposta visual imediata enquanto o caminho da rede ainda não produzira retorno algum.

O controle de fluxo parecia vizinho, mas continuava separado. A RFC 1116 e a RFC 1184 não colocaram FLOW na máscara Linemode. Remeteram ao Telnet Remote Flow Control da RFC 1080, que permitia negociar o consumo local de XON/XOFF na saída do terminal. Isso não era edição do teclado, suspensão do aplicativo, controle de fluxo do TCP nem controle de congestionamento.

Essa modularidade impedia que um único bit conveniente reivindicasse o estado inteiro do terminal. Local de edição, local de eco, mapa de caracteres especiais, consumo do fluxo de saída e comportamento do processo remoto tinham donos diferentes.

O reconhecimento que faltava só podia vir do aplicativo

O registro de opções Telnet da IANA ainda reserva 34 para Linemode e aponta para a RFC 1184. A linha de registro ensina ao interpretador o nome de um número. Não mostra que uma sessão atual negociou a opção, que uma implementação está em conformidade ou que algum comando foi executado.

A RFC 854 fornece a base do terminal virtual de rede e dos comandos de controle Telnet. Ela pode transportar dados e sinais ao processo Telnet remoto. Linemode pode tornar o cliente eficiente e fazer estados de configuração convergirem. Nenhuma das duas especificações transforma evidência de transporte em evidência de aplicação.

Um registro defensável precisa, portanto, conservar as etapas: buffer concluído no cliente; prefixo encaminhado; bytes aceitos localmente pelo TCP; dados interpretados pelo Telnet do servidor; linha entregue ao processo remoto; política aplicada; execução iniciada; execução encerrada; saída retornada; saída associada pelo usuário à linha certa. Cada frase exige sua própria observação.

A lição não é que interfaces locais sejam enganosas. O Linemode funcionava porque tornava imediato um fato local útil. O erro começa quando uma instituição arquiva esse fato sob um nome que promete resultado remoto.

Fontes