Resumo

  • Ginny Strazisar escreveu software pioneiro de gateway na BBN e o instalou em fronteiras heterogêneas; hardware PDP-11, interfaces locais e cronogramas de campo precisavam convergir antes da transmissão entre três redes.
  • A documentação separa o local preparado da rota efetivamente usada e o protótipo da operação contínua, além de registrar uma divergência de datas que impede transformar o teste de 1977 numa lenda sem incerteza.

Em Oslo, Ginny Strazisar encontrou um problema que não cabia numa especificação: o computador no qual instalaria o gateway ainda não estava pronto. Ela esperou alguns dias com Paal Spilling, viajou pela Noruega e voltou quando o PDP-11 pôde receber o software. O episódio aparece sem grandiosidade na história oral do Computer History Museum. Ainda assim, contém uma definição prática de internetworking. Uma fronteira lógica só passa a existir quando programa, máquina, interface e equipe local chegam ao mesmo ponto.

Strazisar ingressou na Bolt Beranek and Newman em abril de 1975. Logo trabalhou nos equipamentos então chamados de gateways, encarregados de ligar redes. Havia um entre a Resource Computer Network experimental da BBN e a ARPANET. Depois vieram as conexões da ARPANET com a Packet Radio Network e com a Atlantic Satellite Network. O museu atribui a ela o primeiro software de roteador de internetworking para os novos protocolos TCP/IP, antes de “roteador” se tornar o nome usual.

Esse crédito não transforma um sistema coletivo numa biografia de inventora única. TCP, as redes e a demonstração tinham autores e equipes distintos. A contribuição de Strazisar era uma superfície definida: o equipamento que recebia um datagrama por um mecanismo local e precisava encaminhá-lo por outro sem exigir que as duas redes fossem redesenhadas como cópias.

As diferenças eram grandes. A rede de rádio enfrentava mobilidade, repetidores e períodos em que o ambiente experimental nem estava ligado. A ARPANET possuía interfaces próprias. A rede de satélite dependia de estações e operadores distribuídos por países. Velocidade, disponibilidade e formas de falha não eram simétricas. O gateway existia para preservar uma comunicação comum acima dessas diferenças.

Nem o arranjo físico era uniforme. Na rede de rádio, o código da estação e o código do gateway compartilhavam um PDP-11. Nas fronteiras entre ARPANET e SATNET, gateways separados usavam um lado para cada rede e direcionavam pacotes entre elas. A função podia ser comum; a incorporação ao local não era.

A lembrança de Strazisar organiza a implantação em três momentos: trabalho na BBN no verão de 1976, Londres em dezembro daquele ano e Noruega no verão de 1977. Hardware e software pertenciam a frentes distintas. Em Londres, a máquina foi instalada antes de sua chegada para carregar o programa. Em Oslo, o atraso do equipamento interrompeu a sequência. O cronograma arquitetônico tornava-se uma dependência física de cada sítio.

As provas também cresceram por etapas. Uma revista do Computer History Museum descreve ensaios no verão de 1976 que ficavam a um salto de rádio da estação onde estava o gateway bidirecional de Strazisar para a ARPANET. A publicação data de 27 de agosto uma transmissão cerimonial entre duas redes. O desafio seguinte era mostrar que a comunicação não dependia de uma adaptação improvisada para apenas um par.

Em 1977, dados saíram de uma van em movimento na Califórnia, entraram na infraestrutura de rádio do SRI e atravessaram ARPANET e a rede de satélite antes de alcançar um servidor na USC após uma rota transatlântica. Três tipos físicos de rede e várias implementações sustentaram uma mesma sessão de ponta a ponta.

O arquivo, porém, não oferece uma cronologia sem atrito. Um texto do museu publicado em 2017 diz que o teste ocorreu na quarta-feira, 22 de novembro. A revista de 2002 legenda o diagrama da transmissão como 27 de novembro. E a geografia instalada não coincide automaticamente com a geografia exercitada. Embora Strazisar tenha implantado um gateway na Noruega, Vint Cerf recordou que o tráfego da demonstração não entrou naquele país.

A distinção evita uma conclusão comum e perigosa. “Instalado” prova que código e equipamento foram reunidos. “Entregue” prova uma rota numa configuração. Nenhum estado demonstra sozinho as alternativas, a recuperação de falhas ou todas as interfaces. Um evento bem-sucedido não autoriza preencher os caminhos não testados.

O trabalho foi coletivo. O museu enumera mais de 35 pessoas e oito instituições. Bob Kahn e Vint Cerf aparecem no conceito de TCP; Jim Mathis e Dave Retz, no cliente; Ray Tomlinson e Bill Plummer, no servidor. Equipes do SRI, Collins Radio, Linkabit, BBN, UCL e da instituição norueguesa cuidaram das redes e estações. Virginia Strazisar é creditada pelos gateways da BBN. Sua responsabilidade fazia sentido justamente porque nenhuma pessoa controlava tudo dos dois lados.

Depois da demonstração, o conhecimento percorreu outro caminho: virou documentação de implementação. O RFC 823 diz que o projeto foi descrito no IEN 30, Gateway Routing: An Implementation Specification, e atualizado no IEN 109 de Strazisar, How to Build a Gateway. O texto dá crédito especial a V. Strazisar, M. Brescia, E. Rosen e J. Haverty. O que antes dependia da equipe original ganhava forma examinável por outros.

O IEN 30 não promete certeza matemática onde ela não existe. Especifica um algoritmo em detalhe suficiente para implementar e contornar componentes falhos, mas reconhece não poder provar que todo tráfego será roteado corretamente ou que nenhum destino ficará sem entrega por tempo indefinido. Algumas fragilidades surgem apenas em experimentos e uso operacional. Dados de rota podem ser corrompidos; hardware, software ou a própria implementação podem estar errados.

O RFC 823 registra a passagem para outro regime. Versões iniciais usavam BCPL e ELF, depois MOS para melhorar desempenho. No fim de 1981, iniciou-se uma nova implementação destinada a uma instalação de comunicações operacional, e não apenas a um ambiente de pesquisa. MACRO-11 economizava espaço para buffers e monitoramento. A linguagem mudou, mas a arquitetura permaneceu fundamentalmente a mesma.

Operar passou a significar tornar limites visíveis. Cada interface tinha fila de saída limitada para que uma rede lenta não consumisse todos os buffers. Um datagrama sem espaço era descartado e gerava um alerta de monitoramento. Estado de interfaces, vizinhos, redes alcançáveis, tráfego e motivos de perda ficavam disponíveis. O próprio RFC 823 se chama de instantâneo da implementação corrente, não de especificação definitiva.

Para avaliar uma fronteira moderna, a ordem das evidências continua válida. Qual binário está rodando? Em qual revisão de hardware e com qual driver? Que interface foi realmente exercitada? Que contador explica a perda quando um lado fica lento? Diagrama é intenção; pacote entregue é uma rota; implantação reproduzível com falha observável é operação.

O código viajou primeiro porque interoperabilidade tem endereço. Ela reside na mídia de instalação, na revisão da placa, no cabo, na janela de mudança e em quem sabe interpretar um estado remoto. O protocolo tornou possível manter as redes diferentes. O trabalho de campo tornou essa possibilidade verdadeira.

Sources