Resumo

  • Jon Postel e Joyce Reynolds definiram na RFC 860, de maio de 1983, a opção 6 do TELNET, TIMING-MARK. Um lado pede DO TIMING-MARK; o outro pode devolver WILL TIMING-MARK no lugar apropriado do fluxo, depois de atravessar suas filas de saída e entrada.
  • Se uma ordem estivesse errada e o usuário já tivesse digitado mais, o servidor podia descartar a entrada adiantada até a volta da marca. Dali em diante, voltava a interpretar os caracteres escritos depois que a pessoa viu o sinal de erro. O lado que pediu a marca decidia o descarte.

O usuário digita um comando, acha que está tudo certo e emenda outro. O servidor enfim responde ao primeiro com um ponto de interrogação. O segundo já pode estar no computador do usuário, na rede ou na fila de entrada do servidor. Se todos esses caracteres virarem novas instruções, um erro pequeno ganha uma escolta de outros comandos que ninguém quis enviar depois de saber do problema. A pergunta da RFC 860 era: em qual caractere a conversa recomeça?

O TELNET básico oferecia comunicação nos dois sentidos. As regras de opções permitiam solicitar e recusar comportamentos adicionais. TIMING-MARK aplicava essa gramática a uma dificuldade muito cotidiana: o ser humano vê a tela em um ritmo, enquanto as filas de dois computadores andam em outro. A palavra “timing” evoca relógio; aqui o dado valioso era uma posição dentro do fluxo.

O servidor manda IAC DO TIMING-MARK. Se o outro lado aceitar, ele insere IAC WILL TIMING-MARK no ponto correto da resposta. A descrição da RFC acompanha a marca pela fila de saída do lado remoto, até o terminal, e de volta pela fila de entrada. Quando o WILL retorna, o servidor encontra uma fronteira reconhecível nesse percurso. Tudo o que o usuário escreveu depois de ver o ponto de interrogação fica do lado novo dessa fronteira.

O roteiro do erro é deliberado. Primeiro o servidor envia retorno de carro, mudança de linha e o ponto de interrogação. Depois envia o pedido de marca e a mensagem de erro. Continua lendo caracteres, mas os põe fora até receber o WILL. A partir daí, volta a tratar a entrada como comando. O ponto procurado fica imediatamente antes da primeira tecla apertada após o aviso aparecer na tela. O servidor deixa de adivinhar a reação humana pelo tamanho de sua própria fila.

A lixeira pertence a quem fez o pedido. A RFC 860 atribui o descarte dos caracteres indesejados ao emissor do DO; o outro lado fornece o marco. Essa divisão permite usar a opção ao contrário. Um terminal inundado por saída velha do servidor pode pedir uma marca, deixar de mostrar essa saída até o retorno do WILL e então voltar a exibir o que foi produzido depois de um comando novo. A direção muda; a responsabilidade continua com o solicitante.

As respostas carregam pesos diferentes. WILL garante a colocação da marca no ponto combinado. WON'T recusa essa garantia e ainda confirma que os dados anteriores foram recebidos. DON'T avisa que um WILL anterior foi ignorado. Por padrão, a conexão não tenta sincronização explícita. A RFC também menciona medir o atraso de ida e volta: conhecer um ponto de retorno ajuda a observar o tempo gasto. A marca que viaja na conversa continua sendo uma fronteira de ordem.

Postel e Reynolds chegaram a imaginar o usuário que percebe o erro antes da resposta e resolve não esperar. Seu terminal pode mandar WILL no ponto escolhido por ele e começar outra vez a digitar; quando o pedido DO chegar mais tarde, o software terá de acertar as contas com ele. O detalhe parece pequeno, mas revela o cuidado com o que o usuário efetivamente viu. A fronteira da correção nasce na conversa inteira, não apenas no relógio do servidor.

Um ponto de interrogação na tela parecia assunto banal. Entre duas máquinas com buffers, ele criava uma pergunta operacional difícil: quais teclas já pertenciam ao passado? TIMING-MARK devolveu ao servidor um lugar para pôr a linha divisória. O teclado pôde continuar tagarelando; a máquina passou a saber de onde vale a pena escutar.