Resumo

  • Em abril de 1983, Andrew G. Malis descreveu no RFC 852 uma opção para computadores ligados a IMPs C/30: se faltassem recursos para processar a mensagem, o IMP a recusaria em até dois segundos e devolveria uma resposta Tipo 9 com a causa. A prática comum podia bloquear todos os novos envios do computador por até quinze segundos.
  • A redução da espera mudava a fila. Uma mensagem posterior podia ser aceita antes que o computador soubesse da rejeição da anterior. Para mesma prioridade, origem e destino, a ARPANET preservava a entrega na ordem de aceitação; a aplicação que exigisse a ordem de envio precisava administrar essa diferença ou ficar com o prazo antigo.

Um atendente recebe uma pasta difícil e fecha o balcão inteiro enquanto procura uma assinatura. Atrás dela está alguém com uma pergunta simples, que poderia ser respondida na hora. Também espera. Era assim que o IMP, o Interface Message Processor da ARPANET, podia tratar um computador de origem. Depois de receber uma mensagem, precisava reunir recursos específicos para processá-la. Quando isso demorava, deixava de aceitar qualquer outra mensagem daquele computador. O destino, o tamanho e o tipo mudavam os recursos necessários. O balcão ignorava essas diferenças e fazia todos pagarem pelo caso mais complicado.

O bloqueio podia chegar a quinze segundos. O RFC 852 oferecia uma escolha: submeter uma mensagem com prazo curto. Se o IMP continuasse sem recursos após no máximo dois segundos, rejeitaria aquela mensagem, enviaria uma resposta de Transmissão Incompleta, Tipo 9, com a causa, e continuaria tentando reunir os recursos. O computador ganhava tempo para apresentar outras mensagens e reoferecer a recusada depois. Um “não agora” rápido liberava o balcão; a entrega da primeira pasta continuava sendo trabalho pendente.

Malis encaixou a escolha nos subtipos. Uma mensagem regular Tipo 0, subtipo 0, mantinha os controles habituais e podia bloquear até quinze segundos. O subtipo 1 conservava os mesmos controles, mas encerrava a espera em dois. Pacotes «uncontrolled» tinham seus pares: subtipo 3 com o limite antigo e subtipo 4 com o curto; eles não tinham garantia de entrega. Quem escolhesse o prazo reduzido precisava interpretar a resposta Tipo 9 corretamente. O mecanismo destinava-se a IMPs C/30 e valia para acesso de host 1822 ou 1822L.

Uma interface não bloqueante antes descrita no Relatório 1822 nunca havia sido implementada; esta era outra proposta, aberta a comentários de quem mantinha o software dos computadores.

Os motivos de recusa separavam problemas que pediam atitudes diferentes. Os novos códigos Tipo 9 apontavam demora para estabelecer a conexão, controle de fluxo de ponta a ponta, falta de espaço no IMP de destino, congestionamento no trajeto ou falta de recursos no IMP local. Em vários desses casos, outra conexão ou outro destino podia seguir. Uma escassez local de buffers ou entradas de tabela atingia quase todos os envios controlados. “A rede está ocupada” soava dramático, mas informava pouco a quem precisava escolher o próximo trabalho.

Uma das filas tinha oito lugares. Em uma conexão, no máximo oito mensagens podiam estar pendentes da resposta sobre seu destino. A nona encontrava o controle de fluxo e não entrava. Mensagens maiores que 1.008 bits, fora o cabeçalho de 96 bits, exigiam reserva de buffer no IMP de destino. Se aquele espaço faltasse, uma mensagem pequena ou de outra conexão ainda poderia ser aceita. O limite de dois segundos impedia que a nona pasta numa fila específica fechasse todas as outras portas do computador.

O custo escondido estava na sequência. A ARPANET prometia entrega sequencial para mesma prioridade, origem e destino na ordem em que o IMP aceitasse as mensagens. O computador podia apresentar uma segunda antes que a resposta de recusa da primeira voltasse. Se a segunda fosse aceita e a primeira só entrasse depois de uma nova tentativa, a sequência reconhecida pela rede seria diferente da sequência pensada pelo remetente. Malis advertiu que uma aplicação que dependesse estritamente da entrega sequencial da sub-rede deveria deixar a opção curta de lado.

O RFC não fazia o IMP trabalhar mais rápido por decreto. Ele impedia que a dificuldade de uma mensagem confiscasse a oportunidade de enviar outras. O IMP precisava dizer cedo por que recusou; o computador precisava guardar a pendência, escolher a hora de voltar e entender quem entrou antes. O balcão abria depressa. A lista de espera mudava de dono.