Resumo

  • Na RFC 794, o processo que atendia um terminal podia manter um LISTEN TCP à espera de novas conexões mesmo ocupado, para decidir se uma chegada de maior precedência tiraria outra da sala.
  • O exemplo de FTP com prioridade «flash-override» exige ação dos dois lados: o serviço receptor cuida da sessão interrompida; o computador que inicia o pedido precisa primeiro ter recursos para fazê-lo.

O arquivo estava a caminho do Host X para o Y. Então o Z bateu à porta de X com um FTP de precedência «flash-override». O SYN chegava à porta certa, mas o trabalho antigo não desapareceria por respeito ao visitante. Vint Cerf usou esse pequeno tumulto em sua RFC 794, de setembro de 1981, para mostrar onde uma política de prioridade encontra uma tarefa concreta e uma conta a pagar.

Antes de abrir a porta do servidor, ele apresentou outras formas de lotação. Um circuito telefônico reservado mantinha a capacidade ocupada mesmo em silêncio; uma chamada muito prioritária podia cortar outra. Num sistema de mensagens armazenadas, a urgência mudava a ordem da fila e até interrompia uma impressão. Numa rede de pacotes saturada, o congestionamento surgia na entrada, onde se escolhia o tráfego a aceitar. Em cada caso, precedência distribuía algo escasso. A semelhança acabava aí: linha, processador e capacidade de entrada não são a mesma cadeira.

Para o terminal de AUTODIN II, Cerf propôs que o processo responsável pelo acesso, o THP, deixasse um LISTEN TCP aberto enquanto atendia uma ou mais conexões. Assim, uma nova chamada chegava com sua precedência visível ao processo. O THP poderia comparar as prioridades, fechar ou abortar a conexão de menor prioridade, transferir o usuário para a nova e publicar outro LISTEN. A chegada urgente conseguia ser ouvida antes que alguém tivesse de sair.

TCP precisava expor a precedência da conexão entrante ao programa que o utilizava. A escolha de quem perderia a sessão ficava com esse programa. TCP normalmente serve processos e não cria, por si só, um atendente para cada pedido. Se o terminal estivesse desligado, criar um processo para atendê-lo seria um requinte inútil. O THP conhecia as conexões abertas, o usuário e os limites de segurança para mantê-las simultaneamente. A regra de prioridade precisava desse conhecimento para funcionar.

O caso FTP tornava a arquitetura menos abstrata. O servidor de X poderia manter uma escuta extra mesmo durante a transferência normal com Y. Com o pedido de Z, FTP decidiria se precisava expulsar um usuário de precedência inferior e iniciaria a arrumação do trabalho interrompido. Se um processo não mantém um LISTEN enquanto está ocupado, essa estratégia não consegue preemptá-lo. Cartão de prioridade nenhum faz campainha aparecer numa porta sem campainha.

Há também o lado de quem chama. Se o próprio Z já tiver esgotado seus recursos de FTP ou TCP, o usuário urgente não consegue sequer criar o processo que fará o pedido. Cerf imaginou o sistema operacional liberando recursos locais, talvez encerrando a sessão de alguém menos prioritário. A precedência podia estar ligada ao usuário ou ao terminal; o sistema operacional ou a implementação TCP poderiam executar diferentes escolhas locais. O servidor de X não teria como limpar a mesa de Z.

Em duas páginas, Cerf tirou a prioridade do palanque. O pedido precisa achar uma escuta, o serviço precisa reconhecer a sua classe, a conexão que cede precisa de encerramento e a origem precisa ser capaz de começar. A palavra «urgente» cabia no pedido. A interrupção acontecia nas mãos do software que sabia o que estava interrompendo.