Página 1

Página 2

ONDE OS WIZARDS FICAM

ATÉ TARDE
(AS ORIGENS DA INTERNET)
Katie Hafner e Matthew
Lyon
Um lançamento de NERDs da DF Books
TOUCHSTONE
Rockefeller Center
Avenida das Américas 1230
Nova York, NY 10020
Visite-nos na World Wide Web:
http://www.SimonSays.com
Copyright © 1996 por Katie Hafner e Matthew Lyon
Todos os direitos reservados, incluindo o direito de reprodução total ou parcial sob qualquer forma.
Primeira edição Touchstone 1998

Página 3
TOUCHSTONE e colofão são marcas registradas da Simon & Schuster Inc.
Inclui índice.
ISBN 0-684-87216-1
À memória de JCR Licklider
e à memória de Cary Lu
Também por Katie Hafner
A casa na ponte: uma história da Alemanha moderna
Cyberpunk: Outlaws e Hackers na Fronteira do Computador (com John Markoff)
As origens de
a Internet
Katie Hafnerand Matthew Lyon

Página 4
UM LIVRO DE TOUCHSTONE
Publicado por Simon & Schuster
Conteúdo
Prólogo
1. O milhão de dólares mais rápido
2. Um bloco aqui, algumas pedras ali
3. A Terceira Universidade
4. Cabeça para baixo nos bits
5. Faça isso Truett
6. Hacking e Hollering
7. E-Mail
8. Um foguete em nossas mãos
Epílogo
Notas do Capítulo
Bibliografia
Agradecimentos
Índice
Luzes de Los Alamos onde os bruxos ficam acordados até tarde
(Fique no carro, esqueça o portão)

Página 5
Para salvar o mundo ou acabar com ele, o tempo dirá
—James Merrill,
“Sob Libra: Pesos e Medidas,”
de Enfrentando os Elementos

Prólogo
Setembro de 1994
Eles vieram para Boston de lugares distantes como Londres e Los Angeles, várias dezenas
homens de meia-idade, reunidos para um fim de semana de outono em 1994 para comemorar o que fizeram
vinte e cinco anos antes. Estes foram os cientistas e engenheiros que projetaram e
construiu a ARPANET, a rede de computadores que revolucionou as comunicações e deu
ascensão à Internet global. Eles haviam trabalhado em relativa obscuridade na década de 1960; um número
deles eram apenas estudantes de graduação quando fizeram contribuições significativas para o
rede. Outros foram mentores. A maioria deles nunca ganhou muito reconhecimento por
a conquista.
Bolt Beranek and Newman, uma empresa de informática com sede em Cambridge, tinha sido seu
centro de gravidade, empregou muitos deles, construiu e operou o ARPA original
rede, em seguida, caiu em relativa obscuridade à medida que a Internet cresceu como uma cidade fervilhante
em torno de seu primeiro bairro. Agora, um quarto de século após a instalação da primeira rede
nó, a BBN convidou todos os pioneiros do ARPANET para se reunirem, na esperança de aumentar
seu próprio perfil, lançando uma celebração pródiga marcando o aniversário.
Muitos dos que estavam na reunião não se viam ou mantinham contato há anos. Enquanto eles
filtrado no saguão do Copley Plaza para uma entrevista coletiva na tarde de sexta-feira
dando início à celebração, eles examinaram a sala em busca de rostos familiares.
Bob Taylor, o diretor de um centro de pesquisa corporativa no Vale do Silício, veio para
a festa pelos velhos tempos, mas ele também estava em uma missão pessoal para corrigir um
imprecisão de longa data. Rumores persistiram por anos de que a ARPANET havia sido
construído para proteger a segurança nacional em face de um ataque nuclear. Era um mito que tinha
não foi desafiado por tempo suficiente para ser amplamente aceito como um fato.
Taylor era o jovem diretor do escritório do Departamento de Defesa
Agência de Projetos de Pesquisa Avançada supervisionando a pesquisa de computador, e foi ele
quem iniciou a ARPANET. O projeto incorporou o mais pacífico
intenções de conectar computadores em laboratórios científicos em todo o país para que
pesquisadores podem compartilhar recursos de computador. Taylor conhecia a ARPANET e sua progênie,

Página 6
a Internet não tinha nada a ver com o apoio ou a sobrevivência à guerra - nunca teve. No entanto, ele sentiu
razoavelmente sozinho em levar esse conhecimento.
Ultimamente, a grande imprensa pegou o mito sombrio de um cenário de sobrevivência nuclear
e o apresentou como uma verdade estabelecida. Quando a revista Time cometeu o erro,
Taylor escreveu uma carta ao editor, mas a revista não a publicou. O esforço para definir o
gravar direto era como perseguir o vento; Taylor estava começando a se sentir um maluco.
Do outro lado da sala durante o jantar naquela noite no Copley, Taylor avistou um idoso e corpulento
homem com um bigode grosso. Ele o reconheceu imediatamente como a única pessoa que poderia
corroborar de forma convincente sua história. Era seu antigo chefe, Charlie Herzfeld, que tinha sido
o diretor da ARPA quando Taylor trabalhava lá. Os dois homens se viram pela última vez
anos antes, antes que alguém se importasse com o início da rede. Vendo Herzfeld
agora, Taylor estava animado. Ele estava de volta entre as pessoas que conheciam a história real. Agora
eles endireitariam as coisas.

1
Os milhões de dólares mais rápidos

Fevereiro de 1966
Bob Taylor geralmente dirigia para o trabalho, trinta minutos pelo campo ondulante
a nordeste de Washington, sobre o rio Potomac até o Pentágono. Lá, de manhã,
ele estacionaria em um dos vastos estacionamentos e tentaria colocar seu bem mais precioso, um
BMW 503, em algum lugar que ele pudesse se lembrar. Havia poucos pontos de verificação de segurança em
as entradas do Pentágono em 1966. Taylor despreocupou-se ao usar seu traje habitual: esporte
casaco, gravata, camisa de manga curta com botões e calças. Trinta mil outras pessoas
enxameavam pelo nível do saguão diariamente, uniformizados e também mufti, passando pelas lojas
e subiu para os jardins do enorme edifício.
O escritório de Taylor ficava no terceiro andar, o nível de maior prestígio do Pentágono, perto do
escritórios do secretário de defesa e do diretor de Projetos de Pesquisa Avançada
Agência (ARPA). Os escritórios dos oficiais de mais alto escalão do Pentágono ficavam no
externo, ou E-ring. Suas suítes tinham vista para o rio e monumentos nacionais. Taylor's
chefe, Charles Herzfeld, chefe da ARPA, estava entre os que tinham vista, na sala 3E160.
O diretor do ARPA classificou os mais altos símbolos de poder conferidos pelo Departamento de
Defesa (DOD), até as bandeiras oficiais ao lado de sua mesa. Taylor foi diretor de
o Information Processing Techniques Office (IPTO), a apenas um corredor de distância, um incomum
seção independente do ARPA encarregada de apoiar os mais avançados
projetos de pesquisa e desenvolvimento de computadores.
A suíte do diretor IPTO, onde Taylor pendurou seu casaco de 1965 a 1969, ficava em
o anel D. O que faltava em seu escritório em vista era compensado por seu conforto e tamanho.
Era uma sala acarpetada de pelúcia e ricamente mobiliada, com uma grande mesa de carvalho pesado

Página 7
mesa de conferência, estantes de livros com fachada de vidro, cadeiras de couro confortáveis e todas as outras
armadilhas de classificação, que o Pentágono mediu cuidadosamente até mesmo na qualidade de
os cinzeiros. (Viajando a negócios militares, Taylor alcançou o posto de general de uma estrela.)
Em uma das paredes de seu escritório havia um grande mapa-múndi; uma têmpora emoldurada esfregando
Tailândia pendurou com destaque em outro.
Dentro da suíte, ao lado do escritório de Taylor, havia outra porta que dava para um pequeno espaço referido
como sala de terminal. Lá, lado a lado, estavam três terminais de computador, cada um diferente
make, cada um conectado a um computador mainframe separado rodando em três locais separados.
Havia um terminal de máquina de escrever IBM Selectric modificado conectado a um computador no
Instituto de Tecnologia de Massachusetts em Cambridge. Um terminal de teletipo modelo 33,
semelhante a uma mesa de metal com uma grande máquina de escrever barulhenta embutida, estava ligada a um
computador na Universidade da Califórnia em Berkeley. E outro terminal de teletipo, um
O modelo 35, foi dedicado a um computador em Santa Monica, Califórnia, chamado, cripticamente
bastante, o AN / FSQ 32XD1A, apelidado de Q-32, uma máquina pesada construída pela IBM para
o Comando Aéreo Estratégico. Cada um dos terminais da suíte de Taylor era uma extensão de um
diferentes ambientes de computação - diferentes linguagens de programação, sistemas operacionais,
e assim por diante - dentro de cada um dos mainframes distantes. Cada um tinha um login diferente
procedimento; Taylor conhecia todos eles. Mas ele achou cansativo ter que lembrar qual
procedimento de login a ser usado para qual computador. E foi ainda mais cansativo, depois que ele
conectado, para ser forçado a lembrar quais comandos pertenciam a quais computadores
meio Ambiente. Esta era uma rotina particularmente frustrante quando ele estava com pressa, que
foi na maioria das vezes.
A presença de três terminais de computador diferentes no escritório do Pentágono de Taylor refletiu
A forte conexão do IPTO com a vanguarda da comunidade de pesquisa em computação,
residente em algumas das melhores universidades e centros técnicos do país. Ao todo, havia
cerca de vinte investigadores principais, apoiando dezenas de alunos de pós-graduação, trabalhando em
vários projetos, todos financiados pelo pequeno escritório de Taylor, que consistia apenas em
Taylor e uma secretária. A maior parte do orçamento de US $ 19 milhões do IPTO estava sendo enviada para o
campus
laboratórios em Boston e Cambridge, ou na Califórnia, para apoiar o trabalho que realizou o
promessa de fazer avanços revolucionários na computação. Sob o guarda-chuva do ARPA, um
O crescente senso de comunidade estava surgindo na pesquisa em computadores em meados da década de 1960.
Apesar da grande variedade de projetos e sistemas de computador, laços estreitos estavam começando a
entre os membros da comunidade de informática. Os pesquisadores se viram em
conferências técnicas e conversadas por telefone; já em 1964, alguns até começaram a usar um
forma de correio eletrônico para comentários comerciais, dentro da proximidade muito limitada de seus
computadores mainframe.
Comunicar-se com essa comunidade a partir da sala do terminal ao lado do escritório de Taylor era
um processo tedioso. O equipamento era de última geração, mas com uma sala cheia de
diversos terminais de computador era como ter uma sala cheia de vários aparelhos de televisão,
cada um dedicado a um canal diferente. “Tornou-se óbvio”, disse Taylor muitos anos depois,
“Que devemos encontrar uma maneira de conectar todas essas máquinas diferentes.”

Um refúgio de pesquisa
Página 8
Que existia uma agência dentro do Pentágono capaz de apoiar o que alguns
pode considerar a pesquisa acadêmica esotérica foi um tributo à sabedoria da ARPA
primeiros fundadores. A agência foi formada pelo presidente Dwight Eisenhower no
período de crise nacional após o lançamento soviético do primeiro satélite Sputnik em outubro
1957. A agência de pesquisa deveria ser um mecanismo de resposta rápida intimamente ligado ao
presidente e secretário de defesa, para garantir que os americanos nunca mais sejam tomados
de surpresa na fronteira tecnológica. O presidente Eisenhower viu o ARPA se encaixando bem
em sua estratégia para conter as intensas rivalidades entre ramos das forças armadas sobre
programas de pesquisa e desenvolvimento. A ideia do ARPA começou com um homem que não era nem
cientista nem soldado, mas vendedor de sabão.
Aos cinquenta e dois anos, Neil McElroy era um recém-chegado ao estabelecimento da defesa. Ele nunca tinha
trabalhava no governo, nunca havia morado em Washington e não tinha experiência militar
exceto na guarda nacional. Por trinta e dois anos, ele subiu na escada corporativa na
Procter & Gamble, fabricante de sabonetes gigante em Cincinnati.
Formado em Harvard, McElroy conseguiu seu primeiro emprego na P&G cortando envelopes como caixa postal
no departamento de publicidade por vinte e cinco dólares por semana. Era para ser um
emprego de verão; ele pretendia entrar na escola de negócios no outono. Mas ele ficou e
começou a vender sabão de porta em porta. Logo ele se tornou gerente de promoção. A partir daí ele
trabalhou seu caminho sendo pioneiro na venda de sabonete no rádio e na televisão. A TV
novela foi ideia de McElroy, sobre a qual ele disse uma vez sem se desculpar: “O
O problema de melhorar o gosto literário é das escolas. As novelas vendem muito sabão. ”
Em 1957, a P&G vendia cerca de um bilhão de dólares em Ivory, Oxydol, Joy e Tide
todo ano. Ele havia aperfeiçoado a estratégia de promover a competição de marca - como se
havia diferenças reais - entre produtos semelhantes feitos pela mesma empresa. E
nos últimos nove anos, o "Mac" alto e bonito como era conhecido pela maioria (ou "Mac ensaboado
de Cinci-O ”para alguns), foi o presidente da empresa - até que Eisenhower recrutou
ele para seu gabinete.
Na noite de sexta-feira, 4 de outubro de 1957, o novo candidato do presidente Eisenhower para
o secretário de defesa, McElroy, estava em Huntsville, Alabama. Ele já tinha sido
confirmado pelo Senado e estava visitando instalações militares antes de seu
juramento. Uma grande comitiva de funcionários do Pentágono estava a reboque para a turnê de Mac em Redstone
Arsenal, lar do programa de foguetes do Exército. Por volta das seis horas da tarde no
clube de oficiais, McElroy estava conversando com o emigrado alemão Wernher von Braun, pai de
foguetes modernos, quando um assessor correu e anunciou que os russos haviam conseguido
no lançamento de um satélite em órbita terrestre. Agora, de repente, antes mesmo de assumir o cargo,
McElroy se viu envolvido em uma crise de enormes proporções. Em uma noite, o soviético
realização havia reduzido a crescente confiança e otimismo da América no pós-guerra para
aumentando o medo e o desespero. De repente, "o espectro da destruição em massa", no
palavras do presidente, pesou sobre a psique americana.
Cinco dias depois, McElroy foi juramentado, com Washington totalmente consumido pela polêmica
sobre a questão de quem havia permitido que os soviéticos roubassem a marcha sobre a ciência americana e
tecnologia. Algumas pessoas previram que os soviéticos lançariam um satélite de observação

Página 9
do Ano Geofísico Internacional. “A pregação anterior deles no deserto foi
redimidos pelos espetáculos científicos soviéticos ”, disse um observador. “Agora assumia o
aura de verdade revelada. ” “Eu avisei” tornou-se um símbolo de status. Medo genuíno, sinistro
eruditos e duras críticas fluíram em torno da questão central da nova ameaça soviética para
segurança nacional. Profecias histéricas sobre o domínio soviético e a destruição de
democracia eram comuns. O Sputnik foi a prova da capacidade da Rússia de lançar
mísseis balísticos, disseram os pessimistas, e era apenas uma questão de tempo até que os soviéticos
ameaçaria os Estados Unidos. Os americanos menos apavorados se resignaram a
decepção com a liderança da Rússia na corrida para explorar o espaço.
Eisenhower não queria um especialista militar experiente chefiando o Pentágono; ele era um
ele mesmo. O presidente desconfiava do complexo militar-industrial e dos feudos do
forças armadas. Sua atitude para com eles às vezes beirava o desprezo.
Em contraste, ele amava a comunidade científica. Ele achou os cientistas inspiradores - suas ideias,
sua cultura, seus valores e seu valor para o país - e ele se cercou de
as melhores mentes científicas da nação. Eisenhower foi o primeiro presidente a hospedar um White
Jantar em casa especificamente para destacar as comunidades científicas e de engenharia como
convidados de honra, assim como os Kennedys mais tarde acolheriam artistas e músicos.
Centenas de cientistas americanos proeminentes serviram diretamente ao Eisenhower
administração em vários painéis. Ele se referiu a eles com orgulho como "meus cientistas". Ike
“Gostava de se ver como um de nós”, observou Detlev W. Bronk, presidente do
Academia Nacional de Ciências.
Dois cientistas proeminentes uma vez tomaram café da manhã com o presidente, e quando eles estavam saindo
Eisenhower observou que o Comitê Nacional Republicano estava reclamando que
cientistas próximos a ele não estavam "gritando" o suficiente para o republicano
Festa.
"Você não sabe, Sr. Presidente?" respondeu um dos homens com um sorriso. “Todos os cientistas são
Democratas. ”
“Não acredito”, respondeu Eisenhower. “Mas de qualquer forma, eu gosto de cientistas por sua ciência
e não por sua política. ”
Quando a crise do Sputnik chegou, Eisenhower puxou seus cientistas ainda mais firmemente em seu
círculo. Primeiro, ele realizou uma série de reuniões privadas com cientistas proeminentes de fora
o governo. Onze dias após a notícia do satélite soviético, em 15 de outubro de 1957,
Eisenhower sentou-se para uma longa discussão com seu Comitê Consultivo Científico, um
contingente completo das melhores mentes da nação. Nem ele nem nenhum deles estava tão preocupado
sobre o real significado do Sputnik, assim como aqueles que estavam usando a questão contra Ike.
Por um lado, Eisenhower sabia muito mais do que poderia dizer publicamente sobre o
status dos programas de mísseis russos; ele tinha visto o espião extremamente detalhado
fotografias feitas a partir de um avião espião U-2. Ele sabia que não havia falha de míssil. Ele também
sabia que os militares americanos e seus contratados tinham um interesse pessoal na União Soviética
ameaça. Ainda assim, ele pediu a seus conselheiros científicos uma estimativa da capacidade soviética.
Eisenhower ouviu atentamente enquanto eles avaliavam sobriamente o significado do lançamento do Sputnik .

Página 10
Disseram-lhe que os russos realmente haviam ganhado um impulso impressionante. Eles disseram que
Os Estados Unidos perderiam sua liderança científica e tecnológica a menos que se mobilizassem.
Muitos dos cientistas em torno de Eisenhower estavam preocupados desde o início dos anos 1950 que
o governo fez mau uso ou não entendeu a ciência e a tecnologia modernas. Eles
instou Eisenhower a nomear um único conselheiro presidencial de ciências de alto nível, “uma pessoa que ele
poderia conviver facilmente ”, para ajudá-lo a tomar decisões envolvendo tecnologia. O lançamento
do Sputnik II apenas um mês após o primeiro Sputnik aumentou a pressão. O primeiro satélite, um
Objeto de 184 libras do tamanho de uma bola de basquete, era ruim o suficiente. Seu companheiro de viagem pesou
pesava meia tonelada e era quase do tamanho de um Fusca.
Poucos dias após a notícia do Sputnik II, Eisenhower disse à nação que encontrou seu homem
para a ciência em James R. Killian Jr., presidente do Massachusetts Institute of Technology.
Killian era um não cientista que falava com eficácia em nome da ciência. Em 7 de novembro,
1957, no primeiro de vários discursos para tranquilizar o povo americano e reduzir o pânico,
o presidente anunciou a nomeação de Killian como consultor científico. Chegou tarde no
endereço, mas virou notícia de primeira página no dia seguinte. O presidente havia desenhado links
entre a ciência e a defesa, e disse que Killian "seguiria no campo científico
melhoria da nossa defesa. ” A imprensa apelidou o Killian America de "Czar do Míssil".
Durante a reunião de 15 de outubro com seus conselheiros científicos, o presidente havia falado de seu
preocupação com a gestão da pesquisa no governo. “Com grande entusiasmo e
determinação que o presidente queria que os cientistas lhe dissessem onde a pesquisa científica
pertencia à estrutura do governo federal ”, disse Sherman Adams, o
assistente executivo do presidente. Além disso, Eisenhower disse-lhes que tinha um bom homem em
Secretário de Defesa McElroy e exortou os cientistas a se reunirem com o novo secretário,
o que eles fizeram naquele mesmo dia.
Eles descobriram que o secretário McElroy tinha uma apreciação semelhante por eles. Um aspecto dele
carreira na P&G da qual ele mais se orgulhava era a quantidade de dinheiro que a empresa tinha
dedicado à pesquisa. Ele acreditava no valor da ciência irrestrita, em sua capacidade de
produzir resultados notáveis, embora nem sempre previsíveis. McElroy e P&G criaram um
grande laboratório de pesquisa de "céu azul", financiou-o bem e raramente pressionou seu
cientistas para justificar seu trabalho. Foi uma das primeiras operações de pesquisa corporativa de sua
tipo, aquele em que os cientistas foram deixados para perseguir quase tudo e foram bem apoiados
do topo.
Avanços tecnológicos significativos vieram de um acordo semelhante entre
universidades e governo durante a Segunda Guerra Mundial: radar, armas nucleares e grandes
máquinas de calcular resultaram do que Killian chamou de "os métodos de roda livre de
cientistas e engenheiros acadêmicos excepcionais que sempre estiveram livres de qualquer inibição
arregimentação e organização. ”
Em consulta com Killian, cujo apoio foi crucial, McElroy começou a discutir o
idéia de estabelecer uma agência independente de pesquisa. Talvez McElroy estivesse ciente de que
a Câmara de Comércio dos Estados Unidos havia sugerido a criação de um único sistema de pesquisa e
agência de desenvolvimento do governo federal durante os meses de audiências no Congresso
antes do Sputnik. Essa conversa estava no ar. A ideia agora surgiu em discussões com um

Página 11
comitê consultivo informal de industriais astutos que se reuniam regularmente com o secretário
de defesa.
Nos dias imediatamente seguintes ao lançamento soviético, dois homens foram ver McElroy:
eminente físico nuclear Ernest O. Lawrence, e Charles Thomas, um ex-CEO da
Monsanto Chemical Company e um assessor ocasional do presidente. Em uma reunião
durando várias horas, eles discutiram a ideia de uma forte agência de P&D avançada que
se reportaria ao secretário, e ambos os visitantes instaram McElroy a acompanhá-lo. Físico
Herbert York, diretor do Laboratório Livermore e confidente próximo de ambos
Eisenhower e Killian entraram nas conversas. Ao mesmo tempo, o próprio McElroy
estava consultando frequentemente Killian e o presidente. Na visão de Killian, o tradicional
as missões das forças armadas foram ultrapassadas pela ciência e tecnologia modernas.
Aqui estava uma maneira de mover o Pentágono para a nova era. Uma das principais atrações
do conceito de agência de pesquisa, na mente de McElroy, era a capacidade que isso lhe daria para
gerenciar a competição feroz dentro do DOD sobre programas e orçamentos de P&D. o
a competição estava alcançando novos patamares absurdos. Comandantes do Exército, Marinha e Força Aérea
tratou o Sputnik como o tiro de partida em uma nova corrida, cada um competindo contra o outro pelo
maior parcela dos gastos com P&D.
McElroy acreditava que uma agência centralizada para projetos de pesquisa avançada reduziria
rivalidade entre serviços, colocando orçamentos federais de P&D substancialmente sob seu próprio fechamento
supervisão. Além disso, quase certamente atrairia o presidente, uma vez que o
as alegações muitas vezes egoístas dos militares e o hype de interesse especial geralmente são recebidos com desdém
no
Casa Branca.
Eisenhower gostou da proposta do secretário. Enquanto a administração tinha planos maiores em
loja - a criação da Administração Nacional de Aeronáutica e Espaço (NASA),
aprovação de uma Lei de Reorganização da Defesa, estabelecimento do cargo de Diretor de
Pesquisa e engenharia de defesa - essas coisas levariam tempo. O avançado
O conceito de Agência de Projetos de Pesquisa foi uma resposta que o presidente poderia apontar
imediatamente. E isso daria a ele uma agência ágil de P&D que ele e seus cientistas poderiam chamar
no futuro.
Em 20 de novembro de 1957, McElroy foi ao Capitólio pela primeira vez como secretário. No
o curso de testemunhar sobre os programas de mísseis balísticos dos EUA, ele mencionou que tinha
decidiu criar um novo “gerente único” para todas as pesquisas de defesa. No curto prazo, ele
disse ao Congresso, a nova agência administraria programas de P&D para satélites e espaciais. Nas próximas
dia, ele distribuiu ao Estado-Maior Conjunto um projeto de carta e diretiva para o novo
agência, pedindo sua revisão e comentários.
Os militares se irritaram com as críticas implícitas. Uma coisa era ter ciência civil e
consultores de tecnologia , mas McElroy agora estava claramente invadindo seu território, planejando gerenciar
e operar um escritório central que controlaria os programas de P&D de defesa e o futuro
projetos de armas. Eles estavam preparados para lutar. Secretário da Força Aérea James
Douglas escreveu: “A Força Aérea aprecia que as propostas sejam sugestões”. Isso é,
mensagem recebida, não aceita. O Exército, a Marinha e o Estado-Maior Conjunto devolveram o
rascunho da carta com várias revisões. Eles brincavam tortuosamente com a linguagem sobre

Página 12
a autoridade contratante da nova agência, suas revisões salpicadas de palavras subversivas
mudanças, adições engenhosas e exclusões astutas, todas destinadas a enfraquecer e confinar o
agência.
McElroy concedeu alguns pontos menores, mas deixou duas coisas claras: O diretor da agência
teria autoridade contratante, e o escopo da pesquisa da agência deveria ser
ilimitado.
Em 7 de janeiro de 1958, Eisenhower enviou uma mensagem ao Congresso solicitando fundos iniciais para
o estabelecimento da Agência de Projetos de Pesquisa Avançada. Dois dias depois ele dirigiu
o ponto principal em sua Mensagem do Estado da União. “Eu não estou tentando passar hoje
julgamento sobre as acusações de rivalidades de serviços prejudiciais. Mas uma coisa é certa. Tanto faz
eles são, a América quer que eles parem. ”
Eisenhower também afirmou “a necessidade de controle único em alguns dos nossos
projetos de desenvolvimento ”, então deu seu golpe de misericórdia aos generais:“ Outro
requisito da organização militar é uma subordinação clara dos serviços militares a
autoridade civil devidamente constituída. Esse controle deve ser real; não apenas no
superfície."
No início de 1958, Roy Johnson, vice-presidente da General Electric, foi nomeado representante da ARPA
primeiro diretor; cinco dias após a nomeação, o financiamento foi aprovado pelo Congresso (como um
item de linha em um projeto de lei de dotações da Força Aérea), e o ARPA entrou em funcionamento.
No pânico pós- Sputnik , a corrida pelo espaço sideral afetou amplamente a vida americana,
causando uma nova ênfase na ciência nas escolas, piorando as relações entre a Rússia
e os Estados Unidos, e abrindo uma comporta para gastos com P&D. Washington's
Os gastos com P&D do “desafio externo” aumentaram de US $ 5 bilhões por ano para mais de US $ 13 bilhões
anualmente entre 1959 e 1964. O Sputnik lançou uma era de ouro para a ciência militar e
tecnologia. (Em meados da década de 1960, as despesas totais de P&D da nação seriam responsáveis por 3
por cento do produto nacional bruto, uma referência que era ao mesmo tempo um símbolo de progresso
e uma meta para outros países.)
Todos os olhos estavam voltados para o ARPA quando ele abriu suas portas com uma dotação de US $ 520 milhões e
um
Plano de orçamento de $ 2 bilhões. Foi dada a direção de todos os programas espaciais dos EUA e de todos
pesquisa avançada de mísseis estratégicos. Em 1959, uma equipe de sede de cerca de setenta
pessoas haviam sido contratadas, um número que permaneceria razoavelmente constante por anos. Estes foram
principalmente gerentes de projetos científicos que analisaram e avaliaram propostas de P&D,
supervisionar o trabalho de centenas de empreiteiros.
Roy Johnson, o primeiro diretor da ARPA, era, como seu chefe, um empresário. Aos cinquenta e dois anos,
ele havia sido recrutado pessoalmente por McElroy, que o convenceu a deixar um $ 160.000
um emprego na General Electric e um emprego de $ 18.000 em Washington.
Não surpreendentemente, Johnson abordou a agenda de P&D da América como um problema de gestão.
Habilidades gerenciais eram seu ponto forte. Seu trabalho, a seu ver, era exortar as pessoas a fazer
tudo o que for necessário para obter vantagem sobre os soviéticos. Ele argumentou frequentemente e vigorosamente
com

Página 13
salas cheias de generais e almirantes e agressivamente enfrentou a Força Aérea. Logo
tornou-se evidente que Johnson era um defensor sério e vociferante de um forte exército
presença no espaço sideral.
Mas é claro que Killian e outros cientistas em torno de Eisenhower queriam alguém bem
versado em questões científicas e tecnológicas executando o ARPA. Johnson foi instruído
contratar um oficial militar como seu vice, e selecionar um cientista-chefe para completar seu
equipe de liderança. A postagem científica quase foi para Wernher von Braun, até que ele
insistiu em trazer toda a sua equipe de uma dúzia de associados com ele para o Pentágono. assim
Herbert York, de quem Killian gostava, recebeu o emprego e mudou-se para a ARPA
do Laboratório Lawrence Livermore. Quando ele chegou ao terceiro andar no
O Pentágono, York prontamente pendurou uma grande imagem da lua na parede de seu escritório. E certo
ao lado dele ele pendurou uma moldura vazia. Ele disse aos visitantes que logo seria preenchido com o primeiro
imagem da parte de trás da lua.
O restante da equipe da ARPA foi recrutado entre os maiores talentos técnicos da indústria em
lugares como Lockheed, Union Carbide, Convair e outros empreiteiros do Pentágono. o
os dias da equipe foram passados peneirando ouro em um fluxo torrencial de propostas de P&D não solicitadas.
O sucesso da ARPA dependeu da postura extremamente vocal de Johnson sobre o papel da América no
espaço sideral e sua visão simplista das tensões soviético-americanas. Ele definiu erroneamente
A missão da ARPA quase inteiramente em termos militares, delineando o tipo de projetos espaciais que ele
previsto: satélites de vigilância global, veículos interceptores de defesa espacial, estratégico
sistemas de armas orbitais, satélites de comunicação estacionários, estações espaciais tripuladas e
uma base lunar.
Eisenhower e seus cientistas civis seguiram em frente com o resto de sua agenda, e
no final do verão de 1958, a Administração Nacional de Aeronáutica e Espaço havia sido
promulgada em lei. Quase durante a noite, enquanto Johnson tocava tambor para uma presença militar em
espaço, os projetos espaciais e programas de mísseis foram retirados do ARPA e
transferido para a NASA ou de volta para os serviços, deixando o orçamento da ARPA reduzido a um
miseráveis $ 150 milhões. O portfólio do ARPA foi destruído, sua equipe ficou praticamente sem nenhum
Função. A Aviation Week chamou a jovem agência de "um gato morto pendurado no armário de frutas".
Johnson renunciou. Antes de partir, no entanto, ele encarregou sua equipe de redigir um documento
pesando quatro alternativas: abolir o ARPA, expandi-lo, não fazer alterações ou
redefinindo sua missão. Seus analistas se empenharam em construir um caso para o quarto
alternativa, e sua tenacidade por si só salvou a agência do esquecimento seguro. Eles encarnaram
definir um conjunto de metas para distanciar a ARPA do Pentágono, mudando o foco da agência para
esforços de “pesquisa básica” de longo prazo da nação. Os serviços nunca estiveram interessados em
projetos de pesquisa abstratos; seu mundo era movido por objetivos de curto prazo e
relações com empreiteiros industriais. A equipe do ARPA viu uma oportunidade de
redefinir a agência como um grupo que assumiria as pesquisas realmente avançadas e “extravagantes”.
Mais importante de tudo, os funcionários da ARPA reconheceram o maior erro da agência até então:
não estava acessando as universidades onde muitos dos melhores trabalhos científicos estavam sendo feitos.
A comunidade científica, previsivelmente, aderiu ao apelo por uma reinvenção do ARPA como um

Página 14
Patrocinador de pesquisa de “alto risco e alto ganho” - o tipo de loja de P&D com que eles sempre sonharam
ao longo. Seu sonho foi realizado; O ARPA recebeu sua nova missão.
À medida que as características do ARPA tomavam forma, uma característica facilmente aparente da agência era
que seu tamanho relativamente pequeno permitiu que a personalidade de seu diretor permeasse o
organização. Com o tempo, o "estilo ARPA" - livre, aberto a alto risco, ágil - iria
ser alardeada. Outros burocratas de Washington começaram a invejar o modus operandi do ARPA .
Eventualmente, a agência atraiu um corpo de elite de defensores de P&D exigentes do
melhores universidades e laboratórios de pesquisa, que começaram a construir uma comunidade do
as melhores mentes técnicas e científicas da pesquisa americana.
A nova pesquisa básica da agência e a orientação de projetos especiais eram ideais para o
mudança atmosférica em Washington causada pela eleição de John F. Kennedy. Com
vigor, as burocracias de Washington responderam ao carisma de Kennedy. No Pentágono,
Robert S. McNamara, o novo secretário de defesa, liderou a mudança do
filosofia de "retaliação maciça" na postura estratégica da América e em direção a uma estratégia
de “resposta flexível” às ameaças internacionais à supremacia americana. A ciência era a
Nova fronteira.
No início de 1961, o segundo diretor da ARPA, Brigadeiro General Austin W. Betts, renunciou e
foi substituído por Jack P. Ruina, o primeiro cientista a dirigir o ARPA. Ruina veio com forte
credenciais acadêmicas, bem como algum histórico militar. Treinado como eletricista
engenheiro, ele havia sido professor universitário e também atuou como assistente adjunto
secretário da Força Aérea. Ele se dava bem com os membros do conselho científico
painéis à Casa Branca.
Uma era de ouro para o ARPA estava apenas começando. Ruina trouxe um estilo de gestão descontraído
e estrutura descentralizada para a agência. Os detalhes não o interessavam; encontrando grande talento
fez. Ele acreditava em escolher as melhores pessoas e deixá-las escolher a melhor tecnologia. Ele
tinha forte vontade de dar rédea solta aos diretores de programa. Seu trabalho, como ele via, era
obter o máximo de apoio e financiamento que pudesse para os projetos selecionados. Ruina
tinha uma teoria de que pessoas verdadeiramente talentosas normalmente não escolheriam ficar muito tempo em um
burocracia governamental, mas pode ser convencido a passar um ou dois anos se for oferecido o suficiente
flexibilidade e orçamentos grandes o suficiente. A rotatividade não o incomodava. A agencia ele
acreditava-se, se beneficiariam da exposição frequente a novas vistas. De acordo com tudo isso,
ele também se via como um temporário.
Com o tempo, Ruina aumentou o orçamento anual do ARPA para US $ 250 milhões. Projetos em mísseis balísticos
detecção de defesa e teste nuclear, expressa em termos de pesquisa básica, foram os principais
prioridades. (Também havia programas como pesquisa comportamental e comando e controle
que, embora interessante, caiu abaixo do nível de atenção de Ruina.)
Então, em maio de 1961, um computador, e muito grande, exigiu sua atenção. UMA
programa em questões de comando e controle militar foi iniciado no ARPA usando
fundos de emergência do DOD. Para a obra, a Força Aérea havia comprado o enorme e caro
Q-32, uma máquina gigantesca que serviria de backup para a defesa aérea da nação
sistema de alerta precoce. A máquina havia sido instalada em uma instalação em Santa Monica,
Califórnia, em uma das principais contratadas da Força Aérea, a System Development Corporation

Página 15
(SDC), onde deveria ser usado para treinamento de operadores e como um software
ferramenta de desenvolvimento.
Em seguida, a Força Aérea foi forçada a reduzir, o que deixou a empresa de Santa Monica
implorando por alguma maneira de manter seus funcionários trabalhando com o computador. A força Aérea,
que já havia investido milhões no contrato SDC, de repente teve um embaraçoso
elefante branco em suas mãos na forma de uma máquina de computação enorme e desajeitada.

Licklider
A relação entre os militares e os estabelecimentos de informática começou com o
a própria indústria de computadores moderna. Durante a Segunda Guerra Mundial, em meio a uma necessidade
percebida
para capacidade de cálculo mais rápida do que poderia ser fornecida pelos bancos de
calculadoras executadas por operadores humanos, os militares financiaram dezenas de computadores
experimentos. A Marinha apoiou Howard Aiken, o professor de matemática de Harvard
que sonhou em construir uma calculadora em grande escala e acabou com o Mark I, um cinquenta
quadro de controle de 30 metros de comprimento e 2,5 metros de altura que poderia realizar operações aritméticas
sem a intervenção de um operador. O Exército também apoiou o famoso Electronic
Projeto de integrador numérico e calculadora (ENIAC) na Universidade da Pensilvânia.
Mais tarde, no MIT, primeiro a Marinha e depois a Força Aérea apoiaram um computador chamado
Whirlwind.
No início dos anos 1950, a computação significava fazer aritmética rápido. Empresas, especialmente bancos,
colocam suas máquinas para trabalhar fazendo cálculos em grande escala. Em 1953, International Business
Machines Corporation (IBM), já a maior fabricante de relógios de ponto do país
bem como equipamento eletromécnico de tabulação, entrou no negócio de fabricação
grandes computadores eletrônicos. Essas eram as máquinas de negócios do futuro. A IBM
máquinas não eram necessariamente melhores do que o Univac (o sucessor do ENIAC), mas
A equipe de vendas da IBM tornou-se lendária e, em pouco tempo, as vendas das máquinas da IBM tinham
superou os da Univac.
Então, no final dos anos 1950, quando a IBM estava ultrapassando a marca de vendas de um bilhão de dólares, Ken
Olsen,
um engenheiro individualista e franco, deixou o Lincoln Laboratory do MIT com $ 70.000 em
capital de risco para explorar comercialmente a tecnologia desenvolvida em torno de uma nova máquina:
o TX-2 no Lincoln Lab. Ele formou a Digital Equipment Corporation para fabricar
e vender componentes de computador, e então ele construiu algo radicalmente diferente do que
existia antes: um computador menor chamado minicomputador que interagia diretamente com
o usuário. A ideia de Olsen para um computador interativo veio de um grupo pioneiro de
pesquisadores da computação no MIT. Um grupo diferente e um pouco mais jovem surgiu com
outro conceito dramático em computação que estava começando a pegar, especialmente em
instituições acadêmicas. Eles chamaram de "tempo compartilhado" e tinha um apelo óbvio como um
alternativa ao método tradicional lento e desajeitado de processamento em “lote”.
O processamento em lote era uma forma complicada de computação. Até mesmo para o menor
tarefa de programação, era necessário ter o código relevante perfurado no programa
cartões, que foram então combinados com "cartões de controle" para cuidar do computador
funções administrativas. Um operador de computador alimentou os cartões no computador ou em

Página 16
fita magnética para processamento, um lote de cada vez. Dependendo do comprimento da fila
e a complexidade dos programas e problemas, a espera pode ser longa. Não era
incomum esperar um dia ou mais pelos resultados.
O compartilhamento de tempo era, como o termo sugere, um novo método de dar a muitos usuários
acesso a computadores em terminais individuais. Os terminais permitiam que eles interagissem
diretamente com o computador mainframe. O aspecto revolucionário do time-sharing era que
eliminou grande parte da espera tediosa que caracterizava a computação em lote.
O compartilhamento de tempo deu aos usuários terminais que lhes permitiam interagir diretamente com o
computador e obter seus resultados imediatamente. “Nós realmente acreditamos que era um melhor
maneira de operar ”, lembra Fernando Corbató, cientista da computação do MIT. “Suponho que se
alguém dissera: 'Eu lhe darei uma máquina gratuita', poderíamos ter dito: 'Nós não
precisam de compartilhamento de tempo. '”Mas os computadores naquela época eram coisas enormes. Eles pegaram
grande
quartos e manutenção contínua necessária porque havia muitos componentes.
“Eles simplesmente não eram uma coisa casual”, Corbató continuou. "Você normalmente não pensa em
ter uma máquina pessoal naquela época - de uso exclusivo, talvez, mas não pessoal.
Então, realmente vimos a necessidade de tentar mudar isso. Ficamos frustrados. ” A apreciação de
o time-sharing era diretamente proporcional à quantidade de acesso direto que se tinha ao
computador. E geralmente isso significava que quanto mais você programava, melhor você
compreendeu o valor do acesso direto.
O que o time-sharing não podia fazer era eliminar a necessidade de coordenar competidores
demandas na máquina por diferentes usuários. Por sua natureza, o time-sharing encoraja os usuários
trabalhar como se tivessem toda a máquina sob seu comando, quando na verdade eles tinham apenas um
fração do poder total de computação. Distribuição de custos entre vários usuários
significa que quanto mais usuários, melhor. Claro, muitos usuários atrapalharam o
máquina, uma vez que uma alta porcentagem dos recursos da máquina foram alocados para
coordenar os comandos de vários usuários. Conforme o número de usuários aumentou, mais
os recursos do computador foram dedicados à função de coordenação, o que reduziu
tempo de processamento utilizável real. Se os programadores tivessem que fazer trabalhos muito pequenos (como
código restrito ou pequena depuração de um programa), eles não precisavam de uma máquina poderosa.
Mas quando chegou a hora de executar os programas completos, muitos dos quais usavam muita máquina
recursos, tornou-se evidente que os usuários ainda competiam entre si por
tempo de computação. Assim que um grande programa exigindo muitos cálculos entrou no
mistura de trabalhos realizados on-line, o trabalho de todos ficou mais lento.
•••
Quando a Força Aérea passou o Q-32 para a ARPA em 1961, Ruina não tinha ninguém para
administrar o contrato. Ruina tinha em mente um trabalho com potencial de expansão agora
além do único contrato que por acaso pressionava no momento: Computadores, como
eles relacionados ao comando e controle, podem um dia fornecer alta velocidade e confiável
informações sobre as quais basear decisões militares críticas. Esse potencial, em grande parte
insatisfeito, parecia infinitamente promissor.

Página 17
Coincidentemente, Ruina também estava procurando alguém que pudesse dirigir um novo programa em
ciências comportamentais que o DOD queria que o ARPA executasse. No outono de 1962, Ruina encontrou
o candidato que poderia preencher os dois cargos, um eminente psicólogo chamado JCR Licklider.
Licklider foi uma escolha óbvia para chefiar um escritório de ciências comportamentais, mas um psicólogo
não era uma escolha óbvia para supervisionar um escritório do governo focado no desenvolvimento de liderança
tecnologia de ponta em informática. No entanto, os interesses amplos e interdisciplinares de Licklider eram
adequados para ele
bem para o trabalho. Licklider havia feito algumas experiências sérias com computadores. “Ele costumava dizer
como ele gostava de passar muito tempo em um console de computador ”, lembrou Ruina. "Ele disse
ele ficava preso a isso e meio que viciado. ” Licklider era muito mais do que apenas
um entusiasta de computador, no entanto. Por vários anos, ele vinha promovendo um radical e
noção visionária: que os computadores não estavam apenas adicionando máquinas. Os computadores tinham o
potencial para atuar como extensões de todo o ser humano, como ferramentas que poderiam amplificar o
alcance da inteligência humana e expandir o alcance de nossos poderes analíticos.
Joseph Carl Robnett Licklider nasceu em St. Louis em 1915. Um único e muito querido
criança, ele passou seus primeiros anos nutrindo uma fascinação por aeromodelos. Ele sabia que ele
queria ser um cientista, mas ele ficou fora de foco durante a maior parte de seus dias de faculdade em
Washington University. Ele mudou as concentrações várias vezes, de química para
da física às artes plásticas e, finalmente, à psicologia. Quando ele se formou em 1937, ele segurou
graduação em psicologia, matemática e física. Para uma tese de mestrado em
psicologia, ele decidiu testar o popular slogan “Durma mais, é bom para você” no
uma população de ratos. Conforme ele se aproximava de seu Ph.D., os interesses de Licklider se estreitaram em
direção
psicoacústica, a psicofisiologia do sistema auditivo.
Para sua dissertação de doutorado, Licklider estudou o córtex auditivo de gatos, e quando ele
mudou-se para o Swarthmore College, ele trabalhou no quebra-cabeça da localização sonora, tentando
para analisar a capacidade do cérebro de determinar a distância e a direção de um som. Se você fechar
seus olhos e peça a alguém para estalar os dedos, seu cérebro lhe dirá aproximadamente
de onde vem o snap e a que distância está. O quebra-cabeça da localização sonora é
também ilustrado pelo fenômeno “coquetel”: em uma sala lotada onde vários
conversas estão ocorrendo dentro do alcance auditivo, é possível isolar
qualquer conversa que alguém escolher sintonizando certas vozes e desligando o resto.
Em 1942, Licklider foi para Cambridge, Massachusetts, para trabalhar como pesquisador associado em
Laboratório Psicoacústico da Universidade de Harvard. Durante os anos de guerra, ele estudou o
efeitos da altitude elevada na comunicação por fala e os efeitos da estática e outros ruídos
na recepção por receptores de rádio. Licklider conduziu experimentos em B-17 e B-24
bombardeiros a 35.000 pés. A aeronave não estava pressurizada e as temperaturas a bordo
frequentemente estavam bem abaixo de zero. Durante um teste de campo, o colega de Licklider e melhor
amigo, Karl Kryter, viu Licklider ficar branco. Kryter entrou em pânico. Ele aumentou o oxigênio
e gritou para o amigo: “Lamba! Fale comigo!" Assim como Kryter estava prestes a pedir ao piloto para
descer, a cor voltou ao rosto de Licklider. Ele tinha sentido uma dor tremenda, disse ele,
mas tinha passado. Depois disso, ele parou de tomar seu café da manhã favorito - Coca-Cola -
antes de ir em missões de alta altitude.

Página 18
Por esta altura, Licklider ingressou no corpo docente de Harvard e estava a ganhar reconhecimento como um
dos principais teóricos do mundo sobre a natureza do sistema nervoso auditivo, que ele
uma vez descrito como "o produto de um arquiteto excelente e um trabalhador desleixado".
A psicologia em Harvard naqueles anos foi fortemente influenciada pelo behaviorista BF
Skinner e outros que afirmavam que todo comportamento é aprendido, que os animais nascem em branco
lousas a serem inscritas pelo acaso, experiência e condicionamento. Quando Skinner foi tão longe
como colocar seu próprio filho em uma chamada caixa de Skinner para testar teorias comportamentais e outras
membros do corpo docente começaram a fazer experiências semelhantes (embora menos radicais), Louise
Licklider bateu o pé. Nenhum filho dela iria para uma caixa, e seu marido
acordado.
Louise era geralmente a primeira pessoa a ouvir as idéias do marido. Quase todas as noites
depois do jantar, ele voltou a trabalhar por algumas horas, mas quando chegou em casa por volta de
23h ele geralmente passava uma hora ou mais contando a Louise seus pensamentos mais recentes. “Eu cresci em
suas idéias ", disse ela," desde quando as sementes foram plantadas pela primeira vez, até que de uma forma ou de
outra ele
os vi dar frutos ”.
Todo mundo adorava Licklider e, por insistência dele, quase todo mundo o chamava
"Lamber." Seu gênio incansável e versátil deu origem, ao longo dos anos, a um culto eclético de
admiradores.
Lick tinha pouco mais de um metro e oitenta de altura. Ele tinha cabelos castanhos cor de areia e grandes olhos azuis.
Seu mais
característica marcante era seu sotaque suave e caseiro do Missouri, que desmentia seu
mente aguda. Quando ele deu palestras ou deu colóquios, ele nunca preparou um discurso. Em vez disso, ele
levantava-se e fazia comentários extensos de improviso sobre um certo problema que ele
por acaso estar trabalhando. O pai de Lick tinha sido um ministro batista, e Louise
ocasionalmente o repreendia ao notar o pregador nele. “Lick at play com um problema em
um briefing ou um colóquio, falando com aquele sotaque caipira suave, era um tour de force " ,
lembrou Bill McGill, um ex-colega. ”Ele falava neste sotaque Missouri Ozark, e
se você entrasse na rua, você se perguntaria: Quem diabos é esse feno? Mas se você
estavam trabalhando no mesmo problema e ouviam sua formulação, ouviam-no
seria como ver o brilho do amanhecer. ”
Muitos dos colegas de Lick ficaram maravilhados com sua capacidade de resolver problemas. Ele já foi
descrito como tendo a intuição mais refinada do mundo. “Ele podia ver a resolução de um
problema técnico antes que o resto de nós pudesse calculá-lo ”, disse McGill. “Isso o fez
bastante extraordinário. ” Lick não era um formalista em nenhum aspecto e raramente lutava com
teoremas arcanos. “Ele era como uma criança de olhos arregalados indo de problema em problema,
consumido pela curiosidade. Quase todos os dias ele tinha algum novo impulso sobre um problema que estávamos
pensando sobre."
Mas viver com Lick também tinha suas frustrações. Ele era humilde, muitos acreditavam.
Freqüentemente, ele participava de reuniões lançando ideias para qualquer um. “Se alguém roubasse uma ideia
dele ”, Louise relembrou,“ eu batia na mesa e dizia que não é justo, e ele dizia: '
não importa quem recebe o crédito; importa que seja feito. '”Ao longo de muitos
anos em que lecionou, ele inspirou todos os seus alunos, mesmo os de graduação, a se sentirem como juniores
colegas. Sua casa estava aberta para eles, e os alunos muitas vezes apareciam na porta da frente

Página 19
com um capítulo de uma tese ou apenas uma pergunta para ele. "Eu colocaria meu polegar para cima e eles
ir até seu escritório no terceiro andar ”, disse Louise.
Nos anos do pós-guerra, a psicologia ainda era uma disciplina jovem, convidando ao escárnio daqueles
nas ciências mais difíceis, com pouca paciência para um novo campo que lidou com tal enigmática
entidades como a mente, ou "o fator humano". Mas Licklider era um psicólogo na maioria
senso rigoroso. Como disse um colega, ele pertencia àqueles "cujo autoconsciente
a preocupação com a legitimidade de sua atividade científica tornou-os mais resistentes.
mente do que muitos de seus colegas em campos mais bem estabelecidos. ”
Em 1950, Lick mudou-se para o MIT para trabalhar no Laboratório de Acústica do Instituto. o
ano seguinte, quando o MIT criou o Lincoln Laboratory como um laboratório de pesquisa dedicado ao ar
defesa, Lick assinou contrato para iniciar o grupo de engenharia humana do laboratório. A guerra Fria
passou a dominar virtualmente toda a vida intelectual da instituição. Lincoln Lab
foi uma das manifestações mais visíveis da aliança da guerra fria do MIT com Washington.
No início dos anos 1950, muitos teóricos militares temiam um ataque surpresa de bombardeiros soviéticos
carregando armas nucleares sobre o Pólo Norte. E assim como os cientistas se uniram durante
década de 1940 para lidar com a possibilidade de armamento nuclear alemão, uma equipe semelhante
reunidos em 1951 no MIT para lidar com a ameaça soviética percebida. Seu estudo foi chamado
Projeto Charles. Seu resultado foi uma proposta à Força Aérea para um centro de pesquisa
dedicado à tarefa de criar tecnologia de defesa contra ataques aéreos. Assim Lincoln
O laboratório foi rapidamente formado, dotado de pessoal e colocado a trabalhar sob o comando de seu primeiro
diretor, o
físico Albert Hill. Em 1952, o laboratório mudou-se do campus para Lexington, cerca de dez milhas
a oeste de Cambridge. Seus principais projetos são centrados no conceito de Distant Early
Aviso - a linha DEW: conjuntos de radares que se estendem, de preferência, do Havaí ao Alasca,
através do arquipélago canadense até a Groenlândia e, finalmente, até a Islândia e as Ilhas Britânicas.
Problemas de comunicação, controle e análise para um tão extenso e complexo
estrutura só poderia ser tratada por um computador. Para satisfazer esse requisito, Lincoln primeiro
assumiu Whirlwind, um projeto de computador no MIT, e então desenvolveu um projeto sucessor
chamado de ambiente de solo semiautomático ou SAGE.
Baseado em um grande computador IBM, o SAGE era tão gigantesco que seus operadores e
os técnicos literalmente entraram na máquina. O sistema cumpria três funções principais:
receber dados de vários radares de detecção e rastreamento, interpretando dados relativos a
aeronaves não identificadas e apontando armas defensivas para aeronaves hostis que se aproximam. SÁBIO
era apenas "semiautomático", uma vez que o operador humano continuava sendo uma parte importante do
sistema. Na verdade, o SAGE foi um dos primeiros totalmente operacionais e interativos em tempo real
sistemas de computador. Os operadores se comunicavam com o computador por meio de monitores,
teclados, interruptores e armas leves. Os usuários podem solicitar informações do computador
e receba uma resposta em alguns segundos. Novas informações fluíram continuamente
diretamente na memória do computador por meio de linhas telefônicas para os usuários, tornando-o
imediatamente disponíveis para os operadores.
O sistema SAGE inspirou alguns pensadores, incluindo Licklider, a ver a computação em um
luz inteiramente nova. SAGE foi um dos primeiros exemplos do que Licklider mais tarde chamaria de
“Simbiose” entre humanos e máquinas, onde a máquina funciona como um problema-

Página 20
parceiro de resolução. Implícita nesta relação simbiótica estava a interdependência de
humanos e computadores trabalhando em uníssono como um único sistema. Por exemplo, em uma batalha
cenário, operadores humanos sem computadores seriam incapazes de calcular e analisar
ameaças com rapidez suficiente para conter um ataque. Por outro lado, computadores trabalhando sozinhos
ser incapaz de tomar decisões cruciais.
Em 1953, o MIT decidiu iniciar um grupo de fatores humanos na seção de psicologia do
departamento de economia, e Lick foi colocado no comando. Ele recrutou um punhado de seus
alunos e colegas mais brilhantes. Lick contratou pessoas com base não em seu trabalho de doutorado ou
classe em pé, mas em um teste simples que ele aplicou: o Teste de Analogias de Miller. (O teste cobre
todos os campos, da geologia à história e às artes. Requer bons conhecimentos gerais
e a capacidade de aplicar esse conhecimento aos relacionamentos.) “Eu tinha uma espécie de regra”, disse ele.
“Qualquer um que pudesse fazer 85 ou melhor no Teste de Analogias de Miller, contrate-o, porque ele
vai ser muito bom em alguma coisa. ”
Em 1954, o grupo de Lick mudou-se com os psicólogos sociais e a gestão do trabalho
especialistas da Sloan School of Management. Mas as ideias do grupo foram muito distantes
de problemas de gestão. Como McGill, um dos primeiros recrutas do Licklider, descreveu, ele e
seus colegas estavam muito mais interessados em computadores e dispositivos de memória de computador como
modelos
para a versatilidade da cognição humana. A primeira dissertação produzida pelo departamento
sob a orientação de Lick veio de Ph.D. candidato Tom Marill, que examinou o
sujeito da detecção auditiva ideal. (Como outros que entraram na esfera de Licklider, Marill
deixaria sua marca no desenvolvimento de redes de computadores nos próximos anos.)
“Nada parecido com isso já havia sido visto antes, pelo menos não em um departamento de psicologia,”
disse McGill. O departamento foi o primeiro departamento de ciências cognitivas da história. "O
trabalho foi psicologia cognitiva experimentalmente baseada, como seria definida hoje, mas
na época não tínhamos linguagem ou nomenclatura adequada. ”
Mas, eventualmente, os administradores do MIT queriam algo mais tradicional, e Lick falhou em
seus esforços para expandir seu novo departamento com nomeações permanentes. Como resultado, todos
seus protegidos, jovens e comerciáveis, se afastaram. “Não tínhamos sofisticação para
promover o que fizemos e não sabíamos que havia algo de único nisso. assim
O MIT deixou tudo escapar ”, disse McGill. Afinal, Lick era um dissidente e um pouco estranho,
talvez demais para o MIT.
No entanto, Lick não lamentou o fim do grupo, pois ele tinha uma curta auto-professada
atenção. Seus interesses mudaram com frequência e dramaticamente ao longo dos anos. Ele uma vez
aconselhou um jovem amigo a nunca se inscrever em um projeto que durasse mais de cinco a sete
anos, para que ele sempre pudesse passar para outras coisas. E qualquer coisa em que Lick se interessasse,
ele mergulhou em grande profundidade.
Talvez o incidente que mais despertou o interesse de Lick em computadores e seu potencial como
instrumentos interativos foi um encontro que ele teve na década de 1950 com um inteligente e teimoso
jovem engenheiro do Lincoln Labs chamado Wesley Clark. Clark era um jovem pesquisador
trabalhando na máquina TX-2, o estado da arte em computação digital e o
sucessor de um computador chamado TX-0. Clark construiu o TX-0 com Ken Olsen antes
Olsen saiu para fundar a Digital Equipment Corporation.

Página 21
O escritório de Clark ficava no porão de Lincoln. Um dia, voltando do
estoque na outra extremidade do corredor, Clark decidiu se aventurar em uma sala que tinha
sempre parecia vagamente fora dos limites. A maioria das portas do laboratório estava aberta, mas não esta. isso foi
sempre fechado. Clark tentou a porta, que ficou surpreso ao encontrar destrancada, e entrou
a sala. “Eu vaguei para dentro e para trás por um pequeno labirinto de defletores e barreiras,”
Clark lembrou. “De um lado estava um laboratório muito escuro e eu entrei, e depois
Sondando no escuro por um tempo, encontrei este homem sentado na frente de alguns monitores.
Ele estava fazendo algum tipo de psicometria e era claramente um sujeito interessante. Eu tenho
interessado no que ele estava fazendo e em seu aparelho, e pelo que me lembro, sugeri a ele
que ele poderia obter os mesmos resultados usando um computador. ” O homem era Licklider.
Clark convidou Lick para vir pelo corredor para ver o TX-2 e aprender alguns fundamentos.
Ensinar Lick a realmente programar a máquina teria sido muito difícil.
Programar um computador como o TX-2 era uma espécie de arte negra. O TX-2, que
continha 64.000 bytes de memória (o equivalente a uma calculadora simples de mão hoje),
alguns quartos. O que muitos anos depois se tornaram minúsculos microchips para o computador
unidade de processamento central eram, naquela época, enormes racks de muitas unidades de plug-in separadas,
cada um consistindo de dezenas de transistores e peças eletrônicas associadas. Ainda mais espaço
foi preenchido com grandes consoles cobertos com interruptores e luzes indicadoras para ajudar o
operador ou solucionador de problemas entender o que o sistema estava fazendo. Todo esse equipamento
necessário rack sobre rack de equipamentos, apenas uma pequena fração dos quais - a tela de vídeo
e teclado - podem ser reconhecidos hoje como peças comuns de computador. “Para sentar no
O TX-2 com Lick seria embutido em uma confusão de coisas aparentemente irrelevantes ”, disse Clark.
Tornar-se um “usuário” TX-2 teria sido um exercício assustador, mesmo para alguém como
rápido como Licklider. Por um lado, não havia ferramentas de ensino per se, nenhuma instrução
ajudas ou menus de ajuda. Por outro lado, o sistema operacional, que padronizaria
programação para a máquina, ainda não tinha sido escrita.
Uma coisa que o TX-2 fez muito bem foi exibir informações em telas de vídeo. Este
tornou-se uma das primeiras máquinas para trabalhos gráficos interativos. Foi esse recurso que
ajudou Clark a demonstrar para Lick as principais idéias do uso interativo.
As sessões com Clark deixaram uma impressão indelével em Lick. Ele se afastou ainda mais de
psicologia e para a ciência da computação. À medida que seus interesses mudavam, a crença de Lick no
o potencial dos computadores para transformar a sociedade tornou-se uma espécie de obsessão.
Sucumbindo à tentação da computação, ele começou a passar horas em um ambiente interativo
console de exibição. Louise acreditava que se ele não fosse pago por este trabalho, ele teria
pago para fazer isso.
A ideia na qual a visão de mundo de Lick se baseava era que o progresso tecnológico salvaria
humanidade. O processo político foi um exemplo favorito dele. Em uma visão McLuhanesca
do poder da mídia eletrônica, Lick viu um futuro no qual, em grande parte graças ao
alcance dos computadores, a maioria dos cidadãos seria "informada sobre, e interessada em, e
envolvidos no processo de governo. ” Ele imaginou o que chamou de “computador doméstico
consoles ”e aparelhos de televisão conectados em uma rede massiva. "O político
processo ”, escreveu ele,“ seria essencialmente uma teleconferência gigante e uma campanha
 Página 22
ser uma série de comunicações de meses de duração entre candidatos, propagandistas,
comentaristas, grupos de ação política e eleitores. A chave é a automotivação
alegria que acompanha a interação verdadeiramente eficaz com as informações por meio de um bom
console e uma boa rede para um bom computador. ”
Os pensamentos de Lick sobre o papel que os computadores podem desempenhar na vida das pessoas atingiram um
ponto culminante
1960 com a publicação de seu artigo seminal “Man-Computer Symbiosis”. Nele ele
destilou muitas de suas idéias em uma tese central: um acoplamento próximo entre humanos e
“Os membros eletrônicos da parceria” acabariam resultando em cooperação
tomando uma decisão. Além disso, as decisões seriam tomadas por humanos, usando computadores,
sem o que Lick chamou de “dependência inflexível de programas predeterminados”. Ele segurou
a visão de que os computadores continuariam naturalmente a ser usados para o que eles fazem melhor: todos
o trabalho mecânico. E isso liberaria os humanos para devotar energia para tomar melhores decisões
e desenvolver percepções mais claras do que seriam capazes sem computadores.
Juntos, Lick sugeriu, homem e máquina teriam um desempenho muito mais competente do que
qualquer um poderia sozinho. Além disso, atacar problemas em parceria com computadores poderia
economize o mais valioso dos recursos pós-modernos: tempo. “A esperança”, escreveu Licklider, “é
que em não muitos anos, cérebros humanos e máquinas de computação serão acoplados. . .
firmemente, e que a parceria resultante pensará como nenhum cérebro humano jamais pensou
e processar dados de uma forma não abordada pelas máquinas de tratamento de informações que
sabe hoje. ”
As ideias de Licklider, que tiveram seu início apenas alguns anos antes em uma chance
encontro no porão do Lincoln Lab, representou alguns dos mais ousados e
pensamento imaginativo do dia. Um ex-aluno do MIT, Robert Rosin, que havia feito
um curso de psicologia experimental de Lick em 1956 e mais tarde foi para o computador
ciência, leia "Simbiose Homem-Computador" e ficou pasmo com o intelectual do ancião
versatilidade. “Pela minha vida, não conseguia imaginar como um psicólogo que, em 1956, tinha
nenhum conhecimento aparente de computadores, poderia ter escrito uma profunda e perspicaz
artigo sobre 'meu campo' em 1960 ”, disse Rosin. “O artigo de Lick me impressionou profundamente
e aprimorou minha própria percepção de que uma nova era da computação estava sobre nós. ”
No momento em que Licklider publicou o artigo, sua reputação como cientista da computação
foi consertado para sempre. Ele abandonou o manto da psicologia e começou a trabalhar na computação. Houve
não voltá-lo de volta. Alguns anos antes de o artigo ser publicado, Licklider havia deixado
MIT vai trabalhar em uma pequena empresa de consultoria e pesquisa em Cambridge chamada Bolt Beranek
e Newman. A empresa concordou em comprar para ele dois computadores para suas pesquisas, e
ele estava tendo o melhor momento de sua vida.
Um dia, em 1962, o diretor da ARPA, Jack Ruina, ligou para Licklider com uma nova possibilidade de emprego.
O que Lick diria ao assumir não apenas a divisão de comando e controle do ARPA, mas um
nova divisão de ciências comportamentais também? E haveria um computador enorme, o Q-32,
jogado no negócio.
Ruina também visitou Fred Frick, amigo e colega de Lick no Lincoln Lab. Frick
e Licklider se encontraram com Ruina juntos. Licklider entrou preparado apenas para ouvir, mas estava
logo se tornando eloqüente sobre o assunto. Os problemas de comando e controle, ele disse a Ruina,

Página 23
eram essencialmente problemas de interação humano-computador. “Eu pensei que era só
ridículo ter sistemas de comando e controle baseados em processamento em lote ”, ele
lembrado anos depois. “Quem pode dirigir uma batalha quando precisa escrever o programa no
meio da batalha? " Licklider e Frick concordaram que o trabalho parecia interessante, mas
nenhum dos dois queria deixar o que estava fazendo.
O discurso de vendas de Ruina foi tão intenso, no entanto, e ele fez a missão parecer tão crítica,
que Frick e Licklider decidiram que um deles deveria fazer isso. Eles jogaram uma moeda, e Lick
aceitou a posição com a condição de que ele recebesse a liberdade de liderar o programa em
qualquer direção que ele achasse adequado. Em parte porque Ruina estava muito ocupado e em parte porque ele
não entendia de computadores, ele concordou com a condição sem hesitação.
Lick pertencia a um pequeno grupo de cientistas da computação que acreditavam que as pessoas poderiam ser
muito mais eficaz se eles tivessem na ponta dos dedos um sistema de computador com boas telas
e bons bancos de dados. Antes de se mudar para Washington no outono de 1962, Lick deu uma série
de seminários de informática no Pentágono, com boa participação do Departamento de Defesa e militares
funcionários. Sua mensagem, já meio que um mantra em Cambridge, mas ainda em grande parte
desconhecido para um público militar, era que um computador deveria ser algo que qualquer um poderia
interagir diretamente, eliminando os operadores de computador como intermediários na solução de seus
problemas.
Para este fim, Lick viu uma grande promessa no compartilhamento de tempo e foi um dos mais ardentes
evangelistas. O compartilhamento de tempo não colocava exatamente um computador na mesa de todos, mas
criou a ilusão de apenas isso. Trouxe o poder do computador direto para a
ponta dos dedos. Isso deu às pessoas uma forte percepção da máquina.
A promoção do time-sharing não era de forma alguma a única missão de Lick quando ele chegou
ARPA. Ele estava tão interessado em explorar as ideias que estavam se infiltrando
interação homem-máquina por vários anos.
Quando Lick chegou para seu primeiro dia de trabalho, em 1º de outubro de 1962, sua secretária disse: “Bem,
Dr. Licklider, você tem apenas uma consulta hoje. Há alguns senhores vindo
do Departamento de Orçamento para revisar seu programa. ” Quando os oficiais de orçamento
chegaram, eles se divertiram ao descobrir que era o primeiro dia de Licklider. Não havia muito de
substância para discutir ainda. O programa de comando e controle consistia em US $ 9 milhões
contrato - com a System Development Corporation - e os restantes $ 5 milhões ou mais em
o orçamento ainda não foi atribuído. Em vez de uma revisão do orçamento, a reunião foi transformada
em um colóquio privado, no qual Lick discorreu sobre tópicos como compartilhamento de tempo,
computação interativa e inteligência artificial. Como muitos outros antes deles, o
contadores foram infectados pelo entusiasmo de Licklider. “Eu disse a eles o que estava animado
sobre, e isso acabou funcionando muito a meu favor, porque eles se interessaram por isso, ”
ele disse mais tarde. “E quando tivemos uma reunião sobre isso, eles não levaram nada do meu dinheiro
longe."
A principal autorização que ele recebeu era para propor usos para outros computadores que não
como ferramentas para cálculos científicos numéricos. Lick desenvolveu novos programas em parte como um
reação contra algumas das aplicações que o Departamento de Defesa tinha em mente para grandes
computadores. A inteligência da Força Aérea, por exemplo, queria aproveitar enormes mainframes para

Página 24
detectar padrões de comportamento entre funcionários soviéticos de alto nível. O computador seria alimentado
informações de inteligência de uma variedade de fontes humanas, como boatos de coquetéis
festas ou observações em um desfile de Primeiro de Maio, e tente desenvolver um cenário de melhor suposição sobre
o que os soviéticos podem estar fazendo. “A ideia era que você pegasse este poderoso computador e
alimente-o com todas essas informações qualitativas, como "O chefe da Força Aérea bebeu dois martinis" ou
'Khrushchev não está lendo o Pravda às segundas-feiras' ”, relembrou Ruina. “E o computador
interpretaria Sherlock Holmes e concluiria que os russos devem estar construindo um MX-72
míssil ou algo parecido. ”
Primeiro Ruina, depois Licklider, tentou acabar com "tipos de coisas estúpidas", como Lick
descreveu os projetos mal concebidos. Então Lick trabalhou para encontrar o melhor do país
centros de informática e estabelecer contratos de pesquisa com eles. Em pouco tempo, ele alcançou
para os melhores cientistas da computação da época, de Stanford, MIT, UCLA, Berkeley e
um punhado de empresas, trazendo-as para a esfera do ARPA. Ao todo, havia cerca de
dúzias do círculo interno de Lick, que Ruina chamou de "sacerdócio de Lick". De maneira típica,
onde suas crenças mais apaixonadas mascaradas como uma piada, Licklider apelidou-o
a Rede Intergaláctica de Computadores.
Seis meses após sua chegada à ARPA, Lick escreveu um extenso memorando aos membros da
Rede Intergaláctica em que expressou sua frustração com a proliferação de
diferentes linguagens de programação, sistemas de depuração, controle de sistema de compartilhamento de tempo
linguagens e esquemas de documentação. Ao fazer o caso para uma tentativa de
padronização, Lick discutiu o problema hipotético de uma rede de computadores.
“Considere a situação em que vários centros diferentes estão interligados, cada centro
sendo altamente individualista e tendo sua própria linguagem especial e seu próprio jeito especial
de fazer coisas ”, postulou. “Não é desejável ou mesmo necessário que todos os centros
concordar com algum idioma ou, pelo menos, com algumas convenções para fazer tais perguntas
como 'Que língua você fala?' Nesse extremo, o problema é essencialmente aquele
discutido por escritores de ficção científica: Como você inicia a comunicação entre
seres sapientes totalmente não correlacionados? "
Dito isso, Lick evitou suas apostas. “Possivelmente acontecerá,” ele continuou, “que apenas em
raras ocasiões a maioria ou todos os computadores no sistema geral operam juntos em um
rede integrada. Parece-me importante, no entanto, desenvolver uma capacidade
para operação de rede integrada. ” E aí estava a semente da visão mais grandiosa de Licklider
ainda. Ele estenderia o conceito de Rede Intergaláctica para significar não apenas um grupo de
pessoas para quem ele estava enviando memorandos, mas um universo de computadores interconectados
que todos podem enviar seus memorandos.
Licklider não foi uma exceção à regra de que as pessoas não passam muito tempo na ARPA. Mas
quando ele saiu em 1964, ele conseguiu mudar a ênfase da agência em
computação R&D de um laboratório de sistemas de comando, jogando cenários de jogos de guerra para
pesquisa avançada em sistemas de compartilhamento de tempo, computação gráfica e computador aprimorado
línguas. O nome do escritório, Pesquisa de Comando e Controle, mudou para
refletem essa mudança, tornando-se o Escritório de Técnicas de Processamento de Informação. Licklider
escolheu seu sucessor, um colega chamado Ivan Sutherland, o maior especialista mundial em
gráficos de computador. Em 1965, Sutherland contratou um jovem figurão chamado Bob Taylor, que

Página 25
logo se sentaria na sala do terminal da ARPA e se perguntaria por que, com tantos
computadores, eles não conseguiam se comunicar uns com os outros.

Ideia de Taylor
Bob Taylor começou a faculdade em Dallas aos dezesseis anos pensando que iria seguir
passos de seu pai e se tornar um ministro. Sua família nunca viveu em um lugar muito
longo, mudando de uma igreja metodista para outra em todo o Texas, em cidades com nomes
como Uvalde, Victoria e Ozona. Mas, em vez de servir ao Senhor, Taylor entrou
o serviço da Marinha dos EUA quando sua unidade de reserva foi chamada para o serviço ativo para o
Guerra coreana.
Taylor passou a guerra na Estação Aérea Naval de Dallas - “o USS Neverfloat ” , ele o chamou.
No final da guerra, ele entrou na Universidade do Texas com o GI Bill sem nenhuma particularidade
curso de estudo em mente. Ele finalmente se formou em 1957 com especialização em psicologia e um
menor em matemática.
Taylor buscou seu amor pela ciência na pós-graduação na UT e escreveu sua dissertação
na psicoacústica, um campo no qual algumas pessoas estavam dando um salto para a computação.
Taylor saltou também. “Quando eu estava na pós-graduação, não havia ciência da computação”,
Taylor se lembrou, “então, eu realmente não tive muita introdução à computação. Mas eu
começou a sentir que a pesquisa em computação seria muito mais gratificante. ”
Recém-saído da escola, Taylor teve alguns empregos na indústria aeroespacial antes de conseguir um emprego
na NASA em 1961, onde trabalhou como oficial de programa em Washington, DC, no
Escritório de Pesquisa e Tecnologia Avançada. Um dia em 1963, Taylor foi convidado para
participar de um comitê não oficial de gerentes de programas governamentais, todos os quais eram
envolvidos no financiamento de pesquisas de informática. Era um grupo informal que simplesmente trocava
informações sobre seus projetos, procuraram formas de colaboração e tentaram evitar
duplicação ou sobreposição. O convite veio, como se viu, de alguém que tinha
foi o modelo intelectual de Taylor na psicoacústica - JCR Licklider. Ele era
chefe da comissão. O trabalho inicial de Licklider em psicoacústica influenciou profundamente
A própria Taylor e ele agradeceu a chance de conhecer o ilustre Licklider.
Taylor ficou impressionado com o quão modesto ele era. "Ele me lisonjeou imediatamente, dizendo que
conhecia meu trabalho de tese ”, disse Taylor. Aqui estava um homem com uma reputação gigante que era
provavelmente uma das pessoas mais legais e descontraídas que Taylor já conheceu.
Quando Taylor se juntou ao comitê, Licklider estava em processo de união
a comunidade de ciência da computação sob o ARPA, a nova geração de pesquisadores desenhada
à computação interativa. Eles estavam ocupados estruturando sua nova e ousada perspectiva, radicalmente
diferente do mainstream em pesquisa e desenvolvimento de computador durante o anterior
Duas décadas. Montanhas de dinheiro e anos de trabalho foram investidos na melhoria do
parâmetros técnicos de velocidade, confiabilidade e tamanho da memória dos computadores. Mas este pequeno
A vanguarda dos pesquisadores concentrados no MIT e em torno de Boston começou a trabalhar na
tornando o computador um amplificador do potencial humano, uma extensão da mente e do corpo.

Página 26
Taylor era conhecido por ter uma boa intuição. Ele foi considerado um
oficial de programa com visão de futuro que tinha um talento especial para escolher vencedores inovadores - ambos
projetos e pesquisadores. Ele ingressou na ARPA no início de 1965, após a saída de Licklider,
para trabalhar como adjunto de Ivan Sutherland, segundo diretor do IPTO. Meses depois, em 1966, em
aos trinta e quatro anos, Taylor tornou-se o terceiro diretor do IPTO, herdando a responsabilidade
para a comunidade e grande parte da visão - na verdade, o próprio escritório - estabelecido por
Licklider. A única diferença, que acabou sendo crucial, foi que o ARPA - agora
chefiado por Charles Herzfeld, um físico austríaco que fugiu da Europa durante a guerra -
foi ainda mais rápido e mais solto com seu dinheiro do que durante a gestão de Ruina. Uma piada
agora circulou entre seus diretores de programa: Tenha uma boa ideia para uma pesquisa
programa e levará cerca de trinta minutos para obter o financiamento.
O "problema terminal", como Taylor o chamou, era uma fonte de frustração não apenas para ele
mas para Sutherland antes dele e para Licklider antes disso. Um dia, pouco depois
tornando-se diretor de IPTO, Taylor se viu pensando em uma ideia que Lick discutira
com ele várias vezes, mas nunca realmente agiu. Agora que era seu relógio, Taylor
decidiu agir.
Taylor foi direto para o escritório de Herzfeld. Sem memorandos. Sem reuniões. Outro programa
diretores ficaram um pouco intimidados por Herzfeld, um homem grande com um grande estrondo
Sotaque vienense. Mas Taylor não viu nada a temer sobre o homem. Na verdade, Taylor se comportou
como um bom rapaz perto de seu chefe que alguém uma vez lhe perguntou: "Taylor, o que
você tem com Herzfeld? Você deve ser parente de Lyndon Johnson. Vocês dois são de
Texas, não é? "
Taylor disse ao diretor da ARPA que precisava discutir o financiamento para um experimento de rede
ele tinha em mente. Herzfeld já tinha falado um pouco sobre networking com Taylor, então o
ideia não era nova para ele. Ele também visitou o escritório de Taylor, onde testemunhou o
exercício irritante de fazer logon em três computadores diferentes. E alguns anos antes ele
tinha até mesmo caído no feitiço do próprio Licklider quando ele assistiu às palestras de Lick sobre
computação interativa.
Taylor deu a seu chefe um briefing rápido: empreiteiros IPTO, a maioria dos quais estavam em pesquisa
universidades, estavam começando a solicitar cada vez mais recursos de informática. Cada
o investigador principal, ao que parecia, queria seu próprio computador. Não só havia um
óbvia duplicação de esforços em toda a comunidade de pesquisa, mas estava ficando danado
caro. Os computadores não eram pequenos e não eram baratos. Por que não tentar amarrar todos eles
juntos? Ao construir um sistema de links eletrônicos entre as máquinas, os pesquisadores fazem
trabalhos semelhantes em diferentes partes do país poderiam compartilhar mais recursos e resultados
facilmente. Em vez de espalhar meia dúzia de mainframes caros por todo o país
dedicado a apoiar pesquisas gráficas avançadas, o ARPA poderia concentrar recursos em
um ou dois lugares e construir uma maneira para que todos possam chegar até eles. Uma universidade pode
concentrar-se em uma coisa, outro centro de pesquisa poderia ser financiado para se concentrar em
outra coisa, mas independentemente de onde você estivesse fisicamente localizado, você teria
acesso a tudo. Ele sugeriu que o ARPA financiasse uma pequena rede de teste, começando com, digamos,
quatro nós e acumulando até uma dúzia ou mais.

Página 27
O Departamento de Defesa foi o maior comprador de computadores do mundo. Investir em um
a marca específica do computador não era uma decisão trivial e muitas vezes colocava os diferentes serviços
em um dilema, especialmente quando confrontado com uma regra federal que determina que todos os fabricantes
sejam
dada oportunidade igual. Parecia não haver esperança de restringir a compra de um
toda uma variedade de máquinas. E as chances pareciam mínimas ou inexistentes de que o
O mundo da computação gravitaria em breve para um conjunto de padrões operacionais uniformes.
Patrocinadores de pesquisas como o ARPA teriam apenas que encontrar alguma outra maneira de superar o
problemas de incompatibilidade da indústria. Se a ideia da rede funcionasse, Taylor disse a Herzfeld,
seria possível que computadores de diferentes fabricantes se conectassem, e o
problema de escolha de computadores seria bastante reduzido. Herzfeld ficou tão impressionado com
essa possibilidade de que esses argumentos por si só poderiam ter sido suficientes para convencê-lo. Mas
havia outra vantagem, centrada na questão da confiabilidade. Pode ser possivel
para conectar computadores em uma rede de forma redundante, de modo que, se uma linha cair, uma mensagem
poderia seguir outro caminho.
"Vai ser difícil de fazer?" Perguntou Herzfeld.
"Ah não. Já sabemos como fazer ”, Taylor respondeu com ousadia característica.
“Ótima ideia”, disse Herzfeld. “Vá em frente. Você tem um milhão de dólares a mais em seu
orçamento agora. Ir."
Taylor saiu do escritório de Herzfeld no anel E e voltou para o corredor que conectava
para o anel D e seu próprio escritório. Ele olhou no seu relógio. "Jesus Cristo", disse ele para
ele suavemente. "Isso levou apenas vinte minutos."

2
Um bloco aqui, algumas pedras ali
Na época em que Taylor assumiu a diretoria do IPTO em 1966, manifestações de
A filosofia de Licklider era evidente em todo o estabelecimento de pesquisa em computação. o
fileiras de pesquisadores que esperam estender o computador além do status de um calculador
instrumento continuou a crescer ao longo da década. Alguns dos primeiros e mais
trabalho importante em gráficos interativos e realidade virtual estava ocorrendo no
Universidade de Utah usando dinheiro do ARPA. O MIT em particular, parecia criar um
desenvolvimento inovador após o outro. Há Marvin Minsky e Seymour Papert
estiveram envolvidos em importantes trabalhos iniciais em inteligência artificial. Programas em outros
instituições focadas em técnicas avançadas de programação, compartilhamento de tempo e computador
línguas.
Construir uma rede como um fim em si mesma não era o objetivo principal de Taylor. Ele estava tentando
para resolver um problema que ele via piorar a cada rodada de financiamento. Pesquisadores eram
duplicar e isolar recursos de computação caros. Não apenas os cientistas estavam
cada site se envolvendo em mais e mais diversificadas pesquisas de computador, mas suas demandas por
os recursos do computador estavam crescendo mais rápido do que o orçamento de Taylor. Cada novo projeto

Página 28
necessário configurar uma operação de computação nova e cara. Dependendo do computador
sendo usados e o número de alunos de pós-graduação sendo apoiados, IPTO's individuais
os subsídios variaram de $ 500.000 a $ 3 milhões.
E nenhum dos recursos ou resultados foi facilmente compartilhado. Se os cientistas fazendo gráficos em
Salt Lake City queria usar os programas desenvolvidos pelo pessoal do Lincoln Lab, eles
teve que voar para Boston. Ainda mais frustrante, se depois de uma viagem a Boston, as pessoas em Utah quisessem
para iniciar um projeto semelhante em sua própria máquina, eles precisariam gastar uma quantidade considerável
tempo e dinheiro duplicando o que acabaram de ver. Naquela época, os programas de software
eram únicos, como obras de arte originais, e não eram facilmente transferidos de um
máquina para outra. Taylor estava convencido da viabilidade técnica de compartilhar tais
recursos em uma rede de computadores, embora isso nunca tenha sido feito.
Além do corte de custos, a ideia de Taylor revelou algo muito profundo. De uma máquina
capacidade de amplificar o poder intelectual humano era precisamente o que Licklider tinha em mente
enquanto escrevia seu artigo sobre a simbiose homem-máquina seis anos antes. Claro,
As ideias de Licklider sobre o compartilhamento do tempo já estavam dando frutos em universidades em todo o
país. Mas a ideia de networking marcou um afastamento significativo do time-sharing. Em um
rede de compartilhamento de recursos, muitas máquinas serviriam a muitos usuários diferentes, e um
pesquisador interessado em usar, digamos, um programa gráfico específico em uma máquina dois
milhares de milhas de distância simplesmente se conectariam a essa máquina. A ideia de um computador
buscar recursos dentro de outra, como colegas em uma organização colaborativa,
representou a concepção mais avançada que surgiu da visão de Licklider.
Taylor tinha o dinheiro e o apoio de Herzfeld, mas precisava de um gerente de programa
que poderia supervisionar o projeto e a construção de tal rede, alguém que não apenas
conhecia as idéias de Licklider, mas acreditava nelas. Essa pessoa tinha que ser um computador de primeira linha
cientista, confortável com uma ampla gama de questões técnicas.
Como isso deveria ser alcançado não preocupava muito Taylor, contanto que a rede fosse
confiável e rápido. Essas eram suas prioridades. Computação interativa significava que você obteria um
resposta rápida de um computador, portanto, no ambiente de computação moderno, fazia sentido
que uma rede também deve ser altamente responsiva. E para ser útil, tinha que funcionar
sempre que você precisar. Quem projetou tal rede precisava ser um especialista em
sistemas de telecomunicações também. Não foi uma combinação fácil de encontrar. Mas taylor
já tinha alguém em mente: um jovem cientista da computação tímido e pensativo da
O terreno fértil do Lincoln Labs é chamado de Larry Roberts.
No início de 1966, Roberts estava na Lincoln trabalhando com gráficos. Mas ele também tinha feito bastante
muito trabalho em comunicações. Ele tinha acabado de completar uma das provas mais relevantes de
principais experimentos em rede até o momento, conectando dois computadores em um continente
separados. Taylor havia financiado o experimento de Roberts. Teve sucesso suficiente para construir
A confiança de Taylor e convencer a si mesmo e a Herzfeld de que um pouco mais complexo
rede era viável. E o conhecimento de Roberts sobre computadores era profundo. O filho de
Químicos de Yale, Roberts frequentou o MIT e recebeu sua introdução aos computadores em
o TX-0. Embora tenha sido o primeiro computador digital transistorizado, o TX-0 era limitado
(a subtração não estava em seu repertório; ela só poderia subtrair adicionando um número negativo).

Página 29
Usando o TX-0, Roberts aprendeu sozinho os conceitos básicos de projeto e operação de computadores.
Roberts, na verdade, havia escrito todo o sistema operacional para seu sucessor, o TX-2
computador em Lincoln, que Wes Clark (que construiu o TX-0 com Ken Olsen) tinha
fatalmente mostrado para Licklider. Quando Clark deixou Lincoln em 1964, o trabalho de supervisão
o TX-2 caiu nas mãos de Roberts.
Taylor não conhecia Roberts muito bem. Parecia que ninguém conhecia Roberts muito bem. Ele
foi tão reservado em suas maneiras quanto Taylor foi aberto em suas. As pessoas com quem Roberts
trabalhou mais de perto não sabia quase nada sobre sua vida pessoal. O que se sabia sobre
ele era que além de expertise em computação e telecomunicações, ele tinha um talento especial
para gestão. O estilo de Roberts era simples, direto, inequívoco e terrivelmente eficaz.
Roberts tinha a reputação de ser um gênio. Aos vinte e oito anos, ele tinha feito
mais no campo da computação do que muitos cientistas conseguiram durante a vida. Abençoado
com uma resistência incrível, ele trabalhava até tarde demais. Ele também era um estudioso rápido:
Mais do que algumas pessoas tiveram a experiência de explicar a Roberts algo que
vinha trabalhando intensamente por anos, e descobri que em poucos minutos ele tinha
agarrou, girou em sua cabeça algumas vezes e fez comentários incisivos
Dele mesmo. Roberts lembrou um pouco a Taylor de Licklider, mas sem o senso de Lick de
humor.
Roberts também era conhecido por sua habilidade quase obsessiva de mergulhar em um desafio,
despejando intensos poderes de concentração em um problema. Um colega certa vez lembrou do
vez que Roberts fez um curso de leitura dinâmica. Ele rapidamente dobrou sua leitura já rápida
taxa, mas ele não parou por aí. Ele mergulhou na literatura profissional de leitura dinâmica
e continuou se esforçando até que ele estava lendo a uma taxa fenomenal de cerca de trinta
mil palavras por minuto com 10 por cento de "compreensão seletiva", como Roberts
descreveu. Depois de alguns meses, o fator limitante de Roberts não tinha nada a ver com seus olhos
ou seu cérebro, mas com a velocidade com que ele poderia virar as páginas. “Ele pegava um
livro e pronto em dez minutos ”, observou o amigo. “Era típico
Larry. ”
Taylor ligou para Roberts e disse que gostaria de ir a Boston para vê-lo. Alguns dias
mais tarde, Taylor estava sentado no escritório de Roberts no Lincoln Lab, contando-lhe sobre o
experimento que ele tinha em mente. Enquanto Taylor falava, Roberts murmurou um "hmm-hmm" nasal como
se disser “por favor, continue”. Taylor descreveu não apenas o projeto, mas uma oferta de trabalho. Roberts
seria contratado como diretor de programa da rede experimental, com o entendimento
que ele seria o próximo na fila para a diretoria do IPTO. Taylor deixou claro que este
projeto teve o apoio total do diretor da ARPA e que Roberts receberia amplo
latitude para projetar e construir a rede da maneira que ele achasse adequado. Taylor esperou por uma resposta.
"Vou pensar sobre isso", disse Roberts categoricamente.
Taylor leu isso como a maneira educada de Roberts de dizer não, e ele deixou Boston desanimado.
Em qualquer outra circunstância, ele simplesmente teria riscado Roberts da lista e chamado
sua segunda escolha. Mas ele não teve uma segunda escolha. Roberts não só tinha o
compreensão técnica necessária, mas Taylor sabia que ouviria Licklider e Wes
Clark, ambos apoiando a ideia de Taylor.

Página 30
Algumas semanas depois, Taylor fez uma segunda viagem a Lincoln. Desta vez, Roberts foi mais
próximo. Ele disse a Taylor educadamente, mas de forma inequívoca que estava gostando de seu trabalho na
Lincoln e não tinha nenhum desejo de se tornar um burocrata de Washington.
Desconsolado, Taylor foi a Cambridge para visitar Lick, que agora estava de volta ao MIT
abrigado em um esforço de pesquisa sobre compartilhamento de tempo chamado Projeto MAC. Eles discutiram quem
outra coisa pode ser adequada para o trabalho. Lick sugeriu algumas pessoas, mas Taylor rejeitou
eles. Ele queria Roberts. A partir de então, a cada dois meses ou mais, durante as visitas a
Outros empreiteiros da ARPA na área de Boston, Taylor, convocou Roberts para tentar persuadi-lo a
faça ele mudar de idéia.
Fazia quase um ano desde a conversa de vinte minutos de Taylor com Herzfeld, e
a ideia de rede estava fracassando por falta de um gerente de programa. Um dia no final de 1966,
Taylor voltou ao escritório do diretor do ARPA.
“Não é verdade que a ARPA está dando a Lincoln pelo menos cinquenta e um por cento de seu financiamento?”
Taylor perguntou a seu chefe.
"Sim, é", respondeu Herzfeld, ligeiramente intrigado.
Taylor então explicou a dificuldade que estava tendo para conseguir o engenheiro que queria executar
o programa de rede.
"Quem é esse?" Perguntou Herzfeld.
Taylor disse a ele. Em seguida, ele fez outra pergunta ao chefe. Herzfeld chamaria o
diretor do Lincoln Lab e peça a ele para ligar para Roberts e dizer que seria em seu
para seu próprio interesse - e no melhor interesse de Lincoln - concordar em aceitar o emprego em Washington?
Herzfeld pegou o telefone e ligou para Lincoln Lab. Ele colocou o diretor na linha
e disse exatamente o que Taylor havia pedido que ele dissesse. Foi uma conversa curta mas, de
o que Taylor poderia dizer, Herzfeld não encontrou resistência. Herzfeld desligou, sorriu para
Taylor e disse: “Bem, tudo bem. Veremos o que acontece." Duas semanas depois, Roberts
aceitou o trabalho.
Larry Roberts tinha vinte e nove anos quando entrou no Pentágono como representante da ARPA
mais novo redator. Ele se adaptou rapidamente e sua antipatia pelo tempo ocioso logo se tornou lendária.
Dentro de algumas semanas, ele tinha o lugar - um dos maiores e mais labirínticos
edifícios - memorizados. A locomoção no prédio foi complicada pelo fato de
certos corredores foram bloqueados como áreas classificadas. Roberts obteve um cronômetro e
começou a cronometrar várias rotas para seus destinos frequentes. ”A Rota de Larry” logo se tornou
comumente conhecida como a distância mais rápida entre quaisquer dois pontos do Pentágono.
Mesmo antes de seu primeiro dia na ARPA, Roberts tinha um esboço rudimentar do computador
rede descobriu. Então, e por anos depois, conforme o projeto crescia, Roberts desenhou
diagramas de rede meticulosos, esboçando onde as linhas de dados devem ir, e o
número de saltos entre os nós. Em papel vegetal e quadrilha, ele criou centenas
de esboços conceituais e lógicos como estes:

Página 31

Página 32
(Mais tarde, depois que o projeto estivesse em andamento, Roberts combinaria com Howard Frank, um
especialista na área de topologia de rede, para realizar análises baseadas em computador sobre como
esquematizar a rede de maneira mais econômica. Ainda assim, por anos Roberts teve a rede
layout e os detalhes técnicos que o definem, nitidamente retratados em sua cabeça.)
Já se sabia muito sobre como construir redes de comunicação complicadas para
carregam voz, som e outros sinais mais elementares. A AT&T, é claro, teve
hegemonia quando se tratava da rede telefônica. Mas a transmissão sistemática de
informações anteriores a Ma Bell em pelo menos alguns milhares de anos. Data de sistemas de mensageiro
pelo menos desde o reinado do rei egípcio Sesostris I, quase quatro mil anos
atrás. O primeiro sistema de retransmissão, onde uma mensagem foi passada de uma estação de guarda para o
em seguida, surgiu em 650B.C. Por centenas de anos depois, a invenção foi impulsionada pelo
necessidade de maior velocidade como a transmissão de mensagens de um lugar para outro
progrediu através de pombos, gritadores, bandeiras codificadas, espelhos, lanternas, tochas e faróis.
Então, em 1793, as primeiras notícias foram trocadas usando semáforos - pivôs giratórios em um
torre que parecia uma pessoa segurando bandeiras de sinalização com os braços estendidos.
Em meados de 1800, as redes telegráficas dependiam da eletricidade e da Western Union
A Telegraph Company começou a cobrir os Estados Unidos com uma rede de fios para
transmissão de mensagens na forma de impulsos elétricos. O telégrafo foi um clássico do início

Página 33
exemplo do que é chamado de “rede armazenar e encaminhar”. Por causa das perdas elétricas, o
os sinais tiveram que ser encaminhados através de uma sequência de estações retransmissoras. No início,
as mensagens que chegavam aos centros de comutação eram transcritas à mão e encaminhadas via
Código Morse para a próxima estação. Mais tarde, as mensagens que chegavam eram armazenadas automaticamente
em
digitou fitas de papel até que um operador pudesse redigitar a mensagem para a próxima etapa. Em 1903,
as mensagens que chegavam eram codificadas em um pedaço de fita de papel como uma série de pequenos orifícios,
e
a fita rasgada estava pendurada em um gancho. As fitas foram retiradas dos ganchos pelos balconistas e
alimentados por um leitor de fita que os encaminhava automaticamente em código Morse.
Em meados do século XX, depois que o telefone suplantou o telégrafo
como principal meio de comunicação, a American Telephone and Telegraph
A empresa detinha um monopólio completo - embora estritamente regulamentado - de longa distância
comunicações dentro dos Estados Unidos. A empresa foi tenaz em seu
reduto tanto do serviço telefônico quanto do equipamento que tornou esse serviço possível.
A anexação de equipamento estrangeiro (não Bell) às linhas da Bell foi proibida no local
que dispositivos estranhos podem danificar todo o sistema telefônico. Tudo adicionado ao
sistema teve que funcionar com o equipamento existente. No início dos anos 1950, uma empresa começou
fabricar um dispositivo chamado Hush-A-Phone, uma capa de plástico para a boca projetada para
permitir que um chamador fale ao telefone sem ser ouvido. AT&T teve sucesso em
tendo a Federal Communications Commission proibindo o dispositivo após apresentar o especialista
testemunhas que descreveram como o Hush-A-Phone danificou o sistema telefônico ao
reduzindo a qualidade do telefone. Em outro exemplo de zelo da AT&T, a empresa processou um
agente funerário no Meio-Oeste que distribuía capas de plástico de listas telefônicas de graça. AT&T
argumentou que a capa de uma lista telefônica de plástico obscureceu o anúncio na capa do
Páginas Amarelas e reduziram o valor da publicidade paga, receitas que ajudaram a reduzir
o custo do serviço telefônico.
Quase não havia maneira de trazer uma nova tecnologia radical ao Sistema Bell para coexistir
com o velho. Não foi até 1968, quando a FCC permitiu o uso do Carterfone - um
dispositivo para conectar rádios bidirecionais privados com o sistema telefônico - que AT&T
O controle implacável do sistema de telecomunicações do país foi afrouxado. Não surpreendentemente,
então, no início dos anos 1960, quando a ARPA começou a explorar uma forma inteiramente nova de
transmitindo informações, a AT&T não queria fazer parte disso.

Invenções coincidentes
Assim como as criaturas vivas evoluem por meio de um processo de mutação e seleção natural, as idéias
na ciência e suas aplicações na tecnologia fazem o mesmo. Evolução na ciência, como em
a natureza - normalmente uma sequência gradual de mudanças - ocasionalmente torna um processo revolucionário
salto rompendo com o curso de desenvolvimento. Novas ideias surgem simultaneamente, mas
independentemente. E assim fizeram quando chegou a hora de inventar uma nova maneira de
transmitir informações.
No início dos anos 1960, antes mesmo de Larry Roberts começar a trabalhar na criação de um novo computador
rede, dois outros pesquisadores, Paul Baran e Donald Davies - completamente desconhecido para
uns aos outros e trabalhando continentes separados em direção a objetivos diferentes - chegamos virtualmente ao

Página 34
mesma ideia revolucionária para um novo tipo de rede de comunicações. A realização de
seus conceitos passaram a ser conhecidos como comutação de pacotes.
Paul Baran era um imigrante bem-humorado da Europa Oriental. Ele nasceu em 1926,
no que era então a Polônia. Seus pais buscaram refúgio nos Estados Unidos dois anos depois,
após uma longa espera pelos documentos de imigração. A família chegou a Boston, onde
O pai de Paul foi trabalhar em uma fábrica de sapatos e mais tarde se estabeleceu na Filadélfia, onde
abriu uma pequena mercearia. Quando menino, Paul entregava mantimentos para seu pai usando uma pequena
vagão vermelho. Uma vez, quando tinha cinco anos, perguntou à mãe se eles eram ricos ou pobres. "Estavam
pobres ”, ela respondeu. Mais tarde, ele fez a mesma pergunta ao pai. “Somos ricos”, os mais velhos
Baran respondeu, fornecendo a seu filho o primeiro de muitos enigmas existenciais em seu
vida.
Paul acabou frequentando a escola a dois saltos de bonde de casa no Instituto Drexel de
Tecnologia, que mais tarde se tornou a Drexel University. Ele foi desconsiderado pela escola
ênfase pesada naqueles dias na resolução rápida de problemas numéricos: Dois triviais
erros aritméticos em um teste (corrida contra o relógio), e você falhou, independentemente de
ou não compreendeu fundamentalmente os problemas. Na época, Drexel estava tentando
criar uma reputação de ser um lugar difícil e prático e se orgulhar de sua alta
taxa de evasão. Os instrutores da Drexel disseram aos seus engenheiros que os empregadores queriam apenas
aqueles que podiam calcular de forma rápida e correta. Para sua consternação, Baran viu muitos brilhantes,
amigos criativos expulsos pela “atitude machista” da escola em relação à matemática. Mas ele
resistiu e, em 1949, formou-se em engenharia elétrica.
Os empregos eram escassos, então ele aceitou a primeira oferta que veio, do Eckert-Mauchly Computer
Corporação. Na capacidade relativamente mundana de técnico, ele testou peças para rádio
tubos e diodos de germânio no primeiro computador comercial - o UNIVAC.Baran em breve
casado, e ele e sua esposa se mudaram para Los Angeles, onde ele conseguiu um emprego na Hughes
Aeronaves trabalhando em sistemas de processamento de dados de radar. Ele teve aulas noturnas na UCLA em
computadores e transistores, e em 1959 ele recebeu um diploma de mestre em engenharia.
Baran deixou a Hughes no final de 1959 para ingressar no departamento de ciência da computação no
divisão de matemática na RAND Corporation enquanto continua a ter aulas em
UCLA. Baran era ambivalente, mas seu conselheiro na UCLA, Jerry Estrin, o incentivou a
continuar seus estudos para o doutorado. Logo, uma agenda pesada de viagens o forçou a
faltar às aulas. Mas foi finalmente a intervenção divina, disse ele, que desencadeou sua decisão de
abandonar o trabalho de doutorado. “Eu estava dirigindo um dia da RAND para a UCLA e não pude
encontrar um único lugar de estacionamento em toda a UCLA nem em toda a cidade adjacente de Westwood, ”
Baran lembrou. “Naquele instante concluí que era a vontade de Deus que eu
interromper a escola. Por que outro motivo Ele teria achado necessário preencher todo o estacionamento
lotes naquele exato instante? ”
Logo depois que Baran chegou à RAND, ele desenvolveu um interesse na capacidade de sobrevivência de
sistemas de comunicação sob ataque nuclear. Ele foi motivado principalmente pelo
pairando sobre as tensões da guerra fria, não os desafios de engenharia envolvidos. Tanto o
Estados Unidos e União Soviética estavam em processo de construção de armas nucleares ativas
arsenais de mísseis balísticos. Em 1960, a escalada da corrida armamentista entre os Estados Unidos

Página 35
e a União Soviética aumentou a ameaça do Juízo Final - aniquilação nuclear - sobre
vida diária em ambos os países.
Baran sabia, assim como todos os que entendiam de armas nucleares e tecnologia de comunicação,
que os primeiros sistemas de comando e controle para lançamento de mísseis eram perigosamente frágeis.
Para os líderes militares, a parte "comando" da equação significava ter todas as armas,
pessoas e máquinas dos militares modernos à sua disposição e sendo capazes de "levá-los
fazer o que você quer que eles façam ”, explicou um analista. “Controle” significava apenas o
oposto - "fazer com que eles não façam o que você não quer". A ameaça de um
país ou outro tendo seus sistemas de comando destruídos em um ataque e sendo deixado
incapaz de lançar um ataque defensivo ou retaliatório deu origem ao que Baran descreveu como "um
perigosa tentação para qualquer uma das partes entender mal as ações da outra e disparar
primeiro."
Na opinião dos estrategistas da RAND, era uma condição necessária que as comunicações
sistemas de armas estratégicas sejam capazes de sobreviver a um ataque, então a retaliação do país
capacidade ainda pode funcionar. Na época, as comunicações de longa distância do país
as redes eram de fato extremamente vulneráveis e incapazes de resistir a um ataque nuclear. Ainda
a capacidade do presidente de solicitar ou cancelar o lançamento de mísseis americanos (chamados
“Comunicação essencial mínima”), dependia fortemente da vulnerabilidade da nação
sistemas de comunicação. Então, Baran sentiu que trabalhar no problema de construir mais
infraestrutura de comunicações estável, ou seja, uma rede mais resistente e robusta, foi a
o trabalho mais importante que ele poderia estar fazendo.
Baran não foi o primeiro na RAND a pensar sobre esse problema. Na verdade, era o estoque da RAND
no comércio para estudar essas coisas. A RAND foi criada em 1946 para preservar a
capacidade de pesquisa operacional desenvolvida durante a Segunda Guerra Mundial. A maioria de seus contratos
veio
da Força Aérea. O problema de sobrevivência do sistema de comunicação era
algo em que a divisão de comunicações da RAND estava trabalhando, mas com
sucesso. Baran foi um dos primeiros a determinar, pelo menos em um nível teórico, que o
problema era realmente solucionável. E ele foi, sem dúvida, o primeiro a ver que o caminho para
resolvê-lo aplicando tecnologia de computador digital.
Poucos especialistas em eletrônica em outros departamentos da RAND sabiam muito sobre o
campo emergente da tecnologia de computador digital, e menos ainda pareciam interessados. Baran
relembrou sua percepção de como seu próprio pensamento era diferente do deles: “Muitas das coisas
Achei que possível tenderia a soar como um total absurdo, ou impraticável, dependendo
a generosidade de espírito daqueles que foram criados em um mundo anterior. ” E não era só dele
colegas da RAND que lançaram um olhar cético sobre o pensamento de Baran. O tradicional
comunidade de comunicações em geral rapidamente descartou suas idéias como não apenas atrevidas, mas
insustentável.
Em vez de se esquivar, Baran apenas mergulhou mais fundo em seu trabalho. RAND permitido
investigadores liberdade suficiente para perseguir suas próprias idéias, e no final de 1960 Baran's
o interesse e o conhecimento das redes cresceram em um pequeno projeto independente.
Convencido do mérito de suas ideias, ele começou a escrever uma série de
documentos técnicos para responder às objeções levantadas anteriormente e explicar em aumentar

Página 36
detalhe o que ele estava propondo. O trabalho, como ele explicou anos depois, não foi feito fora de
curiosidade intelectual nem desejo de publicar. “Foi feito em resposta à maioria
situação perigosa que já existiu ”, disse ele.
No Pentágono, Baran encontrou planejadores que estavam pensando em termos não emocionais sobre
cenários pós-ataque e fazer estimativas quantitativas da destruição que
resultado de um ataque de míssil balístico nuclear soviético. “Existe a possibilidade de uma guerra, mas
há muito que pode ser feito para minimizar as consequências ”, escreveu Baran. “Se a guerra fizer
não significa o fim da terra em preto e branco, então segue-se que devemos
faça aquelas coisas que tornam o tom de cinza o mais claro possível: planejar agora para minimizar
destruição potencial e fazer todas as coisas necessárias para permitir que os sobreviventes do
holocausto para descascar suas cinzas e reconstruir a economia rapidamente. ”
O primeiro artigo de Baran revelou vislumbres de suas ideias nascentes e revolucionárias sobre a teoria
e estrutura das redes de comunicação. Ele havia chegado provisoriamente à noção de que um
rede de dados poderia se tornar mais robusta e confiável, introduzindo níveis mais elevados de
redundância. Os computadores eram fundamentais. Independentemente de Licklider e outros na área de computação
avant-garde, Baran viu muito além da computação convencional, para o futuro do digital
tecnologias e a simbiose entre humanos e máquinas.
Baran estava trabalhando no problema de como construir estruturas de comunicação cujo
componentes sobreviventes podem continuar a funcionar como uma entidade coesa após outras peças
foram destruídos. Ele teve longas conversas com Warren McCulloch, um eminente psiquiatra da
Laboratório de Pesquisa de Eletrônica do MIT. Eles discutiram o cérebro, sua rede neural
estruturas, e o que acontece quando alguma parte está doente, particularmente como o cérebro
as funções às vezes podem se recuperar evitando uma região disfuncional. “Bem, nossa, você
sabe, ”Baran lembrou de pensar,“ o cérebro parece ter algumas das propriedades que
seria necessária uma estabilidade real. ” Pareceu-lhe significativo que as funções cerebrais não
contam com um único conjunto de células dedicado e exclusivo. É por isso que as células danificadas podem ser
contornados enquanto as redes neurais se recriam por meio de novos caminhos no cérebro.
A noção de dividir uma única grande estrutura vulnerável em várias partes, como uma defesa
mecanismo, pode ser visto em muitas outras aplicações. O conceito não é totalmente diferente
à ideia de estruturas segmentadas ou compartimentadas usadas em cascos de navios modernos ou
caminhões-tanque a gasolina. Se apenas uma ou duas áreas da pele forem rompidas, apenas uma seção de
a estrutura geral perde sua utilidade, não a coisa toda. Alguns grupos terroristas e
operações de espionagem empregam um tipo semelhante de organização compartimentada para impedir
autoridades, que poderiam eliminar uma célula sem prejudicar todo o grupo.
Teoricamente, pode ser possível configurar uma rede com vários redundantes
conexões, e você “começaria a obter estruturas como redes neurais”, disse Baran.
Mas havia uma limitação técnica, uma vez que todos os sinais na rede telefônica eram
sinais analógicos. O plano de comutação telefônica proibia que mais de cinco links fossem
conectado em conjunto, porque a qualidade do sinal se deteriorou rapidamente com o aumento
número de links em tandem. Em cada link comutado, o sinal seria ligeiramente distorcido e
a qualidade degradada gradativamente. Isso é semelhante ao que acontece quando alguém faz

Página 37
cópias de cópias de fitas de áudio. A cada nova geração, a qualidade se deteriora,
eventualmente tornando-se irremediavelmente distorcido.
Ao contrário dos sistemas analógicos, as tecnologias digitais convertem essencialmente informações de todos os
tipos,
incluindo som e imagem, para um conjunto de 1s e 0s. As informações digitalizadas podem ser armazenadas
de forma eficiente e replicada um número ilimitado de vezes dentro dos circuitos de um digital
dispositivo, reproduzindo os dados com uma precisão quase perfeita. Em um contexto de comunicação,
informações que são codificadas digitalmente podem ser passadas de um switch para o outro com
muito menos degradação do que na transmissão analógica.
Como Baran escreveu em seu artigo inicial: “O momento para tal pensamento é particularmente
apropriado agora, pois estamos apenas começando a delinear designs para os dados digitais
sistema de transmissão do futuro. ” Os tecnólogos poderiam imaginar de forma realista novos
sistemas onde os computadores falariam uns com os outros, permitindo uma rede com
links conectados sequencialmente o suficiente para criar níveis adequados de redundância. Estes
estruturas vinculadas se assemelham - de uma forma muito modesta - a estruturas incrivelmente complicadas
bilhões de ligações entre os neurônios do cérebro. E os computadores digitais oferecem velocidade.
As chaves telefônicas mecânicas da época demoravam vinte ou trinta segundos apenas para estabelecer
uma única conexão de longa distância em uma linha telefônica típica.
Ao falar com vários comandantes militares, Baran descobriu que a comunicação adequada
em tempo de guerra requer a transmissão de muito mais dados do que o “mínimo
comunicações essenciais. ” Exatamente quanto mais era difícil saber, então Baran mudou
o objetivo de uma rede capaz de suportar quase qualquer volume de tráfego imaginável.
A configuração de rede teórica básica de Baran era tão simples quanto dramaticamente
diferente e novo. As redes telefônicas sempre foram construídas usando centrais
pontos de comutação. Os mais vulneráveis são as redes centralizadas com todos os caminhos
levando a um único centro nervoso. O outro projeto comum é uma rede descentralizada
com vários centros nervosos principais em torno dos quais os links estão agrupados, com algumas linhas longas
conexão entre clusters; é basicamente assim que o sistema telefônico de longa distância ainda
parece em termos esquemáticos hoje.
A ideia de Baran constituiu uma terceira abordagem para o projeto de rede. Ele chamou seu de distribuído
rede. Evite ter um switch central de comunicações, disse ele, e construa uma rede
composto de vários nós, cada um redundantemente conectado ao seu vizinho. O original dele
diagrama mostrou uma rede de nós interconectados que se assemelham a uma rede distorcida, ou peixe
internet.

Página 38
A questão permaneceu: quanta redundância nas interconexões entre
nós vizinhos seriam necessários para a sobrevivência? "Nível de redundância" era o de Baran
termo para o grau de conectividade entre os nós da rede. Uma rede distribuída
com o número mínimo absoluto de links necessários para conectar cada nó foi dito
tem um nível de redundância de 1 e foi considerado extremamente vulnerável. Baran correu
numerosas simulações para determinar a probabilidade de sobrevivência da rede distribuída sob
uma variedade de cenários de ataque. Ele concluiu que um nível de redundância tão baixo quanto 3 ou 4—
cada nó conectado a três ou quatro outros nós - forneceria um excepcionalmente alto
nível de robustez e confiabilidade. “Apenas um nível de redundância de talvez três ou quatro seria
permitir uma rede quase tão robusta quanto o limite teórico ”, disse ele. Mesmo depois de um nuclear
ataque, deve ser possível encontrar e usar algum caminho através da rede restante.
“Essa foi uma descoberta muito feliz porque significava que não precisaríamos comprar um
grande quantidade de redundância para construir redes de sobrevivência ”, disse Baran. Mesmo de baixo custo,
links não confiáveis seriam suficientes, desde que houvesse pelo menos três vezes o mínimo
número deles.
A segunda grande ideia de Baran foi ainda mais revolucionária: fraturar as mensagens também. De
dividindo cada mensagem em partes, você poderia inundar a rede com o que ele chamou
“Blocos de mensagens”, todos correndo por caminhos diferentes até seu destino. Após a sua chegada, um
o computador receptor remontaria os bits da mensagem em uma forma legível.
Conceitualmente, esta foi uma abordagem emprestada mais do mundo dos transportadores de carga do que
especialistas em comunicação. Pense em cada mensagem como se fosse uma grande casa e pergunte
como você mudaria aquela casa através do país de, digamos, Boston para Los
Angeles. Teoricamente, você poderia mover toda a estrutura de uma só peça. Mudanças de casa
faça isso em distâncias mais curtas o tempo todo - lenta e cuidadosamente. No entanto, é mais
eficiente para desmontar a estrutura se puder, carregar as peças nos caminhões e conduzir
aqueles caminhões sobre o sistema de rodovias interestaduais do país - outro tipo de distribuição
rede.
Nem todo caminhão fará a mesma rota; alguns motoristas podem passar por Chicago e
alguns através de Nashville. Se um motorista descobrir que a estrada está ruim ao redor de Kansas City, por
por exemplo, ele pode seguir uma rota alternativa. Contanto que cada motorista tenha instruções claras
dizendo a ele onde entregar sua carga e ele é instruído a tomar o caminho mais rápido que puder encontrar,

Página 39
as chances são de que todas as peças cheguem ao seu destino em LA e a casa possa ser
remontado em um novo site. Em alguns casos, o último caminhão a deixar Boston pode ser o primeiro
para chegar a Los Angeles, mas se cada pedaço da casa carrega uma etiqueta indicando seu lugar no
estrutura geral, a ordem de chegada não importa. Os reconstrutores podem encontrar o
peças e coloque-as nos lugares certos.
No modelo de Baran, essas peças eram o que ele chamava de "blocos de mensagem" e eram para
ter um determinado tamanho, assim como (na analogia do caminhão) a maioria dos veículos trator-reboque
compartilham o
mesma configuração. A vantagem da técnica de mensagem em pacote foi percebida
principalmente em uma rede distribuída que oferece muitas rotas diferentes.
A inovação de Baran também forneceu uma solução muito necessária para a natureza "intermitente" dos dados
comunicações. Na época, todas as redes de comunicação eram comutadas por circuito, que
significava que uma linha de comunicação foi reservada para uma chamada de cada vez e mantida aberta para
a duração dessa sessão. Uma ligação entre adolescentes vai ocupar uma linha por tanto tempo
enquanto lamentam por seus namorados e contam histórias sobre seus rivais. Mesmo durante
faz uma pausa na conversa, a linha permanece dedicada a essa conversa até que ela termine.
E, tecnicamente, isso faz muito sentido, uma vez que as pessoas tendem a manter um nível bastante estável
fluxo de conversa durante uma chamada telefônica.
Mas um fluxo de dados é diferente. Geralmente derrama em rajadas curtas seguidas por vazios
pausas que deixam a linha ociosa na maior parte do tempo, desperdiçando sua “largura de banda” ou capacidade.
Um conhecido cientista da computação gostava de usar o exemplo de uma padaria com um balcão
balconista, onde os clientes geralmente chegam em rajadas aleatórias. O funcionário tem que ficar no
contador ao longo do dia, às vezes ocupado, às vezes ocioso. No contexto de dados
rede de comunicações, é uma forma altamente ineficiente de utilizar uma rede de longa distância
conexão.
Seria muito mais econômico, então, enviar dados em "blocos" e alocar
largura de banda de forma que diferentes mensagens possam compartilhar a linha. Uma mensagem seria
ser dividido em blocos específicos, que seriam então enviados individualmente ao longo do
rede através de vários locais e remontados em seu destino. Porque lá
eram vários caminhos pelos quais os diferentes blocos podiam ser transmitidos, eles podiam
chegam fora da sequência, o que significa que assim que uma mensagem completa chegar, no entanto
desordenado, precisava ser remontado na ordem adequada. Cada bloco seria
portanto, precisa conter informações que identifiquem a parte da mensagem para a qual
pertencia.
O que Baran imaginou foi uma rede de switches não tripulados, ou nós - autônomos
computadores, essencialmente, que encaminhavam mensagens empregando o que ele chamou de
política de aprendizagem em cada nó, sem a necessidade de um controle central e possivelmente vulnerável
ponto." Ele criou um esquema para enviar e receber informações que ligou
"Roteamento de batata quente", que era essencialmente um sistema rápido de armazenamento e encaminhamento
funcionando
quase instantaneamente, em contraste com o antigo procedimento de teletipo post-it-and-forward.
No modelo de Baran, cada nó de comutação continha uma tabela de roteamento que se comportava como uma
espécie de
coordenador de transporte ou despachante. A tabela de roteamento em cada nó refletiu quantos
saltos, ou links, eram necessários para alcançar todos os outros nós da rede. A mesa

Página 40
indicava os melhores caminhos a percorrer e era constantemente atualizado com informações sobre
nós vizinhos, distâncias e atrasos - bem como despachantes ou motoristas de caminhão que
usam seus rádios CB para se manterem informados sobre acidentes, obras, desvios,
e armadilhas de velocidade. A atualização contínua das tabelas também é conhecida como "adaptativa" ou
Roteamento “dinâmico”.
Como o termo "batata quente" sugere, assim que um bloco de mensagem entrou em um nó
jogado fora da porta novamente o mais rápido possível. Se o melhor caminho de saída estava ocupado - ou
explodido em bits - o bloco de mensagem foi enviado automaticamente pela próxima melhor rota. E se
aquele link estava ocupado ou desapareceu, seguiu a próxima melhor rota e assim por diante. E se o
as escolhas acabaram, os dados podem até mesmo ser enviados de volta ao nó de onde foram originados.
Baran, o inventor do esquema, também se tornou seu principal lobista. Ele esperava persuadir
AT&T de suas vantagens. Mas não foi fácil. Ele descobriu que convencer alguns dos
O pessoal de comunicação da RAND sobre a viabilidade de suas idéias já era bastante difícil.
Os conceitos eram totalmente inéditos nos círculos tradicionais de telecomunicações.
Eventualmente, ele ganhou o apoio de seus colegas. Mas conquistando a gestão da AT&T, quem
seria chamado se tal rede fosse construída, provou-se quase impossível.
A primeira tarefa de Baran foi mostrar que o sistema de comunicações de longa distância do país
(consistindo em quase nada além de linhas da AT&T) falharia em um primeiro ataque soviético. Não somente
os funcionários da AT&T se recusaram a acreditar nisso, mas também se recusaram a permitir que a RAND usasse
seus
mapas de circuitos de longa distância. A RAND recorreu ao uso de um conjunto roubado de Long Lines da AT&T
mapas para analisar a vulnerabilidade do sistema telefônico.
Apesar da vulnerabilidade, a ideia de dividir os dados em blocos de mensagens e enviar
cada bloco para encontrar seu próprio caminho através de uma matriz de linhas telefônicas atingiu a equipe da AT&T
membros como totalmente absurdos. Seu mundo era um lugar onde as comunicações eram
enviado como um fluxo de sinais por um tubo. O envio de dados em pequenas parcelas parecia quase
tão lógico quanto enviar óleo por um oleoduto, um copo de cada vez.
Os funcionários da AT&T concluíram que Baran não tinha a menor noção de como o telefone
sistema funcionou. “A atitude deles era que eles sabiam tudo e ninguém fora do
Bell System sabia de tudo ”, disse Baran. “E alguém de fora não poderia
possivelmente compreender ou apreciar a complexidade do sistema. Então aqui vem algum idiota
junto e fala sobre algo ser muito simples, que obviamente não entende
como o sistema funciona. ”
A resposta da AT&T foi educar. A empresa iniciou uma série de seminários sobre telefonia, realizada
para um pequeno grupo de forasteiros, incluindo Baran. As aulas duraram várias semanas. "Isto
levou noventa e quatro alto-falantes separados para descrever todo o sistema, uma vez que nenhum
indivíduo parecia saber mais do que uma parte do sistema ”, disse Baran. “Provavelmente seu
a maior decepção foi que, depois de tudo isso, eles disseram: 'Agora você vê por que não
trabalhar? 'E eu disse,' Não '”
Com exceção de alguns apoiadores da Bell Laboratories que entendiam digital
tecnologia, a AT&T continuou a resistir à ideia. Os céticos mais francos eram alguns
dos técnicos mais experientes da AT&T. “Depois de ouvir o refrão melódico de

Página 41
'besteira' com frequência ”, lembra Baran,“ eu estava motivado para ir embora e escrever uma série de
papéis de memorandos detalhados, para mostrar, por exemplo, que algoritmos eram possíveis que
permitiu que uma mensagem curta contivesse todas as informações necessárias para encontrar seu próprio caminho
através da rede. ” Com cada objeção respondida, outra foi levantada e outra
parte de um relatório teve que ser escrito. No momento em que Baran respondeu a todas as preocupações
levantadas pelas comunidades de defesa, comunicações e ciência da computação, quase quatro
anos se passaram e seus volumes totalizaram onze.
Apesar da intransigência da AT&T, Baran acreditava que estava envolvido no que chamou de
“Discordância honesta” com funcionários da companhia telefônica. “O pessoal da sede da AT&T
sempre escolheu acreditar que suas ações estavam no melhor interesse da 'rede', que era
por sua definição, o mesmo que era melhor para o país ”, disse ele.
Em 1965, cinco anos após embarcar no projeto, Baran tinha o apoio total da RAND,
e que a RAND de agosto enviou uma recomendação formal à Força Aérea de que um
rede de comutação ser construída, primeiro como um programa de pesquisa e desenvolvimento e depois como um
sistema totalmente operacional: “A necessidade de uma sobrevivência. . . flexível, de usuário para usuário
sistema de comunicações é de extrema importância. Não conhecemos nenhum comparável
propostas de sistemas alternativos para atingir essa capacidade, e acreditamos que a Força Aérea
deve agir rapidamente para implementar o programa de pesquisa e desenvolvimento proposto
aqui em."
A Força Aérea concordou com isso. Agora, as únicas pessoas resistindo eram os funcionários da AT&T.
A Força Aérea disse à AT&T que pagaria à companhia telefônica para construir e manter o
rede. Mas a companhia telefônica não seria influenciada.
A Força Aérea, determinada a não deixar o plano morrer nas pranchetas, decidiu que
deve prosseguir sem a cooperação da AT&T. Mas o Pentágono decidiu colocar o novo
formou a Defense Communications Agency (DCA), e não a Força Aérea, encarregada de
construir a rede. Baran não imaginou nada além de problemas. A agência era administrada por um grupo
de oficiais de comunicações antiquados de cada um dos vários serviços, sem
experiência em tecnologia digital. Para piorar as coisas, o entusiasmo do DCA pelo
o projeto correspondeu à resposta da AT&T. “Então eu disse aos meus amigos do Pentágono
abortar todo o programa - porque eles não acertariam ”, lembrou Baran. "Isto
teria sido um desperdício de dinheiro do governo e atrasado as coisas. O DCA
iria estragar tudo e ninguém mais teria permissão para tentar, dada a tentativa fracassada
nos livros. ”
Baran sentiu que era melhor esperar até que "surgisse uma organização competente". E
com isso, após cinco anos de luta, Paul Baran desviou sua atenção para outras coisas. isto
foi, em grande parte, uma visita ao painel “Somos ricos ou pobres?” pergunta que ele tinha
colocado décadas antes para seus pais, cujas respostas totalmente contrastantes o ajudaram
entenda que a maioria das coisas na vida é uma questão de perspectiva.
Em Londres, no outono de 1965, logo após Baran interromper o trabalho em seu projeto, Donald
Watts Davies, um físico de 41 anos do British National Physical Laboratory
(NPL), escreveu a primeira de várias notas pessoais expondo algumas idéias que ele estava tocando

Página 42
com uma nova rede de computadores muito parecida com a de Baran. Ele enviou seu conjunto de notas para alguns
pessoas interessadas, mas - certo de que ele encontraria forte resistência das autoridades em
encarregado do monopólio do serviço de telefonia dos Correios britânicos - principalmente ele manteve suas idéias
para ele mesmo. Davies queria tempo para validar seus conceitos. Na primavera seguinte,
confiante de que suas ideias eram sólidas, ele deu uma palestra pública em Londres, descrevendo o
noção de enviar pequenos blocos de dados - que ele chamou de "pacotes" - por meio de um digital
rede store-and-forward. Como a reunião estava terminando, um homem da audiência
aproximou-se de Davies e disse que ele era do Ministério da Defesa. Ele disse a Davies
sobre algum trabalho extremamente semelhante que circulou na defesa americana
comunidade por um homem chamado Paul Baran. Davies nunca tinha ouvido falar de Baran ou seu RAND
estudos.
Donald Davies era filho de pais da classe trabalhadora. Seu pai, funcionário de uma mina de carvão em
Wales morreu um ano após o nascimento de Donald e sua irmã gêmea. A mãe deles a mudou
jovem família para Portsmouth, um porto naval britânico, onde ela foi trabalhar como contador
escriturário nos correios. Donald fez experiências com o rádio ainda jovem e começou cedo
interesse em física. Ele ainda não tinha quatorze anos no dia em que sua mãe trouxe um livro para casa,
algo que um engenheiro havia deixado no correio, tudo sobre telefonia. o
volume técnico descreveu a lógica e o design dos sistemas de comutação telefônica e
“Fez horas de leitura fascinante”, Davies relembrou anos depois.
Aluno excepcional, Davies recebeu bolsas de estudo para várias universidades. Para
celebrar seu aluno estrela, sua escola declarou um feriado de meio dia. “Por um curto período eu fui
o menino mais popular da escola ”, lembrou. Davies escolheu a Universidade de
Imperial College de Londres, e quando ele tinha 23 anos havia se formado em
física e matemática. Em 1947 ele se juntou a uma equipe de cientistas liderada pelo matemático
Alan Turing do National Physical Laboratory e Davies desempenharam um papel importante na
construindo o computador digital mais rápido da Inglaterra na época, o Pilot ACE. Em 1954
Davies ganhou uma bolsa para passar um ano nos Estados Unidos; parte daquele ano, ele estava em
MIT. Ele então retornou à Inglaterra, subiu rapidamente no NPL, e em 1966, após descrever
seu trabalho pioneiro em comutação de pacotes, ele foi nomeado chefe da ciência da computação
divisão.
A semelhança técnica entre o trabalho de Davies e Baran era impressionante. Não só eram
suas ideias são praticamente paralelas em conceito, mas por coincidência eles até escolheram o mesmo
tamanho do pacote e taxa de transmissão de dados. Independentemente, Davies também criou uma rota
esquema que era adaptável, como o de Baran, mas diferente em detalhes.
Havia apenas uma grande diferença em suas abordagens. A motivação que levou Davies
conceber uma rede de comutação de pacotes não teve nada a ver com as preocupações militares
isso tinha impulsionado Baran. Davies simplesmente queria criar uma nova comunicação pública
rede. Ele queria explorar os pontos fortes técnicos que viu em computadores digitais e
interruptores, para trazer uma computação altamente responsiva e interativa por muito tempo
distâncias. Essa rede teria maior velocidade e eficiência do que os sistemas existentes.
Davies estava preocupado que as redes comutadas por circuito fossem mal combinadas com o
requisitos de computadores em interação. As características irregulares e explosivas do computador
o tráfego de dados gerado não se encaixava bem com a capacidade de canal uniforme do telefone

Página 43
sistema. Combinar o design da rede com os novos tipos de tráfego de dados tornou-se seu principal
motivação.
Em vez de conduzir o tipo de estudos de redundância e confiabilidade que Baran tinha
dedicou tanto tempo, Davies se concentrou em trabalhar os detalhes de configuração dos dados
blocos. Ele também previu a necessidade de superar diferenças em linguagens de computador e
procedimentos de operação da máquina - diferenças em hardware e software - que existiriam
em uma grande rede pública. Ele imaginou o dia em que alguém se sentaria em uma
tipo de computador e interagir com uma máquina de um tipo diferente em outro lugar. Para
preencher a lacuna entre os sistemas de computador amplamente divergentes da época, ele começou
delineando as características de um dispositivo intermediário - um novo computador - que serviria como um
tradutor, montando e desmontando mensagens digitais para as demais máquinas.
A ideia de dividir as mensagens em "pacotes" de dados uniformes - cada um com o comprimento de um
linha típica de texto - foi algo que Davies descobriu depois de estudar time-sharing avançado
sistemas e como eles alocaram o tempo de processamento para vários usuários. Em uma viagem aos Estados Unidos
Estados Unidos em 1965, ele observou o sistema de compartilhamento de tempo do Projeto MAC do MIT. Alguns
meses
mais tarde, o NPL hospedou em Londres um grupo do MIT, incluindo Larry Roberts,
para mais discussões sobre compartilhamento de tempo. Foi nessas reuniões que a ideia do pacote
primeiro atingiu Davies. Ao contrário da reação fria da AT&T a Baran, os britânicos
O estabelecimento de telecomunicações adotou as idéias de Davies. Ele foi encorajado a buscar
financiamento para uma rede experimental no NPL.
Os sistemas de compartilhamento de tempo já haviam resolvido o problema persistente do tempo de resposta lento
em
processamento em lote, dando a cada usuário uma fatia do tempo de processamento do computador. Várias pessoas
podem estar executando tarefas ao mesmo tempo, sem perceber qualquer atraso significativo em seu trabalho.
Analogamente, em uma rede de comunicação digital, um computador poderia dividir mensagens em
pequenos pedaços, ou pacotes, colocam-nos no pipeline eletrônico e permitem que os usuários compartilhem
capacidade total da rede. Davies, como Baran, viu na era digital a viabilidade de um
novo tipo de rede de comunicações.
A escolha de Davies da palavra “pacote” foi muito deliberada. “Achei que era importante
tem uma palavra nova para um dos pequenos dados que viajaram separadamente ”, ele
explicou. “Isso tornaria mais fácil falar sobre eles.” Havia muitos outros
possibilidades - bloco, unidade, seção, segmento, quadro. “Achei a palavra pacote”, disse ele, “em
o sentido de pacote pequeno. ” Antes de decidir a palavra, ele perguntou a dois linguistas de um
equipe de pesquisa em seu laboratório para confirmar que havia cognatos em outras línguas. Quando
eles relataram que era uma boa escolha, ele se fixou nela. Comutação de pacotes. isso foi
preciso, econômico e muito britânico. E era muito mais fácil para o ouvido do que o de Baran
“Comutação de bloco de mensagem adaptável distribuída”. Davies conheceu Baran pela primeira vez
vários anos depois. Ele disse a Baran que tinha ficado totalmente envergonhado de saber
Trabalho de Baran depois que ele terminou o seu próprio e, em seguida, acrescentou: "Bem, você pode ter
lá primeiro, mas eu entendi o nome. ”

Mapeando
Página 44
Em dezembro de 1966, quando Larry Roberts chegou ao Pentágono, ele conheceu Donald Davies
de sua viagem a Londres no ano anterior, mas não sabia sobre o subsequente
trabalhar na comutação de pacotes. E ele nunca tinha ouvido o nome Paul Baran.
Alguns anos antes, Roberts decidiu que a computação estava ficando velha e tudo
vale a pena fazer dentro de um computador já havia sido feito. Isso veio para ele como um
revelação em uma conferência de 1964 realizada em Homestead, Virginia, onde Roberts, Licklider,
e outros ficaram acordados até altas horas da manhã falando sobre o potencial de
redes de computadores. Roberts saiu da reunião decidido a começar a trabalhar no
comunicações entre computadores.
Sua primeira oportunidade surgiu um ano depois, quando ele supervisionou um dos primeiros experimentos reais
em unir máquinas díspares em longas distâncias. Em 1965, o psicólogo Tom Marill, que
tinha estudado com Licklider e que estava igualmente fascinado por computadores, começou um
pequena empresa de compartilhamento de tempo, Computer Corporation of America (CCA). Quando Marill's
maior investidor desistiu no último minuto, Marill procurou algum trabalho de P&D. Ele
propôs à ARPA que conduzisse um experimento de rede vinculando o TX-2 de Lincoln
computador para o SDC Q-32 em Santa Monica. A empresa de Marill era tão pequena, no entanto,
que a ARPA recomendou a realização de seu experimento sob a égide de Lincoln
Laboratório. Funcionários da Lincoln gostaram da ideia e colocaram Larry Roberts no comando de
supervisionar o projeto.
O objetivo era claro. Como Marill argumentou em uma carta a Roberts em 1965, a computação tinha
atingiu um estado de coisas infeliz; projetos de compartilhamento de tempo proliferavam, mas havia
não era um “terreno comum para troca de programas, pessoal, experiência ou ideias”. Seu
impressão da comunidade de ciência da computação foi "de uma série de essencialmente semelhantes
projetos, cada um indo em sua própria direção, sem levar em conta os outros ”. Por quê
desperdiçar recursos?
No que se refere a isso, o experimento TX-2 foi ambicioso. A ligação entre os dois
computadores foi feito usando um serviço full-duplex de quatro fios Western Union especial (full
duplex fornece transmissão simultânea em ambas as direções entre dois pontos). Para
este Marill anexou uma forma tosca de modem, operando a 2.000 bits por segundo, que ele
chamado de discador automático. Ao ligar diretamente as máquinas, Marill contornou o
problema de incompatibilidades entre eles. A ideia era conectar os computadores como um
par de gêmeos siameses, executando programas in situ. Embora não esteja transferindo arquivos de volta e
Em seguida, o experimento permitiu que as máquinas enviassem mensagens umas às outras. Conjunto Marill
um procedimento para agrupar caracteres em mensagens, enviá-los através do link e
verificando se as mensagens chegaram. Se nenhuma confirmação for seguida, a mensagem
foi retransmitido. Marill referiu-se ao conjunto de procedimentos para o envio de informações de volta
e adiante como uma mensagem "protocolo", solicitando a um colega que pergunte: "Por que você usa
esse termo? Achei que se referisse à diplomacia. ”
Em um relatório de 1966 resumindo os resultados iniciais do experimento, Marill escreveu que ele
poderia "prever nenhum obstáculo que uma quantidade razoável de diligência não possa ser esperada para
superar." Apesar da diligência, quando Marill e Roberts realmente conectaram o
duas máquinas, os resultados foram mistos. A própria conexão funcionou conforme planejado. Mas o
 Página 45
a confiabilidade da conexão e o tempo de resposta eram, como Roberts os descreveria
vários anos depois, simplesmente péssimo.
Reunir dois computadores diferentes era uma coisa, mas o projeto para o qual
Roberts foi tirado de Lincoln para trabalhar na ARPA foi outro, muito maior
desafio. Interligar uma matriz de máquinas, cada uma com características distintas, seria
ser extremamente complicado. Para realizá-lo, provavelmente seria necessário ligar para cada
o especialista Roberts conhecia todas as áreas da computação e comunicações.
Felizmente, o círculo de colegas de Roberts era amplo. Um de seus melhores amigos de
Lincoln Laboratory, com quem trabalhou no TX-2, era Leonard Kleinrock, um
engenheiro inteligente e ambicioso que frequentou o MIT com bolsa integral. Se alguém
influenciou Roberts em seu primeiro pensamento sobre redes de computadores, foi Kleinrock.
A dissertação de Kleinrock, proposta já em 1959, foi um importante trabalho teórico
que descreveu uma série de modelos analíticos de redes de comunicação. E em 1961,
enquanto trabalhava com Roberts, Kleinrock publicou um relatório no MIT que analisou o
problema de fluxo de dados nas redes. Kleinrock também trabalhou no roteamento aleatório
procedimentos e tinha algumas ideias iniciais sobre a divisão de mensagens em blocos para
uso de canais de comunicação. Agora Kleinrock estava na UCLA, e Roberts deu a ele um
Contrato ARPA para configurar o Centro de Medição de Rede oficial lá, um laboratório dedicado a
teste de desempenho de rede.
A amizade entre Roberts e Kleinrock foi muito além do profissional
interesses que compartilhavam. As provocações cerebrais eram um interesse comum. Esquemas para ganhar dinheiro
eram outro. Cada um reforçou a abertura do outro à aventura fiscal. Aqueles que
pensou que Roberts era só trabalho e nenhuma diversão nunca o tinha visto em ação com seus amigos.
Roberts e Kleinrock eram jogadores inveterados de cassino. Roberts desenvolveu um "alto-baixo"
esquema de contagem para blackjack e ensinou-o a Kleinrock. Eles nunca conseguiram entrar no
galeria oficial de contadores de cartas na lista negra, mas mais de uma vez, eles foram vistos
por detetives de cassino e pediu para sair.
E em outro episódio ousado, Roberts e Kleinrock arquitetaram um plano para lucrar com o
física da roleta. A ideia era prever, empregando leis rudimentares do movimento, apenas
quando a bola cairia fora de sua trajetória. Para fazer isso, eles precisavam saber a velocidade de
a bola, que viajou em uma direção, e a velocidade da roda, que viajou na
de outros. Eles decidiram construir uma pequena máquina que faria as previsões, mas eles
precisava de alguns dados. Roberts pegou um gravador, colocou um microfone na mão e
fez um molde que fez parecer que ele tinha um pulso quebrado. Os dois se sentaram à mesa e
Roberts colocou a mão ao lado do volante para registrar o som do passe, de
que mais tarde eles poderiam extrapolar sua velocidade. O trabalho de Kleinrock era distrair o chefe do poço
jogando várias rodadas de roleta. “Tudo estava funcionando bem, exceto por um
coisa ”, disse Kleinrock. “Comecei a ganhar. Isso chamou a atenção para mim. O chefe do poço parece
e vê um cara com um braço quebrado com a mão perto da roda da roleta, e ele
agarra o braço de Larry e diz: 'Deixe-me ver seu braço!' Larry e eu seguimos rapidamente
há."

Página 46
•••
Roberts concordou com Taylor que o tempo de resposta rápido para a rede era crítico, porque um
o baixo tempo de atraso da mensagem era crucial para a interatividade. Qualquer pessoa que tenha usado o tempo
compartilhado
sistemas que transmitiam dados por linhas de comunicação padrão sabiam o quão lentos
poderia ser. Os dados viajavam de e para o computador principal a taxas terrivelmente lentas de um
algumas centenas de bits por segundo. Recuperar ou enviar até mesmo uma pequena quantidade de informações
era um processo que deixava bastante tempo para se servir de uma xícara de café, ou mesmo preparar um
panela inteira, enquanto o modem girava. Ninguém queria uma rede lenta.
Durante uma reunião inicial do grupo solto de conselheiros que Roberts reuniu, alguém
bateu com o punho na mesa e disse: "Se esta rede não pode me dar um segundo
resposta, não é bom. ” De forma otimista, um tempo de resposta de meio segundo foi escrito no
requisitos. A segunda prioridade, é claro, era a confiabilidade. Se uma rede fosse
eficaz, os usuários precisavam de total confiança em sua capacidade de enviar e receber dados
sem confusão.
Outra fonte de consternação era a questão de como a rede seria mapeada
Fora. Várias pessoas propuseram que o compartilhamento de recursos fosse feito em um único sistema centralizado
computador, sentado em, digamos, Omaha, um lugar popular para centrais telefônicas de longa distância
porque ficava no centro geográfico da nação. Se a centralização fizesse sentido para um
rede telefônica, por que não para uma rede de computadores? Talvez a rede deva usar
linhas telefônicas dedicadas - uma questão que ainda não estava resolvida - que ajudaria a manter
custos uniformes. Baran evitou um sistema centralizado porque isso aumentou seu
vulnerabilidade. Roberts também se opôs a uma abordagem centralizada, mas decidiu adiar
sua decisão final até que ele pudesse trazer o assunto à tona com um grande grupo. Sua chance veio
em breve, em uma reunião dos principais investigadores da ARPA em Ann Arbor, Michigan, no início
1967.
Taylor havia convocado a reunião e o principal item da agenda era o networking
experimentar. Roberts expôs seu plano inicial. A ideia, como ele descreveu, era conectar
todos os computadores de compartilhamento de tempo uns com os outros diretamente, por meio de linhas telefônicas
dial-up.
As funções de rede seriam administradas pelos computadores “host” em cada local. Então, em
outras palavras, os hosts fariam uma tarefa dupla, tanto como computadores de pesquisa quanto como
roteadores de comunicação. A ideia foi recebida com pouco entusiasmo. Pessoas do
Os sites de hospedagem propostos previam problemas sem fim. Ninguém queria renunciar a um desconhecido
parte dos valiosos recursos de computação para administrar uma rede sobre a qual estavam
dificilmente animado. Então, havia dezenas de variações idiossincráticas para lidar, não o
menos do que era o fato de que cada máquina falava uma linguagem substancialmente diferente
dos outros. Parecia quase impossível padronizar em torno de um conjunto de protocolos.
A reunião de Ann Arbor revelou a falta de entusiasmo, se não de hostilidade absoluta, para
Proposta de Taylor e Roberts. Poucos investigadores principais do ARPA queriam participar
no experimento. Essa atitude foi especialmente pronunciada entre os pesquisadores do
Universidades da Costa Leste, que não viam razão para se vincularem a campi no Oeste. Eles
eram como a mulher da crosta superior em Beacon Hill que, quando informada de que

Página 47
serviço telefônico para o Texas estava disponível, ecoou a famosa frase de Thoreau: “Mas o que
eu teria que dizer a alguém no Texas? ”
Douglas Engelbart, um cientista da computação do Stanford Research Institute (SRI) em 1967,
lembrava-se da reunião com clareza. “Uma das primeiras reações foi: 'Oh, inferno, aqui estou
este computador de compartilhamento de tempo, e meus recursos são escassos como estão. ' Outra reação foi,
'Por que eu deixaria meus alunos de pós-graduação serem sugados para algo assim?' ”
No entanto, rapidamente ficou claro o quão sério Roberts era. Primeiro ele tentou acalmar
o ceticismo sobre o compartilhamento de recursos, apontando que todos tinham algo de
interesse em seu computador que outros possam querer. “Lembro-me de um cara virando-se para o outro
e dizendo: 'O que você tem no seu computador que eu possa usar?' ”, relembrou Engelbart,
“E o outro cara respondeu: 'Bem, você não lê meus relatórios?'” Ninguém ficou surpreso com
a ideia. “As pessoas pensavam: 'Por que eu precisaria do computador de outra pessoa quando
está tudo certo aqui? ” lembrou Jon Postel, então um estudante de graduação na UCLA. "O que
eles teriam o que eu quero e o que eu teria que gostaria que alguém mais olhasse? "
Um problema ainda mais difícil era superar as barreiras de comunicação entre
computadores díspares. Como alguém poderia programar o TX-2, por exemplo, para falar com o
Sigma-7 na UCLA ou o computador na SRI? As máquinas, seus sistemas operacionais, seus
linguagens de programação eram todas diferentes, e só Deus sabia quais outras
incongruências os dividiam.
Pouco antes de a reunião terminar, Wes Clark passou um bilhete para Roberts. Dizia: “Você
colocou a rede do avesso. ” Roberts ficou intrigado e queria ouvir mais; Contudo,
a reunião estava terminando e as pessoas já estavam indo embora. Roberts, Taylor e alguns
outros se juntaram em torno de Clark depois, e um pequeno grupo decidiu continuar a
discussão durante a viagem de volta ao aeroporto. No carro, Clark esboçou sua ideia:
Deixe os computadores host fora dele o máximo possível e, em vez disso, insira um pequeno
computador entre cada computador host e a rede de linhas de transmissão. (Este foi,
por coincidência, precisamente o que Davies concluiu separadamente na Inglaterra.)
Da maneira como Clark explicou, a solução era óbvia: uma sub-rede com pequenas e idênticas
nós, todos interconectados. A ideia resolveu vários problemas. Colocou muito menos demandas
em todos os computadores host e, correspondentemente, menos demandas sobre as pessoas responsáveis por
eles. Os computadores menores que compõem esta rede interna falariam todos da mesma maneira
linguagem, é claro, e eles, não os computadores host, seriam responsáveis por todos os
roteamento. Além disso, os computadores host teriam que ajustar seu idioma apenas uma vez -
para falar com a sub-rede. A ideia de Clark não só fazia sentido tecnicamente, mas também
solução administrativa também. ARPA poderia ter toda a rede sob seu comando
controlar e não se preocupar muito com as características de cada hospedeiro. Além disso, fornecendo
cada site com seu próprio computador idêntico daria uniformidade ao experimento.
O mais curioso sobre a ideia é que Clark a inventou. Ele não tinha sido
prestando muita atenção aos procedimentos em Ann Arbor. Na verdade, ele estava um pouco entediado com isso
tudo. Ele já havia dito a Roberts em termos inequívocos que não tinha nenhum desejo de colocar seu
computador na Washington University em St. Louis na rede. Clark não era amigável
em direção ao compartilhamento de tempo, ou mesmo compartilhamento de recursos. Ele estava trabalhando em
computadores

Página 48
projetado para uso individual e não via nenhuma razão particular para compartilhar suas instalações com as pessoas
em uma rede. Mas quando ele ouviu a discórdia sobre como o experimento ARPA deveria ser
implantado, ele não pode deixar de arriscar uma sugestão. Talvez fosse a antipatia de Clark
em direção ao compartilhamento do tempo que o permitiu pensar nisso. Ao atribuir a tarefa de roteamento a
os computadores host, Roberts e outros estavam essencialmente adicionando outro time-sharing
função. A ideia de Clark era poupar os hosts dessa carga extra e construir uma rede de
computadores idênticos, não compartilhados, dedicados ao roteamento.
Durante o trajeto até o aeroporto, a discussão ficou animada. Não seria uma sub-rede inteira
composto de computadores individuais ser proibitivamente caro e frustrar o objetivo original
de economizar dinheiro? E quem, Roberts queria saber, Wes Clark achava que poderia construir
tal coisa? “Só há uma pessoa no país que pode fazer isso”, respondeu Clark.
“Frank Heart.”
Larry Roberts conhecia Frank Heart. Os dois trabalharam juntos no Lincoln Lab, e
Roberts dividia o escritório com a esposa de Heart, Jane, uma programadora em Lincoln. Roberts
e Heart nunca trabalharam juntos diretamente, mas Roberts sabia que Heart era um exigente
engenheiro de sistemas. Ele era um especialista em sistemas em tempo real construídos para quando o físico
mundo exige uma resposta em frações de segundos - ou pelo menos antes do próximo conjunto de
os dados chegam. Qualquer coisa que lide com informações que chegam de maneira crítica, como
como dados de rastreamento de radar enviados para o sistema SAGE e informações sísmicas geradas durante
um terremoto, era considerado um sistema em tempo real e, na década de 1960, poucas pessoas
entendia os sistemas em tempo real tão bem quanto o Heart.
Roberts também sabia que Heart e Clark eram bons amigos de Lincoln, onde Heart
mostrou a Clark as cordas da programação mais de uma década antes. Agora, tanto quanto
Roberts sabia, Heart estava em Bolt Beranek e Newman em Cambridge, onde ele tinha
mudou-se em 1966 para trabalhar no uso de computadores na medicina.
A rede ARPA não foi concebida como um sistema em tempo real, não no mesmo sentido do
palavra que os verdadeiros cronistas entendem. (Qualquer coisa que leve mais de 10 a 20
milissegundos, o ponto em que os atrasos se tornam humanamente perceptíveis, não é considerado
em tempo real.) Estritamente falando, a rede ARPA deveria ser um sistema de armazenamento e envio.
Mas os dados iriam entrar e sair dos nós tão rapidamente, e o tempo de resposta de um
a perspectiva humana seria tão rápida, que se qualificou como um problema em tempo real. O sistema
teria que lidar com dezenas de problemas envolvendo eventos estreitamente sequenciados e
tempo extremamente apertado. O status da rede mudaria constantemente, e quem quer que seja
programado os computadores que compunham a sub-rede proposta por Clark precisariam saber
como fazer com que o sistema lide com dados de entrada e saída de forma confiável em taxas muito rápidas.
Apesar da lógica da recomendação de Clark, no entanto, Roberts não poderia simplesmente transformar o
trabalho para o coração. O ARPA teve que jogar pelas regras de contratação do governo. Sobre o
anos, a maioria das propostas solicitando financiamento chegou ao ARPA não solicitada. Raramente teve
agência realmente solicitou propostas. Mas este era diferente. A agência tinha surgido
com a ideia de rede internamente e, nesse aspecto, era incomum. Além disso, porque o
rede seria propriedade do governo controlada centralmente pela ARPA e não

Página 49
residir em um campus, digamos, ou em uma empresa de pesquisa, Roberts e outros decidiram que tinham
para enviar este projeto para licitações.
Quando voltou a Washington, Roberts escreveu um memorando descrevendo a ideia de Clark
e distribuiu para Kleinrock e outros. Ele chamou os computadores intermediários que
controlaria os "processadores de mensagem de interface", ou IMPs, que ele
pronunciado "imps." Eles deveriam desempenhar as funções de interconectar a rede,
envio e recebimento de dados, verificação de erros, retransmissão em caso de erros,
roteamento de dados e verificação de que as mensagens chegaram aos destinos pretendidos. UMA
protocolo seria estabelecido para definir apenas como os IMPs devem se comunicar com
computadores host. Após a notícia da ideia de Clark se espalhar, a hostilidade inicial em relação à rede
diminuiu um pouco. Por um lado, um computador separado para realizar as funções de comutação
removeu o pesado kludge (um kludge é uma solução deselegante para um problema técnico)
que pode resultar da adição dessas funções ao computador host. As pessoas também viram isso como um
maneira de obter outro computador para brincar.
No final de 1967, outra conferência de informática, esta em Gatlinburg, Tennessee,
ajudou a avançar o plano da rede. Este simpósio foi patrocinado pela Associação para
Computing Machinery, a mais antiga e prestigiosa das organizações profissionais para
a crescente indústria de computadores. Embora pequeno em número, os participantes representaram o
níveis mais altos do estabelecimento de ciência da computação.
Gatlinburg foi um local perfeito para Roberts apresentar seu primeiro artigo sobre o que ele chamou de
“Rede ARPA.” Em sua apresentação, Roberts se concentrou nas razões da rede e
descreveu a sub-rede de IMPs, mas disse pouco mais sobre como a rede realmente
trabalhos. Um grande enigma que ainda precisava ser resolvido era a questão de como os dados seriam realmente
transmitido - por meio de que tipo de canal. Sempre atento aos custos, Roberts fechou seu
apresentação com uma breve discussão sobre o que ele chamou de "necessidades de comunicação". Ele era
pensando em usar o mesmo tipo de linha telefônica que ele e Marill haviam usado para seus
experimento TX-2 pequeno: linhas full-duplex de quatro fios. A conversa sobre o assunto terminou com uma nota
de frustração. As linhas telefônicas dial-up comuns (em oposição às linhas dedicadas alugadas) eram
lento e manter uma linha aberta era um desperdício. Roberts ainda não tinha encontrado um altamente eficiente
meios de transportar os dados.
Considerando que a reunião de Ann Arbor meses antes tinha sido o equivalente intelectual de um
briga de bar, Gatlinburg era o chá da tarde. As pessoas estavam educadamente aceitando a ideia
de uma rede. A apresentação de Roberts foi geralmente bem recebida, até mesmo saudada
entusiasticamente por alguns.
Outro artigo foi apresentado por Roger Scantlebury. Veio da equipe de Donald Davies em
Laboratório de Física Nacional e discutiu o trabalho em andamento na Inglaterra. O papel dele
apresentou um estudo de projeto detalhado para uma rede comutada por pacotes. Foi o primeiro Roberts
tinha ouvido falar disso. Depois disso, Roberts e alguns outros abordaram Scantlebury, e eles
começou a discutir o trabalho do NPL. A discussão continuou no bar do hotel e foi tarde
pela noite a dentro. Scantlebury levantou a questão da velocidade da linha com Roberts. Ele disse que ele e
Davies estava planejando usar linhas que operavam muito mais rápido do que 2.000 bits por
segunda velocidade que Roberts estava propondo. Ele sugeriu que Roberts construísse a rede ARPA

Página 50
com menos linhas transportando dados em velocidades mais de vinte vezes maiores para melhorar o
tempo de resposta.
Roberts também soube de Scantlebury, pela primeira vez, sobre o trabalho que havia sido feito
por Paul Baran da RAND alguns anos antes. Quando Roberts voltou para Washington, ele
encontraram os relatórios RAND, que na verdade estavam coletando poeira nas informações
Processando Técnicas de Escritório por meses, e as estudei. Roberts estava projetando este
rede experimental não com comunicações de sobrevivência como seu principal - ou mesmo
secundária - preocupação. Cenários de guerra nuclear e questões de comando e controle não eram
no topo da agenda de Roberts. Mas as percepções de Baran sobre comunicações de dados o intrigaram
no entanto, e no início de 1968 ele se encontrou com Baran. Depois disso, Baran se tornou algo
um consultor informal do grupo que Roberts reuniu para projetar a rede. o
O artigo de Gatlinburg apresentado por Scantlebury em nome do esforço britânico foi claramente um
influência também. Quando ele visitou Roberts durante o projeto da rede ARPA, Davies
disse: “Eu vi que nosso jornal tinha sido usado tanto que suas páginas estavam caindo aos pedaços”.
Roberts achou que a rede deveria começar com quatro sites - UCLA, SRI, a Universidade
de Utah e da Universidade da Califórnia em Santa Bárbara - e eventualmente crescer para
por volta de dezenove. UCLA foi escolhido como o primeiro site porque a rede de Len Kleinrock
O Measurement Center estava lá. Em cada um dos outros locais, pesquisas patrocinadas pela ARPA que
forneceria recursos valiosos para a rede já em andamento. Pesquisadores em
UCSB estava trabalhando em gráficos interativos. Pesquisadores de Utah também estavam fazendo muitas
os gráficos funcionam bem como investigam a visão noturna para os militares. Dave Evans, quem,
com Ivan Sutherland, mais tarde fundou a Evans and Sutherland, uma empresa gráfica pioneira,
estava em Utah montando um sistema que pegaria imagens e as manipularia com um
computador. Evans e seu grupo também estavam interessados em saber se a rede poderia ser usada
para mais do que apenas trocas textuais.
Stanford Research Institute (mais tarde rompeu seus laços com Stanford e se tornou apenas SRI) tinha
foi escolhido como um dos primeiros locais porque Doug Engelbart, um cientista de extraordinária
visão, trabalhou lá. Vários anos antes, quando Bob Taylor estava na NASA, ele tinha
financiou a invenção de Engelbart do primeiro mouse de computador (Engelbart recebeu uma patente para
o dispositivo como um "indicador de posição XY para um sistema de exibição"), e nos anos seguintes
Taylor apontou com orgulho para seu apoio ao mouse de Engelbart.
Engelbart estava presente na reunião de Ann Arbor de 1967 do diretor da ARPA
investigadores quando Taylor e Larry Roberts anunciaram que cerca de uma dúzia deles
devem ligar seus computadores em uma rede experimental e que cada
espera-se que o site disponibilize seus recursos de computador na rede. Enquanto
outros responderam com ceticismo ao plano, Engelbart ficou encantado com ele. No
vez, ele estava dirigindo um laboratório de pesquisa de computador SRI. Não ao contrário de Licklider, Engelbart era
interessado em usar computadores para aumentar o intelecto humano. Sob um contrato do ARPA,
ele estava desenvolvendo um sistema (chamado NLS, para o NL ine System) que dependia de
comunidades com conhecimento de informática. Ele viu a rede experimental ARPA como um excelente
veículo para estender o NLS a uma ampla área de colaboração distribuída. “Eu percebi lá
era uma comunidade de computadores pronta ”, relembrou Engelbart. “Era exatamente o que eu era
procurando por."

Página 51
Parte da força do NLS era sua utilidade na criação de bibliotecas digitais e no armazenamento
e recuperação de documentos eletrônicos. Engelbart também viu o NLS como uma forma natural de apoiar
uma câmara de compensação de informações para a rede ARPA. Afinal, se as pessoas fossem
compartilhar recursos, era importante que todos soubessem o que estava disponível. No
Reunião em Michigan, Engelbart se ofereceu para montar o Network Information Center,
que veio a ser conhecido como NIC (pronuncia-se “nick”). Engelbart também sabia que seu
grupo de pesquisa em Menlo Park ficaria igualmente entusiasmado com o
rede. Seus colegas eram programadores talentosos que reconheceriam um interessante
projeto quando o viram.
A conversa com Scantlebury esclareceu vários pontos para Roberts. Do bretão
comentários sobre comutação de pacotes, em particular, ajudaram a conduzir Roberts mais perto de uma
Projeto. Ao especificar os requisitos de rede, Roberts foi guiado por alguns
princípios. Em primeiro lugar, a sub-rede IMP deveria funcionar como um sistema de comunicações cujo
a tarefa essencial era transferir bits de maneira confiável de um local de origem para um destino especificado.
Em seguida, o tempo médio de trânsito pela sub-rede deve ser inferior a meio segundo. Terceiro,
a sub-rede deve ser capaz de operar de forma autônoma. Computadores daquela época normalmente
requeria várias horas por semana de inatividade para manutenção. IMPs não podiam ser
dependente de um computador host local ou pessoal do site host; eles deveriam ser capazes de
continue operando e roteando o tráfego de rede, independentemente de um host estar ou não em execução. o
sub-rede também teve que continuar a funcionar quando IMPs individuais foram desativados por
serviço. Essa ideia de que manter a confiabilidade deve ser incumbência da sub-rede, não
os anfitriões, foi um princípio fundamental. Roberts e outros acreditavam que os IMPs também deveriam atender
tarefas como seleção de rota e confirmação de recebimento.
No final de julho de 1968, Roberts terminou de redigir a solicitação de propostas. Ele enviou
para 140 empresas interessadas em construir o Interface Message Processor. o
documento estava repleto de detalhes de como a rede deveria se parecer e como os IMPs
seria esperado que fizesse. Foi uma rica peça de prosa técnica, repleta de uma mistura eclética
de ideias. Kleinrock influenciou os primeiros pensamentos de Roberts sobre o teórico
possibilidades. Baran contribuiu para a base intelectual sobre a qual o técnico
conceito foi baseado, e o esquema de roteamento dinâmico de Roberts deu um aceno extra ao
trabalhos; Roberts adotou o termo “pacote” de Davies e incorporou o seu e o de Scantlebury
velocidades de linha mais altas; A ideia de sub-rede de Clark foi um golpe de gênio técnico. "O processo de
o desenvolvimento tecnológico é como construir uma catedral ”, comentou Baran anos depois.
“Ao longo de várias centenas de anos, novas pessoas aparecem e cada uma estabelece uma
bloco no topo das antigas fundações, cada um dizendo: 'Eu construí uma catedral'. No próximo mês, outro
o bloco é colocado em cima do anterior. Então vem um historiador que pergunta: 'Bem,
quem construiu a catedral? ' Pedro adicionou algumas pedras aqui, e Paul acrescentou mais algumas. E se
você não é cuidadoso, você pode se enganar e acreditar que fez o mais importante
parte. Mas a realidade é que cada contribuição tem que seguir um trabalho anterior.
Tudo está ligado a todo o resto. ”
Mas em 1968 o principal arquiteto da rede foi Larry Roberts: ele fez o primeiro
decisões, e ele estabeleceu os parâmetros e especificações operacionais. Embora ele
obteria informações de outros, Roberts seria o único a decidir quem o construiu.

Página 52
As primeiras respostas à solicitação de propostas foram da IBM e da Control Data
Corporation (CDC). A IBM era então a maior fabricante mundial de computadores e
dominou o mercado de grandes sistemas de computador. O CDC, embora diminuído pela IBM, foi
outra empresa que investiu pesadamente no desenvolvimento de grandes sistemas. Ambos recusaram
lance, e seus motivos eram idênticos: a rede nunca poderia ser construída, eles disseram categoricamente,
porque não existia nenhum computador pequeno o suficiente para torná-lo econômico. Para o IMP,
A IBM havia pensado em propor um computador 360 Modelo 50, um grande mainframe. Mas em um
preço muitas vezes superior ao de um minicomputador, o Modelo 50 era muito caro para ser considerado
comprando em grandes quantidades.
Roberts, por outro lado, estava pensando pequeno. O primeiro computador que ele pensou foi
o PDP-8, um minicomputador feito pela Digital Equipment Corp. Digital havia lançado o
PDP-8 em 1965. Não foi apenas o primeiro grande sucesso da empresa, mas o PDP-9 também estabeleceu
os minicomputadores como a nova vanguarda da indústria de computadores. Roberts conheceu Ken Olsen
de Lincoln, e ele pensou que a Digital poderia até oferecer um desconto por quantidade na máquina.
Quando os lances começaram a chegar, a maioria escolheu um computador Honeywell. isto
era um minicomputador chamado DDP-516; Honeywell acabara de apresentá-lo. Parte de
o diferencial da nova máquina era que ela podia ser construída de acordo com especificações pesadas. Em seu
Versão “robusta”, custou cerca de US $ 80.000. Logo após a introdução da máquina, em um
conferência de computador em Las Vegas, a versão militar reforçada foi retirada da
chão de showroom por uma grua. Ao balançar nas cordas presas ao guindaste, um Honeywell
empregado levou uma marreta para ele. O objetivo do exercício era demonstrar que
a máquina era resistente o suficiente para operar em um campo de batalha. Para licitantes, o mais provável
O apelo do 516 era sua impressionante relação custo-desempenho e o design de seu
sistema de entrada / saída.
Mais de uma dúzia de propostas foram enviadas, resultando em uma pilha de papel de quase dois metros. Marill's
empresa, CCA, licitou em conjunto com a Digital. A Raytheon licitou e a Bunker-Ramo também. Roberts
ficou agradavelmente surpreso que vários dos entrevistados acreditavam que poderiam construir um
rede com desempenho mais rápido do que a meta listada nas especificações.
Raytheon foi um dos pioneiros. Uma grande empreiteira de defesa na área de Boston, especializada
em componentes de sistemas eletrônicos, a Raytheon já havia proposto construir um sistema de alta velocidade,
rede de computadores de curta distância. Em meados de dezembro, Roberts entrou na final
negociações com a Raytheon para o contrato IMP. Funcionários da Raytheon responderam ao ARPA
restantes questões técnicas e aceitou o preço.
Então, todos ficaram surpresos quando, poucos dias antes do Natal, o ARPA anunciou que
o contrato para construir os Processadores de Mensagem de Interface que residiriam no núcleo de seu
rede experimental estava sendo concedida a Bolt Beranek e Newman, uma pequena
empresa de consultoria em Cambridge, Massachusetts.

3
Página 53
A terceira universidade
Quando Richard Bolt e Leo Beranek começaram sua empresa de consultoria em 1948, avançaram
a computação não estava em suas mentes. Beranek era engenheiro elétrico, Bolt arquiteto
e físico. Ambos eram acústicos e membros do corpo docente do MIT durante os anos 1940.
Bolt havia trabalhado para a Marinha na Segunda Guerra Mundial em métodos de uso de som para detectar
submarinos. Após a guerra, como chefe do laboratório de acústica do MIT, Bolt fez
trabalho de consultoria, assim como Beranek. O MIT começou a receber pedidos de ajuda em acústica
planejando novos edifícios em todo o país e os repassando a Bolt e Beranek.
Independentemente um do outro, os dois já haviam trabalhado bastante no que é
conhecido como acústica aerotransportada - o som transportado em salas de concerto e cinemas - como
bem como no controle de ruído e redução de ruído em edifícios.
Quando as Nações Unidas pediram a Bolt para projetar a acústica de seu novo complexo de
edifícios em um antigo bairro de matadouros no East River de Manhattan, Bolt chamou
Beranek entrou em seu escritório e mostrou a pilha de papéis que continham o trabalho da ONU. isso foi
muito para uma pessoa assumir. Na época, Beranek estava ocupado em um projeto para
melhorar a acústica em uma rede de cinemas do Brooklyn. Mas Bolt convenceu Beranek
juntar-se a ele na criação de uma empresa de consultoria para assumir o projeto da ONU. Um ano depois eles
pegaram
em Robert Newman, um arquiteto com formação em física que foi aluno de
Nasceu Bolt's e Bolt Beranek e Newman.
Em seus primeiros dias, a BBN foi realmente uma empresa de consultoria. Ou seja, Bolt e Beranek contrataram
pessoas, forneciam-lhes espaço de escritório - e esperava que encontrassem o trabalho. E encontra
trabalho que eles fizeram. O projeto da ONU foi um sucesso tão notável que a empresa não
precisa anunciar durante os primeiros dez anos de sua existência. O negócio cresceu com a BBN
consultado sobre o projeto de sistemas acústicos para edifícios de escritórios, complexos de apartamentos,
e centros de artes cênicas. Quando um grande túnel de vento foi construído para testar motores a jato
perto de Cleveland, o barulho perturbou as pessoas em um raio de dezesseis quilômetros e os residentes locais
ameaçou fechar as instalações. Os engenheiros da BBN descobriram uma maneira de abafar o
som. A empresa estava desenvolvendo expertise na análise de fitas de áudio: foi chamada em
após o assassinato do presidente John F. Kennedy em 1963 e seria chamado
novamente após o tiroteio na Kent State University em 1970. Sua análise de fita mais famosa
viria durante o escândalo de Watergate em 1974, quando a BBN estaria envolvida no
análise do infame intervalo de 18,5 minutos nas fitas de Nixon. Um comitê liderado por
Dick Bolt concluiria que o apagamento foi deliberado.
Em 1957, Beranek recrutou Licklider para a BBN. Ele havia trabalhado com Lick em Harvard
durante a guerra, e quando ele foi para o MIT, ele convenceu Lick a ir para lá também. Quando
Beranek contratou Lick na BBN, não era tanto a experiência de Lick em psicoacústica, mas
seu interesse na interação homem-máquina que Beranek considerou interessante. Beranek
percebeu que os empregos de consultoria aumentariam no ramo de ajudar as empresas a construir
máquinas que eram amplificadores mais eficientes do trabalho humano, o que significava trazer
sobre algum tipo de compatibilidade entre humanos e máquinas. “Eu não sabia o quão grande
era um negócio ”, recordou Beranek mais tarde. “Mas eu pensei que era um bom suplemento para
o que estávamos fazendo. ”

Página 54
Lick, é claro, havia pensado mais profundamente. Ele acreditava no futuro da ciência
a pesquisa seria ligada a computadores de alta velocidade, e ele pensava que a computação era
um bom campo para a BBN entrar. Ele estava na BBN há menos de um ano quando disse
Beranek gostaria de comprar um computador. A título de persuasão, Lick enfatizou que o
computador que ele tinha em mente era uma máquina muito moderna - seus programas e dados eram
perfurado em fita de papel em vez de pilhas convencionais de cartões IBM.
“Quanto vai custar?” Beranek perguntou a ele.
“Cerca de $ 25.000.”
“É muito dinheiro”, respondeu Beranek. "O que você vai fazer com isso?"
"Eu não sei."
Licklider estava convencido de que a empresa seria capaz de obter contratos da
governo para fazer pesquisa básica usando computadores. Os $ 25.000, garantiu a Beranek,
não seria desperdiçado.
Nenhum dos três diretores da empresa sabia muito sobre computadores. Beranek sabia disso
Lick, por outro lado, era quase evangelístico em sua crença de que os computadores não mudariam
apenas a maneira como as pessoas pensavam nos problemas, mas a maneira como os problemas eram resolvidos.
A fé de Beranek em Licklider venceu o dia. “Eu decidi que valia a pena gastar
$ 25.000 em uma máquina desconhecida para um propósito desconhecido ”, disse Beranek. O computador
que ele comprou para Lick foi um LGP-30, fabricado em 1958 pela Royal-McBee, um
subsidiária da Royal Typewriter Company. Ele tinha uma memória de bateria e era lento até
pelos padrões de sua época. No entanto, Lick foi direto para o trabalho de mexer nele, usando-o para
longos cálculos estatísticos e experimentos psicoacústicos.
Pouco depois de o computador chegar, Ken Olsen parou para ver o Royal-McBee
máquina e para contar à BBN sobre o computador que ele estava construindo em sua nova empresa, a Digital
Equipamento. Olsen queria emprestar a Beranek um protótipo da máquina, que ele chamou
o PDP-1, para que os engenheiros da BBN pudessem dar uma olhada nele. Beranek concordou. Mas o computador
media mais de um metro por 2,5, e havia poucas portas na BBN pelas quais
aperte. Então, foi instalado no saguão. Um mês ou mais depois, depois que todos tiveram uma chance
para brincar com ele, a BBN o enviou de volta a Olsen com recomendações de ajustes. Quando
o PDP-1 foi colocado no mercado por pouco menos de US $ 150.000, a BBN comprou o primeiro.
A presença do PDP-1 e o trabalho que Licklider estava fazendo com ele atraiu vários
dos principais cientistas da computação para a BBN. A empresa também se tornou conhecida como um lugar
cuja filosofia de contratação era recrutar pessoas que abandonaram o MIT. A ideia era que se eles pudessem obter
no MIT eles eram inteligentes e, se desistissem, você poderia obtê-los mais barato. Beranek
deu a Lick uma grande liberdade para contratar quem quisesse, e Licklider fez apenas
isso, às vezes esquecendo de contar a Beranek. “Eu estava vagando pelo prédio
dia para ver o que estava acontecendo no lado do computador, e eu vi dois caras estranhos sentados
uma das grandes salas lá ”, disse Beranek. (Lick ficaria feliz em usar um terno
a um piquenique, mas seus contratados eram decididamente menos formais.) Beranek não tinha ideia de quem eram
os dois
os homens eram. “Aproximei-me do primeiro sujeito e perguntei: 'Quem é você?' e ele disse: 'Quem

Página 55
e você? '”Os dois jovens, ao que parece, eram amigos de Licklider do MIT -
Marvin Minsky e John McCarthy, duas das figuras mais proeminentes do mundo emergente
campo da inteligência artificial.
O PDP-1 tinha poder de computação aproximadamente equivalente aos organizadores de bolso de hoje e um
um pouco menos de memória. O pessoal da BBN mantinha o computador funcionando dia e noite fazendo
programação interativa. Eles até construíram um sistema de compartilhamento de tempo em torno disso, dividindo o
tela para quatro usuários simultâneos. A demonstração de time-sharing foi um sucesso e
A BBN decidiu iniciar um serviço de compartilhamento de tempo na área de Boston, colocando terminais
em toda a cidade. Logo, no entanto, a General Electric montou um esforço semelhante e
rapidamente roubou a maior parte dos negócios de compartilhamento de tempo da BBN.
A presença de um computador acessível inspirou uma mudança na empresa. Todos
começou a pensar em coisas que poderiam ser feitas com ele. Um cientista da BBN, Jordan Baruch,
decidiu que os hospitais poderiam usar computadores para manter informações mais precisas sobre os pacientes,
então
ele começou a informatizar o tratamento de registros no Massachusetts General Hospital. Lamber
e outros começaram a explorar maneiras de os computadores transformarem as bibliotecas. Mas
os computadores no início dos anos 1960 ainda eram muito fracos para fazer alguma coisa.
Nessa época, a BBN começou a se concentrar seriamente na tecnologia da computação. o
A rica atmosfera acadêmica da BBN deu à empresa de consultoria a reputação de “a terceira
universidade ”em Cambridge. “Eu tinha a política de que cada pessoa que contratávamos tinha que ser melhor
do que as pessoas anteriores ”, disse Beranek. Ao lado do MIT e Harvard, a BBN tornou-se uma das
os lugares mais atraentes para trabalhar na área de Boston. Algumas pessoas até consideraram isso
melhor do que as universidades porque não havia obrigação de ensino e nem preocupação com
ganhando estabilidade. Era um ambiente rarefeito - o conhaque do negócio de pesquisa.
A divisão de acústica-arquitetônica da empresa passou por uma crise no início dos anos 1960, quando
Beranek foi contratado para projetar a acústica do novo Philharmonic Hall (mais tarde renomeado
Avery Fisher Hall) no Lincoln Center de Nova York. Beranek e o arquiteto-chefe
foram criticados por ignorar certos princípios acústicos importantes na concepção
salas de concerto. Depois de muitas tentativas de pequenos ajustes, ficou claro que a situação
estava sem esperança. O problema teve que ser resolvido pela força bruta: as paredes e varandas eram
arrancado, junto com o teto - dez mil toneladas de material de construção ao todo - e carregado
para lixões. O reparo levou vários anos e milhões de dólares para ser realizado, sob o
supervisão de um novo consultor. Em sua cobertura exaustiva dos problemas, a NewYork
O Times concentrou sua atenção em Leo Beranek.
Se a BBN já não tivesse diversificado em pesquisa de computador, o desastre do Lincoln Center
poderia ter representado seu fim. Em meados da década de 1960, no entanto, os escritórios da empresa tinham
expandiu-se em uma fileira de edifícios baixos e bastante indefinidos, principalmente armazéns antigos que
ficava ao longo de uma rua tranquila perto de Fresh Pond, na margem oeste de Cambridge. Os escritórios
tinha uma uniformidade arquitetônica casual melhor descrita como modernismo barato - Mondrian
sem as cores. Eram prédios simples, parecidos com caixas, cujos telhados planos,
poucas janelas e paredes finas exalavam simplicidade e economia no design. Quatro dos
edifícios foram construídos para outros fins, principalmente como espaço de armazenamento, antes da BBN
comprou e converteu em escritórios, lojas e laboratórios. Edifício número 2 era

Página 56
projetado pelo próprio Bolt e tinha algumas características incomuns: Sua base "flutuou" em
a lama de Cambridge, isolando efetivamente toda a estrutura das vibrações externas;
e foi projetado para o tipo de pessoa que a BBN estava contratando - acadêmicos - que Bolt
espera encher seus escritórios com livros. Portanto, ele projetou o novo edifício para
suportar uma quantidade incomum de peso. Havia corredores e passarelas fechadas
entre todos os edifícios da BBN, tornando possível seguir uma espécie de caminho sinuoso
através da linha completa sem sair de casa durante o inverno. Por um tempo, BBN
dependia de vapor emprestado canalizado de uma lavanderia adjacente para aquecer alguns dos
quartos.
Entre os pesquisadores da computação estavam Wally Feurzeig e Seymour Papert, que foram
trabalhando em aplicações educacionais. Papert foi consultor da BBN por cerca de quatro anos
no final dos anos 1960. Enquanto estava lá, ele concebeu e fez o primeiro design bruto de um
linguagem de programação acessível a crianças em idade escolar. A ideia era
adotado como tema de pesquisa pelo grupo de educação da BBN, dirigido por Feurzeig, e o
a linguagem passou a ser chamada de LOGO.
Embora os acústicos geralmente trabalhassem de paletó e gravata, a atmosfera no
lado do computador estava decididamente mais relaxado. “Quando entramos no negócio de computadores, nós
teve as pessoas mais estranhas trabalhando para nós ”, disse Beranek. Ele apreciou o brilho de
as pessoas que Lick contratava, mas raramente se sentia confortável perto deles. Ele lembrou de ter sido convidado
para uma festa de Ano Novo na casa de um engenheiro de computação por volta de 1965. “Foi como
indo para a casa da Família Addams ”, disse Beranek. “Estavam todos descalços. o
as mulheres usavam roupas justas. Eu apareci de gravata e tive que levar
fora."
Frank Heart foi uma exceção notável. Conservador em seu traje e propenso a cautela em
general, Heart era na época um engenheiro de sistemas de computador no Lincoln Lab do MIT. No
1966 A BBN embarcou em uma campanha para contratá-lo para seu projeto de computador hospitalar. Coração
era um engenheiro com reputação de fazer as coisas acontecerem. Diga a ele que você queria
algo construído e, por Deus, você o teria. Mas Heart também era obstinado e não
fácil de arrancar de Lincoln.
Um autodescrito "garoto judeu superprotegido de Yonkers", Heart era estudioso e, em
colegial, meio nerd. Frank queria desesperadamente frequentar o MIT, o que representava um
problema para seus pais, que eram modestos. (Durante a depressão, o coração
pai conseguiu manter seu emprego como engenheiro da Otis Elevator.) A ideia de enviar
seu único filho em uma escola tão distante foi particularmente difícil para a mãe de Frank, que
fez a maior parte da superproteção. O MIT o admitiu em 1947, mas com uma bolsa de estudos.
pequeno para garantir contínuas lutas financeiras para seus pais.
Seguindo o exemplo dado por seu pai, que construiu sistemas de controle de elevador, Frank
decidiu se tornar engenheiro elétrico antes de entrar no MIT. Para aliviar a tensão financeira
sobre a família, matriculou-se em um programa de mestrado de cinco anos, no qual trabalha e
escola foram combinados em semestres alternados. Ele trabalhou um verão em um General
Fábrica elétrica testando grandes transformadores. “Isso era algo que você quer fazer
apenas uma vez ”, lembrou Heart. Em seu segundo ano, ele escolheu se especializar em poder

Página 57
engenharia - o projeto de sistemas elétricos em grande escala, como usinas de energia, construção
transformadores, geradores e motores.
Então ele descobriu os computadores. Em 1951, o último ano do Heart, o MIT ofereceu seu primeiro curso
nunca em programação de computadores, ensinado por um professor visitante chamado Gordon Welchman.
Coração inscrito. “Foi uma revelação incrível para mim que algo como um computador
poderia existir ”, disse Heart. Ele abandonou o programa de trabalho-estudo, uma decisão que
chocou muitas pessoas porque era um programa muito difícil de entrar. “Eu tenho todos os tipos
de cartas desagradáveis do MIT e GE ”Mas ele pegou o bug do computador e nunca
Olhou para trás.
Graças à introdução de Welchman, Heart ficou tão interessado em computadores que ele
obteve seu diploma de bacharel um semestre antes e terminou seu mestrado enquanto
trabalhando como assistente de pesquisa no Projeto Whirlwind. Whirlwind controlou um radar
sistema de defesa para rastreamento de aeronaves. Um sistema de radar ( RA dio D etection A nd R anging)
mede pulsos eletromagnéticos refletidos de um objeto para fornecer informações
quanto à sua direção e distância. Dispositivos de interferência podem destruir dados de um único
radar, mas uma série de radares pode compensar se estiverem trabalhando em conjunto com um
computador. Whirlwind deu a Heart seu primeiro gostinho de programação em tempo real
meio Ambiente. Quando Whirlwind foi transferido para Lincoln Lab, Heart foi transferido
com isso. “Foi o tipo de mudança de emprego mais indolor que alguém poderia imaginar”, disse Heart.
Muitos programas na década de 1950 foram escritos em "linguagem de máquina", as instruções reais
na “linguagem natural” do computador. Os comandos tinham que ser especificados de forma exaustiva
detalhe; havia uma correspondência um a um entre cada linha do programa e cada
instrução para a máquina. Trabalhar em linguagem de máquina pode ser entediante e cometer erros
eram difíceis de encontrar e corrigir. Mas deu aos programadores um forte senso de
identificação com a máquina. A programação de computadores ainda era tão nova que poucas pessoas
compreendeu suas complexidades. Muitos que trabalharam nas ciências mais tradicionais ignoraram (ou
rejeitados) aqueles que exploravam os computadores como uma ciência.
O Lincoln Laboratory estava provando ser uma incubadora perfeita para o tipo de gênio que
O ARPA precisaria levar a computação para a era interativa e interconectada. Tinha
já se tornou um terreno fértil para alguns dos trabalhos iniciais mais importantes em
computação e rede. Muitos de seus ex-alunos - entre eles, Licklider, Roberts, Heart,
e outros ainda por vir - desempenhariam papéis cruciais na concepção e desenvolvimento do
Rede ARPA. Nos primeiros dias, os programadores de computador da Lincoln eram mal
considerada. Apenas físicos e matemáticos de pleno direito foram permitidos na pesquisa
funcionários e muitos programadores deixaram Lincoln como resultado. Mas Heart quebrou o
preconceito. Ele começou como programador de pós-graduação, tornou-se membro da equipe e
em pouco tempo ele estava comandando um grupo.
Heart também desrespeitou as regras. Ele tinha pouca tolerância para delineamentos profissionais e
não levava os títulos muito a sério. Quando um jovem programador chamado Dave Walden veio
trabalho na Lincoln, foi contratado com o título de assistente técnico. O fato de que isso
não era um cargo de nível de equipe foi claramente indicado em seu crachá de segurança. Títulos eram
importante na Lincoln, e entre outras coisas, o distintivo o mantinha fora do contato

Página 58
seminários. Ignorando tudo isso e desprezando o protocolo que designava não-funcionários para os menos
desejável espaço de trabalho, Heart instalou Walden em um escritório com um dos mentores de Walden, um
jovem graduado do MIT chamado Will Crowther. Crowther era um físico que virou computador
cientista.
No final dos anos 1950 e início dos anos 1960, Heart, Crowther e outros próximos a eles trabalharam em
um projeto inovador após o outro. Com o tempo, Heart e sua equipe em Lincoln tornaram-se
especialistas em conectar uma variedade de dispositivos de medição a computadores por meio de linhas telefônicas
para
coleta de informações. Isso, por sua vez, os tornou especialistas na construção de computação em tempo real
sistemas.
Quando um grupo de colegas do Heart saiu para iniciar a MITER Corporation em 1958, o Heart
permaneceu firmemente amarrado a Lincoln, em parte porque ele sempre não gostou de mudanças e
em parte porque ele amava o que estava fazendo. Ele não conseguia se imaginar tendo mais
trabalho interessante ou um grupo mais talentoso com o qual trabalhar.
No verão de 1965, Heart conheceu Danny Bobrow, que estava trabalhando em
inteligência na BBN. Bobrow sugeriu a Heart que deixasse Lincoln para trabalhar na BBN,
supervisionar um projeto para introduzir tecnologia de informática em hospitais. Quando coração
recusou, Dick Bolt interveio.
Uma das razões pelas quais os diretores da BBN estavam ansiosos para cortejar Heart era que ele tinha
experiência frutífera em montar sistemas que funcionaram de forma eficiente no campo. o
a empresa precisava de alguém assim. Apesar de toda a sua inovação, a BBN não foi muito
sucesso em transformar suas idéias em sistemas funcionais e utilizáveis. “A cultura na BBN em
o tempo era fazer coisas interessantes e passar para a próxima coisa interessante ”, disse um
ex-empregado. Havia mais incentivo para ter ideias interessantes e
explorá-los do que tentar capitalizá-los depois de desenvolvidos.
Bolt convidou Heart para sua casa. Eles tiveram mais reuniões na BBN. Eles se conheceram no local
Howard Johnson. Heart continuou relutante, mas havia aspectos do trabalho da BBN que
apelou para ele. Como Licklider, Heart sempre teve o que ele descreveu como um
Visão do “dogooder”: Heart acreditava que os computadores e a tecnologia poderiam ajudar a sociedade.
Casado como era com os militares, o Lincoln Lab nunca tinha ido muito longe do ar
Necessidades da força. Na verdade, o foco estreito do laboratório precipitou a saída de pessoas como
Ken Olsen e Wes Clark, que saiu para construir computadores. Heart também estava interessado no
aplicação de computadores às ciências da vida, e Bolt o informou que teria o
oportunidade de perseguir esse interesse na BBN. Além disso, um amigo do Heart de Yonkers,
Jerry Elkind estava na BBN, e Heart respeitava Elkind bastante. “Também ocorreu a
eu ”, admitiu Heart,“ que havia uma chance de eu ganhar algum dinheiro em um privado
corporação."
No final, Bolt o convenceu a aceitar o cargo, mas quando Heart chegou à BBN, o
a pesquisa de computador da empresa estava sendo realizada por duas divisões distintas:
ciências da informação e sistemas informáticos. Como regra geral, aqueles com Ph.D. trabalharam
nas ciências da informação, ou pesquisa, divisão, enquanto aqueles sem Ph.D. trabalharam em
a divisão de sistemas de computador. Um membro da divisão de ciências da informação
descreveu a divisão de sistemas de computador como consistindo de um grupo de caras com solda

Página 59
ferros. Em outras palavras, eles acabaram de construir as coisas, enquanto aqueles na divisão de pesquisa
consideravam-se mais preocupados em inventar o futuro. Não havia muito
polinização cruzada entre os dois grupos. Eles trabalharam em edifícios separados, divididos por
uma passarela estreita envidraçada. Não era a animosidade, exatamente, que os separava, nem
foi rivalidade. Cada um estava ciente das limitações do outro, resultando em uma notável falta
de interesse no que aconteceu no outro campo. Frank Heart era um cara de sistemas através
e por diante.

Licitação
Quando o pedido de propostas da ARPA para construir o IMP chegou à BBN em agosto de 1968, o
a empresa teve trinta dias para responder. Jerry Elkind, que agora era o chefe do Heart, estava em
responsável por ambas as divisões de informática. Ele achou que a BBN deveria dar um lance, e ele pensou
era a melhor pessoa da empresa para administrá-lo. Desde o fim do hospital
projeto de computador logo após sua chegada, o Heart estava procurando por um projeto de longo prazo
projeto no qual se imergir. Além disso, Heart provavelmente teve mais experiência
na construção do tipo de sistema de computador que a ARPA estava procurando. No entanto, quando
Elkind sugeriu que ele assumisse, Heart era tipicamente cauteloso.
Coração pode ser difícil de interpretar no início. Alex McKenzie, que trabalhou para o Heart em
e fora por vinte e sete anos, lembrou-se da primeira vez que encontrou seu novo chefe - de
a outra extremidade de um corredor. Coração estava falando em voz alta e estridente para alguém
outra coisa e parecia agitado. “Ele estava realmente gritando, e eu pensei que deveria ser um problema,”
McKenzie lembrou. “Mais tarde, descobri que era simplesmente entusiasmo.” Alguns anos depois,
enquanto estava em um avião com Heart, McKenzie finalmente contou a ele sobre sua impressão inicial.
O coração ergueu as sobrancelhas. "GRITANDO?!" Coração gritou, sua voz alcançando seu
falsete marca registrada, alto o suficiente para atrair a atenção de todos ao seu redor. "Eu não
grito!" Isto é, não quando estiver com raiva. “Quando ele está com raiva, ele fica muito quieto”, disse McKenzie.
As reuniões com o Heart ocasionalmente envolviam muitos gritos. “E então no dia seguinte
Acontece que ele ouviu o que você disse durante toda a gritaria ”, lembrou outro
funcionário de longa data. "Se você estava disposto a aguentar a gritaria, ele fez
as coisas dão certo, ao contrário da maioria das pessoas que gritam e berram. ” Coração tinha prodigioso
energia, o que tornava difícil para ele ficar parado por mais do que alguns minutos de cada vez.
Ele ficava mais relaxado quando estava em casa, trabalhando em sua marcenaria no porão,
onde ele assobiava peças longas e complexas de música perfeitamente, raramente ciente de que estava
fazendo isso. Quando as coisas estavam tensas ou incertas, ele roia as unhas ou tamborilava
dedos nas mesas.
Heart era intensamente leal às pessoas que trabalhavam para ele e elas, por sua vez, eram leais
para ele. Ele também estava cuidando, não apenas de seus três filhos (ele alegremente assumiu
muitas tarefas de cuidar dos filhos, não esperadas dos maridos naquela época), mas também para com seus
funcionários. Ao mesmo tempo, ele levava muitas coisas para o lado pessoal, especialmente quando as pessoas
deixou seu grupo para ir trabalhar em outro lugar, mesmo que fosse apenas do outro lado do corredor para outro
divisão.

Página 60
Um dos maiores pontos fortes de Heart foi garantir que os empregos para os quais ele se inscreveu realmente
feito, e ao assumir o trabalho do ARPA, ele estava preocupado com o risco de cometer o
empresa a algo que talvez não seja capaz de realizar. O projeto foi embalado com
incertezas e tecnologia inexplorada. Coração achou difícil avaliar exatamente o que
estava envolvido. Não havia tempo para fazer o tipo de planejamento detalhado que gostaria de fazer em um
projeto de software de sistemas, como estimar o número de linhas de código que seriam
necessário.
A avaliação de risco é essencial em qualquer empresa de engenharia. Porque não é significativo
projeto tecnológico pode ser totalmente livre de riscos, as probabilidades de sucesso e fracasso de
projetos particulares são fatorados e pesados. O potencial para problemas cai em três
categorias: o previsto, o imprevisto mas previsível e o imprevisível. No ultimo
engenheiros de caso são forçados a tomar decisões com os dedos cruzados. A situação
enfrentando Coração caiu amplamente nesta última categoria, uma vez que grande parte do sistema não tinha
precedente no qual basear as estimativas de risco.
As incertezas do software eram bastante sérias, mas existia uma infinidade de outras incógnitas.
Por exemplo, quanto tráfego uma rede poderia lidar sem encontrar
logjams? Qual era a chance de que a falha de um nó se propagasse através do
rede? Em novembro de 1965, por exemplo, um relé sobrecarregado causou um efeito cascata
que derrubou a rede de energia elétrica que atendia a todo o nordeste dos Estados Unidos.
Acima de tudo, qual era a probabilidade de a rede funcionar? Inscrevendo-se para um
projeto como a rede ARPA exigia uma certa dose de fé absoluta, e que
Coração perturbado.
Elkind foi motivado por sua sensação de que a ARPA estava promovendo o estado da arte da
computação em uma nova era, e do ponto de vista dos negócios, fazia muito sentido
lançar a BBN em direção a esse futuro. Elkind reconheceu que as preocupações de Heart eram racionais.
“Mas me ocorreu que este era um contrato que tínhamos que fazer e poderíamos fazer tão bem quanto qualquer um”,
Elkind disse. “Nós sabíamos como trabalhar com o ARPA e tínhamos conhecimentos de informática tão bons quanto
alguém por perto. ”
Elkind sugeriu a Heart que um pequeno grupo da BBN se reunisse para decidir o que fazer
com a solicitação de propostas do ARPA. Eles concordaram em se encontrar informalmente e escolheram Danny
A casa de Bobrow em Belmont como o local. A primeira reunião foi até tarde da noite.
Quando acabou, Heart estava convertido e a participação da BBN tinha sido igual
como garantido.
Essa era a parte fácil. Eles então tiveram apenas um mês para escrever uma proposta detalhada. Um de
a primeira pessoa a se envolver com a proposta foi Bob Kahn, professor de elétrica
de licença do MIT e trabalhando na divisão de ciências da informação da BBN. Em
MIT, Kahn foi um matemático aplicado trabalhando em comunicações e
teoria da informação. A maioria de seus colegas possuía uma combinação de teóricos e
habilidades de engenharia aplicada. Um dia Kahn estava conversando com um colega sênior do MIT
sobre os diferentes problemas técnicos nos quais ele estava interessado, e ele perguntou: “Como
você pode dizer quando um problema é mais interessante do que outro? ” “É apenas experiência,”
O colega de Kahn respondeu. “Como se consegue isso?” Kahn perguntou. "Encontra alguém

Página 61
que tem muita experiência e vai trabalhar com ele. ” Um lugar óbvio para Kahn
adquirir essa experiência foi a BBN. Então ele foi.
Por coincidência, em 1967, na época em que Larry Roberts estava em Washington formulando
o projeto da rede e seus requisitos, Kahn estava na BBN tendo suas próprias ideias
sobre redes. Ainda mais coincidentemente, por insistência de Jerry Elkind, ele tinha enviado
memorandos técnicos não solicitados para Bob Taylor e Roberts. Quando Roberts disse a Kahn que
ARPA estava planejando financiar uma rede nacional, foi uma revelação agradável para Kahn.
Então Elkind disse a ele que um grupo da divisão de sistemas de computador da BBN estava interessado
em montar uma proposta para a rede ARPA e sugeriu que Kahn obter
envolvidos no processo.
Não muito tempo depois, Frank Heart vagou até o escritório de Kahn. “Eu entendo de
Jerry, que você tem pensado na área de networking. Podemos conversar sobre isso? ”
“Sim, claro”, respondeu Kahn. "Quem é Você?"
Em 1968, a BBN tinha mais de seiscentos funcionários. O grupo de Frank Heart ocupou uma fileira
de escritórios ao longo de um trecho de corredor de azulejos de linóleo no Edifício Número 3. Em uma das
extremidades do
o corredor era uma sala de conferências com muitos quadros-negros e assentos para grandes
encontros. Os próprios escritórios eram pequenos e modestos, com mesas feitas
de portas às quais pernas foram fixadas pela oficina de construção da BBN. Dorso rígido
cadeiras de madeira e cadeiras de diretor com forro de lona eram os estilos preferidos. Fluorescente
iluminação, alguns efeitos pessoais, muitas prateleiras e pouco mais completavam o quadro.
Heart gostava de trabalhar com grupos pequenos e bem unidos compostos de pessoas muito brilhantes. Ele
acreditava que a produtividade e o talento individuais variavam não por fatores de dois ou três, mas
por fatores de dez ou cem. Porque Heart tinha um talento especial para localizar engenheiros que
poderia fazer as coisas acontecerem, os grupos que ele supervisionou em Lincoln tendiam a ser
excepcionalmente produtivo.
Uma das primeiras pessoas que o Heart chamou para ajudar com a proposta do IMP foi Dave
Walden, que havia seguido Heart de Lincoln à BBN. Embora jovem, com apenas quatro ou
cinco anos de experiência em programação, Walden tinha um conhecimento altamente cultivado em real
sistemas de tempo - ideais para o trabalho da rede ARPA. A Next Heart elaborou Bernie Cosell, um
jovem programador que trabalhava na divisão de sistemas de computador da BBN. Cosell
era um depurador por excelência, alguém que poderia mexer em um computador
programa que ele nunca tinha visto antes e em dois dias consertar um problema que não tinha solução
por semanas. Heart também recrutou Hawley Rising, um engenheiro elétrico de fala mansa que foi
um velho amigo dos tempos de estudante de Heart no MIT.
O ás do hardware do Heart foi Severo Ornstein, um ex-aluno de Lincoln de 38 anos que
havia trabalhado para o Heart intermitentemente por anos. Ornstein era um homem intenso de muitos e
interesses diversos. Filho de um pianista virtuoso e compositor proeminente, Ornstein teve
frequentou Harvard e flertou brevemente com uma especialização em música antes de seus pais discutirem
ele fora disso. Ele finalmente decidiu pela geologia. Depois de deixar Harvard, Ornstein tornou-se
interessado em computadores e tinha ido trabalhar na Lincoln. Quando seu colega Wes Clark

Página 62
partiu para a Universidade de Washington em St. Louis para construir um computador projetado por ele mesmo,
Ornstein foi com ele. Após três anos em St. Louis, Ornstein ansiava por voltar
Cambridge, então ele ligou para Heart, que lhe ofereceu um cargo na BBN.
Quando chegou o pedido de propostas da ARPA, Heart entregou uma cópia a Ornstein e
disse: "Por que você não leva isto para casa e dá uma olhada, vê o que você acha?" Ornstein
voltou ao escritório do Heart no dia seguinte e disse: "Bem, claro, suponho que poderíamos construir
isso se você quisesse. Mas eu não consigo ver para que alguém iria querer uma coisa dessas. ” Não obstante,
Ornstein achou que o projeto de construção do IMP parecia divertido, o que sempre foi uma
consideração por ele.
Heart tinha uma predileção por julgar as pessoas não por sua aparência, maneiras ou política
opiniões, mas quase puramente por quão inteligentes ele acreditava que eles eram. Ou, como ele gostava de dizer,
por quantos neurônios por centímetro cúbico seus cérebros continham. Se ele decidiu o
o número era excepcionalmente alto, o Heart provavelmente toleraria muito mais idiossincrasia em um
do que em outro cuja massa cinzenta ele pensava estar menos compactada. Ao falar,
Heart costumava usar jargões de informática em circunstâncias não técnicas. “É um ambiente autônomo”, ele pode
dizer a sua esposa Jane se eles decidiram deixar uma tarde de domingo livre. (No-op, ou não
operação, refere-se a uma linha de código que não realiza nada.) Ou ele pode dizer: “É
binário ”, para um de seus filhos pequenos, o que significa que é uma situação em preto e branco.
O talento de Heart para reunir equipes de engenharia eficazes o tornara um excelente
gerente de projeto considerado e valioso. Ele procurou por pessoas que estariam comprometidas com
uma missão comum em vez de uma agenda pessoal. Ele preferia manter as equipes pequenas, então
que todo mundo estava sempre falando com todo mundo. O coração escolheu o tipo de pessoa que
assumiu responsabilidade pessoal pelo que fizeram. E enquanto Heart tolerava idiossincrasia, ele
evitava “casos importantes” egocêntricos, por mais espertos que fossem.
Ao reunir a equipe da BBN para a proposta do ARPA, Heart garantiu que puxaria
engenheiros com todas as habilidades necessárias para um empreendimento tão ambicioso. Kahn, para
exemplo, foi o teórico consumado. Ele, mais do que qualquer pessoa na BBN, entendeu
os problemas associados ao envio de informações por linhas telefônicas, e ele teve
idéias sobre os melhores mecanismos de controle de erros. Ornstein era um perfeccionista e
mostrado no hardware que ele construiu, enquanto Walden trouxe com ele tanto o seu conhecimento
sistemas em tempo real e uma vontade decidida de trabalhar longas horas. Cosell tinha a habilidade de
mergulhe em programas de software complexos e encontre bugs mais rápido do que qualquer outra pessoa na BBN.
Por isso, Cosell era uma das apólices de seguro humano da empresa: Projetos
seria trabalhado por equipes, mas todo gerente da BBN sabia que se seu projeto entrasse
problemas, ele poderia colocar Cosell no trabalho e coisas sobre-humanas aconteceriam em um
pressa. Embora tenha permanecido uma grande quantidade de trabalho de design detalhado, entre eles o
os membros da equipe compreenderam as questões técnicas mais importantes.
Quando a equipe começou, o Heart já sabia o que o esperava: quatro semanas de trabalho
o tempo todo. Heart era esperado para jantar em casa todas as noites às seis e meia, e ele
sempre fez isso. Mas depois do jantar, ele desapareceu em seu escritório e não saiu até
muito depois de sua família ter ido para a cama.

Página 63
Uma decisão inicial importante foi qual hardware usar. A confiabilidade era, de longe, do coração
Principal preocupação. Seus quinze anos no Lincoln Lab construindo antenas e sistemas de radar para
os militares o ensinaram a se preocupar com a confiabilidade acima de tudo. Intuitivamente, Coração
acreditava que os alunos de pós-graduação que estariam mexendo nos IMPs no
os sites das universidades não conseguiriam tirar as mãos do equipamento. Ele tinha sido um
aluno, e ele provavelmente até fez os mesmos tipos de coisas que temia - inferno,
ele sabia - eles tentariam fazer. Eles iriam vasculhar a caixa para ver como funcionava.
As escolhas do coração eram limitadas. A indústria de minicomputadores ainda era relativamente jovem. Está
os líderes foram Digital Equipment e Honeywell. Desde o início, o problema de confiabilidade levou
Coração para favorecer o novo Honeywell DDP-516, a máquina alojada no aço para serviços pesados
gabinete. A Marinha tinha a reputação de estabelecer padrões de engenharia rigorosos. E alguns
da equipe da BBN conhecia algumas pessoas da Honeywell, que fizeram a máquina em uma fábrica
não muito longe da localização da BBN em Cambridge. O 516 também ajudou a acalmar o medo de Heart de que
alunos de pós-graduação curiosos podem derrubar a rede com seus ajustes. Ele poderia
descansar muito mais fácil sabendo que os IMPs seriam alojados em uma caixa construída para resistir a uma guerra.
A funcionalidade da sofisticada entrada / saída (E / S) do computador Honeywell
capacidade - a velocidade e eficiência com que poderia se comunicar com
dispositivos como modems - também ajudaram a colocá-lo no topo da lista. Como o manuseio de
O tráfego de I / O era a função principal do IMP, uma máquina com uma boa estrutura de I / O era
absolutamente essencial.
Pouco depois de escrever a proposta, Dave Walden começou a sentir que poderia estar fora de
sua profundidade. Como o primeiro programador que Heart trouxe para o projeto, Walden fez muitas das
pensando cedo sobre questões gerais de codificação, e ele fez alguns dos gráficos originais
esboçar em bloco o fluxo lógico e o tempo do programa. Walden teve
descreveu o suficiente do programa para perceber que estavam empreendendo algo difícil. Ele
decidiu que a proposta do ARPA seria uma boa desculpa para recrutar Will Crowther,
o engenhoso programador para quem Walden havia trabalhado na Lincoln, para liderar o software
esforço. Walden não estava nem um pouco relutante em chamar alguém acima dele. Ele era
confiante o suficiente em seus próprios talentos para ignorar preocupações hierárquicas que possam preocupar
muitas outras pessoas. Os dois trabalharam juntos na Lincoln, e Walden ficou mais feliz em
estar em um time com Crowther do que em um sem ele. E, além disso, Crowther era
excepcional.
Ter Crowther na equipe não aumentaria apenas as chances de fazer o software
trabalhos. Ter Crowther na BBN tornaria o trabalho mais agradável. Crowther
era silencioso, fácil de trabalhar e quando se tratava de escrever código, ele era totalmente
inspirador. Ele também era um bom amigo e companheiro de escalada de Ornstein. Crowther
parecia se concentrar melhor enquanto se pendurava nas molduras das portas pelas pontas dos dedos, fazendo
ups. E ele era conhecido por seus rabiscos matemáticos. Enquanto outros passaram o tempo em
longas reuniões desenhando rabiscos e arabescos, Crowther preencheu sua página com um
emaranhado de equações diferenciais.
Walden, Heart e Ornstein tinham certeza de que Crowther não tinha ficado totalmente feliz com
Lincoln desde que Heart partiu. Crowther gostava de trabalhar para o Heart e enquanto se reportava a

Página 64
Coração em Lincoln, ele se acostumou a ver coisas construídas. Depois que o Heart saiu, muito
das pessoas que trabalharam para ele voltaram a fazer ajustes menos produtivos.
Ornstein ligou para Crowther e disse: "Willy, você deveria vir para a BBN", para o qual
Crowther concordou prontamente.
Em Crowther, a BBN ganhou um acréscimo inestimável. Ele se especializou na produção de complexos,
pedaços de código bem escritos, que eram exatamente o que era exigido no IMP. De fato,
escrever pequenos e intrincados códigos era um dos maiores prazeres da vida de Crowther. Seu
código estava entre os mais enxutos que alguém que trabalhou com ele já tinha visto. Desde os IMPs
deviam ser conectados a linhas telefônicas, com dados constantemente fluindo para dentro e para fora, a ideia
era para um pacote de dados chegar a um IMP, ser processado e imediatamente enviado
encaminhar ou ser colocado em uma fila para aguardar sua vez - tudo em menos tempo do que levou para encaixar
seu
dedos. Cada instrução levou um ou dois milionésimos de segundo (microssegundos) para
executar. Uma vez que cada instrução desnecessária consumia um ou dois microssegundos extras, cada
pequena tarefa, ou pedaço de código de software, teve que ser escrito com frugalidade intensa, usando o
menor número de instruções possível.
Central para o projeto da rede era a ideia de que a sub-rede de IMPs deveria operar
invisivelmente. Então, por exemplo, se alguém sentado em um computador host na UCLA quisesse registrar
em um computador na Universidade de Utah, a conexão deve parecer direta. o
o usuário não deve se preocupar com o fato de que uma sub-rede existe. O efeito
era semelhante à discagem direta no sistema telefônico, o que liberava os chamadores do
aborrecimento de ter que esperar que uma operadora faça suas conexões. Como o labirinto de
equipamento de comutação automatizado em uma companhia telefônica, os IMPs deveriam ser "transparentes"
para o usuário. Como Roberts descreveu na chamada de propostas, “Cada host transmissor
olha para a rede através de seu IMP adjacente e se vê conectado ao receptor
hospedeiro."
Para conseguir essa transparência, a rede teria que ser rápida, livre de congestionamentos,
e extremamente confiável. Esses eram requisitos relativamente simples que Roberts
havia escrito na solicitação de propostas, mas ninguém esperava que realmente
realizá-los seria fácil.
No entanto, uma das primeiras coisas que a equipe de software da BBN descobriu foi que eles podiam
fazer o código processar dez vezes o número de pacotes por segundo que Roberts era
exigindo. Antes de qualquer coisa, Crowther e Walden escreveram o código para o interior
loop - o coração do programa - e contou o número de instruções. Roberts iria
se contentaram com um loop interno de 1.500 instruções; Crowther e Walden usaram
150. A partir daí, os dois programadores calcularam a rapidez com que o IMP poderia processar
cada pacote. Com essas informações, eles foram capazes de prever quantos pacotes poderiam ser
movido por segundo. “Na verdade, sentamos e escrevemos cento e cinquenta linhas de código,
os contamos e então soubemos ”, disse Crowther. Eles descobriram o kernel.
“Assumimos a posição de que será difícil fazer o sistema funcionar”, escreveu a BBN
na sua proposta. Desta forma cautelosa, a equipe da BBN informou a Roberts que
não deu por garantida uma tarefa sem precedentes em sua complexidade, revolucionária em

Página 65
conceito e cheio de detalhes técnicos de viabilidade incerta. No entanto, a proposta então
passou a demonstrar que a BBN parecia ter o problema resolvido.
Quando a proposta foi concluída, ela ocupava duzentas páginas e custava mais à BBN
de US $ 100.000, o máximo que a empresa já havia gasto em um projeto tão arriscado. A BBN
a equipe cobriu tanto do design dos IMPs que uma grande fração de todo o
sistema já estava claramente definido. A proposta final da BBN era mais um projeto do que
esboço. Seus engenheiros projetaram programas de teste e verificações regulares de desempenho para
IMPs e a rede. Eles descreveram como a rede lidaria com o congestionamento no
buffers (áreas de armazenamento nas máquinas que serviam como áreas de espera e áreas de preparação para
o fluxo de pacotes para dentro e para fora da rede), e como ele se recuperaria da linha e
falhas de computador. Eles forneceram ao ARPA fluxogramas que descrevem como o software IMP
trataria de problemas difíceis como o tempo e a atualização contínua de roteamento
tabelas. Eles vieram com cálculos detalhados, equações e tabelas que cobriam,
entre outras coisas, atrasos de transmissão e enfileiramento de pacotes. Estava tudo lá para
Roberts para ver.
A equipe da BBN apresentou sua proposta em 6 de setembro de 1968, relativamente certa de que não
outra pessoa preparou uma oferta tão detalhada quanto a deles. Anos depois, quando as pessoas que trabalharam em
a proposta da BBN foi questionada sobre quanto tempo levou para compor o documento, alguns dos
eles disseram honestamente que pensaram que tinha levado seis meses.
A equipe de Heart obviamente fez uma quantidade impressionante de trabalho extra de pá, resolvendo
alguns problemas que Larry Roberts não esperava ver cobertos. BBN realizou outro
vantagem: seu tamanho relativamente pequeno. Roberts não queria lidar com muita burocracia,
e as outras propostas estavam repletas disso. A equipe que Raytheon estava apresentando, para
por exemplo, abrangeu cinco camadas de gerenciamento. Roberts percebeu que apenas encontrar o
pessoa com quem conversar sobre o menor problema pode exigir uma dúzia de ligações.
A equipe da BBN, por outro lado, tinha uma hierarquia muito simples. Todos reportaram a
Coração, que distribuiu as tarefas e viu que eram feitas. O coração tinha um chefe, mas ele
parecia estar dando a Heart ampla liberdade para fazer o que quisesse com este projeto.
O primeiro sinal de que a oferta da BBN estava sendo levada a sério veio quando Roberts ligou para um
reunião para revisar partes da proposta. Heart, Crowther, Kahn e Ornstein, seus espíritos
alto, peguei o trem para Washington. (Heart tentou, sem sucesso, convencer Crowther a
usar algo nos pés além de tênis.) Durante a reunião, eles se defenderam e
expandido em sua proposta. Roberts testou, cutucou e cutucou os engenheiros para ver se
eles realmente pensaram profunda e completamente sobre o sistema. E suas perguntas
continuou por algumas semanas depois. “Em algum nível, acho que a continuação
o questionamento de Larry nos manteve pensando sobre os problemas e continuando a preencher
detalhes de design subliminarmente ”, lembrou Ornstein. “Mas acho que o mais importante era
que levamos isso a sério mais do que os outros concorrentes. Tornamos o design nosso problema
e fizemos o nosso melhor para encontrar soluções nas quais acreditávamos, sem nos curvarmos muito aos
especificações que outros colocaram. ”
Mas na maior parte do tempo, tudo o que podiam fazer era esperar. Se Roberts tivesse uma proposta favorita, ele
não estava deixando ninguém saber disso. Pode levar meses até que eles ouçam algo definitivo.

Página 66
No meio do outono, todos eles voltaram ao que estavam fazendo antes da proposta
maratona. O tempo desacelerou novamente. Crowther foi cavar, que, ao lado da escalada
e escrever código, era sua paixão. Heart chegou em casa na hora do jantar e não voltou para
trabalhos. Kahn era praticamente o único que, por força do hábito, costumava trabalhar até tarde
pela noite a dentro. Todo mundo estava ansioso. “Eu, pessoalmente, parti da certeza de que nosso
proposta não poderia ser derrotada ", disse Ornstein," para a crença de que não havia como
vitória, dado o tamanho da BBN em comparação com os outros concorrentes. ”
Ao longo do processo de avaliação, como o concurso para a Interface de Mensagem
O processador foi reduzido, a equipe da BBN ouviu rumores por meio do ARPA,
embora nunca do próprio Roberts, que permaneceu como uma esfinge. Naturalmente, eles fizeram muito
adivinhação. Em seus momentos mais pessimistas, os engenheiros da BBN estavam inclinados a
acreditam que, uma vez que Roberts conhecia muitos deles de Lincoln, pode ser difícil ou
estranho ou impossível para ele conceder o contrato à BBN. No entanto, o ARPA fez
só isso.
Quando a notícia chegou ao gabinete do senador Edward Kennedy de Massachusetts, pouco antes
Natal em que um contrato ARPA de um milhão de dólares foi concedido a alguns meninos locais,
Kennedy enviou um telegrama agradecendo à BBN por seus esforços ecumênicos e parabenizando o
empresa em seu contrato para construir o "Interfaith Message Processor".

4
Cabeça para baixo nos bits
O dia de ano novo de 1969 foi a última vez que o grupo de Frank Heart poderia descansar por
um bom tempo. Na semana seguinte, o contrato para construir a primeira Mensagem de Interface
Os processadores começaram oficialmente. Por um pouco mais de US $ 1 milhão, a BBN construiria quatro
IMPs; o primeiro era devido na UCLA no Dia do Trabalho, seguido por um a cada mês até
Dezembro. Em doze meses, a rede deveria estar instalada e funcionando, com quatro
sites on-line. A equipe da BBN já havia feito um grande trabalho na geração do
proposta. Agora, olhando para o futuro, eles viram pelo menos mais oito meses de madrugadas e
trabalho intensivo de engenharia de sistemas. Ainda havia muitos desafios desconhecidos, um ponto
enfaticamente enfatizado pela BBN em sua proposta. Além disso, os membros do Heart's
toda a equipe tinha ideias diferentes sobre como seria difícil construir os IMPs.
Heart encontrou vários céticos - funcionários da companhia telefônica e acadêmicos
principalmente - que não acreditava que uma rede de comutação de pacotes funcionaria. Construindo o
hardware não era realmente a parte difícil, eles argumentaram; em vez disso, fazer tudo funcionar junto -
a parte dos sistemas - era o truque. Mesmo se você pudesse integrar todo o hardware e
software e demonstrar a viabilidade de uma rede de computadores, alguns apontaram, ali
ainda não havia nenhum lucro nisso para uma empresa como AT&T ou IBM, não como um negócio
proposição. Quem, exceto alguns burocratas do governo ou cientistas da computação jamais
usa uma rede de computadores? Não era como se a computação tivesse um mercado de massa como a televisão
redes ou a companhia telefônica.

Página 67
Durante as semanas antes de ganhar a licitação, a maior dúvida da BBN era se o ARPA
confiaria o trabalho a uma empresa tão pequena. Os membros da equipe da BBN sabiam lá
estava dependendo muito deles agora. Se os IMPs não funcionassem, rede e comutação de pacotes
cairia no esquecimento de experimentos fracassados. Algumas pessoas - outros licitantes principalmente -
expressou surpresa pela pequena BBN ter ganhado o contrato. “Este tipo de sistemas grandes
trabalho simplesmente não parecia ser o beco da BBN ”, disse um concorrente.
Em geral, Heart ignorou os detratores, embora ele também se preocupasse ocasionalmente com
os desafios técnicos que se avizinham. Para ser eficaz, uma rede de dados teria que
enviar pacotes de forma confiável, apesar dos erros inevitavelmente introduzidos durante a transmissão
linhas telefônicas comuns. Os ouvidos humanos toleram o ruído da linha telefônica, que muitas vezes é pouco
audível, mas os computadores que recebem dados são minuciosos sobre ruído e o menor chiado ou
pop pode destruir pequenos bits de dados ou instruções. Os IMPs deveriam ser capazes de
compensar.
Em seguida, havia interrupções de circuito a serem previstas, especialmente se o experimento de quatro nós
expandiu de costa a costa conforme previsto pelo ARPA. Um ponto de mau tempo em algum lugar, um
tempestade no meio-oeste ou uma nevasca da Nova Inglaterra, interromperia o serviço em um
linha telefônica de longa distância transportando tráfego de dados de rede. Breves interrupções no serviço
não poderia ser evitado e teria que ser tratado pelos IMPs. Além disso, no
melhor das condições, havia uma matriz muito complicada de problemas de roteamento a serem
resolvido. A equipe do Heart teve que evitar que as mensagens circulassem indefinidamente na rede,
saltando de nó em nó sem nunca chegar ao destino final. finalmente, o
a equipe teve que considerar a possibilidade de congestionamentos nos buffers de memória. As mensagens podem ser
no máximo 8.000 bits; Os IMPs deveriam quebrar essas mensagens em uma sequência de pacotes
com um tamanho máximo de 1.000 bits cada. Um pacote conteria o equivalente a
cerca de duas linhas de texto nesta página.
O sistema tinha que entregar pacotes e mensagens dentro das especificações de tempo Roberts
tinha definido - meio segundo para uma mensagem ir de qualquer host de origem para qualquer host de destino
através da sub-rede IMP. Isso significaria processar dados em velocidades da ordem de cem
mensagens por segundo, o que certamente era possível apesar de sincronizar tudo
seria difícil.
Como se os desafios técnicos não bastassem, o cronograma do projeto da rede ARPA foi
em um caminho rápido; a programação definida por Roberts estava ligada ao ciclo orçamentário e político
realidades que ele enfrenta em Washington. Oito meses não foram suficientes para ninguém construir o
rede perfeita. Todo mundo sabia disso. Mas o trabalho da BBN era mais limitado do que isso; foi para
demonstrar que o conceito de rede poderia funcionar. Coração foi experiente o suficiente para saber
que compromissos eram necessários para que qualquer coisa tão ambiciosa fosse concluída a tempo. Ainda assim, o
a tensão entre o perfeccionismo de Heart e sua vontade de cumprir prazos sempre esteve com
ele, e às vezes era aparente para os outros como uma contradição aberta e não resolvida.
A BBN enfrentou inúmeros outros problemas que empurraram outros licitantes e potenciais licitantes para fora
da corrida. Agora, todos esses problemas pertenciam a Frank Heart.

Começando
Página 68
“Uma coisa é quando você se conecta a uma tomada na parede e o fluxo de elétrons”, disse Bob
Kahn. “Outra coisa é quando você tem que descobrir, para cada elétron, em que direção
leva." Para a maneira de pensar de Kahn, isso resumia a dificuldade de construir uma rede
que trocou pacotes de bits e o fez dinamicamente. Kahn sabia muito pouco sobre
design de hardware. Ele era um cientista que fazia principalmente trabalho conceitual em projetos de sistema
e arquitetura. Porque ele ponderou os aspectos conceituais maiores do problema
talvez um pouco mais profundamente do que seus colegas, ele se preocupava mais com a complexidade do
construir a rede. Para Kahn, a rede era mais uma abstração, perfectível e
todo, do que para os outros membros da equipe, envolvidos como estavam na
programação e fiação de suas várias partes.
O conceito de comutação de pacotes abriu um rico universo em que uma teoria orientada
e engenheiros treinados como Kahn podiam investigar uma ampla gama de cenários hipotéticos.
As análises de Kahn já ajudaram a moldar o projeto da rede ARPA. Kahn teve
contribuiu com ideias livremente para Larry Roberts, incentivando-o a lançar a rede ARPA
experimente em larga escala usando linhas telefônicas de longa distância. Outras pessoas disseram um
experimento em pequena escala seria bom para começar, mas Kahn temia que nada
significativo pode ser aprendido com um pequeno experimento. Roberts concordou e decidiu por um
rede transcontinental de pelo menos dezenove nós.
Você certamente poderia construir um experimento de rede em um único laboratório - se quisesse.
A essa altura, Donald Davies finalmente recebeu autorização e algum financiamento para fazer
apenas isso no National Physical Laboratory em Londres, usando linhas curtas, cada uma com centenas
de jardas no máximo. Kahn tinha certeza de que um experimento de pequena rede não "aumentaria", em
pelo menos não em termos práticos. Ele raciocinou que links curtos em um laboratório não teriam o
mesmas taxas de erro do mundo real e problemas que as linhas longas usadas no sistema telefônico.
O objetivo real era conectar cientistas da computação e, eventualmente, outros usuários de computador,
país. Portanto, uma rede real teria que cobrir milhares de milhas, e teria que ser
projetado para lidar com pacotes - e corrigir erros de linha telefônica - a uma taxa muito maior do que
qualquer pequena rede.
Roberts parecia confiar no julgamento de Kahn. Antes que o pedido de propostas chegue às ruas
e a BBN tornou-se licitante, os dois homens falavam ocasionalmente. Uma vez que Kahn foi
alistado para contribuir com o esforço de proposta da BBN, ele trabalhou até as primeiras horas da manhã,
noite após noite, ocasionalmente na sala de Severo Ornstein, ajudando a projetar o
sistema de licitação da BBN. O trabalho valeu a pena, a BBN ganhou o contrato e a Kahn já havia
decidiu retornar ao seu próprio trabalho de pesquisa após o Natal.
Mas, com o passar do ano, Kahn começou a ter dúvidas. O técnico
as questões eram complicadas. Talvez ele deva ficar por perto para a implementação. isto
não poderia machucar. Além disso, Kahn estava ansioso para aprender mais sobre o lado do hardware das coisas
de Ornstein. E mudar para a loja do Heart era a única maneira de Kahn continuar
sua própria pesquisa de rede, ou assim as pessoas que dirigiam a BBN o levaram a acreditar.
Jerry Elkind, o homem a quem Heart e Kahn se reportavam, incitou Kahn a se juntar ao
Grupo IMP porque o Heart agora tinha um contrato na BBN especificamente dedicado a
networking. Embora ele continuasse a se reportar a Elkind, Kahn mudou-se para os sistemas do Coração

Página 69
grupo. Logo ele se pegou pegando seu escritório e atravessando a passarela da BBN
do refúgio acadêmico de Bolt para o armazém redesenhado onde o grupo de jovens
homens que começaram a se chamar de “caras do IMP” já eram duros. (E
caras que eram. De acordo com as normas da época, com exceção do Heart's
secretária, as pessoas que projetaram e construíram a rede ARPA eram todos homens. Poucos
mulheres ocupavam cargos na ciência da computação. A esposa de Heart, Jane, havia parado de programar
trabalho na Lincoln para criar seus três filhos.)
A equipe que Heart reuniu sabia como fazer coisas que funcionavam, se não perfeitamente,
então bem o suficiente. Eles eram engenheiros e pragmáticos. Todas as suas vidas eles construíram
coisas, fios conectados e conceitos tornados reais. Seu ethos era utilitário. Em seu núcleo,
toda a engenharia se resume a fazer concessões entre o perfeito e o viável.
Funcionalidade importava agora, não elegância ou beleza. Ao contrário, digamos, dos bons relojoeiros suíços,
cuja engenharia e arte são inseparáveis em um relógio de $ 40.000, a equipe do Heart naturalmente
separou a arte da arte de construir um computador confiável. Olhando para o
bits, engenheiros menores com egos maiores podem tentar se exibir, para infundir o mecanismo
com arte, para criar alguma maravilha da engenharia, uma maravilha de filigrana incrustada em ouro
complexidade. A força interior da equipe do Heart era seu controle, sua maturidade. Este não era
lugar para artesanato de assinatura. “Havia uma infinidade de maneiras de dar errado,
e um número substancial de maneiras de dar certo ”, disse Walden, o primeiro programador Heart
tinha assinado. “Bons engenheiros encontram uma das maneiras de dar certo.”
Os sistemas de radar em tempo real, os sistemas de detecção sísmica de testes de bomba atômica e
terremotos e os outros sistemas que Heart, Ornstein, Crowther e Walden tinham
trabalhado no Lincoln Lab tinha sido mais complicado do que o IMP. Anos depois, alguns
as pessoas diriam que o IMP nada mais era do que um grande dispositivo de E / S e, na verdade, muito simples.
Para o usuário, o IMP deveria ser tão simples quanto uma tomada elétrica ou um interruptor de parede que
seu trabalho sem chamar a atenção para si. Então, novamente, construir o IMP para ter um bom desempenho
e tão discretamente quanto uma tomada ou interruptor doméstico era precisamente o desafio.
A equipe de software tem trabalhado em conjunto desde a proposta. Cada membro
teve um papel específico. Crowther trabalhou em comunicações IMP-to-IMP, Walden
concentrou-se nas questões IMP-to-host, enquanto Cosell trabalhou no desenvolvimento e
ferramentas de depuração.
Willy Crowther, de trinta e dois anos, quieto mas obstinado, era a alma da equipe. No
Nas primeiras semanas de 1969, Crowther pendurou-se muito em batentes de portas de escritórios.
Todos ao seu redor simplesmente aceitaram o comportamento como uma forma de Willy de aquecimento. Ajudou
fortalecer suas mãos para escalada e parecia ajudar ainda mais seu pensamento.
O estilo de Crowther, reconhecido pelo resto da equipe, era parecer que ele estava fazendo
nada por dias, ou apenas fazer um monte de elevações no batente da porta, antes de finalmente liberar em um
torrente o que quer que tenha se formado em sua mente.
Se Crowther e seus colegas estivessem confiantes sobre sua programação e software
design, Ornstein estava igualmente confiante em dirigir o esforço de hardware. Ele era
responsável por projetar dispositivos de I / O de alta velocidade que a BBN planejou adicionar ao
Honeywell 516. O esforço considerável que ele já havia investido na elaboração do

Página 70
a proposta foi um tempo bem gasto. Depois de fazer apenas alguns refinamentos e acabamentos adicionais
toques, a equipe estaria pronta para avançar para a construção de hardware e
fases de programação do projeto. A primeira tarefa de Ornstein foi trazer o design de hardware
a um ponto em que ele poderia ir para a Honeywell com um conjunto de modificações detalhadas no 516.
Depois disso, a Honeywell iria começar a construir os dispositivos de I / O especializados que o IMP precisava para
comunicar-se com os hosts e outros IMPs.
A equipe IMP teve que decidir quais operações de rede seriam tratadas pelo IMP
software e que seria conectado ou embutido no hardware IMP. Tarefas simples
isso tinha que acontecer rapidamente e era melhor tratado pelo hardware. Mas, uma vez projetado e construído, um
peça de equipamento era mais difícil de modificar do que qualquer peça de software. Então, como regra, o
IMP Guys preferia soluções de software. Se algo pudesse ser feito rápido o suficiente em
software eles fizeram lá, projetando o sistema para dar-se mais liberdade para
revisões mais tarde.
Em fevereiro, a BBN havia firmado seu contrato com a Honeywell para a compra da
DDP-516s. Em poucos dias, a Honeywell entregou e instalou o primeiro computador 516 em um
quarto na frente do complexo Moulton Street da BBN. Esta máquina não foi modificada,
versão de nível militar sob encomenda, mas um simples 516, pronto para uso. Era um testador, o
Máquina de "desenvolvimento", com a qual os programadores experimentariam conforme definiam
trabalhos. Os programadores geralmente não estão dispostos (ou são capazes) de ir longe na escrita de código para
um
computador específico até que o hardware real no qual ele será executado esteja disponível. Ornstein tinha acabado
de
iniciou o processo de elaboração de todos os detalhes finais das interfaces especializadas de I / O; isto
pode levar semanas antes que a Honeywell pudesse disponibilizar essas interfaces para conduzir
experimentos.
Como praticamente todos os computadores de sua época, a máquina Honeywell não tinha disco - nenhum disco
rígido
drive, sem disquete (disquetes ainda não tinham sido inventados). Ele tinha uma memória central - uma densa
matriz de fios de cobre finos como cabelos e anéis de ferrite magnetizados, ou núcleos, cada um sobre o
tamanho de uma semente de mostarda. O tamanho total da memória solicitada (12k) era minúsculo por
padrões de hoje. A quantidade de memória em um computador desktop em meados da década de 1990, se
consistia em núcleos de ferrite, ocuparia uma área aproximadamente do tamanho de um campo de futebol.
Uma vantagem interessante da memória central é sua natureza não volátil. Se você virou o
máquina desligada no meio de trabalhar em algo, ela não perderia seu lugar; seria
pegue novamente de onde parou. A equipe do Heart também projetou um
recurso de reinicialização automática: se a energia falhou, a máquina deveria chegar a um
limpe pare e reinicie automaticamente quando a energia retornar. Com a memória central,
a máquina seria reiniciada no início do programa assim que a energia fosse restaurada.
A única vez que um programa precisava ser recarregado era quando uma nova versão era emitida ou quando
alguma falha de hardware ou software fez com que a memória fosse sobrescrita. Nesses casos,
o programa IMP seria recarregado a partir de um leitor de fita de papel, um dispositivo elétrico kludgy
dispositivo mecânico que emitia luz de uma lâmpada incandescente através de uma fita de papel que
foi puxado através de uma linha de fotocélulas. O IMP tinha outras medidas de autossuficiência, uma
do qual foi chamado de temporizador “watchdog”. “Se o programa enlouqueceu”, explicou Heart, um
pequeno temporizador na máquina iria cair para zero (mas um programa saudável iria
redefina-o continuamente). Se o cronômetro chegou a zero e disparou, o IMP foi assumido como tendo

Página 71
um programa destruído. Em seguida, ele acionaria um relé para ligar o leitor de fita de papel e fornecer um
enquanto para aquecer e, em seguida, recarregue o programa. A BBN enviaria cada máquina com um
cópia de uma fita que continha três cópias de todo o programa operacional IMP em sequência,
dando a cada IMP a chance de fazer três recarregamentos automáticos antes que alguém tivesse que ir e
rebobine a fita. Mais tarde, um esquema ainda mais engenhoso seria inventado pela BBN para
recarregue os IMPs travados dos IMPs vizinhos mais próximos e comece do zero. Estes foram todos
características incomuns na época.
Os IMP Guys começaram a trabalhar na escrita do código e, quando terminassem,
acabou sendo cerca de seis mil palavras. “Um programa minúsculo”, disse Heart. Eles fizeram todos os seus
programação na linguagem Honeywell 516 “assembly”.
Os computadores são mecanismos de seguimento de instruções. Programação em linguagem assembly
requer pensar em um grande número de etapas minuciosas e, em seguida, escrever as instruções para
realizá-los. Por exemplo, digamos que você deseja encontrar o elevador. Um conjunto equivalente de
instruções em uma linguagem de alto nível podem ser mais ou menos assim: “Saia pela porta, vire
à direita, passe pela fonte de água e está à sua esquerda. ”
O equivalente em linguagem assembly começaria mais assim: “Encontre seu pé esquerdo;
encontre seu pé direito. Coloque o pé esquerdo na frente do pé direito. Agora coloque o seu direito
pé na frente do pé esquerdo. Repita dez vezes. Pare. Vire noventa graus para o
certo." Etcetera.
Programar em linguagem assembly era me deter loucamente no mecanismo. isso foi
fácil para os programadores perderem de vista o objetivo maior e difícil escrever resumidamente,
programas econômicos. Programadores não qualificados muitas vezes acabavam escrevendo linguagem assembly
programas que vagavam sem rumo, como uma expedição ártica infeliz em uma nevasca.
Crowther conseguiu manter as etapas detalhadas da programação em linguagem assembly em ordem
em sua cabeça sem se perder. Mas ele estava sempre desenhando grandes fluxogramas para que pudesse
imagine tudo de uma vez. Um colega comparou o processo ao projeto de uma cidade inteira
enquanto acompanha a fiação de cada lâmpada e o encanamento de cada banheiro.
Às vezes, entretanto, Crowther evitava os diagramas de fluxo e os fazia mentalmente.
Onde outros se esforçaram para aplicar as ferramentas rudimentares de programação da época,
Crowther estava lá operando em um plano superior.
A escrita do software IMP começou nos escritórios dos membros da equipe de programação, onde
cada um digitaria o código em um Teletipo Modelo 33 em um “editor” PDP-1. Depois que o código foi
criado no PDP-1, foi transferido em fita de papel para o computador Honeywell, onde
foi convertido para a linguagem de máquina da Honeywell, uma tarefa realizada por um programa
conhecido como assembler, que converteu o código em 1s e 0s que o 516 poderia
Compreendo. O código montado foi então perfurado em fita de papel. Por um tempo o
programadores tentaram usar o montador que acompanha o Honeywell 516, mas foi assim
ineficiente, eles logo o abandonaram: Walden e Cosell passaram quatorze horas em um fim de semana
em uma montagem do código do sistema IMP, usando quase uma caixa inteira, quase meia milha, de
fita.

Página 72
Não muito depois disso, Cosell escreveu algum código para modificar o assembler muito melhor em
Computador PDP-1 compartilhado da BBN no final do corredor. Isso tornou possível para o PDP-1
para produzir fitas em linguagem de máquina para o Honeywell 516. A partir de então, a equipe escreveu
pedaços de código IMP, editados e montados sob o compartilhamento de tempo PDP-1
sistema. Assim que estivesse satisfeito com o processo de montagem, o programador instruiria
o PDP-1 para perfurar o código montado em uma fita de papel e, em seguida, levar a fita de volta para
o laboratório onde o 516 estava. Ele carregaria a fita no 516, executaria e esperaria para ver
o que aconteceu. Normalmente, haveria alguns bugs e, portanto, o processo seria repetido.
Naturalmente, quando um dos programadores viu algo interessante ou peculiar acontecendo
conforme um novo código fosse executado no 516, os membros da equipe gravitariam para o evento e
ficar ao redor da Honeywell falando sobre isso.
A maioria dos caras do IMP morava perto de Cambridge, e foi fácil para eles fazer o check-in e
fora do laboratório a qualquer hora. O restaurante chinês original da chef Joyce Chen ficava ao lado
para a BBN, e isso ajudava quando eles trabalhavam até tarde, como costumavam fazer. Cosell e Walden
bebeu muita Coca para se manter; Crowther nunca tocou no material. Ele era
um comedor notoriamente enjoado (qualquer coisa além do nível culinário de uma mortadela simples
sanduíche era um risco), tornando-o um convidado ou companheiro de jantar impossível.
No início do projeto, a BBN foi solicitada a informar um grupo de alto nível da ARPA e militares
pessoal do Pentágono. Crowther estava entre aqueles que planejavam fazer a viagem em
em nome dos caras do IMP. O coração ficou nervoso só de pensar no que Crowther poderia
desgaste para o briefing. As pessoas certamente notariam seus pés, pensou Coração. A única vez que
qualquer um poderia se lembrar de Crowther usando sapatos que você poderia engraxar foi no dia em que
casado. Heart foi para Ornstein e pediu-lhe para dizer a Crowther para não usar tênis para
o Pentágono. Ornstein fez.
"Willy, Frank disse que você não deveria usar tênis nesta reunião."
Houve um longo silêncio do outro lado da linha. E então a voz calma de Crowther.
“Diga a Frank que eles viram meus tênis no JSAC [Comitê Consultivo de Serviços Conjuntos]
reuniões antes e vai ficar tudo bem. ” Isso foi.
Crowther e Ornstein estavam entre os funcionários mais dedicados do Heart. Mas eles gostavam de brincar
o chefe quando surgiu a chance. “Frank levava as coisas muito, muito a sério”, Ornstein
observado.
Ornstein foi um oponente declarado da Guerra do Vietnã. Em 1969, muitas pessoas que
nunca questionaram seu próprio envolvimento em projetos de pesquisa patrocinados pelo Pentágono
começou a ter dúvidas. Ornstein costumava usar um broche de lapela que dizia RESIST.
O pino também continha o? sinal, para resistência elétrica, um símbolo anti-guerra popular para
engenheiros elétricos. Um dia, antes de uma reunião do Pentágono, Ornstein concebeu um novo uso
para seu distintivo. Em reuniões no Pentágono, não era incomum para os homens ao redor da mesa
tire os paletós e arregace as mangas das camisas. Ornstein disse a Heart que ele estava indo
para prender seu botão RESIST na jaqueta de um general quando ninguém estivesse olhando. “Eu acho que Frank
realmente preocupado que eu faria ”, disse Ornstein. (Ornstein não o fez, mas ele usou seu alfinete para
a reunião.)

Página 73
Quando os caras do IMP traçaram seus planos em Washington, ficou claro que o ARPA
rede seria um híbrido das idéias originais de Baran e Davies. A rede ARPA
usaria um esquema de roteamento adaptável que os IMP Guys desenvolveram por conta própria,
mas que era semelhante à ideia básica que Baran esboçou. No entanto, ao contrário de Baran
rede teórica, a rede ARPA não teria quase o mesmo nível de redundância
ou número de links para cada nó. Os nós no esquema da BBN eram normalmente ligados a dois
nós vizinhos, ocasionalmente a um ou três. Como foi concebido agora, apenas dois falharam
os links podem dividir ou particionar a rede em segmentos isolados. Paul Baran disse
que uma rede com uma infinidade de links redundantes poderia ser construída com partes baratas; se um
parte com defeito, haveria outros para fazer o backup. O baixo nível de redundância em
a rede ARPA estava mais próxima do plano de Davies. A abordagem do coração era fazer com que cada parte
da rede o mais robusto e confiável possível.
Durante o período da proposta, Crowther e Walden já haviam feito algumas tarefas cruciais
trabalho, com resultados surpreendentes. Primeiro, eles encontraram uma maneira de fazer o roteamento adaptativo
funcionar
eficientemente. Eles também descobriram que podiam fazer o sistema funcionar muito mais rápido
do que qualquer um imaginou. Os observadores disseram que seu código não funcionaria; Crowther e Walden
sabia que iria. Ao escrever o "kernel" do seu programa ("a parte muito pequena que é o
única coisa que importa ", como Crowther colocou), eles descobriram quão poucos comandos
seria realmente necessário em um programa de software para puxar pacotes para o IMP, descobrir
para onde enviá-los e colocá-los na próxima linha.
Crowther e Walden desenvolveram rapidamente os algoritmos críticos - as regras básicas para
resolver o processamento de pacotes e problemas de roteamento. Isso os levou ao
determinação de que seriam necessárias apenas 150 linhas de código para processar um pacote
através de um dos IMPs. Mas sem uma máquina real para testá-lo, a execução do código
tem que esperar. No entanto, eles tinham um bom pressentimento de que o IMP funcionaria.
Uma tarefa importante com a qual Heart se preocupou, mas não teve que lidar, foi o subcontrato com
AT&T. Era responsabilidade de Larry Roberts providenciar as linhas de 50 kilobit (capazes de
transmitir cerca de duas páginas de texto por segundo) em cada site host na data em que os IMPs foram
pronto. Roberts transferiu o trabalho para outra agência do Pentágono, agora trabalhando com a AT&T
nos termos de instalação e aluguel das linhas, modems e outros
equipamento de comunicação necessário para formar links na rede. A conexão física
dos IMPs para o escritório telefônico local deveria ser feito por fio telefônico normal -
dois pares trançados de fios de cobre enrolados em um cabo contendo cerca de mil outros
pares trançados - com equipamento de terminação especial em cada extremidade para oferecer suporte a dados
elevados
cotações. As linhas dedicadas e outros equipamentos deveriam estar instalados nas instalações da Califórnia
no momento em que os primeiros IMPs chegaram no outono. Heart sabia que a companhia telefônica era
terá que se esforçar para cumprir suas obrigações, e ele estava feliz por garantir que a AT&T
a cooperação não era problema dele.
Roberts era uma força distante, mas persistente, vital para o projeto. Seu estilo era ficar de fora
à maneira dos investigadores principais na maioria das vezes. Sempre que ele se injetou em um
projeto, ele nunca perdeu o tempo de ninguém. Ele sempre fez seu ponto e seguiu em frente. Pessoas
na crescente comunidade de computadores passou a ter uma grande consideração por Roberts.

Página 74
Foram dias excelentes para administrar o Escritório de Técnicas de Processamento de Informações em
ARPA. Com Taylor e Roberts lá, o orçamento para pesquisa em computação continuou crescendo
mesmo quando o resto dos fundos do ARPA estavam sendo cortados por causa do custo crescente do
Guerra do Vietnã. Os gerentes da IPTO poderiam gastar dinheiro em prioridades de sua própria escolha.
E eles poderiam facilmente rescindir o financiamento se não recebessem o tipo de
a cooperação que eles queriam dos empreiteiros.
Dar ampla autoridade a pessoas como Roberts era típico do estilo de gestão da ARPA,
que remonta aos seus primeiros dias. Estava enraizado em uma profunda confiança da linha de frente
cientistas e engenheiros. Em seu leito de morte em 1969, Dwight Eisenhower perguntou a um amigo
sobre "meus cientistas" e disseram que eles eram "um dos poucos grupos que encontrei em
Washington que parecia estar lá para ajudar o país e não ajudar a si próprios. ” De fato,
muitos dos melhores cientistas do país, Roberts entre eles, começaram a ver o trabalho
para a agência como uma responsabilidade importante, uma forma de servir.
Mas os administradores do ARPA não eram bem pagos. Ornstein uma vez ficou com Roberts em
uma reunião fora da cidade e vi Roberts dirigindo um pequeno carro alugado amassado. Ornstein
perguntou-lhe por que diabos ele alugaria tal pilha. Roberts murmurou algo sobre
como Ornstein não entendia as regras e despesas do governo. “Eu sempre pensei nele
como distribuindo esses milhões de dólares ”, disse Ornstein. "Não me ocorreu que ele
estava de fato vivendo, pessoalmente, com um orçamento bastante limitado. Pessoas como Larry se sacrificaram
por um tempo, a fim de colocar as mãos em um grande acelerador. ”
Roberts foi tratado em muitos aspectos como se fosse um membro da equipe da BBN, mesmo
embora ele estivesse em Washington. Ele não viajava para Cambridge com frequência, mas sua presença era
constantemente sentido. Como apenas algumas pessoas estavam trabalhando no projeto na BBN, Roberts sentou
para baixo com todos juntos quando ele visitou. Estas foram conversas informais sobre seus
progresso, longas sessões de alcatra de alto nível. Como investigador principal e gerente de grupo,
Frank Heart era o principal ponto de contato de Roberts na BBN, mas Roberts também permaneceu em
contato próximo com Kahn.
Cada site foi responsável por construir uma interface personalizada entre o host e o IMP. Desde a
computadores de várias marcas estavam envolvidos, nenhuma interface serviria para todos os sites.
Isso implicou em um projeto de desenvolvimento de hardware e software separado em cada local e foi
não é algo que as equipes anfitriãs possam fazer durante a noite.
O IMP Guys teve que escrever a especificação host-to-IMP antes que os hosts pudessem começar
construindo qualquer coisa. A ordem de negócios mais urgente de Heart era concluir o projeto da BBN
da especificação host-to-IMP, para que o pessoal da UCLA pudesse começar a trabalhar a tempo de atender
A programação de Roberts. Heart já previa dificuldade em fazer com que os sites hospedeiros
conclua seu trabalho no prazo. Ele sabia o quanto os principais investigadores confiavam
alunos de pós-graduação, e Heart temeu que o projeto pudesse ser prejudicado por causa de um
o fracasso do aluno de graduação em tratar o cronograma com seriedade suficiente
Dias gastos discutindo a especificação host-to-IMP se transformaram em semanas. Ficou obvio
que a menos que alguém da equipe do Heart assumisse a tarefa de apenas escrever a especificação,

Página 75
haveria mais conversa e pouca escrita. Kahn assumiu a responsabilidade de elaborar o
especificação, e seus colegas ficaram felizes em permitir. O coração achou que Kahn era o melhor
escritor que o grupo tinha, então ele recuou e deixou Kahn produzir a especificação que se tornou
conhecido como Relatório BBN 1822.
Algumas pessoas achavam que Heart se preocupava excessivamente com potenciais falhas de engenharia. Ele
era um piloto mais defensivo quando se tratava de engenharia. Coração aprendeu cauteloso
engenharia desde seu mentor no Lincoln Lab, Jay Forrester, o inventor do núcleo
memória. A Forrester incutiu confiabilidade nas cabeças de toda uma geração do MIT
engenheiros. Acima do custo, desempenho ou qualquer outra coisa, a confiabilidade era sua principal prioridade -
projetar para isso, construir para ele, se preparar para o pior e, acima de tudo, não coloque sua máquina em um
posição para falhar. O mantra do coração incorporou confiabilidade ao IMP de mil maneiras certas
do começo.
Os fabricantes de computadores eram conhecidos por economizar para competir em preço e
construir novas máquinas a tempo. Quase sempre pagavam algum preço em termos de maior
taxas de falha - bugs e travamentos de computador - mas geralmente não arruinou reputações. De
Roberts to Heart, no futuro, todos os caras do IMP esperavam um padrão mais alto neste
projeto. Uma rede funcionando vinte e quatro horas por dia exigiria um desempenho sólido
dos IMPs construídos pela BBN. O imperativo aceito era que os IMPs fizessem seus
melhor entregar cada mensagem com precisão. Uma linha pode falhar, mesmo uma máquina host
pode falhar, mas os IMPs não. A confiabilidade era, de certa forma, o princípio fundamental da
a rede. A rede ARPA sempre refletiria a própria estabilidade de Frank Heart
personagem.
Ornstein tinha a reputação de ser um mestre de tarefas duro e era muito eficaz como técnico
examinador. Sua linha de marca registrada era: “Sou apenas um cara burro de hardware, me convença!” Ele
não desistiria até que a explicação fizesse sentido para ele. Freqüentemente, ele descobria alguns
ponto fraco.
Muitas das sessões de planejamento na BBN ocorreram na Sala Weiner, uma sala de teto alto
sala de conferências com uma grande mesa quadrada e muitos quadros-negros. Foi convenientemente
localizado em um cruzamento de corredores no meio da divisão de sistemas da BBN, um
encruzilhada entre a sala de informática 516, o refeitório e o escritório do Heart. o
A Sala Weiner servia como um ponto de encontro regular para os caras do IMP. A equipe IMP foi
pequeno o suficiente, seus escritórios próximos o suficiente e contato frequente entre os membros da equipe
o suficiente para que revisões formais de design fossem desnecessárias. Eles conversaram nos corredores, sentaram-
se
os escritórios uns dos outros, debatiam e compartilhavam ideias constantemente. Na sala Weiner, giz
foi aplicado liberalmente e frequentemente para explicar, diagramar, esboçar, argumentar e ensinar. Ornstein
usou a sala para realizar uma série de palestras informais, em que software e hardware foram
explicado em detalhes, e ocasionalmente visitantes vinham falar sobre
assuntos. Toda a equipe compartilhou informações. “Todo mundo sabia de tudo”, como
Crowther disse.
Os membros da equipe também escreveram uma série numerada de notas técnicas informais que eles
circularam entre si. As notas não tinham um formato estrito, mas sempre começavam
“The IMP Guys'Notes.” Eles escreveram suas ideias, trocaram-nas e, geralmente,

Página 76
se reuniram para discuti-los. As notas também deram ao Heart uma maneira de monitorar seus
progresso.
As análises de Heart sobre o trabalho à medida que amadurecia não eram nada como as análises de design
tradicionais. UMA
a revisão do projeto é geralmente um evento importante no curso de um projeto de engenharia. A
a equipe de engenharia pode trabalhar durante semanas preparando um projeto para revisão e depois se reunir
submeter, elaborar e debater sob o escrutínio de colegas e sênior
engenheiros. As avaliações do Heart tendem a ser ad hoc e contínuas, o que não quer dizer que
foram fáceis. "Foi como seu pior pesadelo para um exame oral feito por alguém com vidente
habilidades ”, lembrou Bernie Cosell, o melhor solucionador de problemas de software da equipe. “Ele poderia intuir
as partes do design das quais você tinha menos certeza, os lugares que você entendeu menos bem, o
áreas onde você estava apenas cantando e dançando, tentando sobreviver e lançando uma
destaque nas peças que você menos queria trabalhar, enquanto praticamente ignorando as peças
você estava tão orgulhoso por ter sido realmente acertado e feito direito. ”
Assim como as reuniões menos frequentes com Roberts, as análises de design do Heart foram feitas “para ajudar
atravesse as partes difíceis ”, disse Cosell. Coração tinha respeito implícito pelas coisas que seu
engenheiros fizeram isso funcionou bem. Mas ele estava poupando seus elogios. Sua atitude parecia
ser, por que perder tempo com isso? Engenheiros mais jovens e menos experientes podem ter sido
devastado pela falta de feedback positivo do Heart, mas os IMP Guys eram
grupo experiente, muito unido, seguro de si, bem acostumado aos costumes de Heart.
Devido à insistência de Heart na confiabilidade e à análise inicial de Kahn dessa área, um grande
vários mecanismos de controle de erros foram projetados no sistema. Cada
sistema de comunicações está sujeito a erros de transmissão causados por ruído no
circuitos de comunicação. Vozes que passam por telefones, uma transmissão analógica, podem
ser ilegíveis ou ambíguos - como quando os sons de “s” e “f” são confusos. Digital
as transmissões também podem ser distorcidas: um “1” pode surgir como um “0” e vice-versa.
Erros ocorrem em bursts. Se um determinado bit está errado, a probabilidade de os bits circundantes serem
com erro é muito maior do que o normal. Apesar desses problemas, existem boas técnicas
para detectar e até corrigir erros digitais, e os IMPs teriam que confiar neles.
A correção digital de erros baseia-se na ideia básica da "soma de verificação", uma relativamente pequena
número que é calculado a partir dos dados em sua origem e, em seguida, transmitido junto com os dados,
e recalculado no destino. Se os números originais e recalculados não coincidirem,
houve um erro na transmissão, a menos que talvez o próprio hardware de verificação
falhou, uma proposição muito improvável.
Somas de verificação aparecem em transmissões de dados de todos os tipos. Por exemplo, cada bipe que você ouve
em
o caixa do supermercado indica que um minúsculo laser leu um código de barras e
transmitiu seus dígitos para um computador onde a soma de verificação foi calculada e encontrada para
esteja correto. A máquina no caixa registrou algumas decimais sofisticadas
aritmética ao longo do caminho, embaralhando, multiplicando e adicionando os dígitos digitalizados - tudo em
um piscar de olhos. Na maioria dos sistemas de supermercado, o resultado deve terminar em 0, o dígito
soma de verificação usada para todos os produtos.
Se um produto é verificado e o computador não emite bipes, isso significa que a aritmética não
Verifica. Se o computador tivesse uma maneira de corrigir o erro, ele emitiria um bipe a cada passagem e

Página 77
economizar tempo. Mas as técnicas de correção de erros adicionam custos ao sistema, de modo que o funcionário do
checkout
deve passar o item pelo scanner novamente, talvez duas ou três vezes até que o código seja
transmitido sem erro.
Os IMP Guys enfrentaram um problema semelhante: se uma soma de verificação detectasse um erro de pacote no
rede, como deve ser tratada? Se o IMP transmissor enviar o pacote novamente,
ou o IMP receptor deve ser aumentado com hardware para corrigir o erro? Em um
rede, a correção de erros consome espaço nos circuitos de comunicação e aumenta
despesas de hardware no equipamento de comutação. Consequentemente, a equipe da BBN decidiu que
se um IMP detectasse um erro em um pacote, ele descartaria o pacote sem
acusando recebimento. O IMP de origem, ainda possuindo um pacote duplicado e ainda
aguardar confirmação, mas não obtê-la, retransmitirá a duplicata.
Antes de emitir a solicitação de propostas, Roberts teve que decidir sobre o tipo de
soma de verificação para os IMPs. Quantos bits devem ser atribuídos a ele e quão sofisticado
deveria ser? O requisito preciso, com base em um número médio de erros no telefone
linhas, era difícil de determinar porque não havia informações concretas disponíveis sobre
taxas de erro nas linhas de alta velocidade pelas quais os dados deveriam ser enviados. Ainda assim foi
óbvio que uma soma de verificação de 1 bit nunca seria suficiente. Nem um de 2 bits, ou mesmo um de 8 bits. Até
uma soma de verificação de 16 bits pode não ser boa o suficiente.
Kahn havia documentado anteriormente que uma soma de verificação de 16 bits pode não ser suficientemente
poderosa
para atingir o nível desejado de confiabilidade na rede, especialmente dada a incerteza em
desempenho de erro das linhas de alta velocidade. Kahn compartilhou com Roberts alguns
cálculos que sugerem fortemente que uma soma de verificação de 24 bits seria uma escolha muito melhor,
apontando que os 8 bits extras adicionaram muito pouca despesa ao hardware. A soma de verificação
foi um dos muitos problemas técnicos em que Roberts ouviu o conselho de Kahn, e um 24-
bit checksum foi escrito no RFP. Mais tarde, Kahn argumentou o mesmo caso de forma convincente para
Crowther e os outros, e os caras do IMP definiram a soma de verificação de 24 bits como um elemento vital
peça do sistema de controle de erros.
Os engenheiros da BBN tinham boa intuição de quais problemas resolver em hardware e
quais resolver no software. Fazia sentido deixar o hardware do IMP calcular o
soma de verificação, porque um cálculo de software seria muito lento. O IMP-to-IMP final
esquema de detecção de erros era uma combinação inteligente de técnicas de engenharia conhecidas e outras de
invenção da própria equipe da BBN. Como disse Crowther, “Roubaríamos ideias de qualquer lugar,
mas na maioria das vezes tínhamos que fazer o nosso próprio. ”
No Dia dos Namorados de 1969, Cambridge foi atingida por uma tempestade de neve. Cerca de duas dúzias
pessoas estavam presentes em uma reunião de um dia inteiro na BBN. Este foi o primeiro encontro
entre a equipe do Heart e os pesquisadores e alunos de pós-graduação dos sites anfitriões.
Através dos olhos cautelosos de Heart, esta multidão de estudantes de graduação em sua maioria parecia faminta por
colocar as mãos nos IMPs. Ele suspeitou que quando o ARPA decidiu colocar os IMPs para fora
nos locais, os pesquisadores esperavam ter outro computador para brincar. Ele imaginou
eles gostariam de usar os IMPs para todos os tipos de outras coisas - para jogar xadrez ou calcular seus
impostos de renda. “Eu assumi uma posição extraordinariamente rígida”, lembrou Heart. “Eles não deveriam

Página 78
toque, eles não deveriam chegar perto dele, eles deveriam apenas olhar para ele. Era uma caixa fechada com
sem interruptores disponíveis. ”
Kahn ainda estava trabalhando duro na especificação da interface host-to-IMP, então permaneceu
não está claro para hospedar os membros da equipe exatamente o que eles precisam construir. Algumas pessoas
dos sites hospedeiros pediram para ver o que a BBN tinha em mente, mas o IMP Guys não havia resolvido
em um plano entre eles. Sobre esse assunto, nada foi resolvido na reunião.
Os alunos de pós-graduação decidiram compartilhar com a BBN um plano que haviam elaborado para os anfitriões
calcule uma soma de verificação de ponta a ponta. Isso forneceria uma camada extra de proteção contra
erros nas comunicações host-a-host. Ele foi projetado para detectar vários erros imaginários,
incluindo a possível montagem incorreta de pacotes de mensagens pelos IMPs.
Coração ficou angustiado ao ouvir isso, porque isso tornaria os anfitriões mais lentos e faria o
todo o sistema parece lento. Nem a própria ideia de que os IMPs podem passar danificados
pacotes enviados aos hosts lhe agradam. Os alunos argumentaram que a BBN de 24 bits
a soma de verificação não cobriu os caminhos dos IMPs para os computadores host, e que bits
viajou “nu” entre as duas máquinas. Coração assegurado a todos, sem dúvida
termos, que a soma de verificação IMP seria confiável. Faltava ver, e com o tempo o
os alunos estariam mais certos do que errados, mas com a confiança de Heart em exibição, o
sites de host abandonaram seus planos de incluir uma soma de verificação nos protocolos de host.
Mais problemática era a ideia de conectar vários computadores host ao IMP em cada
local. Quando Roberts projetou a rede pela primeira vez, sua ideia era conectar um - e apenas
um - computador host para cada IMP. No entanto, na reunião do Dia dos Namorados,
representantes dos sites deixaram claro que queriam se conectar mais do que
um computador host para cada IMP. Cada centro de pesquisa tinha vários computadores, e
faz sentido tentar conectar mais de uma máquina por site, se possível. Roberts enviou
Palavra para Cambridge que a BBN iria redesenhar o IMP para lidar com até quatro hosts cada.
Walden, Crowther e Cosell inventaram uma maneira inteligente de fazer isso.
Depois do Dia dos Namorados, os caras do IMP realmente começaram a trabalhar. Suas horas de trabalho esticaram
até tarde da noite. Heart, que morava na cidade rural de Lincoln, tentou voltar para casa em
hora de jantar, mas muitas vezes ele não chegava. Foi mais fácil para os outros voltarem para casa
para jantar e voltar ao trabalho, ou nem voltar para casa. Quando ele estava profundamente envolvido no projeto,
Crowther se sentaria em seu terminal até adormecer.
Agora a verdadeira pressão estava em Kahn. Ele passou grande parte dos próximos dois meses ao telefone
com as pessoas nos sites de host, lutando contra a especificação da interface. Kahn tornou-se
Principal ponto de contato da BBN com a comunidade de pesquisa anfitriã. Pesquisadores ligaram para ele
regularmente para verificar o que estava acontecendo e qual era o cronograma, ou simplesmente para passar
junto com novas idéias.
Em meados de abril, Kahn terminou a especificação, um documento espesso que descreve como um host
o computador deve se comunicar com um switch de pacote ou IMP. “Foi escrito parcialmente
tendo em mente o que nos disseram que os anfitriões queriam, e bastante tendo em mente
o que seria possível implementar e o que fazia sentido para nós ”, disse Walden. UMA
comitê de representantes dos sites de hospedagem analisou e disse à BBN onde eles não

Página 79
acho que iria funcionar. A especificação foi revisada até que um projeto aceitável fosse
alcançado. Os sites hospedeiros tinham algo a construir agora. A equipe da UCLA, que seria
primeiro, tinha menos de cinco meses para se preparar para a chegada de seu MI.
Heart traçou uma linha clara entre o que os IMPs lidariam e o que os hosts
faria. “Logo no início, Frank tomou uma decisão, uma decisão muito sábia, de fazer uma limpeza
limite entre as responsabilidades do host e as responsabilidades da rede ", disse
Crowther. Heart e sua equipe decidiram colocar "separação lógica máxima" entre o
IMP e o host. Fazia sentido conceitual e de design para eles traçar a linha lá para
evite sobrecarregar ou sobrecarregar as funções do IMP. Isso também tornou a construção dos IMPs mais
gerenciável. Todos os IMPs podem ser projetados da mesma forma, em vez de serem personalizados para cada
local. Também evitou que a BBN fosse pega no meio, tendo que mediar entre o anfitrião
sites sobre os protocolos de rede.
A BBN havia concordado com Roberts que os IMPs não realizariam nenhuma função host-a-host.
Esse foi um grande problema técnico. Não havia padrões de linguagem nem palavras
padrões de comprimento, e até agora nada que facilitaria a comunicação fácil entre
hospedeiros. Até mesmo fabricantes individuais, como a Digital, criaram uma série de
computadores incompatíveis.
A última coisa que a BBN queria era a dor de cabeça adicional de resolver o problema de host para host
problemas. Além disso, Roberts não queria dar à BBN ou a qualquer outro contratante que
muito controle sobre o design da rede. Roberts estava determinado a distribuir
responsabilidades uniformemente. Entre Roberts e a BBN ficou decidido: o IMP seria construído
como um mensageiro, um dispositivo sofisticado de armazenar e encaminhar, nada mais. Seu trabalho seria
para transportar bits, pacotes e mensagens: Para desmontar mensagens, armazenar pacotes, verifique se há
erros, roteie os pacotes e envie confirmações para os pacotes que chegam sem erros; e
em seguida, para reagrupar os pacotes recebidos em mensagens e enviá-los para o host
máquinas - tudo em uma linguagem comum.
Os IMPs foram projetados para ler apenas os primeiros 32 bits de cada mensagem. Esta parte do
mensagem, originalmente chamada de "líder" (e posteriormente alterada para "cabeçalho"), especificava o
origem ou destino e incluiu algumas informações de controle adicionais. O líder
continha os dados mínimos necessários para enviar e processar uma mensagem. Essas mensagens eram
em seguida, dividido em pacotes dentro do IMP de origem. O fardo de ler o conteúdo do
as mensagens estariam nos próprios hosts.
Os computadores host falavam muitos idiomas diferentes e a parte mais difícil de fazer o
rede útil seria fazer os hosts se comunicarem uns com os outros. o
sites de hospedagem teriam que fazer com que seus computadores díspares conversassem entre si por meio de
protocolos que eles concordaram previamente. Estimulada pelo ARPA, a comunidade anfitriã estava fazendo
um esforço organizado para começar a resolver esses problemas de protocolo, sabendo que seria bastante
enquanto antes que qualquer coisa fosse resolvida definitivamente.

Número IMP 0
Página 80
Em um dia de primavera, um caminhão de entrega da Honeywell virou na Moulton Street. Dentro
foi a primeira máquina 516 construída de acordo com as especificações da BBN. O computador do tamanho de uma
geladeira
foi trazido do caminhão para uma doca de carregamento na parte de trás da divisão de sistemas
edifício e, em seguida, foi transformado em uma grande sala, logo conhecida como sala IMP,
adjacente ao cais. A equipe converteu um depósito em espaço para testar os IMPs
adicionando um piso elevado para computador, iluminação fluorescente brilhante e ar condicionado. o
uma sala sem janelas era onde o homem mais jovem da equipe, Ben, de 22 anos
Barker logo passaria muito tempo.
Barker era um estudante de graduação cujo brilhantismo chamou a atenção de Ornstein em
uma das aulas que ministrou em Harvard. Quando a BBN obteve o contrato ARPA,
Heart ofereceu um emprego a Barker, e Barker tirou uma licença para aceitá-lo.
Barker, como Ornstein, era engenheiro de hardware e dava sinais de que estava se tornando um ás
depurador - alguém que poderia resgatar um projeto quando chegasse a hora. Ele foi colocado em
encarregado de configurar cada IMP Honeywell entregue e depurar o hardware antes dele
saiu da loja da BBN.
Esta primeira máquina foi o protótipo (IMP Número 0), um 516 não-farmacológico contendo
Implementação inicial da Honeywell das interfaces da BBN. Com a máquina no meio
da sala, Barker ligou o computador, conectou tudo e o ligou.
Barker construiu um testador e escreveu algum código de depuração. Ele estava ansioso
para resolver quaisquer bugs que a máquina tivesse. Sem dúvida haveria algo
isso precisaria de conserto, porque sempre houve; bugs faziam parte do processo natural
de design de computador. Heart e toda a equipe estavam ansiosos para descobrir quais partes
do projeto IMP funcionou e que precisava de mais atenção.
Barker tentou carregar o primeiro programa de diagnóstico IMP na máquina não testada. Ele
não conseguia fazer funcionar. Então, ele carregou algum outro código, e isso também não funcionou. Barker
tentei algumas outras coisas e descobri que nada funcionava. “A máquina não veio
perto de fazer qualquer coisa útil ”, disse ele. Até agora, o primeiro IMP foi um fracasso efervescente.
Antes do projeto IMP, as pessoas da BBN e da Honeywell interagiam casualmente e
as relações eram amigáveis. Nos dias que antecederam o projeto IMP, um senso de trabalho em equipe
cresceu. Honeywell dedicou uma equipe de sistemas especial para trabalhar no contrato da BBN de
dia um. A pedido da BBN, a Honeywell designou um de seus técnicos exclusivamente para
a tarefa de conduzir a parte do trabalho da Honeywell até a conclusão.
Isso era incomum. Em geral, fabricantes de minicomputadores como a Honeywell não atendiam
muito para as demandas especiais de seus clientes. “A maioria das empresas de informática não construirá
especiais em tudo ”, disse Heart. "Ou, se o fizerem, será sob grande pressão." Minicomputador
os vendedores foram atrás de um amplo mercado, enquanto os fabricantes de computadores mainframe eram
conhecidos por
trate os clientes como a realeza. Ninguém no ramo de minicomputadores trabalhava muito
segurando.
Na esteira do grande fracasso do IMP Número 0, o chefe de hardware da BBN Ornstein começou a
examine o design com a equipe da Honeywell. Ele descobriu que ninguém na Honeywell
parecia entender em muitos detalhes como as interfaces projetadas pela BBN deveriam

Página 81
trabalhos. Ele ficou surpreso ao saber que os técnicos que construíram a primeira interface não
realmente entendo os desenhos. Honeywell não tentou desenvolver nenhum diagnóstico
para testar o design; ele simplesmente tentou produzir uma implementação fiel do bloco
diagramas que Ornstein havia desenhado e que a BBN incluiu em sua proposta ao ARPA.
O problema era que, ao fornecer à Honeywell um conjunto de diagramas de blocos bastante genéricos,
A BBN presumiu que a familiaridade e experiência da Honeywell com suas próprias máquinas
permitir ao fabricante do computador antecipar quaisquer problemas peculiares com os da BBN
solicitou modificações no modelo 516. A Honeywell tinha seus próprios módulos lógicos, próprios
sistema de design. Mas em vez de trabalhar os detalhes essenciais nas plantas,
Honeywell construiu a máquina da BBN sem verificar se as interfaces projetadas pela BBN,
conforme desenhado, funcionaria com o modelo 516 básico.
Claro, nem a BBN no desenho dos diagramas de blocos nem a Honeywell na implementação
o design realmente tinha todas as ferramentas necessárias para criar um protótipo perfeitamente funcional
IMP na primeira passagem. Na construção de novos computadores, disse Barker, o pressuposto operacional
é que você projeta algo que acha que funcionará, prepare o protótipo, comece a testar
em seguida, corrija gradualmente os erros de projeto até que a máquina passe no teste. Teria sido
um acaso de engenharia se a máquina funcionou perfeitamente imediatamente. Mas mesmo como primeira passagem,
a condição desta máquina protótipo era inaceitável.
Se Ornstein estava preocupado com o desempenho da Honeywell, Barker estava totalmente
nervoso. Como depurador-chefe, ele era o responsável por fazer a máquina
realmente funciona. Nesta fase do projeto IMP, as interfaces do 516, disse ele,
“Não teria chegado perto de funcionar mesmo se a Honeywell os tivesse implementado
devidamente."
Barker estava diante de semanas de trabalho concentrado pela frente. Ele sentiu o peso do
cronograma de repente ficar mais pesado. Se a equipe de hardware da BBN pretendia passar para o
Equipe de programação da BBN uma versão funcional do Honeywell 516 modificado a qualquer momento
em breve, para que Crowther, Walden e Cosell tivessem tempo para a depuração final de seus
código operacional, então os especialistas em hardware teriam que se apressar. Com a ajuda de Ornstein,
Barker teria que "pegar as coisas que a Honeywell construiu", disse ele, "e descobrir como
para fazê-lo realmente fazer o que foi planejado. ”
A chegada do protótipo IMP em seu estado inicial marcou um verdadeiro revés; corrigindo o
Claro que levaria tempo, e logo haveria muito pouco disso.
Armado com um osciloscópio, uma pistola de arame e uma ferramenta de desembrulhar, Barker trabalhava sozinho
na máquina dezesseis horas por dia. O circuito do computador dependia de blocos de pinos, ou
placas envoltas em fios, que serviam como pontos de conexão centrais para os quais os fios,
centenas e centenas de fios foram encaminhados. Havia vários blocos de trinta
quatro pinos nos quais as placas lógicas foram conectadas e que carregavam componentes para formar
os circuitos corretos. Depois de descobrir para onde os fios deveriam ir, Barker teve que
desembrulhe cada fio mal conectado firmemente enrolado de seu pino. Os pinos em cada bloco eram
cerca de uma polegada de comprimento e estavam bem espaçadas (1/20 de uma polegada de distância) em uma
matriz quadrada;
cada bloco parecia uma cama em miniatura de pregos com fios fluindo como Medusa em
e fora dele. Depois de determinar onde os fios corretos devem ser reconectados, Barker

Página 82
usei a arma para embrulhar cada fio cuidadosamente em seu pino correto. Foi um longo,
processo trabalhoso e delicado.
Para complicar as coisas, Barker tinha uma leve paralisia nas mãos. Trabalhando com um envoltório de arame
arma exigia uma mão firme e boa concentração. O espaçamento estreito dos pinos, o
peso da arma de embalagem de arame e o tamanho do bico da arma que teve que ser deslizada
abaixado sobre um único alfinete em meio a uma pequena floresta de alfinetes, todos conspirando contra ele. O risco
era
em colocar o fio no pino errado ou entortar ou quebrar um pino. Você poderia destruir muito
de bom trabalho se você não fosse cuidadoso. Então, o tremor nas mãos de Barker causou um grande rebuliço
entre os outros caras do IMP quando Barker levou sua arma de arame para os blocos de pinos dentro
o Imperador.
A maior parte da reconfiguração foi feita com a energia desligada. Quando algo tinha que ser feito com
a energia ligada, foi feita com pequenos cabos de grampo que escorregaram nos pinos. Aqui, porém,
havia um perigo muito real de causar curto-circuito e explodir os circuitos.
Barker passou meses depurando a máquina. Ornstein estava supervisionando o design
correções no protótipo e certificando-se de que eles foram retransmitidos de volta para a Honeywell
engenheiros. A próxima máquina que a Honeywell deveria entregar seria a primeira
516 robusto com todos os bugs de design resolvidos: IMP Número Um destinado a
UCLA. “O suor era fazer os projetos funcionarem a tempo de serem enviados”, disse Barker. O Verão
estava sobre eles.
A preocupação do coração com as hordas de estudantes curiosos de pós-graduação levou a BBN a
conceituar medidas de proteção ainda maiores para os PMI. Com o tempo, entre os mais
coisas criativas que a equipe do Heart fez foi inventar maneiras de obter dados operacionais críticos de
os IMPs da rede - lendo os sinais vitais das máquinas - discretamente à distância.
Heart queria poder sentar em um terminal em Cambridge e ver o que é um IMP em Los
Angeles, Salt Lake City ou qualquer outro lugar estava fazendo. Implementação completa da BBN de
ferramentas de diagnóstico remoto e recursos de depuração mais tarde se tornariam um grande ativo.
Quando a rede amadureceu, o controle remoto permitiria à BBN monitorar e manter
todo o sistema a partir de um centro de operações, coletando dados e diagnosticando problemas como
As coisas mudaram. Periodicamente, cada IMP enviaria de volta a Cambridge um "instantâneo de sua
status ”, um conjunto de dados sobre suas condições operacionais. Mudanças na rede, menores e
maior, poderia ser detectado. O grupo de Heart imaginou que algum dia seria capaz de olhar através do
rede para saber se alguma máquina estava com defeito ou se alguma linha estava falhando, ou
talvez se alguém estivesse se intrometendo nas máquinas.
No entanto, a BBN ainda não tinha levado o protótipo IMP a um estado em que pudesse
execute o código operacional. E a equipe de programação - Crowther, Walden e Cosell - foi
agora entrando em um território difícil: o projeto de um sistema de roteamento flexível ou "dinâmico",
permitindo o roteamento alternativo, de modo que os pacotes fluam automaticamente em torno
nós e links. Um esquema de roteamento fixo teria sido simples: você
envie um pacote com instruções claras para viajar pelos pontos x, y e z no mapa. Mas se
ponto y foi interrompido, todo o tráfego seria interrompido. E isso frustraria um dos
vantagens de uma rede com múltiplos links e nós.

Página 83
A solicitação original do ARPA especificou o roteamento dinâmico, sem oferecer uma pista
sobre como fazê-lo funcionar. Crowther havia encontrado uma maneira de fazer isso. Ele estava construindo um
sistema
de tabelas de roteamento dinâmico que seriam atualizadas a cada fração de segundo ou mais. Essas mesas
diria aos IMPs em que direção encaminhar cada pacote que ainda não tivesse alcançado seu
destino. As tabelas de roteamento refletem as condições da rede, como falhas de linha e
congestionamento e roteariam os pacotes da maneira mais curta possível. Fazendo este design
realmente funcionar parecia um problema alucinante - até que Crowther veio com um simples,
conjunto perfeito de código. Crowther "sempre teve a cabeça bem abaixada", como Ornstein
descreveu o talento intuitivo e misterioso de Crowther.
O algoritmo de roteamento dinâmico de Crowther era uma poesia de programação. "Isso foi
incrivelmente minimalista e funcionou incrivelmente bem ”, observou Walden. Crowther era
considerado por seus colegas como estando dentro da fração superior de 1 por cento dos programadores
no mundo. Na ocasião, o minimalismo gracioso do código de Crowther não era suficiente para
lidar com a complexidade dos sistemas do mundo real. Outros programadores teriam que ajustar
o que Crowther havia criado. Mas suas ideias centrais eram na maioria das vezes brilhantes. "A maioria
do resto de nós ganhamos a vida lidando com os detalhes resultantes do uso de Will de seu
cérebro ”, observou Walden.
O controle de fluxo foi outro desafio de programação. Mas quando Kahn olhou para Crowther's
código e viu como ele implementou o controle do fluxo de pacotes de um lado do
a rede para a outra, ele estava preocupado. As mensagens entre hosts deveriam ser transmitidas
pela sub-rede por meio de "links" lógicos. A sub-rede aceitaria uma mensagem por vez em um
determinado link. As mensagens esperando para entrar na sub-rede foram armazenadas em um buffer de memória
(um
área de espera dentro da máquina), em uma fila. A próxima mensagem não foi enviada até o
enviar IMP recebeu uma confirmação (semelhante a um recibo de retorno) dizendo que o
a mensagem anterior chegou sem erros ao host de destino. Quando um link era
limpo e uma nova mensagem pudesse ser enviada, a sub-rede notificaria o IMP de envio por
meio de um sinal de controle especial que os engenheiros da BBN chamaram de Pronto para a próxima mensagem,
ou RFNM (pronuncia-se RUFF-num). Mensagens nos buffers do host de envio, aguardando
links para limpar, eram como clientes em um restaurante esperando por mesas; RFNMs eram os
equivalente ao anúncio do maître “Sua mesa está pronta”.
Isso significava que era impossível enviar um fluxo contínuo de mensagens em qualquer
link através do sistema de um host para outro. RFNM era um controle de congestionamento
estratégia projetada para proteger os IMPs de sobrecarga, mas às custas de reduzir
serviço ao hospedeiro. Kahn havia estudado o problema de controle de congestionamento antes mesmo do
O projeto da rede ARPA começou. Sua reação à solução de Crowther foi que os links e
Os RFNMs ainda permitiriam o congestionamento fatal das artérias da rede. Os buffers do IMP
iria encher, disse ele. Você teria mensagens incompletas nos IMPs receptores
esperando que seus pacotes finais cheguem para que a mensagem inteira possa ser remontada, e
não haveria espaço para os pacotes chegarem.
O cenário de bloqueio de remontagem de Kahn tem um análogo no negócio de remessas. Diga que um
Concessionária Toyota em Sacramento encomenda conjuntos de blocos de motor e pistões de reposição
de um armazém em Yokohama. Os dois itens juntos são essenciais para os trabalhos do revendedor
tem em mãos. No porto de Yokohama, cargueiros estão carregando grandes contêineres, todos iguais

Página 84
tamanho, preenchido com produtos de vários tipos. Os blocos do motor e os pistões acabam em
navios separados. Quando o contêiner de blocos de motor chega a São Francisco, é
descarregado para um armazém de contêineres cujo conteúdo também são remessas parciais aguardando
a chegada de outras peças antes de serem enviadas: componentes para aparelhos de televisão, pin
blocos para pianos e assim por diante. Quando o cargueiro com os pistões chega, ele encontra o
armazém cheio. Cada navio posterior tem o mesmo problema: ninguém pode descarregar; Nada pode
sair do armazém. Impasse. Solução? O remetente de Yokohama concorda em ligar com antecedência
da próxima vez para reservar espaço para todos os contêineres que vão juntos. Se não houver espaço disponível, ele
espera até que esteja disponível antes de enviar.
Kahn também previu outro tipo de impasse que pode levar à perda de pacotes. Ele disse
que ocorreria em tráfego intenso dentro da sub-rede quando os buffers de um IMP fossem
preenchido com pacotes roteados para outro e vice-versa. Uma espécie de impasse resultaria, em
que nenhum deles seria capaz de aceitar os pacotes do outro. A forma como o roteamento
software tinha sido escrito os IMPs iriam descartar os pacotes.
Kahn e Crowther debateram longamente a questão do impasse. Sobre pontos como estes
As visões conceituais de Kahn entraram em conflito aberto com a tendência pragmática do resto do
os caras do IMP e abriu um amplo desacordo entre eles. O resto da equipe
só queria colocar a rede em funcionamento dentro do prazo. Conforme a rede crescia, eles
tenha tempo para melhorar seu desempenho, resolver problemas e aperfeiçoar os algoritmos.
Mas Kahn persistiu. “Eu podia ver coisas que para mim eram falhas óbvias”, disse ele. "O
a mais óbvia era que a rede poderia travar. ” Kahn tinha certeza de que a rede
iria trancar, e ele disse isso a Heart e aos outros imediatamente. Eles discutiram com ele.
“Bob estava interessado na teoria das coisas e na matemática, mas não estava realmente interessado
na implementação ”, disse Crowther. Crowther e Kahn começaram a conversar sobre isso, e
os dois tiveram o que Crowther descreveu como "pequenas brigas grandiosas". O esquema de controle de fluxo
não foi projetado para uma rede enorme e com um pequeno número de nós Crowther pensou
eles poderiam sobreviver com isso.
Heart pensou que Kahn estava se preocupando muito com uma rede hipotética e improvável
condições. Sua abordagem era esperar para ver. Alguns dos outros pensaram que Kahn não
entender muitos dos problemas com os quais eles estavam lutando. “Algumas das coisas
ele estava sugerindo que eram absurdos, simplesmente errados ”, disse Ornstein. Kahn queria assistir
simulações de tráfego de rede em uma tela. Ele queria ter um programa que mostrasse
pacotes se movendo pela rede. Na verdade, os pacotes nunca se moveriam de uma forma humana
velocidade observável; eles iriam “zip-zip” em microssegundos e milissegundos. "Nós dissemos,
'Bob, você nunca vai entender os problemas de olhar para as coisas dessa maneira.' ”Os outros caras do IMP
respeitava Kahn, mas alguns acreditavam que ele estava indo na direção errada. Gradualmente, eles
prestou menos atenção a ele. “A maioria de nós no grupo estava tentando tirar Kahn de nosso
cabelo ”, disse Ornstein.
Heart rejeitou a sugestão de Kahn de que usassem uma simulação. Coração odiava ver o seu
a equipe de programação gasta tempo em simulações ou escrevendo qualquer coisa, exceto código operacional.
Eles já estavam se distraindo com outra coisa de que ele não gostava - construir software
Ferramentas. O coração temia o atraso. Ao longo dos anos, ele viu muitos programadores cativados

Página 85
pela construção de ferramentas, e ele passou uma carreira impedindo os jovens engenheiros de fazer
coisas que podem desperdiçar tempo ou dinheiro. As pessoas na divisão do Coração sabiam que se eles
pediu a ele o ok para horas escrevendo editores, montadores e depuradores, eles
encontraria forte resistência, talvez até uma disputa de gritos. Então, ninguém perguntou;
eles simplesmente fizeram isso, construindo ferramentas quando achavam que era a coisa certa a fazer,
independentemente de
o que o coração pensou. Este era um software que eles eventualmente precisariam quando chegasse a hora
para testar o sistema. Todos eram peças de programação personalizadas, projetadas especificamente para
projeto ARPA.
Com o pico do verão, um problema preocupante surgiu: a BBN ainda estava esperando o lançamento da Honeywell
entrega do primeiro IMP de produção, com todas as interfaces depuradas construídas para BBN's
especificações. A equipe de programação desistiu de esperar e seguiu em frente com seu
trabalhar carregando uma máquina de desenvolvimento de nível inferior com um programa de simulação que a
equipe
foi projetado para imitar as operações do modelo de produção IMP e suas interfaces de E / S.
Ainda assim, testar o software na máquina real foi a abordagem preferida. E sempre que
a máquina entrou, Barker primeiro precisaria de tempo para depurá-la. O tempo restante era
diminuindo. No final do verão, a máquina ainda não havia cruzado a doca de carregamento da BBN.
A entrega programada do IMP para a Califórnia era agora apenas algumas semanas de distância, e da BBN
sua própria reputação estava em jogo.

O inseto
Finalmente, cerca de duas semanas antes do Dia do Trabalho, a Honeywell apressou o primeiro 516 robusto
IMP na porta da loja e em Cambridge. Assim que a máquina tocar o chão
na BBN, Barker estava pronto para trabalhar nisso. Ele ligou o IMP Número Um no
backroom.
Barker carregou o código de diagnóstico IMP. Quando ele tentou executá-lo, nada aconteceu. o
máquina não respondeu. Em uma inspeção mais próxima, era evidente que a máquina BBN
recebido não era o que havia ordenado. Este 516 teve algumas das modificações que Barker
e Ornstein havia trabalhado meticulosamente na depuração do protótipo; na verdade, foi
conectado exatamente como o protótipo disfuncional original tinha sido conectado. Com o prazo
aproximando-se, Barker tinha apenas um recurso: consertá-lo na BBN. Desta vez pelo menos ele já
sabia onde cada fio deveria ir. Com a máquina parada no meio do grande
sala, Barker começou a trabalhar na implementação de todas as modificações de design necessárias para
torná-lo um IMP funcional.
Dentro de alguns dias, Barker havia persuadido a máquina à vida. Ele conseguiu ativar o
Interfaces do IMP - após o que o computador começou a travar em intervalos aleatórios. o
a aleatoriedade das falhas era incomumente ruim. Problemas intermitentes desse tipo eram os
diabo. O IMP funcionaria de 12 a 40 horas seguidas,
em seguida, morrer e estar em algum lugar "perdido". O que fazer? Ornstein relembrou: “Nós
não conseguia descobrir o que diabos estava acontecendo. "
Conforme o Dia do Trabalho se aproximava, eles pressionaram o IMP, submetendo-o a tantos testes difíceis
que possível. Pode funcionar bem por vinte e quatro horas e, em seguida, morrer inexplicavelmente. Barker iria
procure uma pista, persiga o que parecia ser um problema, corrija-o e ainda assim a máquina

Página 86
bater novamente. Faltando apenas alguns dias para o prazo de entrega, parecia que eles
não iríamos fazer isso.
Barker, que estava cuidando do computador, suspeitou que o problema estava na máquina
Cadeia de temporização. Foi apenas um palpite.
O IMP tinha um relógio usado pelo sistema operacional para manter o tempo na máquina, não como
humanos marcariam segundos, minutos ou horas, mas contando o tempo em 1-
incrementos de microssegundos (um milhão de tiques por segundo) - rápido para o dia, mas cem
vezes mais lento do que os computadores pessoais de hoje. Este relógio forneceu uma estrutura na qual
o IMP operava e regulava as muitas funções do computador de maneira síncrona. Em um
sistema de comunicações, as mensagens chegam sem aviso prévio; sinais interrompem a máquina
de forma assíncrona. Como uma chamada telefônica no meio do jantar, um pacote que chega mostra
em seu próprio cronograma na porta do IMP e diz: “Leve-me agora”.
O computador tinha um sistema sofisticado para lidar com as interrupções de entrada em um
forma metódica, para não perturbar o funcionamento síncrono de todas as suas funções. E se
não projetados corretamente, esses sincronizadores podem ser acionados por um sinal de entrada
ocorrendo no momento errado. Bugs de sincronizador são raros. Mas quando eles ocorrem
e o sincronizador não responde adequadamente a uma interrupção, as consequências são
profundamente perturbador para a operação total da máquina. Pode-se chamar de nervoso
demolir; os cientistas da computação têm outro termo para isso: o sincronizador entra em um
Condição “metaestável”. “Nessas circunstâncias”, disse Ornstein, “a máquina
invariavelmente morre em um estado desesperadoramente confuso - diferente a cada vez. ”
Ornstein sabia muito bem sobre bugs do sincronizador. Ele tinha lidado com o problema no
computador que ele e Wes Clark construíram alguns anos antes em St. Louis. Ornstein era o
autor de alguns dos primeiros artigos publicados sobre o assunto, e foi uma das poucas pessoas
no mundo que realmente teve alguma experiência com este gremlin em particular.
Sua imprevisibilidade tornava os bugs do sincronizador um dos mais frustrantes
devido à ausência de qualquer padrão reconhecível para as falhas resultantes. ao contrário da maioria
outros problemas que podem fazer com que os computadores travem, um bug do sincronizador deixado para trás
virtualmente nenhuma evidência forense útil que possa apontar um diagnosticador para o problema. No
Na verdade, a ausência de pistas era uma das pistas mais úteis. Além disso, as falhas
causados por este bug eram tão raros (apenas uma vez por dia ou mais, mesmo em testes completos),
que era impossível detectar qualquer evidência em um osciloscópio. Só os mais astutos
os depuradores tinham alguma ideia do que estavam lidando.
Esse parecia ser o problema que Ornstein e Barker tinham em mãos. Mas quem sabe,
porque você não poderia realmente rastreá-lo. O que fazer agora? A Honeywell 516 nunca
sido usado em um aplicativo tão exigente quanto a rede de comutação de pacotes. Foi um rápido
máquina; os IMP Guys o escolheram precisamente por suas capacidades de E / S. Ninguém mais estava
provavelmente nunca verá o problema em uma aplicação típica do computador 516. “Se o seu
a máquina morria uma vez por ano ”, disse Ornstein,“ eles nunca notariam. Eles simplesmente recomeçariam. ”
Mas os caras do IMP estavam conduzindo a máquina com força. O fluxo de pacotes dentro e fora do
IMP aconteceu mais rápido do que os projetistas da Honeywell haviam previsto. A máquina 516
não parecia capaz de lidar com esse tráfego. Talvez a BBN tenha sido otimista demais.
 Página 87
Ornstein e Barker foram para a Honeywell e insistiram que o fabricante "cavasse fora do
carpintaria, caminho nos bastidores ”, o projetista do computador 516. Ele era muito inteligente
cara, Ornstein teve que admitir, mas no início o homem da Honeywell se recusou a admitir que um
estado metaestável era possível na máquina. Ele nunca tinha lido os papéis de Ornstein, e
nunca tinha visto o problema. "Embora cheio de descrença", disse Ornstein, ele "pelo menos
entendeu o que estávamos dizendo. ”
Em condições normais, o 516 funcionaria por anos sem experimentar o
problema do sincronizador. No entanto, nas condições de rede de comutação de pacotes da ARPA,
a máquina estava falhando uma vez por dia ou assim. Tente dizer a Frank Heart, Sr. Confiabilidade,
que ele apenas teria que viver com isso.
Ornstein e Barker se encolheram. Foi apenas um palpite de que o IMP tinha um sincronizador
problema. Para testar a hipótese, Ornstein projetou e instalou um "agravante" que
deliberadamente produziu solicitações de dados no que Barker chamou de "taxa forte". Aumentou o
probabilidade de obter interrupções no nanossegundo exato que revelaria o problema.
O agravador tinha um botão que funcionava como um afinador. Usando o botão, Ornstein e Barker
poderia "ajustar" o tempo dos pedidos para trazer um sinal perfeitamente fora de ordem com o
relógio, o pior caso. Então, usando um osciloscópio, eles observaram a máquina
“Batimento cardíaco” e outras funções internas.
A equipe de depuração começou a trabalhar. Os padrões que procuravam no
o osciloscópio seria tão fraco que só seria visível em uma sala escura. Então, com todos os
luzes apagadas na sala IMP e com todos os seus equipamentos de diagnóstico e o Honeywell
ligado, eles observavam, enquanto brincavam com o agravante. Os rastros que viram no
osciloscópios eram brilhantes, regularmente posicionados e de ritmo constante - os sinais vitais de uma
máquina.
Mesmo com o agravante, a equipe de depuração demorou um pouco para descobrir o que era
procurando por. Ainda assim, a cada poucos minutos um traço fantasma muito tênue passava pelo osciloscópio.
Foi isso? O traço fugaz foi talvez o único sinal revelador de que os acidentes foram
causado por um problema de tempo: um sincronizador paralisado em uma condição metaestável por alguns
nanossegundos muito longos. Era o equivalente de computador a uma fração de segundo de
confusão ou indecisão de um piloto de corrida que termina repentinamente em um acidente fatal. o
as evidências pareciam bastante incontestáveis, e Honeywell finalmente reconheceu isso.
Nesse ínterim, Barker projetou uma possível correção e reconfigurou o sincronismo central do IMP
corrente. Quando Barker trouxe a máquina de volta, carregou seu código de diagnóstico e
olhou na mira, os vestígios de fantasmas tinham desaparecido.
Embora Barker e Ornstein estivessem razoavelmente certos de que o problema foi corrigido, eles tinham
nenhuma maneira de saber com certeza a menos que a máquina funcionasse por alguns dias consecutivos sem
batendo. E eles não tiveram alguns dias. Heart já aprovou o envio do primeiro
Interface do processador de mensagens para a Califórnia no dia seguinte. IMP número um estava quase fora
a porta.

Página 88

5
Faça isso Truett
Steve Crocker e Vint Cerf eram melhores amigos desde que estudaram na Van Nuys High School
em San Fernando Valley, em Los Angeles. Eles compartilhavam o amor pela ciência, e os dois gastaram mais
do que algumas noites de sábado construindo jogos de xadrez tridimensionais ou tentando recriar
Experimentos de Edwin Land com percepção de cores.
Vint era um garoto magro, intenso e efusivo. Ele se juntou à unidade ROTC do colégio para evitar ginástica
classe. Nos dias em que não aparecia na escola com seu uniforme ROTC, Vint usava uma jaqueta
e gravata. E ele sempre carregava uma grande pasta marrom. Pelos padrões locais, era um
modo incomum de vestir, mesmo no final dos anos 1950. “Usei o casaco e a gravata para distinguir
eu mesmo da multidão - talvez a maneira de um nerd de ser diferente ”, ele lembrou.
No entanto, para consternação de seus amigos, Vint nunca teve problemas para atrair
a atenção do sexo oposto. Ele era, todos concordaram, único.
Desde cedo, Vint aspirou a igualar o histórico de sucesso de seu pai, que
subiu na hierarquia para se tornar um executivo sênior da North American Aviation
(agora Rockwell International). Os dois irmãos mais novos de Vint jogavam futebol e
vira presidente do corpo discente. Int era o leitor ávido. Seus gostos literários inclinados
em direção à fantasia. Bem em sua vida adulta, ele regularmente reservado vários dias para reler A
Trilogia O Senhor dos Anéis. Vint se saiu particularmente bem em química, mas sua paixão era matemática.
Quando Steve Crocker começou o clube de matemática em Van Nuys High, Vint foi um dos primeiros a
Junte-se.
Como resultado de um parto prematuro, Vint ficou com deficiência auditiva. Embora aparelhos auditivos em ambos
ouvidos mais tarde corrigiram grande parte do déficit, ele cresceu desenvolvendo estratégias inteligentes para
comunicar-se no mundo dos ouvintes. Anos mais tarde, depois que se tornaram amigos, Bob Kahn
trouxe alguns dos truques auditivos de Cerf à atenção de seus amigos e Cerf acabou escrevendo um
artigo chamado "Confissões de um engenheiro com deficiência auditiva", no qual ele compartilhou alguns dos
seus segredos.
Em ambientes particularmente ruidosos (lanchonetes, restaurantes e casas com cães e
crianças pequenas), a dependência da pessoa surda no contexto de conversação geralmente sofre muito.
Uma estratégia típica aqui é dominar a conversa, não apenas falando, mas
fazendo muitas perguntas. Desta forma, o ouvinte surdo saberá pelo menos que pergunta
o falante está se dirigindo, mesmo que ele não possa ouvir toda a resposta. Num grupo
conversa, isso pode sair pela culatra embaraçosamente se a pergunta que você faz é uma que foi
apenas perguntado por outra pessoa. Uma variação (igualmente embaraçosa) é entusiasticamente
sugira algo que acabei de sugerir, por exemplo:
Amigo A: Eu me pergunto qual é a origem desse termo?
Amigo B: Por que não procuramos no Oxford English Dictionary?

Página 89
Amigo A: Sim, mas é uma pena que não temos um O.ED
Cerf: Eu sei. Por que não procuramos no Oxford English Dictionary?
Steve Crocker entrava e saía da vida de Vint. Os pais de Steve eram divorciados e ele
passou os anos do ensino médio viajando entre o subúrbio de Chicago e o San Fernando
Vale. Sempre precoce, Steve cresceu sabendo que era provavelmente o garoto mais inteligente de
qualquer sala. Aos treze anos, um dia em casa com um resfriado, ele aprendeu sozinho a
elementos de cálculo. E no final do décimo ano, ele aprendeu os rudimentos do computador
programação. “Lembro-me de ficar emocionado quando finalmente entendi o conceito de um
loop ”, relembrou Crocker,“ que permitia ao computador prosseguir com uma longa
sequência de operações com apenas algumas instruções. Eu era um pouco imaturo, mas eu
lembre-se de pensar que esse foi o tipo de revelação que deve ter levado Arquimedes a correr
rua abaixo gritando, 'Eureka!' ”
Por volta de 1960, quando Steve voltou para LA, Vint o seguiu até o laboratório de informática
na UCLA. Embora ainda estivesse no ensino médio, Steve conseguiu permissão para usar o UCLA
computador, mas o único tempo livre que ele e Vint tinham era nos finais de semana. Um sábado eles
chegou para encontrar o prédio do laboratório de informática trancado. “Não pude ver outra escolha senão desistir
e vá para casa ”, disse Crocker. Mas eles olharam para cima e viram uma janela aberta no segundo andar.
Eles se entreolharam. “A próxima coisa que sei é que Vint está sobre meus ombros”, Crocker
recordado. Cerf entrou pela janela e, uma vez dentro, abriu a porta e colou o
trava para que eles possam entrar e sair do prédio. “Quando os ladrões de Watergate fizeram o
mesma coisa doze anos depois e fui pego, estremeci ”, disse Crocker.
Após o colegial, Cerf frequentou Stanford com uma bolsa de quatro anos de seu pai
companhia. Ele se formou em matemática, mas logo se viciou em computação séria. "Houve
algo incrivelmente atraente sobre programação ”, disse ele. “Você criou o seu próprio
universo e você era o mestre dele. O computador faria qualquer coisa que você
programado para fazer. Era esta caixa de areia inacreditável em que cada grão de areia estava
sob seu controle. ”
Depois de se formar em 1965, Cerf decidiu que queria trabalhar por um tempo antes de prosseguir para
pós-graduação. A IBM estava recrutando no campus de Stanford e Cerf conseguiu um emprego na IBM
em Los Angeles. Ele foi trabalhar como engenheiro de sistemas para um sistema de compartilhamento de tempo da
IBM.
Percebendo que precisava de mais conhecimentos em ciência da computação, ele logo se juntou a seu amigo
Crocker, agora um estudante graduado no departamento de ciência da computação da UCLA. Computador
a ciência ainda era uma disciplina jovem, e o Ph.D. da UCLA programa - um dos primeiros no
país - era um de apenas uma dúzia de existentes na época. Cerf chegou assim como Crocker
estava indo para o MIT. O orientador da tese de Crocker na UCLA foi Jerry Estrin, o mesmo
o professor Paul Baran havia trabalhado alguns anos antes. Estrin tinha um contrato ARPA
para o "Snuper Computer", que usou um computador para observar a execução de
programas em execução em uma segunda máquina. Estrin contratou Cerf como um estudante de pesquisa para o
projeto; tornou-se a base para a tese de doutorado de Cerf. No verão de 1968 Crocker
voltou para a UCLA e juntou-se a Cerf no grupo de Estrin.

Página 90
Para Cerf e Crocker, 1968 marcou o início de uma fascinação ao longo da vida com o
rede de computadores. Para Cerf, a rede de computadores se tornaria a peça central
de sua carreira profissional. Embora Crocker passasse para outras coisas por muito tempo
trechos de cada vez, ele também acabaria voltando ao campo das redes.
No outono de 1968, a ARPA transferiu seu contrato da Estrin para Len Kleinrock na UCLA.
Kleinrock estava montando seu Centro de Medição de Rede, com US $ 200.000 anuais
contrato do ARPA. Por coincidência, quando Kleinrock conseguiu o contrato, a pessoa do
o escritório ao lado foi convenientemente transferido, então Kleinrock expandiu seu domínio; ele rasgou
desceu a parede entre os dois escritórios e instalou uma grande mesa de conferência para reuniões
com alunos e funcionários. As reuniões eram frequentes enquanto Kleinrock construía ativamente um pequeno
Império.
Ao planejar a rede ARPA, Larry Roberts concebeu a rede
Measurement Center como a organização que seria responsável pela maioria das
teste e análise de desempenho. O centro de medição foi projetado para ser aproximadamente
análogo a uma pista de teste onde os motoristas ultrapassam os limites dos carros de alto desempenho.
Kleinrock e seu grupo eram responsáveis pela coleta de dados - tempo total de resposta da rede,
densidade de tráfego, atrasos e capacidade - as medidas necessárias para avaliar como a rede está
desempenho. Como Bob Kahn, Kleinrock tinha uma inclinação teórica; o negócio dele era
simulação, modelagem e análise. Por meio de simulações, ele chegou tão perto quanto
poderia monitorar as maneiras como as redes funcionam sem realmente ter um
rede para funcionar. Ele gostou da chance de testar suas teorias na realidade.
Os engenheiros da BBN não prestaram muita atenção a Kleinrock. Eles pensaram que ele era um
pouco pesado em teoria e razoavelmente leve em engenharia. O ceticismo era mútuo, pois
Kleinrock acreditava que a equipe da BBN não estava muito interessada em desempenho. BBN's
os programadores foram excelentes, mas, disse Kleinrock, “Em geral, um programador simplesmente
deseja obter um software que funcione. Isso é bastante difícil. Se funciona
bem ou bem, geralmente não é o problema. ” Ele não sabia, talvez, de Walden e
A obsessão de Crowther com a eficiência do software, mas, em qualquer caso,
aperfeiçoar o desempenho da rede , decidiu Kleinrock, era seu trabalho.
Em pouco tempo, Kleinrock estava gerenciando quarenta alunos que ajudavam a administrar o centro. Crocker
e Cerf estavam entre os membros mais antigos do grupo de Kleinrock. Outro importante
membro foi Jon Postel. Ele tinha uma longa barba espessa, usava sandálias o ano todo e tinha
nunca colocou uma gravata em sua vida. Sempre elegante e geralmente mais conservador, Cerf
apresentou um contraste notável com a aparência firmemente casual de Postel. Crocker, o
líder não oficial, estava em algum lugar no meio. Ele tinha deixado crescer a barba no MIT (“Policiais
olhou para mim com um pouco mais de atenção, mas as meninas eram muito mais amigáveis, e essa foi uma troca
que pude
viver com ”, disse Crocker), mas estava disposto a calçar um par de sapatos sociais de vez em quando
então.
Enquanto Cerf e Crocker eram estrelas acadêmicas, Postel, que tinha 25 anos, teve um
carreira acadêmica mais quadriculada. Ele cresceu nas proximidades de Glendale e Sherman
Oaks, e ele também frequentou a Van Nuys High School, onde suas notas eram medíocres.
O interesse de Postel em computadores desenvolvido em uma faculdade comunitária local. No momento em que ele
conseguiu

Página 91
para a UCLA para terminar um curso de graduação em engenharia (a coisa mais próxima de computador
ciência na época) a computação era sua vida. A UCLA finalmente decidiu estabelecer
ciência da computação como um departamento formal, mais ou menos na época em que Postel estava entrando no
escola de pós-graduação da universidade. Postel estava quieto, mas tinha opiniões fortes. As pessoas
administrar o departamento de ciência da computação ocasionalmente interpretava a firmeza de
As opiniões de Postel como má atitude.
Em 1966, Cerf casou-se com uma jovem ilustradora chamada Sigrid. Ela era profundamente surda.
Sua primeira reunião foi planejada por seu vendedor de aparelhos auditivos, que agendou
compromissos adjacentes para eles em uma manhã de sábado na esperança de que cruzassem
caminhos e batê-lo fora. Eles foram almoçar e Sigrid ficou pasmo com o seu companheiro
curiosidade eclética. Vint parecia dançar em sua cadeira com entusiasmo enquanto descrevia seu
trabalhar com computadores. Eles estenderam seu tête-à-tête com uma visita ao Los Angeles
Museu de Arte do Condado para ver algumas das pinturas favoritas de Sigrid. Não estudou arte, mas
ansioso para aprender, Cerf olhou por um longo tempo para um enorme Kandinsky. “Essa coisa me lembra
de um hambúrguer verde, ”ele finalmente observou. Um ano depois eles se casaram, com Steve
Crocker como padrinho de Vint (papéis que seriam invertidos alguns anos depois). Crocker
experiência em eletrônica foi útil quando, minutos antes do início da cerimônia, ele
descobriu que o gravador da música do casamento estava com defeito. Padrinho e
O noivo frenético retirou-se para uma pequena sala perto do altar e consertou bem a tempo.
Kleinrock, embora apenas dez anos mais velho que o resto de seu grupo, tinha uma grande reputação
na teoria das filas (o estudo de quanto tempo as pessoas e coisas passam esperando nas filas, como
longas filas e como projetar sistemas para reduzir a espera). Ele já tinha
publicou um livro e ficou encarregado de um laboratório em crescimento; sua energia parecia ilimitada.
Além disso, ele foi um dos poucos cientistas que produziram modelos analíticos de
redes armazenar e encaminhar antes de Roberts começar o projeto ARPA.
Na época, o departamento de ciência da computação da UCLA possuía um computador feito por
A Scientific Data Systems chamou de Sigma-7, o mais recente na linha de computadores daquela empresa.
A UCLA também tinha três grandes centros de computação equipados com mainframes IBM 7094. Mas
o Sigma-7 era a máquina atribuída aos alunos de graduação. Ninguém gostou do Sigma-7
Muito de. Não era confiável e era difícil de programar. Como disse um membro da equipe da UCLA,
o Sigma-7 era um cachorro. (“Mas era o nosso cachorro”, disse Cerf anos depois.) Foi também o único
computador com o qual eles tinham que brincar - isto é, até que a rede ARPA apareceu. Não somente
os cientistas da computação da UCLA estariam recebendo o primeiro IMP, mas provavelmente o
rede abriria portas para todos os tipos de máquinas host diferentes em outros sites.
A tarefa mais urgente no verão de 1969 era construir a interface - uma combinação
de hardware e software - entre o Sigma-7 e o IMP. Como os caras da UCLA
entendeu, a BBN estava trabalhando em algumas especificações para construir tal
conexão. A interface host-to-IMP teve que ser construída do zero cada vez que um novo site
foi estabelecido em torno de um modelo de computador diferente. Mais tarde, sites usando o mesmo modelo
pode comprar cópias da interface personalizada.
Quase tão urgente era o desafio de longo alcance de escrever o software que permitia
computadores host em toda a rede para se comunicarem uns com os outros. Isto era para ser

Página 92
o protocolo host-a-host, um conjunto muito amplo de termos operacionais que seriam
comum a todas as máquinas. Tinha que ser como um cheque de viagem: bom em qualquer lugar e capaz de
suporta uma gama de aplicativos, desde logins remotos a transferências de arquivos e processamento de texto.
Inventar não seria fácil.

A busca por protocolos

No verão de 1968, um pequeno grupo de estudantes de pós-graduação dos quatro primeiros locais de acolhimento -
UCLA, SRI, UC Santa Barbara e a University of Utah - se conheceram em Santa Barbara.
Eles sabiam que a rede estava sendo planejada, mas receberam poucos detalhes além
aquele. Mas a rede em geral, e o experimento ARPA em particular, eram tópicos quentes.
O encontro foi seminal, pelo menos pelo entusiasmo que gerou. “Tivemos muitos
perguntas - como IMPs e hosts seriam conectados, o que os hosts diriam uns aos outros,
e quais aplicativos seriam suportados ”, disse Crocker. “Ninguém tinha respostas, mas
as perspectivas pareciam excitantes. Nós nos encontramos imaginando todos os tipos de possibilidades -
gráficos interativos, processos de cooperação, consulta automática de banco de dados, correio eletrônico -
mas ninguém sabia por onde começar. ”
Desse encontro surgiu um corpo de jovens pesquisadores dedicados a trabalhar, pensando
por meio de e planejando sobre as comunicações host-a-host da rede. Acelerar
o processo, eles decidiram se reunir regularmente. Teoricamente, uma rede de computadores cortaria
para baixo em algumas das viagens financiadas pela ARPA, mas logo Crocker estava viajando o suficiente
que Kleinrock teve que obter um orçamento de viagens separado para ele.
Um mês ou mais depois que o novo grupo começou a se reunir, ficou claro para Crocker e outros
que é melhor eles começarem a acumular notas sobre as discussões. Se as reuniões
em si foram menos do que conclusivos, talvez o ato de escrever algo fosse
ajude a ordenar seus pensamentos. Crocker se ofereceu para escrever os primeiros minutos. Ele era um
jovem extremamente atencioso, sensível aos outros. “Lembro-me de ter muito medo de que
ofenderíamos quem quer que fossem os designers de protocolo oficiais. ” Claro, não havia
designers de protocolo oficiais, mas Crocker não sabia disso. Ele estava morando com amigos em
o tempo e trabalhei a noite toda na primeira nota, escrevendo no banheiro para não acordar
ninguém na casa. Ele não estava preocupado com o que queria dizer, tanto quanto ele
queria atingir o tom certo. “As regras básicas eram que qualquer um poderia dizer
nada e que nada era oficial. ”
Para evitar soar muito declarativo, ele rotulou a nota "Solicitação de comentários" e enviou
foi lançada em 7 de abril de 1969. Intitulada "Host Software", a nota foi distribuída para outros sites
a forma como todos os primeiros pedidos de comentários (RFCs) foram distribuídos: em um envelope com
a lambida de um selo. RFC Número 1 descreveu em termos técnicos o "aperto de mão" básico
entre dois computadores - como as conexões mais elementares seriam tratadas.
“Pedido de comentários”, descobriu-se, era uma escolha perfeita de títulos. Soou de uma vez
solícito e sério. E ficou preso.
“Quando você lê a RFC 1, você se afasta com uma sensação de 'Oh, este é um clube que
Eu também posso jogar '”, lembrou Brian Reid, mais tarde um estudante de graduação na Carnegie-Mellon. "Isto

Página 93
tem regras, mas acolhe outros membros, desde que os membros estejam cientes dessas
regras." A linguagem da RFC foi calorosa e acolhedora. A ideia era promover
cooperação, não ego. O fato de Crocker manter seu ego fora do primeiro RFC definiu o estilo
e inspirou outros a seguirem o exemplo nas centenas de RFCs amigáveis e cooperativos que
seguido. “É impossível subestimar a importância disso”, afirmou Reid. "Eu fiz
não se sinta excluído por um pequeno núcleo de reis do protocolo. Eu me senti incluído por um grupo amigável de
pessoas que reconheceram que o propósito da rede era trazer todos para dentro. ” Para
anos depois (e até hoje) RFCs têm sido o principal meio de expressão aberta
na comunidade de redes de computadores, a forma aceita de recomendar, revisar,
e adoção de novos padrões técnicos.
Em pouco tempo, a assembléia começou a se autodenominar Network Working Group, ou NWG.
Foi uma alta comissão para os jovens e excepcionalmente talentosos do país
programadores de comunicação. Seu principal desafio era concordar em princípio sobre
protocolos - como compartilhar recursos, como transferir dados, como fazer as coisas. Na real
termos, isso significava escrever programas, ou pelo menos adotar certas regras para a forma
programas foram escritos, regras com as quais a maioria poderia consentir. Acordo era o seno
qua non. Esta era uma comunidade de iguais. Todos eles poderiam escrever código - ou reescrever o código
outra pessoa havia escrito. O NWG era uma adhocracia intensamente criativa, adormecida
gênios da computação carentes, idiossincráticos e bem-intencionados. E eles sempre meio que esperavam,
qualquer dia, ser educadamente agradecido por seu trabalho e prontamente substituído por outros que
eles imaginavam ser os verdadeiros profissionais da área. Não havia ninguém para lhes dizer que eles
foram tão oficiais quanto possível. O RFC, um mecanismo simples para distribuição de documentação
aberto a qualquer pessoa, teve o que Crocker descreveu como um "efeito de primeira ordem" na velocidade de
quais ideias foram disseminadas e na disseminação da cultura de networking.
Antecipando a construção da rede, o Grupo de Trabalho da Rede continuou
reuniões regulares, e novos termos e invenções muitas vezes surgiam por consenso. O próprio
palavra "protocolo" encontrou seu caminho para a linguagem das redes de computadores com base no
necessidade de acordo coletivo entre os usuários da rede. Por muito tempo a palavra foi
usado para a etiqueta da diplomacia e para certos acordos diplomáticos. Mas no antigo
Grego, protokollon significava a primeira folha de um volume, uma folha de rosto presa ao topo de um
rolo de papiro que continha uma sinopse do manuscrito, sua autenticação e a data.
Na verdade, a palavra que se refere ao topo de um pergaminho correspondeu bem ao cabeçalho de um pacote,
a parte do pacote que contém informações de endereço. Mas um significado menos formal parecia
ainda mais adequado. “A outra definição de protocolo é que é um acordo escrito à mão
entre as partes, normalmente elaborado nas costas de uma lancheira ", observou Cerf," que
descreve com bastante precisão como a maioria dos projetos de protocolo foi feita. ”
Mas as primeiras reuniões do Grupo de Trabalho da Rede foram menos do que produtivas.
Ao longo da primavera e verão de 1969, o grupo continuou lutando com
os problemas de projeto de protocolo de host. Todos tinham uma visão do potencial para
comunicação intercomputador, mas ninguém nunca se sentou para construir protocolos que
poderia realmente ser usado. Não era função da BBN se preocupar com esse problema. O único
promessa que alguém da BBN havia feito sobre a sub-rede planejada de IMPs foi que
ele moveria os pacotes para frente e para trás e garantiria que eles chegassem ao destino. isso foi
cabe inteiramente ao computador host descobrir como se comunicar com outro host

Página 94
computador ou o que fazer com as mensagens depois de recebê-las. Isso foi chamado de
Protocolo “host-a-host”.
Os próprios computadores eram dispositivos extremamente egocêntricos. O mainframe típico de
o período se comportou como se fosse o único computador do universo. Não havia óbvio
ou uma maneira fácil de envolver duas máquinas diferentes até mesmo na comunicação mínima necessária
para mover os bits para frente e para trás. Você pode conectar máquinas, mas uma vez conectado, o que
eles diriam um ao outro? Naquela época, um computador interagia com os dispositivos que
estavam apegados a ele, como um monarca se comunicando com seus súditos. Tudo
conectado ao computador principal realizava uma tarefa específica, e cada dispositivo periférico
presumia-se que ele estava sempre pronto para um tipo de comando buscar meus chinelos. (No
linguagem do computador, esta relação é conhecida como comunicação mestre-escravo.)
Os computadores foram estritamente projetados para esse tipo de interação; eles enviam instruções para
leitores de cartões, terminais e unidades de fita subordinados e eles iniciam todos os diálogos. Mas se
outro dispositivo tocou no ombro do computador com um sinal que dizia: “Oi,
Eu também sou um computador ”, a máquina receptora ficaria perplexa. O objetivo de conceber o
protocolo host-a-host era fazer com que as máquinas mainframe conversassem como pares, para que
lado poderia iniciar um diálogo simples e o outro estaria pronto para responder com pelo menos
um reconhecimento da existência da outra máquina.
Steve Crocker uma vez comparou o conceito de um protocolo host-a-host à invenção de dois
por quatro. "Você imagina cidades e edifícios e casas, e assim por diante, mas tudo que você vê é
árvores e floresta. E em algum lugar ao longo do caminho, você descobre dois por quatro como um
bloco de construção intermediário, e você diz, bem, posso obter dois por quatro de todos esses
árvores ”, lembra Crocker. “Não tínhamos o conceito de um equivalente a dois por quatro,
os protocolos básicos para fazer todos os computadores falarem, e que seriam úteis para
construir todos os aplicativos. ” O equivalente de computador de um dois por quatro era o que o
O Grupo de Trabalho de Rede estava tentando inventar.
Ao conceber o protocolo, os membros do NWG tiveram que se perguntar algumas questões básicas
questões. Qual deve ser a forma da base comum? Deve haver um único,
protocolo básico no qual construir todos os protocolos de aplicativos? Ou deveria ser mais
complexo, subdividido, em camadas, ramificado? Seja qual for a estrutura que escolheram, eles sabiam que
queria que fosse o mais aberto, adaptável e acessível à inventividade possível. o
visão geral era que qualquer protocolo era um bloco de construção potencial e, portanto, o melhor
abordagem era definir protocolos simples, cada um limitado em escopo, com a expectativa de que
qualquer um deles pode algum dia ser unido ou modificado de várias maneiras inesperadas. o
filosofia de projeto de protocolo adotada pelo NWG abriu caminho para o que veio a ser
amplamente aceito como a abordagem “em camadas” para protocolos.
Um dos objetivos mais importantes da construção do protocolo de camada inferior entre os hosts era
ser capaz de mover um fluxo de pacotes de um computador para outro sem ter que
se preocupe com o que estava dentro dos pacotes. O trabalho da camada inferior era simplesmente mover
bits genéricos não identificados, independentemente do que os bits podem definir: um arquivo, um interativo
sessão entre pessoas em dois terminais, uma imagem gráfica ou qualquer outro
forma de dados digitais. Analogamente, um pouco de água da torneira é usada para fazer café,
alguns para lavar pratos e alguns para tomar banho, mas o cano e a torneira não ligam; eles
 Página 95
transportar a água independentemente. O protocolo host-a-host era para realizar essencialmente o
mesma função na infraestrutura da rede.
Projetar o protocolo host-a-host não foi a única tarefa antes do grupo. O NWG também
teve que escrever os aplicativos de rede para tarefas específicas, como transferência de arquivos. Enquanto o
as palestras ficaram mais focadas, decidiu-se que as duas primeiras inscrições deveriam ser para
logins remotos e transferências de arquivos.
Na primavera de 1969, alguns meses antes de Kleinrock e a equipe anfitriã da UCLA serem
esperando receber o primeiro IMP, um envelope grosso chegou de Cambridge. Os caras da
A UCLA estava antecipando isso. Dentro do pacote estava o Relatório da BBN 1822, o novo
conjunto escrito de especificações para conectar computadores host aos que serão entregues em breve
IMPs. A rede ARPA finalmente parecia estar começando.
Após meses de adivinhação, a equipe da UCLA agora aprendeu o que se esperava para obter
seu site pronto e construir sua interface de hardware. O Relatório da BBN 1822 também instruiu os sites
na criação de um software chamado driver de dispositivo - uma coleção de códigos e tabelas para
controlar um dispositivo periférico - para operar a interface host-para-IMP. E finalmente,
A emissão das especificações pela BBN esclareceu a fronteira entre o IMP e o host.
Ficou claro que a BBN planejava não incluir nenhum software especial no IMP para realizar
comunicação host-a-host. Esse problema seria deixado, de uma vez por todas, para o anfitrião
computador e, portanto, ao NWG.
Isso significou muito trabalho de verão para os alunos de Los Angeles. Eles pensaram que eles
pode ser capaz de concluir a construção da interface host-para-IMP a tempo. Mas escrever o host-to-
o protocolo do host já havia paralisado Crocker, Cerf e todo o Grupo de Trabalho de Rede
por meses. Em vez de tentar apressar algo a tempo, eles decidiram contar a cada site
para remendar seus próprios protocolos improvisados por enquanto.
A UCLA pediu aos técnicos da Scientific Data Systems, fabricantes do Sigma-7, para construir o
hardware de interface para sua conexão host-a-IMP. A resposta da empresa foi
desanimador: levaria meses e provavelmente não seria concluído a tempo para o
Chegada do IMP. Além disso, a empresa queria dezenas de milhares de dólares pelo trabalho. assim
quando um estudante de graduação chamado Mike Wing-field pediu o emprego, ele conseguiu. E porque
não? Wingfield era um gênio em hardware e tinha acabado de construir um complexo gráfico
interface para outro computador.
A especificação da BBN para as interações e conexões host-para-IMP foi esplêndida
projeto. Uma espécie de livro de receitas, escrito por Bob Kahn em prosa cristalina, o documento
foi acompanhado por diagramas detalhados. A especificação de Kahn deu a Wingfield o básico
requisitos para acoplar o Sigma-7 a um IMP. Quase antes de Wingfield saber disso, o
o verão voou e a interface foi construída sem problemas.
Uma semana antes do IMP estar programado para chegar em 1º de setembro, Wingfield teve o
hardware concluído, depurado e pronto para se conectar ao IMP. Crocker ficou tão impressionado
ele o descreveu como um trabalho “maravilhoso”. Mas, tentando obter as comunicações
feito o software, Crocker estava rodando atrasado. Ele tinha uma tendência a procrastinar de qualquer maneira,
e a ausência do IMP real apenas encorajou essa tendência.

Página 96
Agora, como qualquer pessoa tentando ultrapassar um prazo, Crocker olhou para o calendário e fez um
poucos cálculos. Contava com pelo menos um dia a mais, já que 1º de setembro era
Dia de trabalho. Além disso, ele tinha ouvido falar que a BBN estava tendo alguns problemas com o IMP
Cadeia de temporização. Os bugs do sincronizador eram terrivelmente desagradáveis. Seu bug era sua boa sorte, e
com um pouco de sorte, poderia até lhe dar uma ou duas semanas a mais, pensou. Então ele era mais
que levemente surpreso quando Len Kleinrock disse a ele que a BBN estava prestes a colocar o IMP
em um avião que deve chegar a Los Angeles no sábado, 30 de agosto, dois dias antes.
Em Cambridge, Frank Heart estava preocupado com a questão da melhor forma de enviar o
IMP para UCLA. Depois de debater por alguns dias, Heart decretou que deveria ir ao ar,
e que Ben Barker deveria acompanhá-lo. Um voo comercial estava fora de questão. o
Honeywell 516 modificado - agora oficialmente Número do Processador de Mensagens da Interface BBN
Um - era grande demais para o compartimento de carga de um avião de passageiros. Teve que sair por via aérea
frete. Se Heart tivesse sido capaz, ele teria colocado Barker direto no avião de carga
segure com o pulso algemado ao IMP. Não importa que ele tenha escolhido a máquina
precisamente porque foi endurecido pela batalha; os rigores do combate não eram nada comparados a
a punição que os carregadores de companhias aéreas poderiam aplicar. “Ele queria que alguém estivesse lá,
gritando com o pessoal de carga para se certificar de que eles não fossem descuidados com isso ”, lembra Barker.
Mas Barker teria que viajar separadamente em um vôo comercial de passageiros. Truett
Thach, um técnico do escritório da BBN em Los Angeles, seria instruído a receber o avião.
Assim que o IMP foi embalado, Barker pegou um marcador mágico vermelho e escreveu em letras grandes DO
TI PARA ELE TRUETTon ao lado da caixa. Foi carregado em um voo de manhã cedo
do aeroporto Logan de Boston, e Thach estava lá para recebê-lo no aeroporto LAX naquela tarde. Quando
ele chegou, acompanhado por um transportador de carga, ele ficou aliviado ao ver a caixa cair
o avião, mas ficou chocado quando percebeu que a mensagem de Barker para ele estava de cabeça para baixo.
“Em algum lugar ao longo do caminho, o IMP foi invertido um número ímpar de vezes”, ele
observado. Thach mandou os carregadores corrigirem a caixa antes de carregá-la em seu caminhão. Depois ele
seguiu-os para a UCLA.
Era um sábado antes do Dia do Trabalho e Thach percebeu que as ruas estavam estranhamente silenciosas
todo o caminho através de Westwood até o campus. Barker já estava esperando o
doca de carregamento em Boelter Hall com cerca de uma dúzia de outras pessoas - Kleinrock, Crocker,
Postel, Wingfield, Vint e Sigrid Cerf e um punhado de curiosos. O Cerfs teve
trouxe um pouco de champanhe. Imediatamente ao ver a caixa, alguém levantou um
questionar se a caixa caberia no elevador; o IMP foi descompactado por isso
poderia ser encaixado.
Quando a máquina foi retirada da caixa, a festa de boas-vindas foi surpreendida por seu
Tamanho. Embora menor que o Sigma-7, não era um dispositivo pequeno. Era aproximadamente do tamanho
de uma geladeira, pesando mais de novecentas libras, e estava incrivelmente envolta
em aço cinza de navio de guerra, exatamente de acordo com as especificações militares. Havia quatro olhais de aço
no topo do IMP para içá-lo em um navio por guindaste ou helicóptero. Na UCLA, o IMP era
como um soldado em uniforme de combate batendo em uma festa de professores.

Página 97
Quando o elevador chegou ao terceiro andar, os carregadores de carga empurraram a máquina para baixo
o corredor e ao virar da esquina para sua nova casa no quarto 3400. O Sigma-7 zumbia
por perto, alheio à enorme perturbação que estava prestes a invadir sua privacidade. "Isso foi
um pouco como ver seus pais convidarem para jantar alguém que você nunca conheceu ”, disse Crocker.
"Você não presta muita atenção até descobrir que eles realmente pretendem casar você com
este estranho. ”
Thach e Barker passaram alguns minutos conectando o IMP e ligando-o. Instantaneamente o
a memória central da máquina sabia exatamente o que fazer: continuou exatamente de onde havia parado em
Cambridge, executando o diagnóstico que os caras do IMP escreveram para ele. A seguir Mike
Wingfield conectou sua interface. Uma vez que este era o nó número um, não havia um
rede em si na qual testá-lo. Mas Barker poderia fazer experimentos de manobra entre os
Sigma-7 e o IMP, como fizeram muitas vezes na Moulton Street entre as máquinas
para simular links de rede. Em uma hora, o Sigma-7 e o IMP estavam passando dados
para a frente e para trás, como se já estivessem fazendo isso há anos.
Barker ainda não tinha certeza absoluta de que o problema do sincronizador havia sido resolvido. Mas
ele estava confiante o suficiente para pensar em voltar para casa. Naquela noite, Barker ligou para Heart.
“Terminamos, está tudo funcionando”, disse ele. “É falar com as coisas de Mike [Wingfield]. Eu estou
pensando em pegar um voo para casa pela manhã. ”
O coração parou e Barker sentiu o que poderia estar por vir. “Por que você simplesmente não sai
lá alguns dias? ” Coração respondeu. “Só para ver se algo dá errado.” Barker gastou
três dias relaxando com Thach, viajando por Los Angeles e esperando o IMP quebrar. isto
não.

Uma rede real

Um mês após o primeiro IMP ter sido instalado na UCLA, o IMP Número Dois chegou ao SRI,
exatamente no dia 1 de outubro de 1969. Nesse mesmo mês, Bob Taylor deixou a ARPA. Ele tinha
há muito tempo se afastou dos detalhes do projeto de rede. Como ele explicou, em
década de 1960, “ARPA” era uma palavra mágica. O escritório de Taylor era frequentemente chamado para resolver
problemas que outros não conseguiam. Em 1967 e 1968, Taylor foi enviado várias vezes para
Vietnã para ajudar a esclarecer, entre outras coisas, a controvérsia sobre o Exército
Relatórios de “contagem de corpos” tratados pelos centros de informações militares. A experiência tinha partido
Taylor ficou exausto. Ele conseguiu um cargo na Universidade de Utah.
Muitos marcos no experimento da rede foram ultrapassados até agora: o financiamento de Taylor
vitória e cortejo de sucesso de Roberts; Conceito de rede de Roberts; BBN's
construção e entrega do primeiro IMP. Mas a instalação do IMP Número Dois
marcou a conquista mais importante até à data. Por fim, os pesquisadores conseguiram conectar dois
computadores díspares e fazê-los falar uns com os outros como dois velhos camaradas.
Como a equipe da UCLA antes, o grupo do SRI teve uma confusão louca semelhante se preparando para
a chegada do IMP. Uma diferença crucial entre os dois sites era que enquanto o
Os caras da UCLA não gostavam do Sigma-7, os caras do SRI adoravam seu computador host, um SDS 940.
Como o Sigma-7, o 940 foi construído pela Scientific Data Systems. Mas o Sigma-7 tinha

Página 98
foi projetado como um processador comercial, enquanto o 940 era basicamente um processador acadêmico
dispositivo, um sistema revolucionário de compartilhamento de tempo criado pela primeira vez por uma equipe de
Berkeley
pesquisadores, posteriormente vendido sob a placa de identificação da SDS. Como resultado, foi muito mais divertido
programa do que o Sigma-7.
Bill Duvall, um pesquisador do SRI, passou cerca de um mês escrevendo um programa inteligente para o 940
que essencialmente o enganou fazendo-o pensar que não estava se comunicando com outro computador
mas com um terminal “burro”. Um terminal burro não pode computar nem armazenar informações;
serve apenas para exibir o conjunto mais recente de informações enviadas a ele pelo computador para
ao qual está vinculado. O programa de Duvall era uma solução provisória muito específica para o host-to-
problema de comunicação do host. Por semanas, os pesquisadores da UCLA estavam se preparando para
sua primeira sessão de login discando de longa distância para o sistema SRI usando um
modem e um teletipo, para se familiarizarem com o sistema de compartilhamento de tempo da SRI. Com
ambos os IMPs agora no lugar, e ambos os hosts em execução, o momento de testar os dois nós reais
A rede ARPA finalmente chegou.
A primeira coisa a fazer, é claro, era conectar. Ao contrário da maioria dos sistemas de hoje, que
solicitar ao usuário um nome de login e uma senha, o sistema SRI esperou por um comando
antes de reconhecer uma conexão. “LOGIN” era um desses comandos.
Preso aos primeiros IMPs como uma craca estava uma pequena caixa semelhante a um telefone, com um cabo e
fone de ouvido. Ele compartilhava a linha com os IMPs e usava um subcanal destinado à voz
conversas. A linha de voz era, como a linha de dados, um link dedicado. Alguns dias depois
o IMP estava em vigor no SRI, Charley Kline, então um graduando na UCLA, pegou
o fone de ouvido do telefone em LA e apertou um botão que tocou uma campainha no IMP em Menlo
Parque. Um pesquisador do grupo de Engelbart no SRI respondeu. Era de alguma forma mais
emocionante para Kline do que discar para um telefone comum.
A qualidade da conexão não era muito boa e os dois homens estavam sentados em um ambiente barulhento
salas de informática, o que não ajudou. Então Kline gritou bem no porta-voz: "Estou
vou digitar um L ! ” Kline digitou um L.
“Você pegou o L? " ele perguntou. “Consegui um-um-quatro”, respondeu o pesquisador do SRI; ele era
lendo a informação codificada em octal, um código usando números expressos na base 8.
Quando Kline fez a conversão, ele viu que realmente era um L que havia sido transmitido. Ele
digitou um O.
“Você conseguiu o O? " ele perguntou.
“Consegui um-um-sete”, foi a resposta. Foi um O.
Kline digitou um G.
“O computador travou”, disse a pessoa do SRI. O fracasso veio graças a um inteligente
pouco de programação da parte de Duvall. Assim que a máquina SRI reconheceu as letras LOG,
completou a palavra. “Acho que é onde estava o bug”, lembrou Kline. “Quando o SRI
O sistema 940 recebeu o G, tentou enviar de volta "GIN" e o programa do terminal não
pronto para lidar com mais de um personagem ao mesmo tempo. ”

Página 99
Mais tarde naquele dia, eles tentaram novamente. Desta vez funcionou perfeitamente. Crocker, Cerf e Postel
foi ao escritório de Kleinrock para contar a ele sobre isso para que ele pudesse vir ver por si mesmo. De volta
o laboratório UCLA Kline se conectou à máquina SRI e foi capaz de executar comandos no
o sistema de compartilhamento de tempo do 940. O computador SRI em Menlo Park respondeu como se o
Sigma-7 em LA era um terminal burro de boa-fé.
Não há pequena ironia no fato de que o primeiro programa usado na rede foi um
isso fez o computador distante se disfarçar de terminal. Todo aquele trabalho para conseguir dois
computadores conversando entre si e eles acabaram na mesma situação mestre-escravo
a rede deveria eliminar. Então, novamente, os avanços tecnológicos geralmente começam
com tentativas de fazer algo familiar. Pesquisadores constroem confiança em novas tecnologias por
demonstrando que podemos usá-lo para fazer coisas que entendemos. Depois de fazer isso, o
os próximos passos começam a acontecer, à medida que as pessoas começam a pensar ainda mais à frente. Como
pessoas
assimilar a mudança, a próxima geração de ideias já está evoluindo.
Agora existia uma rede. O primeiro mapa da rede ARPA era assim:
O IMP Número Três foi instalado na UC Santa Bárbara em 1º de novembro. Para o Santa
Instalação de Barbara, Barker voou para a Califórnia novamente. Por esta altura, Heart era mais
relaxado. Havia poucos traços do suspense que havia acompanhado a primeira viagem. De fato,
instalar IMPs estava começando a parecer rotina.
Mais tarde naquele mês, Larry Roberts decidiu voar para a Califórnia para inspecionar a rede
em primeira mão pela primeira vez. Roberts não gostava de viajar. Quando ele viajava, ele nunca saiu
para pegar seu avião até o último minuto. Isso deixou sua secretária louca, mas ele perdeu apenas
um avião que qualquer um poderia se lembrar. Isso aconteceu uma tarde quando ele estava
parou por excesso de velocidade a caminho do aeroporto Dulles. Convencido de que ele não tinha ido
muito rápido, Roberts decidiu contestar o ingresso. Ele tinha sido parado pela viatura
perto do ponto em que ele entrou na George Washington Parkway depois de um
parar, e sua alegação era que naquela curta distância ele não poderia ter
acelerou seu Volkswagen Beetle até a velocidade alegada pelo oficial. Roberts voltou
para a cena e medindo cuidadosamente as distâncias. Ele reuniu dados no motor
saída e peso de seu bug VW, fatorado na lei da inércia de Newton e fez alguns

Página 100
outros cálculos, e estava preparado para se apresentar a um juiz para apresentar seu caso. Não foi até
amigos o convenceram de que ele dificilmente conseguiria um juiz com um diploma de física que ele
concedeu o ponto e pagou a multa em vez de levá-la ao tribunal.
Felizmente, não houve multas por excesso de velocidade nesta viagem. Roberts e seu gerente de programa,
Barry Wessler voou para a Califórnia sem incidentes e no laboratório de Kleinrock em Boelter Hall
eles assistiram a rede em operação. Desta vez, Kleinrock fez a digitação e em menos
de um minuto ele havia se conectado ao computador host no SRI. Roberts observou de perto e
saiu satisfeito com o sucesso da experiência.
O quarto foi Utah. A essa altura, era dezembro - a melhor temporada de esqui. Também aconteceu de ser
uma reunião do Grupo de Trabalho da Rede agendada no local. Esquiadores interessados em toda a BBN
equipe, até mesmo Frank Heart, foi a Salt Lake City para conectar o IMP. (Ironicamente, Barker
foi o único excluído da viagem a Utah - um fato que ele não deixaria os outros esquecerem
por muitos anos.)
O layout do crescente número de links de comunicação estava se tornando um interessante
problema. Por um lado, não havia um link ponto a ponto entre cada par de sites.
Por razões de economia, Roberts decidiu que nenhuma ligação direta era necessária entre a UCLA
e Utah, ou entre Santa Bárbara e Utah, de modo que todo o tráfego destinado a Utah teve que
passar pelo IMP no SRI. Tudo bem, desde que estivesse instalado e funcionando. Se ele travou,
a rede se dividiria e Utah seria cortado até que o SRI fosse colocado novamente online.
Como aconteceria, a rede de quatro nós que Roberts projetou não era uma rede robusta
de conexões redundantes.
As interrupções no sistema também se manifestaram de maneiras menos óbvias. Este foi
deixou claro muito cedo, quando os alunos de Santa Bárbara começaram a fazer exatamente o que
Heart temeu que isso acontecesse: brincando com seu novo brinquedo. E a atitude deles era: por que não?
Eles nunca tiveram que se preocupar com conexões externas, e não lhes ocorreu que
algo que eles fizeram em seu laboratório de informática pode ter um efeito em outro lugar. “Nós alegremente
pensei que o IMP era nosso para brincar ”, lembrou Roland Bryan, um morador de Santa Bárbara
investigador. “Estávamos testando, ligando e desligando, reiniciando, recarregando e
tentando novamente." Como resultado, as pessoas que faziam medições de rede e quem
contassem com o caminho da rede através de Santa Bárbara, teriam seu experimento lançado
fora. “Embora não tenhamos prejudicado os links entre outros sites, estávamos interrompendo os dados
análise de tráfego realizada pela BBN e UCLA ”, disse Bryan. “Nós não pensamos sobre
o fato de que toda vez que fazíamos isso, alguém iria sofrer. ”
No final de 1969, o Grupo de Trabalho da Rede ainda não havia criado um host-a-host
protocolo. Sob coação para mostrar algo à ARPA em uma reunião com Roberts em
Dezembro, o grupo apresentou um protocolo remendado - Telnet - que permitiu
logins remotos. Roberts não gostou do escopo limitado do esforço. Apesar
O Telnet foi claramente útil e fundamental, pois permitiu que um terminal alcançasse vários
computadores remotos, um programa de login remoto por si só não resolveu o problema de permitir
dois computadores trabalham juntos. Além disso, o Telnet era uma forma de usar a rede, não um
bloco de construção de nível inferior. Roberts os mandou de volta para continuar tentando. Depois de mais um ano de
reuniões e várias dezenas de RFCs, no verão de 1970, o grupo ressurgiu com um

Página 101
versão preliminar de um protocolo para comunicações host-a-host básicas e sem adornos.
Quando o "comitê de limpeza de falhas" terminou seu trabalho um ano depois, o NWG finalmente
produziu um protocolo completo. Era chamado de Protocolo de Controle de Rede ou NCP.
Em janeiro de 1970, Bob Kahn decidiu que, com os primeiros quatro nós funcionando, era hora de
teste seus vários cenários nos quais a rede pode sofrer falha congestiva. O tipo
de bloqueio que mais o preocupava, o cenário que ele sugeriu a Crowther meses
anteriormente, seria causado por congestionamento em um IMP de destino. Ele tinha especulado que
buffers de armazenamento ficariam tão cheios que os pacotes necessários para remontagem
as mensagens não poderiam fluir para um IMP de destino, que por si só seria preenchido
com partes desmembradas da mensagem aguardando conclusão.
Para testar essa hipótese e apaziguar Kahn, Heart sugeriu que Kahn e Dave Walden
voe para Los Angeles para colocar a rede à prova. Kahn teve vários
experimentos em mente. Ele queria enviar todas as permutações possíveis de tráfego de IMP para
IMP, alterando o tamanho dos pacotes e a frequência com que foram enviados, em um
tentativa de induzir um impasse. Walden foi junto porque ele era o hands-on
programador que sabia como manipular o código e fazer os pacotes fazerem o que Kahn
queria que eles fizessem. Walden se encarregou de reconfigurar os IMPs para enviar o tráfego
padrões específicos. Ele poderia alongar ou truncar os pacotes, enviá-los a cada três
segundos ou a cada meio segundo. O software IMP, os algoritmos, todo o design estava em
para uma grande torção.
A primeira coisa que Kahn configurou foi um teste para demonstrar que seu medo de uma remontagem travava
foi bem fundado. Assim como Kahn havia previsto, cercando os IMPs com pacotes,
em poucos minutos, ele e Walden conseguiram forçar a rede a entrar em catatonia. "EU
acho que fizemos isso nos primeiros doze pacotes ”, lembrou Kahn. “A coisa toda veio a um
parada de moagem. ”
Kahn foi justificado. Ele e Walden permaneceram por alguns dias, continuando a
experimentos. Para Walden, que havia passado tantos meses confinado em Cambridge
escrever código em um quase vácuo, foi gratificante ver a rede em operação, mesmo que
seu objetivo agora era quebrá-lo. Ele estava se divertindo. “Eu estava hackeando por dinheiro”, Walden
recordado. “Fui levado a aprender o máximo que pudesse e o mais rápido que pudesse.”
Kahn e Walden estabeleceram uma rotina. Todas as manhãs, eles se levantavam e tomavam café da manhã no
o restaurante do Sambo ao lado do hotel em Santa Monica. Walden usava essas manhãs
como uma oportunidade de saciar o gosto de seu nativo californiano por suco de laranja feito na hora,
ainda uma raridade em Boston. Em seguida, eles dirigiram para o campus da UCLA e passaram o dia todo e
grande parte da noite testando os limites dos IMPs. Às vezes, eles faziam uma pausa para o jantar;
às vezes eles não percebiam que a hora do jantar tinha chegado e passado. Eles tiraram uma noite de folga
ver o filme M * A * S * H, que acabava de ser lançado.
Freqüentemente, Cerf se juntava a eles e, ocasionalmente, Crocker e Postel também. Em um
ponto no teste, Cerf programou o Sigma-7 para gerar tráfego para o IMP e usou
a máquina host para coletar dados sobre os resultados. Esta foi a primeira vez que ele trabalhou

Página 102
de perto com Kahn em um projeto desafiador, cimentando um vínculo profissional que duraria
para anos que virão.
No final da semana, o caderno de Kahn estava cheio de dados que provavam seu caso. Quando ele
e Walden voltou para Cambridge, eles compartilharam suas descobertas com Crowther e Heart.
Crowther não disse muito, mas Kahn suspeitou que a bateria de testes o fez começar
pensando sobre o problema. "De alguma forma, Crowther deve ter registrado na parte de trás de sua
lembre-se de que se dois de nós voltássemos e relatássemos esse problema, talvez houvesse um
questão ”, disse Kahn. De volta ao laboratório, Crowther construiu uma simulação do que Kahn e Walden
tinha feito em campo e descobriu por si mesmo que a rede poderia realmente travar.
Ele relatou suas descobertas a um Coração ligeiramente desanimado, que instruiu Crowther a trabalhar
com Kahn sobre como resolver o problema. “Bob começou a se sentir muito melhor e Frank sentiu um
um pouco pior ”, disse Walden sobre todo o episódio. "Claro, Frank nunca pensou que
a coisa estava perfeita, mas ele sempre ficava desanimado quando as coisas não davam certo. ”
Coração tinha todos os motivos para olhar além das poucas falhas que estavam começando a aparecer no
rede nascente. Afinal, problemas com controle de congestionamento puderam ser corrigidos. Em um maior
escala, a empresa havia assumido um experimento arriscado, envolvendo ideias e técnicas
nunca testado antes. E funcionou. O hardware funcionou e o software funcionou.
E as formas únicas como a ARPA conduziu seus negócios e seu relacionamento com seus
empreiteiro trabalhou também.
Acima de tudo, o conceito esotérico em que toda a empresa girou - pacote
comutação funcionou. As previsões de fracasso total estavam totalmente erradas.

6
Hacking Away and Hollering
A rede era real, mas com apenas quatro nós agrupados na Costa Oeste, sua topologia
era simples, o experimento pequeno. Centrais de computação da Costa Leste, como MIT e
O Lincoln Laboratory, onde tanta coisa estava acontecendo, não estava conectado. O próprio local
onde Bob Taylor tinha sonhado acordado com uma rede, a sala de terminais ARPA no
Pentágono, ainda não estava conectado. Nem a própria BBN. Todos estavam esperando novas máquinas,
que a Honeywell prometeu estar em produção no Natal de 1969.
Os últimos doze meses foram difíceis para o ARPA. O orçamento da agência atingiu um
pico histórico e entrou em declínio. A Guerra do Vietnã estava consumindo tudo. No
Dezembro de 1969 ARPA foi expulso de sua sede no Pentágono e
forçada a se mudar para um prédio comercial alugado em Arlington, Virgínia. Diretor Stephen
Lukasik chamou isso de "o equivalente americano de ser banido para a Sibéria". O ARPA que
uma vez classificada como uma bandeira americana emitida pelo Pentágono atrás da mesa do diretor, foi
discretamente
despojado de tais armadilhas. Apesar do baixo moral, os funcionários da ARPA mantiveram sua bandeira e
exibido na nova sede, esperando que ninguém importante percebesse que
apenas quarenta e oito estrelas.

Página 103
A computação continuou a ser a única linha do orçamento da agência que não diminuiu
no início da década de 1970. Larry Roberts estava determinado a ganhar o apoio do topo,
e fez. Ele estava igualmente determinado a obter mais uma dúzia de investigadores principais
em todo o país para comprar a ideia da rede ARPA. Ele continuou empurrando. Ele manteve
pressão constante em novos locais para se prepararem para o dia em que um IMP chegará em seus
portas com uma equipe da BBN para conectar seus computadores host à rede. Não era um
questão de se, mas quando, e Roberts sempre colocou dessa forma.
Em Cambridge, a atividade na Moulton Street começou a ganhar ares de produção - “o
fábrica ”, alguns a chamavam. A maior parte do esforço mudou para a grande sala na parte de trás
do prédio baixo com a doca de carregamento, onde as entregas da Honeywell foram
recebido; e lá cada nova máquina foi configurada para ser depurada e testada antes de ser
enviado para o campo. Ao mesmo tempo, a equipe do Heart continuou melhorando rapidamente o
projeto do IMP, desenvolvimento, teste e ajustes de software e hardware. o
quinto, sexto e sétimo 516 computadores chegaram da Honeywell nos primeiros meses do
ano.
No final de março, o primeiro circuito de cross-country na rede experimental ARPA foi
instalado. A nova linha de 50 kilobits conectou o centro de informática da UCLA ao Moulton da BBN
Site de rua, que se tornou o quinto nó da rede. E não foi apenas um avanço
simbolicamente da Costa Oeste para o Leste (expansão da fronteira ao contrário); a
o link transcontinental também foi um benefício imediato para a manutenção da rede e
solução de problemas.
Nos meses anteriores à BBN tinha sua própria máquina e estava conectada à rede,
lidar com problemas de rede no cluster de quatro nós a oeste foi um trabalho realizado por
pessoas que estavam no local. Na maioria das vezes, significava alguém na Califórnia ou em Utah
passava horas ao telefone falando de cross-country com alguém da BBN, enquanto o
infeliz alma que se ofereceu para resolver o problema transferida entre o telefone
e o IMP para executar as instruções verbais vindas de Cambridge. Durante o
desde o início, a equipe do Heart passou muito tempo no telefone e manteve um mais ou menos
presença contínua em campo, orientando parentalmente o início da rede infantil. Em
um ponto, Walden voou para Utah, Stanford, Santa Barbara e UCLA para entregar em mãos um
novo lançamento de software.
Mas quando um IMP foi instalado na BBN no início da primavera de 1970, de repente houve um
maneira de enviar dados e relatórios de status eletronicamente dos IMPs da Costa Oeste diretamente de volta
para a BBN. A obsessão do coração com a confiabilidade resultou em mais do que computadores envoltos
em aço pesado. Sua insistência em construir computadores robustos - e em manter o controle
sobre os computadores que ele colocou em campo - inspirou a equipe da BBN a inventar um
tecnologia: manutenção e diagnóstico remoto. A equipe da BBN projetou no
IMPs e a rede, a capacidade de controlar essas máquinas à distância. Isso eles usaram ambos
para solucionar problemas e às vezes consertar os processadores de mensagens remotamente
controle, bem como manter um olhar atento sobre os IMPs vinte e quatro horas por dia.
Horrorizado como estava com a perspectiva de alunos de pós-graduação mexendo em seus IMPs, Heart tinha
procurava construir máquinas que pudessem funcionar sem supervisão. Ele canalizou sua obsessão

Página 104
para inventar este conjunto de ferramentas extremamente úteis e técnicas de gerenciamento de sistema.
Recursos para o controle remoto da rede foram construídos integralmente em todo o
Projetos de hardware e software do IMP.
Na BBN, no lado do hardware, um terminal de teletipo com recursos de registro foi adicionado ao
o processador de mensagens da BBN, junto com luzes de advertência especiais e um alarme sonoro para
indicam falhas de rede. Ao projetar os IMPs, a BBN tornou possível fazer um loop do host
e interfaces de modem da máquina, para que pudessem realizar testes de “loopback”. o
teste de loopback, que pode ser executado remotamente, conecta a saída de um IMP à sua entrada,
isolando efetivamente o IMP do resto da rede. Este tráfego gerou teste
através da interface e permitiu à BBN verificar o tráfego de retorno em relação ao de saída
tráfego gerado pelo IMP.
Os testes de loop foram extremamente importantes; eles forneceram uma maneira de isolar as fontes de problemas.
Por um processo de eliminação, dando laços em um componente ou outro, a BBN poderia determinar
se o problema está nas linhas telefônicas, nos modems ou no próprio IMP. Se testar o tráfego
completou o loop intacto e sem erros, então o problema era quase certo em alguns
parte externa de um circuito - provavelmente nas linhas da companhia telefônica ou nos modems.
E os testes de loopback foram realizados com freqüência suficiente para que dois dos caras do IMP, Ben
Barker e Marty Thrope tornaram-se especialistas em assobiar na linha exatamente à direita
frequência para imitar os sinais que a companhia telefônica usou para testar as linhas.
Da sala de informática PDP-1 na Moulton Street, onde a rede da BBN está monitorando
equipamento foi instalado, o IMP Guys poderia dizer quando um circuito telefônico em qualquer lugar do
rede agiu. Eles podiam ver, pela qualidade das mensagens e pacotes que cruzam um
circuito, quando a qualidade do sinal estava sendo degradada, quando a linha estava perdendo bits,
quando estava introduzindo ruído, ou desaparecendo completamente. Quando o problema estava no telefone
linhas ou modems, então a companhia telefônica seria chamada para consertá-lo.
Os engenheiros da BBN aproveitaram as oportunidades de assustar o conserto da companhia telefônica
pessoas com sua capacidade de detectar e, eventualmente, prever problemas de linha à distância. De
examinando os dados, a BBN às vezes podia prever que uma linha estava para cair. o
Os escritórios de reparos da companhia telefônica nunca tinham ouvido falar de tal coisa e não aceitaram bem.
Quando os testes de loopback da BBN determinaram que havia problemas em uma linha, digamos, entre Menlo
Park (Stanford) e Santa Bárbara, um dos engenheiros do Heart em Cambridge, pegou o
telefone e ligou para Pacific Bell. ”Você está tendo problemas com sua linha entre Menlo Park
e Santa Bárbara ”, dizia.
"Você está ligando de Menlo Park ou Santa Bárbara?" o técnico da Pacific Bell iria
pergunte.
”Estou em Cambridge, Massachusetts.”
"Okay, certo."
Eventualmente, quando as ligações da BBN se provaram absolutamente corretas, a companhia telefônica começou
enviar equipes de reparos para consertar qualquer problema que a BBN tivesse detectado.

Página 105
Devido à dificuldade de detectar remotamente falhas de componentes na área geográfica
sistema disperso, o software de rede ficou mais complicado com o tempo. Entre o
suposições básicas feitas pelo IMP Guys era que a maneira mais eficaz de detectar
falhas foi através de um mecanismo de relatório ativo. Eles projetaram seu sistema para que
cada IMP compilava periodicamente um relatório sobre o status de seu ambiente local - número
de pacotes manipulados pelo IMP, taxas de erro nos links e similares - e encaminhou o
relatar através da rede para um centro de operações de rede centralizado que a BBN estabeleceu
em Cambridge. O centro iria então integrar os relatórios de todos os IMPs e construir
uma imagem global do estado atual mais provável da rede.
Nos primeiros meses, eles o chamaram de Centro de Controle de Rede. Mas na verdade foi realmente
nada mais do que um pequeno canto de um escritório na BBN. E o monitoramento da rede
era informal. O teletipo de registro foi conectado através da própria rede a todos os IMPs
no campo, e o terminal estalava, recebendo relatórios de cada IMP a cada quinze
minutos. De vez em quando, por curiosidade, alguém da BBN entrava e olhava
no log que estava saindo da máquina, só para ver o que estava acontecendo com o
rede. Ninguém tinha responsabilidade específica pela varredura do log. Ninguém verificado, fora
do horário comercial, então às vezes havia longos períodos em que as falhas de linha
não detectado, especialmente à noite. Mas se alguém em um site de rede realmente ligou para dizer,
“Ei, parece que há um problema”, então um dos caras do IMP iria imediatamente
olhe o registro do teletipo e tente descobrir o que estava acontecendo.
A equipe de Heart projetou os IMPs para funcionar sem supervisão tanto quanto possível, concedendo
os IMPs podem reiniciar sozinhos após uma falha de energia ou acidente. o
“Cronômetro de vigilância” foi o componente crucial que acionou medidas autocorretivas em
os IMPs. A rede como um todo "olhava muito para o umbigo o tempo todo", disse
Coração ", enviando pequenas mensagens dizendo-nos como estava se sentindo e nos dizendo o que
tipo de coisas estavam acontecendo onde, portanto, poderíamos de fato iniciar o trabalho ”, se necessário.
Nem tudo pode ser diagnosticado ou restaurado à ordem de funcionamento remotamente. Havia
momentos em que as pessoas na BBN notaram que um IMP tinha acabado de parar de funcionar, tornando-o
necessário para recarregar o software. Primeiro, a BBN teria que alertar alguém do outro lado
da linha e peça a ele para reinserir uma fita de papel ou acionar alguns interruptores e apertar o botão de reset
botão. Então, da Moulton Street, tocariam a campainha do "mordomo", o telefone
caixa de distribuição conectada a cada IMP, na esperança de alcançar alguém. Uma vez que os IMPs foram
instalado em grandes centros de computação altamente ativos, não havia como dizer quem poderia responder.
Era quase como ligar para um telefone público. Você pode contratar um especialista ou um zelador
ou algum estudante de graduação que não tinha ideia do que estava acontecendo. Independentemente de
quem atendesse o telefone, os técnicos da BBN tentariam falar com essa pessoa
todas as correções necessárias. Mesmo as pessoas nos sites que realmente sabiam uma ou duas coisas
sobre os computadores foram solicitados, da mesma forma, a seguir as instruções estritas da BBN.
“Lembro-me de passar de meia hora a uma hora ocasional com o telefone colado
meu ouvido ”, lembrou Cerf, cuja deficiência auditiva não o tornou amigo do telefone em
em primeiro lugar, “seguindo as instruções de alguém da BBN dizendo: 'Aperte este botão.
Vire essa coisa. Digite essas coisas para tentar descobrir o que deu errado e obter o
coisa funcionando novamente. ” Em um caderno, a BBN manteve uma lista detalhada de sites, locais exatos para

Página 106
cada máquina e contatos em vários locais, que em pelo menos um caso incluiu
o guarda do prédio como pessoa-recurso de último recurso.
Assim que o IMP Número Cinco foi instalado na BBN, a equipe intensificou seus testes
programa para medir o desempenho da rede e suas limitações. Todos estavam interessados em
saber como a rede funcionaria bem em vários cenários e se
suportaria cargas extremamente pesadas. Mas os engenheiros da BBN não estavam acima
ficando irritados quando Len Kleinrock e outros da rede da UCLA
O Measurement Center tentaria deliberadamente travar a rede. Os testes descobriram
bugs e correções inspiradas. Ainda assim, uma coisa era óbvia: sob tráfego moderado, o
a rede era tão rápida quanto a BBN previra que seria. BBN reportado a Roberts
que a nova rede poderia ser descrita como um "sistema de comunicações tenso". Isso é,
as mensagens que entram na rede não mostraram tendência a se perder. “Observamos que
as mensagens não vagam pela rede, mesmo com grandes cargas de tráfego ”, escreveu a equipe da BBN em
um de seus relatórios técnicos periódicos.
No verão de 1970, as máquinas número seis, sete, oito e nove foram extraídas de
Honeywell e agora operavam no MIT, RAND, System Development Corp. e
Harvard. A AT&T substituiu a primeira ligação cross-country por uma nova linha de 50 kilobit
ligando a BBN à RAND. Um segundo link cross-country conectou o MIT e a Universidade
de Utah. A rede ARPA estava crescendo a uma taxa de cerca de um nó por mês.
Um dia em 1970, um caminhão de entrega da Honeywell parou na Moulton Street
dock de carregamento e começou a fazer backup para descarregar outro novo computador 516. Alertado para o
chegada do caminhão, Severo Ornstein correu para fora da porta, fez uma rápida inspeção do
máquina enquanto ainda estava no caminhão, e acenou ruidosamente para o motorista sair. Coração, quem tinha
saiu de seu escritório para ver o que estava acontecendo, ficou olhando, surpreso,
como Ornstein disse ao motorista para virar e dirigir a máquina de volta para Honeywell; ele
estava rejeitando a entrega.
Ornstein estava farto de entregas atrasadas e equipamento incompleto e defeituoso. Enviando o
O caminhão de volta causou um alvoroço na Honeywell, disse ele. Mas pela primeira vez a atenção deles foi
focado. A BBN não estava aceitando outro Honeywell 516 até que algumas coisas fossem
endireitou. As dificuldades foram crescendo. Para a equipe de Heart, o relacionamento
com a Honeywell parecia mais uma luta de braço do que uma parceria. "Eles mantiveram
despachando máquinas que continham os mesmos velhos erros ”, lembra Ornstein. Depois de
incidente na doca de carregamento, ele começou a ir regularmente à Honeywell para inspecionar cada novo
máquina antes de ser enviada para a BBN.
Em pouco tempo, a Honeywell reuniu sua equipe de construção de IMP e estava produzindo
máquinas aceitáveis. IMPs foram entregues ao Lincoln Laboratory e Stanford, e por
o final do ano Carnegie-Mellon University e Case Western Reserve University
também foram conectados à rede. Nesse ponto, centenas de pequenas revisões haviam sido
escrito no software IMP. O hardware foi ajustado e adaptado. O telefone
A empresa, fazendo a sua parte, passou a ter quatorze links de 50 kilobit instalados na rede.
As ferramentas de diagnóstico remoto e gerenciamento de rede da BBN também estavam em constante

Página 107
melhoria. ARPA estendeu o contrato da BBN para continuar produzindo IMPs e executar o
centro de controle, e tudo estava clicando.
O nível de atividade da central de monitoramento da BBN aumentou. Com a rede
expansão constante, os relatórios de diagnóstico que chegavam à BBN estavam começando a inchar e
tornar-se pesado. Os IMP Guys estavam tendo dificuldade em manter o controle dos dados,
digitalizar a impressão do registro do teletipo e localizar sinais de problemas. Eles precisavam de um
governanta. Então, eles decidiram conectar uma máquina sobressalente, o primeiro protótipo IMP da BBN,
para a Rede ARPA, onde funcionaria como uma máquina host atrás do
BBN IMP. Esta nova máquina host seria usada para ajudar a processar o status da rede
relatórios. Os programadores da BBN escreveram um novo código para compilar resumos de hora em hora do
mensagens de status IMP mais frequentes que agora estavam se acumulando na taxa de um por
minuto de cada IMP. A suposição operacional do código era que nenhuma notícia era uma má notícia:
Se o Centro de Controle de Rede não conseguiu receber uma mensagem de status de um IMP por três
minutos, a leitura do status da rede indicaria que aquele IMP estava morto. Isso e
outras melhorias tornaram mais fácil detectar mudanças de status importantes na rede.
Era novembro de 1970 quando Alex McKenzie retornou à BBN após uma breve licença de
ausência. Ele e sua esposa passaram seis meses acampando na Europa. Em pouco tempo ele
se foi, o projeto de rede avançou dramaticamente. Resolvido em Cambridge
agora, McKenzie percebeu a importância para a BBN de gerenciar a rede como se fosse um
utilidade elétrica. Isso significava que uma reordenação de certas suposições fundamentais teria
ocorrer. Chegou a hora de mudar a rede de experimental para operacional
modo, ele raciocinou. E McKenzie começou a pressionar essa opinião para todos os seus colegas.
Organizado e meticuloso, McKenzie parecia o candidato perfeito para assumir
O Centro de Controle de Rede da BBN e Heart o nomearam para a tarefa.
Outras mudanças culturais estavam no vento em torno da BBN. A sensibilidade de McKenzie sobre o
projeto de rede estava em sintonia com uma empresa mais orientada para os negócios em geral. A própria BBN
estava crescendo. Um ou dois anos depois de McKenzie fazer seu esforço para administrar o
rede como um utilitário, a BBN comprou a Lavanderia Superior no extremo movimentado de Moulton
Street e demoli-lo para dar espaço a um novo edifício-sede de sete andares.
Eventualmente, o Centro de Controle de Rede e o resto da divisão do Heart foram transferidos para o
quinto andar dos novos aposentos. Arquitetonicamente, o estilo do impressionante novo edifício
sugeria sutilmente uma fortaleza elegante. Construído no auge do movimento anti-guerra no início
1970, refletiu a consciência corporativa emergente da BBN sobre antiestablishment
ameaças a empresas envolvidas na contratação do Departamento de Defesa dos EUA. O prédio tinha
sem janelas no andar térreo, onde ficava um grande centro de informática. Ele também tinha um
garagem subterrânea projetada para que o próprio edifício ficasse para trás, cercado por um
fosso substancial sem água, permitindo o acesso à porta da frente apenas por uma curta ponte para pedestres.
No quinto andar, o Centro de Controle de Rede ocupava uma grande sala com uma grande placa
janelas de vidro voltadas para o norte, para as colinas além de Cambridge. Equipe do coração, numerando
cerca de trinta pessoas, espalhadas em escritórios modernos e laboratórios bem equipados
o chão. A divisão do Heart tinha o único andar do prédio com sua própria pequena cozinha
escondido em um corredor central, um pedido especial da Heart, que pretendia equipá-lo com um
máquina de café expresso italiana com qualidade de restaurante algum dia.

Página 108
Dominando uma grande parede do centro de controle estava um mapa lógico da rede.
Construído com peças magnéticas móveis em um fundo de metal, o mapa era uma fiação
diagrama mostrando todos os IMPs, computadores host e links - indicados por quadrado, redondo,
e marcadores triangulares. Códigos de cores e ponteiros indicavam o status de cada IMP, nó,
e link. À primeira vista, os operadores podiam dizer quais linhas ou IMPs estavam inativos e onde
o tráfego estava sendo direcionado para os pontos problemáticos. Além de informações críticas, um
piada ocasional ou desenho animado pode ser pregado com um ímã como se o mapa de controle fosse
uma porta grande da geladeira.
Uma das principais tarefas do NCC era emitir atualizações de software e recarregar o IMP
programas operacionais quando necessário. Os operadores usaram um esquema habilmente cooperativo
pelo qual cada IMP baixou o software de um vizinho. Todas as terças-feiras a partir das 7:00
às 9h00, a BBN reservou a rede para distribuição de software, teste de rede,
e manutenção. Dentro dessas duas horas, os operadores do NCC poderiam ter todos os IMP em
a rede executando uma nova versão de software. Todas as novas versões dos códigos operacionais IMP
foram eventualmente distribuídos desta forma. O processo de propagação eletrônica começaria
em Cambridge, um novo programa de software foi baixado para um site próximo, que por sua vez
faria o download do pacote de software para outro vizinho, ao comando do
operadores.
O método também tinha potencial restaurador. Se um programa operacional de IMP foi encontrado para
ser destruído, o IMP pode enviar uma solicitação de recarregamento do programa para um IMP vizinho.
O IMP respondente enviaria de volta uma cópia de seu próprio programa.

Afinação
Outras grandes mudanças também ocorreram no segundo ano da rede. BBN e ARPA
decidiu que o Honeywell 516 robusto, refletindo muita preocupação com a confiabilidade,
foi uma expressão de exagero. Também era caro. O 516 custou cerca de 20 por cento
mais do que uma versão mais recente do computador, o Honeywell 316, que não estava disponível
em forma robusta. Ben Barker, que permaneceu intimamente envolvido na manutenção e
solucionar problemas de mais de uma dúzia de IMPs agora em campo, na verdade, concluiu que o
armários no 516 reforçado era uma fonte de confiabilidade reduzida , porque dificultava
o que deveria ter sido tarefas de manutenção de rotina facilmente realizadas.
A Honeywell estava sob contrato para lidar com a manutenção de rotina. Mas aqui, também, eles estavam
lento em chegar à visão emergente da BBN - o modelo de utilidade de McKenzie - de como um
rede de computadores deve operar. Houve períodos em que o tempo de inatividade do
IMPs em média tanto quanto 3 ou 4 por cento em uma base mensal. Se uma empresa de eletricidade ou o
sistema telefônico ficava fora do ar na maior parte do tempo - um dia de cada mês - é
desempenho seria considerado péssimo. Mas Honeywell teve que ser persuadida a
imaginando onde a BBN e a ARPA queriam chegar com a rede.
“Lembro-me de uma grande reunião quando repassamos os números com os caras da
Honeywell ”, lembrou Barker. “Os caras da Honeywell disseram: 'Espere um minuto. Você está dizendo
essas máquinas ficam inativas entre meia hora e uma hora por dia? Isso é tipo, uh, três

Página 109
porcentagem de inatividade. Quer dizer, essas máquinas ficam noventa e sete por cento do tempo em
24 horas por dia. Como você está fazendo isso!?'"
O tempo de inatividade de 3% que surpreendeu a Honeywell foi, nas palavras da BBN, “prolongado
síndrome de falha de hardware. ” Os procedimentos normais de ligar e trabalhar com
Os engenheiros de campo da Honeywell não resolveram várias dessas "falhas persistentes",
relatou BBN. Eles estavam particularmente preocupados com os problemas em vários locais do
Washington, DC, área.
Frustrado por problemas de manutenção recorrentes, Roberts ameaçou, vagamente,
cancelar o contrato da BBN. Barker finalmente foi ao Heart e propôs deixá-lo colocar
junto com uma equipe de manutenção dirigida pela BBN, com uma equipe de campo adequada para
manutenção e um “bombeiro” perito móvel. Mas McKenzie se opôs veementemente à ideia,
não porque ele estava satisfeito com a forma como as coisas estavam indo com a Honeywell, mas porque ele
temia que Barker só piorasse as coisas. Era o estilo pessoal desleixado de Barker
ao que McKenzie, um homem fastidioso, estava reagindo; ele disse que o escritório de Barker parecia um
caminhão de lixo foi apoiado nele e esvaziado de seu conteúdo, e de fato era um
imagem adequada. Poucos contestariam que o escritório de Barker estava, em um dia bom, uma bagunça total.
Nem contestariam a agudeza de seu conhecimento técnico e habilidades. Então, no comércio,
Barker fez um esforço concentrado para manter seu escritório limpo, e Heart entregou-lhe o trabalho de
construir e dirigir uma equipe de manutenção de crack.
Manutenção à parte, a própria confiança de Heart sobre a confiabilidade intrínseca da rede tinha
crescido no primeiro ano. Ele tinha visto os IMPs funcionando com sucesso no campo. Seu
equipe havia cumprido seus testes iniciais. Ele também ficou um pouco mais relaxado depois de um tempo sobre o
confiabilidade dos investigadores locais e alunos de pós-graduação. Como conseqüência, o
última versão reforçada do Honeywell 516 rolou para a Moulton Street no final
de 1970 e finalmente foi despachado como IMP Número Quinze, com destino a Burroughs
Corporation em Paoli, Pensilvânia. Quase ao mesmo tempo, a Universidade de Illinois em
Urbana-Champaign recebeu a máquina Número Doze, que estava atrasada.
Até agora, a BBN tinha recebido o sinal verde da ARPA para mudar para outra engenharia intensiva
esforço: projetar um IMP com base em 316 protótipo. Honeywell prometeu entrega do
máquina no início de 1971. A transição para o 316 IMP mais leve foi apenas parte de um
desenvolvimento de mudança estrutural na rede ARPA.
Durante meses, a equipe do Heart e Roberts discutiram a possibilidade de conectar
muitos novos usuários na rede sem passar por um computador host. Parecia que eles podiam
possibilitar o logon na rede, alcançar um host distante e controlar remotamente
recursos através de um dispositivo de terminal simples - um teletipo ou um CRT com um teclado -
diretamente conectado a um IMP. O novo esquema eliminaria a necessidade de um host
computador entre cada usuário e a sub-rede IMP. Tudo que você precisa para fazer funcionar é
ser um terminal burro conectado a um IMP. Isso abriria muitos novos pontos de acesso.
Se pudesse ser resolvido tecnicamente, centenas ou mesmo milhares de usuários mais poderiam
obter acesso à rede sem proximidade física a um computador host. Então o
rede não seria mais apenas um experimento para os cientistas da computação hardcore com
contas de mainframe, mas aberto a toda uma panóplia de usuários mais casuais - oficiais militares,

Página 110
burocratas do governo, administradores universitários, estudantes - que seriam trazidos para
a comunidade de rede. Isso deixaria o mundo um passo mais perto de perceber
A visão de Licklider do computador como um facilitador da comunicação e do ser humano
interação.
Mas nem os IMPs originais nem os novos 316 IMPs podiam suportar mais de quatro hosts
interfaces. Nenhuma das máquinas pode acomodar uma conexão de terminal. Para fazer o novo
conceito viável, a equipe do Heart teria que construir uma nova interface que pudesse lidar
dezenas de linhas de terminais alimentando o IMP e a rede. Sentindo o valor de ir
nesta nova direção, a BBN lançou um esforço acelerado para projetar um controlador de terminal
que poderia gerenciar o tráfego gerado por um grande número de dispositivos terminais conectados
diretamente ou por meio de linhas dial-up. O novo dispositivo foi chamado simplesmente de Terminal IMP, ou
DICA.
Em seis meses, a BBN e a Honeywell concluíram o projeto e a construção de dois
novas máquinas protótipo baseadas no 316. O primeiro era um IMP básico, o outro um TIP que
incluiu um controlador multilinha capaz de gerenciar o tráfego de sinal de até sessenta e três
terminais de uma vez. Todos os dispositivos terminais ligados a um TIP seriam endereçáveis como se
pertencentes a um único host na rede. Nos bastidores, onde a BBN fazia as entregas,
A equipe de Heart havia criado uma pequena célula de teste para depurar as máquinas que chegavam; o último do
516 máquinas estavam chegando em um ritmo bastante constante a cada quatro semanas, e
a qualquer momento, pode haver duas ou três máquinas, às vezes mais, conectadas para testar
seu desempenho e simular o tráfego de rede. Os primeiros quatro resultados finais foram
programado para chegar à BBN no final do verão de 1971.
Tudo parecia estar funcionando de acordo com o projeto. BBN começou a explorar a gama
de dispositivos terminais que podem estar conectados à rede. As opções variaram de
visores gráficos CRT, para impressoras lentas e rápidas, para visores alfanuméricos, e
Terminais semelhantes a teletipos. A equipe também estava considerando como vincular aos leitores de cartão,
gravadores de fita magnética e outros dispositivos periféricos.
Ainda mais testes de algoritmo de roteamento, testes de rendimento, testes de esquemas de controle de fluxo e
testes de diagnóstico remoto continuaram a ocupar a equipe da BBN diariamente, semana após semana e
semana fora, levando a melhorias constantes em sua tecnologia de comutação de pacotes.
O Centro de Controle de Rede continuou se expandindo com a rede. Pressão para manter o
rede cresceu. Tornou-se uma parte constante do contrato da ARPA com a empresa, e logo o
O centro funcionava 24 horas por dia, sete dias por semana. Em um ponto, o NCC atualizou
alguns equipamentos e adicionou um discador automático ao sistema. O discador automático era
destina-se especificamente a monitorar a condição dos modems espalhados pela rede.
Havia dezenas de modems tratando do tráfego de dados para os TIPs. A BBN
os solucionadores de problemas fizeram com que o discador automático executasse um teste simples: O discador foi
programado para ligar
cada modem uma vez por dia e ouça uma resposta. Se um modem atendeu e assobiou
costas, seus sinais vitais foram considerados normais. Qualquer modem não está respondendo ou sinalizando
back indevidamente apareceu em um relatório de problema.
A certa altura, a equipe da NCC detectou um modem específico que parecia ser
com defeito sempre que o discador automático executava sua verificação. Alguém sugeriu fazer uma chamada

Página 111
através do discador automático para o modem problemático, enquanto um técnico ouvia; possivelmente
ele poderia diagnosticar o retorno do sinal. Então ele fez a ligação, ouviu o modem
para atender e ouvi uma voz irritada do outro lado da linha. Antes de bater
o receptor, a voz é conhecida em inúmeras recontagens por ter dito: “Ei, Martha, é
aquela noz com o apito de novo! ”
Controle de congestionamento, um dos problemas problemáticos demonstrados pela Kahn's
experimentos, foram atacados e melhorados. A BBN havia redesenhado o esquema para
reserve espaço suficiente nos buffers de memória IMP para remontagem de pacotes de entrada. UMA
quantidade específica de espaço de remontagem para cada mensagem seria reservada em um destino
IMP antes que a mensagem pudesse entrar na rede. O IMP de envio seria
verificar, e se informado de que não havia espaço suficiente disponível no IMP de destino
buffers, o RFNM (solicitação da próxima mensagem) foi atrasado. A solução não foi
ao contrário do tratamento que muitos passageiros de linha aérea experimentam quando um avião não pode
desligado porque o mau tempo no aeroporto de destino impede o avião de pousar. o
passageiro senta no chão e espera por uma vaga no destino. Em simulações,
o novo esquema conseguiu evitar a inserção de mais tráfego na rede
do que o destino IMP poderia lidar.
Se o desenvolvimento da rede fosse prosseguir em um ritmo constante agora, uma coordenação mais próxima
seria necessário entre o esforço da BBN para introduzir o Terminal IMP e o
Esforço do Network Working Group para desenvolver protocolos. Então, a equipe do Heart decidiu
envolver-se muito mais profundamente no trabalho do Grupo de Trabalho da Rede. Em meados
1971, a BBN se injetou nos comitês do NWG (McKenzie era a BBN
representante) trabalhando no protocolo host-a-host, no protocolo de transferência de arquivos e no
Protocolo Telnet.
Embora tenha demorado mais de um ano para funcionar, o protocolo Telnet era relativamente simples
procedimento. Era um mecanismo mínimo que permitia a comunicação básica entre dois
máquinas host. Os primeiros quatro nós conectaram quatro máquinas diferentes, enquanto outros
sites de hospedagem ofereceram uma nova mistura de computadores incompatíveis, desde o DEC
PDP-10 para grandes IBMs, para Honeywell e máquinas Xerox. Telnet foi concebido para
para superar diferenças simples, como estabelecer uma conexão e determinar o que
tipo de conjunto de caracteres a ser usado. Foram os TIPs e o Telnet juntos que abriram o caminho para
expansão da rede.
As transferências de arquivos foram o próximo desafio. Por alguns anos, meia dúzia de pesquisadores
está tentando chegar a um protocolo de transferência de arquivos aceitável, ou FTP. A transferência de arquivos
protocolo especificou a formatação para arquivos de dados negociados na rede. Transferindo arquivos
foi uma espécie de força vital para a rede. As transferências de arquivos eram o equivalente digital de
respiração - inspiração de dados, expiração de dados, ad infinitum. FTP tornou possível compartilhar arquivos
entre máquinas. Mover arquivos pode parecer simples, mas as diferenças entre
máquinas tornavam tudo menos. FTP foi o primeiro aplicativo a permitir que duas máquinas
coopere como pares em vez de tratar um como um terminal para o outro. Trazendo isso
funcionalidade para a rede dependia do grupo de trabalho de FTP chegando com um
produto final de trabalho.

Página 112
O presidente do grupo, Abhay Bhushan, um estudante de pós-graduação do MIT e sistemas
arquiteto, era um especialista em Multics, um sistema operacional ambicioso e complexo. Bhushan
estudou problemas de multitarefa em um único computador. O próximo passo foi
eventualmente, transferir blocos de dados em um sistema multicomputador como a rede ARPA.
Nos seis meses que passou trabalhando no protocolo de transferência de arquivos, a equipe costumava se encontrar
pessoalmente
para enfrentar em sessões regulares do Grupo de Trabalho da Rede. Mas também é usado com frequência
teleconferência por computador em tempo real. Todos os membros da equipe se conectariam ao mesmo tempo, a
partir de
Palo Alto e Cambridge e LA e Salt Lake, e por uma ou duas horas seguidas
trocar comentários para frente e para trás. Conversar por meio de teclados e terminais era menos
espontâneo do que falando, mas Bhushan acreditava que forçava clareza em seus pensamentos. isto
também teve a vantagem de criar um registro de seu trabalho. No início de julho de 1972, a final
toques foram colocados no FTP, e Jon Postel, agora o editor e distribuidor dos Pedidos
Para comentários, lançou como RFC 354.

Exibindo
O único problema real com esta rede agora era o carregamento. Ou seja, não havia muito disso.
No início, o tráfego estava leve porque os protocolos estavam atrasados. Agora, em um dia normal, o
os canais estavam praticamente vazios. No outono de 1971, a rede carregava em média apenas
675.000 pacotes por dia, pouco mais de 2 por cento de sua capacidade de 30 milhões de pacotes
um dia. O UCLA Network Measurement Center continuou gerando tráfego de teste para
sondar os pontos fracos de todos os algoritmos de rede. Mas não havia o suficiente natural
tráfego na rede para realmente ultrapassar os limites dos esquemas de roteamento e anticongestão.
Houve alguns usos iniciais interessantes. Os programadores da SRI estavam usando o PDP-10 de Utah
compilador em preparação para a instalação de seu próprio PDP-10, e eles geraram a maioria
tráfego real. Jon Postel, da UCLA, estava usando a rede para executar o Sistema oNLine da SRI.
Bob Metcalfe, um estudante de pós-graduação de Harvard que trabalha no MIT, e um amigo, Danny Cohen,
que ensinou em Harvard, fez um dos primeiros experimentos mais empolgantes da rede.
Metcalfe e Cohen usaram o PDP-10 de Harvard para simular o pouso de um porta-aviões e
em seguida, exibiu a imagem em um terminal gráfico no MIT. Os gráficos foram processados em
MIT, e os resultados (a vista da cabine de comando da transportadora) foram enviados de volta ao
Rede ARPA para o PDP-1 em Harvard, que também os exibiu. O experimento
demonstrou que um programa pode ser movido pela rede em alta velocidade a ponto de
tempo real aproximado. Metcalfe e outros redigiram um RFC para anunciar o triunfo
e intitulou-o "Momentos históricos na rede".
Outros não tiveram tanto sucesso. Houve uma tentativa inicial de inventar algo chamado de
serviço de reconfiguração de dados; foi uma tentativa fracassada de escrever uma linguagem de programação que
interpretaria arquivos incompatíveis em computadores diferentes.
A rede ARPA, no entanto, era virtualmente desconhecida em todos os lugares, exceto no interior do sancta
da comunidade de pesquisa em computação. E apenas por uma pequena parte do computador
comunidade, cujo interesse de pesquisa era networking, era a rede ARPA desenvolvendo
em uma ferramenta utilizável. Para eles, foi um experimento fantástico, mas você tinha que estar envolvido

Página 113
coisas como teoria das filas ou teoria da comunicação para apreciá-la. Se, por outro
lado, seu trabalho foi em inteligência artificial ou robótica ou computação gráfica ou quase
qualquer outra coisa que a comunidade estava investigando, a utilidade deste grande transcontinental
sistema de comutação de pacotes ainda não tinha sido implementado. Ninguém apareceu com um útil
demonstração de compartilhamento de recursos; os protocolos para fazê-lo funcionar nem mesmo estavam em vigor.
A rede ARPA era uma crescente rede de links e nós, e era isso - como um
sistema rodoviário sem carros.
No entanto, ostensivamente em toda a comunidade, havia ricos recursos a serem compartilhados.
Carnegie-Mellon tinha um departamento de inteligência artificial de primeira linha e aplicativos exclusivos
atendente a ele. Stanford tinha um grupo extraordinário de robótica. Teoricamente, quase
a cada site, algum recurso exclusivo poderia ser contribuído para a rede.
Se a rede algum dia se tornasse algo mais do que um ambiente de teste para o ambiente artificial
tráfego gerado pelas Medições de Rede e Centros de Controle de Rede, palavra de
seu potencial precisava se espalhar. Larry Roberts sabia que era hora de uma demonstração pública.
Roberts fez parte do comitê de programa da primeira Conferência Internacional sobre Computação
Comunicação, a ser realizada em Washington em outubro de 1972. Ele circulou a data e
ligou para Bob Kahn, que ainda estava na BBN, e pediu-lhe que organizasse uma demonstração do
Rede ARPA como a única exposição na reunião. Faltava cerca de um ano para a conferência.
Roberts pediu a Kahn para começar a planejar imediatamente. Kahn na verdade já tinha sido
planejando deixar a BBN e trabalhar para Roberts na ARPA. Mas os dois homens decidiram que seria
Seria uma boa ideia Kahn ficar na BBN por um tempo para planejar a manifestação.
O primeiro movimento de Kahn foi recrutar Al Vezza, do Projeto MAC do MIT, para auxiliá-lo.
sempre causou uma boa impressão. Ele era sociável e impecavelmente articulado; ele tem um
mente científica apurada e instintos administrativos de primeira linha. Entre os dois homens ali
provavelmente não era um projeto de computador importante na comunidade de pesquisa dos EUA que eles não
conheciam
sobre ou um jogador-chave que eles não conseguiram persuadir a se juntar a eles.
Em meados de 1971, Kahn e Vezza convocaram um pequeno grupo de cerca de oito investigadores principais
de todo o país para vir a uma reunião na Tech Square do MIT em Cambridge. Eles
apresentou a ideia de uma demonstração altamente acessível e envolvente da comunidade
recursos mais interessantes - acessíveis pela rede. Vezza sabia que teria que ser
uma demonstração interativa ao vivo se fosse ter algum impacto. Alguém no
reunião argumentou vigorosamente a favor de uma apresentação em vídeo, para evitar
o computador trava durante o show. Vezza estava incrédulo e argumentou com a mesma veemência
que tudo, menos uma demonstração prática ao vivo usando equipamentos e software reais
sinalizaria incerteza e falha potencial para todo o experimento da rede ARPA.
Tinha que ser feito em tempo real, tinha que ser algo que pudesse ser tocado e controlado
por qualquer um sentado em um terminal. Foi uma aposta. Ainda não tinha muito
experiência operacional com os protocolos Telnet e Transferência de Arquivos, que os participantes
teria que empregar. E isso aumentava o risco de que a demonstração fracassasse. Mas
se a demonstração fosse bem-sucedida, provaria que a rede não era apenas real, mas útil.
Nos nove meses seguintes, Kahn e Vezza viajaram pelo país com o orçamento de Roberts.
“Havia muitos becos sem saída”, lembra Vezza. Eles se reuniram com dezenas de fornecedores no

Página 114
indústria de computadores, pedindo a cada um para participar, trazendo seus próprios terminais para o
Washington Hilton, onde a reunião seria realizada e onde um TIP se conectaria
para a rede ARPA. Roberts estava providenciando para que a AT&T trouxesse duas unidades de 50 kilobits
linhas para o hotel. O plano era fazer demonstrações no maior número de máquinas possível,
conectado a tantos sites quanto possível. Os organizadores convidariam os participantes da conferência para
entre, sente-se, faça logon e use os recursos da rede.
Dezenas de reuniões aconteceram nos vários sites da rede para projetar cenários interessantes.
Equipes de alunos de pós-graduação e pesquisadores principais se inscreveram. E quase tão logo
eles fizeram, eles começaram a sentir um certo pânico. Para conseguir isso, eles teriam que intensificar
seus esforços para finalizar as ferramentas e protocolos de rede inacabados. Roberts, sempre
corretamente, previu a probabilidade de que a programação de um público altamente visível
demonstração de outubro de 1972 aumentaria a pressão sobre a comunidade para se mobilizar e
certifique-se de que a rede esteja funcionando perfeitamente até essa data. Kahn também
reconheceu que a demonstração foi "criada para forçar a utilidade da rede a
ocorrer aos usuários finais. ”
No outono de 1971, a BBN tinha um protótipo TIP rodando em 50 Moulton Street. Dois outros
Os TIPs estavam operacionais em outras partes da rede, neste momento consistindo em apenas dezenove
nós. Os TIPs, baseados no Honeywell 316, eram totalmente compatíveis com todos os
os 516s mais antigos. No início de 1972, vários 316 IMPs e TIPs adicionais foram instalados
e a parte central da rede entre as costas leste e oeste estava começando a
preencher. Em agosto de 1972, uma terceira linha de cross-country foi adicionada. Além de IMPs
espalhados pelo centro do país, agora havia grupos de IMPs em quatro
áreas geográficas: Boston; Washington DC; São Francisco; e Los Angeles. Enquanto o
A demonstração da ICCC se aproximou, havia vinte e nove nós no que agora estava sendo
amplamente conhecido como ARPANETor, mais frequentemente, apenas Rede.
E as pessoas nos sites estavam lutando loucamente. Dezenas de grandes contribuidores de
em todas as comunidades acadêmicas e de pesquisa dos Estados Unidos se envolveram. Intensivo
esforços estavam em andamento para depurar aplicativos e colocar os computadores host em funcionamento em
hora da demonstração pública. Cada fabricante de terminal foi convidado a provar
seu equipamento poderia funcionar com a ARPANET: Eles estavam fazendo fila para mostrar mais de
quarenta terminais de computador diferentes na demonstração. Vezza negociou com um local
vendedor na área de Washington, DC, que concordou em emprestar uma grande seção de antiestático,
piso elevado da sala de informática para instalação na sala de reuniões do Hilton, onde
o TIP e os terminais seriam localizados. AT&T prometeu que iria passar com o
link de dados. Instalar tal circuito em qualquer lugar em menos de seis meses não foi nada pequeno
problema, e certamente não foi um problema para a AT&T ter essa linha no Hilton como
o ICCC abordou.
Vários dias antes da reunião, o equipamento de rede e as pessoas começaram a chegar
o hotel. Kahn e Vezza haviam elaborado uma planta baixa. O TIP foi localizado em um
seção de piso elevado no centro da grande sala de reuniões. Em torno do perímetro
da sala seriam dezenas de terminais, virtualmente não havia dois iguais. Levaria um
alguns dias para que todo o equipamento seja movido para o lugar, conectado, ligado e
verificado. Em questão de horas, a sala era um emaranhado de fios e pessoas

Página 115
falando jabber técnico. Os técnicos estavam esticando cabos por toda parte. Membros de
A equipe do Heart estava por toda parte, ferramentas em mãos, profundamente engajados em ajudar os vários
fabricantes de terminais modificam os cabos de conexão em cada um dos vários terminais
dispositivos, de modo que cada um pudesse ser conectado ao TIP. Horas foram gastas descascando fios,
religando os conectores, reconectando, testando e depurando.
Muitos dos participantes estavam trabalhando com febre. Muitos tinham feito as malas enquanto ainda
terminando seus projetos e vieram a Washington para dar os retoques finais. Foi o primeiro
vez que toda a comunidade apareceu em um lugar ao mesmo tempo. “Se alguém tivesse
jogou uma bomba no Washington Hilton, que teria destruído quase todos os
comunidade de rede nos EUA naquele ponto ”, observou Kahn. Sem mencionar o
comunidade internacional, até mesmo para Donald Davies, pai do termo "comutação de pacotes",
tinha vindo da Inglaterra para ver como tudo isso iria funcionar. “Foi simplesmente incrível
experiência ”, disse Vint Cerf. “Cortando e gritando e gritando e dizendo, 'Não,
não . . . você entendeu errado. 'Acertar todos os detalhes. ”
No final do sábado (a conferência foi aberta na segunda-feira), o BBN TIP era como um rei
em um trono de arame estendido para todos os cantos da sala. AT&T fez seu trabalho e virou
no momento certo com a linha certa. Domingo foi outro dia frenético de preparação,
mas agora o TIP estava em ação, então as pessoas estavam começando a executar programas e fazer seu
checkouts. Muitos não terminaram até o final da tarde de domingo, pouco antes de uma prévia
demonstração foi agendada para um grupo de VIPs - um círculo de congressistas de Washington,
Funcionários do Pentágono e outros. Por volta das seis horas da tarde, minutos antes do
portas deveriam abrir, Vezza estava perto do TIP quando Metcalfe disse, sem desmaiar
urgência em sua voz, "Estamos perdendo pacotes!"
Vezza lançou um olhar para McKenzie, que estava ali: “Alex, o que mudou?”
McKenzie alcançou a linha direta para Cambridge e gritou ao telefone: “Tire isso daqui!
Coloque para fora!"
O Centro de Controle de Rede estava observando e monitorando uma linha ligeiramente irregular em
a rede nos últimos dias. Eles pensaram que tinham resolvido o problema naquela tarde
e adicionou o circuito de volta à rede. Dentro de trinta segundos de McKenzie's
chamada, o link foi removido pelos operadores no NCC e os pacotes estavam fluindo
suavemente no TIP novamente.
A tecnologia de gerenciamento remoto da BBN nunca teve um momento tão bom.
Mais tarde naquela noite, Jon Postel estava na sala de exposição sentado diante de um teclado, conectado
para o anfitrião na UCLA. Sua equipe havia projetado uma demonstração em que alguém em
Washington poderia puxar um arquivo em Boston por meio do computador host em Los Angeles. A ideia
era para imprimir o arquivo na sala de exposições do Hilton. Quando Postel enviado
o arquivo para a impressora sentada ao lado dele, nada aconteceu. Ele olhou ao redor da sala.
Houve muitas outras demonstrações, uma das quais foi uma pequena tartaruga robótica construída em
MIT. A tartaruga foi construída para demonstrar como um programa de computador pode ser escrito para
dirigir o movimento de uma máquina. As crianças podem escrever seus próprios programas no LOGO
linguagem que dizia "vá para a esquerda, vá para a direita, vá para frente, volte para cima, mova-se para o lado", e
quando o

Página 116
programa fosse executado, a tartaruga faria isso. No momento, porém, a tartaruga estava
pulando para cima e para baixo, se contorcendo e sacudindo loucamente. Em vez de enviar o arquivo de Postel para
a impressora, o sistema havia acidentalmente enviado para o porto da tartaruga, e o robô obedientemente
ofereceu sua interpretação do que considerava ser comandos de movimento.
Como um estudante de graduação entusiasmado, Bob Metcalfe assumiu a tarefa de escrever um
livreto de acompanhamento das manifestações. Ele descreveu dezenove cenários para usar
theARPANET, listou recursos em vários sites e mostrou como fazer logon em um remoto
host, como obter acesso a um dos aplicativos e como controlar um programa ou
se envolver em algum tipo de comunicação interativa na rede. Eram vários
jogos de xadrez, um quiz interativo sobre a geografia da América do Sul, uma forma de leitura
o fio de notícias da Associated Press pela rede e muitos outros jogos, ferramentas e
demonstrações. Uma das aplicações mais práticas simulava um controle de tráfego aéreo
cenário em que a responsabilidade pelo monitoramento de um voo de avião é automaticamente entregue
fora de um computador para outro, representando diferentes centros de controle de tráfego aéreo, como o
avião atravessa fronteiras geográficas. O livro de cenários de Metcalfe foi projetado para caminhar
participantes, a maioria dos quais pouco conhecia da ARPANET, em cada demonstração
passo a passo.
Na manhã de segunda-feira, os cientistas da computação ARPANET aguardavam ansiosamente seu público.
Quando os participantes da conferência curiosos se aproximaram, os caras da rede, como as Testemunhas de Jeová
distribuindo cópias de A Sentinela, colocou o livro de cenários de Metcalfe em suas mãos
e os conduziu para a sala. Embora fosse possível seguir as instruções, a todos
mas o livro de cenários iniciado era bastante incompreensível, e era fácil de sujar
o sistema. Um homem sentou-se em frente a um terminal e digitou uma instrução de
o livro. Por alguma razão ou outra, o host que ele estava tentando alcançar não estava funcionando, ou
ele interpretou mal a coisa. A mensagem voltou: “HOST DEAD.”
"Oh meu Deus. Eu matei! " ele exclamou. Ele não tocaria em um terminal depois disso.
Outras coisas engraçadas aconteceram. Duas pessoas haviam se registrado na Universidade de Utah. 1
vi que alguém que ele conhecia, mas nunca conheceu, estava conectado. Eles estavam conversando
modo, e então ele digitou: "Onde você está?" O outro respondeu: "Bem, estou em Washington",
"Onde em Washington?" “No Hilton.” "Bem, eu também estou no Hilton." Os dois viraram
por estarem a apenas alguns metros um do outro.
Algumas coisas não eram tão engraçadas. Como autor do livro de cenários, Metcalfe foi escolhido
para levar dez executivos da AT&T em um tour virtual da ARPANET. Foi uma visão estranha:
Jovem Metcalfe, com sua grande barba ruiva, mostrando dez empresários listrados da AT&T
em torno da rede. No meio da demonstração, os computadores travaram. Foi o
primeira e única vez que os computadores pararam. Os primeiros executivos da companhia telefônica
a reação foi rir.
“Eu olhei para cima com dor”, disse Metcalfe, “e os peguei sorrindo, deliciado com aquele pacote-
a mudança era instável. Isso eu nunca vou esquecer. Isso confirmou para eles que a comutação de circuito
a tecnologia estava aqui para ficar, e essa coisa de comutação de pacotes era um brinquedo não confiável que
nunca teria muito impacto no mundo comercial, e agora eles poderiam voltar para casa,
Nova Jersey. Ficou claro para mim que eles estavam emaranhados no passado. ”

Página 117
Se tivessem olhado além do infeliz Metcalfe e da demonstração fracassada, os executivos da AT&T
teria visto a exuberância em outros cantos da sala. Não só o pacote-
mudar de trabalho, mas tornou possíveis coisas maravilhosas.
Algumas das demonstrações mais engenhosas envolveram conversação em inglês
programas. Estes eram programas elaborados construídos para envolver um usuário em um verbal
diálogo com uma máquina. Havia quatro programas em exibição, dois dos quais ofereciam um
uma visão especialmente fascinante da computação interativa.
PARRY, o primeiro desses conversadores virtuais, imitou o sistema de crenças de um
psicótico paranóico. Ele interrompeu a conversa oferecendo respostas prontas para
declarações que ele pensou ter entendido. Caso contrário, sua resposta foi evasiva.
PARRY foi ideia do Dr. Kenneth Colby da Universidade de Stanford.
O Doutor era outro programa de conversação, baseado em ELIZA, uma linguagem natural
programa escrito por Joseph Weizenbaum do MIT. The Doctor, que imitou o
comportamento de um psiquiatra, era um pouco mais acanhado do que PARRY. O doutor aceitou
declarações, em seguida, tentou produzir novas frases com base nas palavras e sintaxe do
outro familiarizado. Embora a conversa resultante fosse totalmente banal, os usuários costumavam ser
impressionado com o quão real a qualidade de suas conversas com o Doutor realmente parecia.
“As pessoas se sentariam e interagiriam com essa coisa”, observou Cerf. "E às vezes
eles pediam que outras pessoas saíssem da sala, porque pensaram que estavam tendo um
conversa privada."
Cerf e outros haviam brincado com a ideia de criar a paranóia de Colby para ter um
“Sessão” com o psiquiatra. Apenas algumas semanas antes da demonstração ICCC,
PARRY realmente encontrou o Doutor para uma conversa incomum no ARPANET, em um
experimento orquestrado na UCLA. Talvez tenha marcado a origem, no sentido mais verdadeiro, de todos
bate-papo no computador. Não houve intervenção humana no diálogo. PARRY estava correndo em
Laboratório de inteligência artificial de Stanford, o Doctor estava rodando em uma máquina na BBN, e em
UCLA sua entrada e saída foram conectadas cruzadamente através do ARPANET, enquanto o
os operadores sentaram e assistiram.
“Boa noite”, disse o doutor. “Conte-me seus problemas. Finalize a entrada com um
ponto final ou um ponto de interrogação. ”
“ As pessoas me dão nos nervos às vezes ” , PARRY respondeu.
"Não tenho certeza se entendi você."
“ Você deveria prestar mais atenção. ”
“Suponha que você deva prestar mais atenção.”
“ Você tem direito à sua própria opinião. ”
 Página 118
"O que o faz pensar que tenho direito à minha própria opinião?"
“ Me incomoda apenas estar perto das pessoas em geral. ”
"Por favor continue."
“ Eu fui para a pista de Bay Meadows um tempo atrás. ”
"Por que você diz isso agora?"
“ Há um monte de apostas desonestas acontecendo lá. ”
"Por favor continue."
“ Eu jogo em cavalos. ”
"O que isso sugere para você?"
“ Eu fui para as corridas. ”
"O que mais você gostaria de discutir?"
“O jogo não foi nada além de problemas para mim. ”
"Por que você diz isso agora?"
“ Eu tive experiência com bandidos que jogam na pista. ”
"Não tenho certeza se entendi você totalmente."
“ Você sabe alguma coisa sobre bookies? ”
"O que te faz pensar que sei alguma coisa sobre corretores de apostas?"
“ Um corretor de apostas não me pagou nenhuma vez. ”
"O que isso sugere para você?"
“ Eu bati no corretor que não pagou e pensei que ele poderia usar seus amigos no
submundo para se vingar de mim. ”
"De quem você está realmente falando?"
“ Você já pensou realmente sobre a MAFIA? ”
“Suponha que você realmente tenha pensado sobre a MAFIA.”
“ Vamos conversar sobre outra coisa. ”
"Não tenho certeza se entendi você totalmente."

Página 119
“ Você fica me perguntando as mesmas coisas, por que não muda de assunto? ”
“Por que essas perguntas estão em sua mente?
“ Pensei ter te dito, as pessoas me dão nos nervos. ”
"Seus nervos?"
“ Prefiro não discutir mais isso. ”
"Você gostaria de discutir seus nervos?"
“ Eu acho que sim. ”
"Não tenho certeza se entendi você totalmente."
“ Você fica insistindo demais nas mesmas perguntas. ”
“O que essa semelhança sugere para você?”
“ Eu não entendo você. ”
"Você gostaria de não ter entendido?"
“ Já era hora de você mostrar algum interesse nos meus sentimentos. ”
“Oh? Eu mostrei algum interesse em seus sentimentos? ”
“ Eu vou te ajudar se eu confiar em você. ”
"Você gostaria de confiar em mim?"
“ Talvez sim, talvez não. ”
"Você não parece ter certeza."
“ Na minha opinião, você tem uma mente focada. ”
“O que te faz pensar que tenho uma mente focada?”
“ Costumava ir à pista todas as semanas. ”
“O que mais você gostaria de discutir?
“ Isso é algo que eu não quero entrar. ”
"Por que você diz isso agora?"
“ Não é da sua conta. ”
“Por que você está preocupado com meu negócio?”

Página 120
“ Eu não confio em estranhos. ”
"Você realmente não confia em estranhos?"
“ Vamos mudar de assunto. ”
"Não tenho certeza se entendi você totalmente."
“ O que há de errado com você que fica me incomodando com isso? ”
"Por favor continue."
“ Você é um verdadeiro chato. ”
"Você gosta de acreditar que sou um chato de verdade?"
“ Eu tive o suficiente disso. ”
"O que isso sugere para você?"
“ Adeus. ”
“Foi um prazer.
“Medo = 4,2223001
“Raiva = 10
“Desconfiança = 12.650703
“Isso é $ 399,29, por favor.”
Centenas de pessoas participaram da demonstração da ICCC durante seus dois dias e meio.
Executivos, engenheiros e técnicos das áreas de telecomunicações e informática
indústrias, um bom número delas, entraram na sala céticas em relação à ARPANET e
comutação de pacotes. Muitos ainda acreditam que a tecnologia pode ser real, afinal. Para a maioria
parte, os mais de quarenta terminais funcionavam, os recursos eram envolventes, o TIP funcionava
espetacularmente, e o ARPANET ganhou vida. “Era quase como a indústria ferroviária
desacreditando que os aviões pudessem realmente voar até que eles realmente vissem um em vôo ”, disse
Kahn.
A demonstração da ICCC fez mais para estabelecer a viabilidade da comutação de pacotes do que
qualquer outra coisa antes disso. Como resultado, a comunidade ARPANET ganhou um sentido muito mais amplo
de si mesmo, de sua tecnologia e dos recursos à sua disposição. Para os fabricantes de computadores, havia
a percepção de que um mercado pode surgir. “A sensação naquela sala não era de medo,
ou preocupação ”, disse Len Kleinrock. “Foi excitação. Quer dizer, aqui poderíamos exibi-lo,
sabíamos que funcionaria. Mesmo que errasse, essas coisas podiam ser corrigidas. Era um

Página 121
experiência maravilhosamente emocionante. ” Roberts mostrou uma confiança constante. Ele tinha conseguido
o que ele queria, um esforço mais solidificado, a base para uma comunidade, algo que ele
poderia construir. Os esforços de choque e o pânico que precederam o evento valeram a pena. E em
naquele dia, até a BBN e a Honeywell estavam se dando bem.
Bob Kahn tinha acabado de dedicar um ano de sua vida para demonstrar que o compartilhamento de recursos
uma rede poderia realmente funcionar. Mas em algum ponto no decorrer do evento, ele se voltou para um
colega e comentou: “Sabe, todo mundo realmente usa isso para o correio eletrônico”.

7
O email
Numa noite de setembro de 1973, Len Kleinrock estava desfazendo as malas quando
descobriu que havia esquecido sua navalha. Ele tinha acabado de voltar para casa em Los Angeles de
Brighton, Inglaterra, onde ele deixou a navalha no banheiro de um dormitório da Universidade Sussex.
Um barbeador elétrico comum, não foi uma grande perda. “Mas era meu”, lembrou ele, “e eu
queria de volta. "
Kleinrock acabara de chegar de uma conferência sobre computação e comunicações. o
conferência reuniu cientistas de vários países, alguns dos quais
começaram a desenvolver redes digitais sob os auspícios de seus próprios governos. Mas o
A ARPANET do governo dos EUA era de longe a maior e mais sofisticada rede
experimento no mundo, e a comunidade internacional deu as boas-vindas à chance de ver o
projeto demonstrado. Os organizadores da conferência também decidiram usar o
ocasião de testar a transmissão de pacotes de dados via satélite. Para a conferência, um
O link temporário dos Estados Unidos foi conectado a Brighton. Pacotes viajados
por um link de satélite da Virgínia para uma estação terrestre na Cornualha, em Goonhilly Downs
perto de Land's End, e de lá uma linha telefônica dedicada foi instalada para se conectar com o
Universidade de Londres. De Londres, um salto final foi remendado para Brighton, onde
as pessoas tiveram a chance de usar a ARPANET como se estivessem sentadas em um escritório em
Cambridge, Massachusetts ou Menlo Park, Califórnia.
Kleinrock havia retornado aos Estados Unidos um dia antes, então, quando percebeu que havia esquecido seu
navalha, ele pensou que poderia encontrar alguém ainda na conferência para recuperá-lo. Havia um
um software útil na rede chamado executivo de compartilhamento de recursos ou RSEXEC.
Se você digitou "onde fulano", o RSEXEC procurou fulano pesquisando o "quem"
lista - uma lista de todos os conectados - em cada site. Você pode localizar uma pessoa no
rede desta forma se ele estivesse conectado naquele momento. “Eu me perguntei o que
maníaco estaria logado às três da manhã.? " Kleinrock se lembrava. Ele foi para o seu
terminal e digitado, "where roberts".
Poucos minutos depois, o terminal de Kleinrock exibiu a resposta. Larry Roberts era
na verdade, ainda em Brighton, acordado e, no momento, conectado a um host da BBN em
Cambridge. Um número de teletipo para Roberts também apareceu na tela de Kleinrock, o suficiente
informações para ele dar um tapinha no ombro de seu colega eletronicamente de LA

Página 122
“Tudo o que tive que fazer foi estabelecer uma conexão de teletipo com a BBN”, disse Kleinrock. Ele ligou a
Roberts usando o TALK, o que permitiu que eles conversassem digitando na metade de uma divisão
tela durante a leitura do outro. Os dois amigos trocaram saudações. “Eu perguntei se ele
poderia recuperar a navalha. Ele disse: 'Claro, sem problemas.' ”No dia seguinte, a navalha estava
devolvido por Danny Cohen, um amigo em comum que tinha estado na conferência e tinha vindo
de volta a LA
Não havia regras formais restringindo o uso do ARPANET por aqueles com autorização
Acesso. A manobra de recuperação da navalha de Kleinrock não foi a primeira vez que alguém passou por cima
parâmetros oficiais no uso da rede. As pessoas estavam enviando cada vez mais mensagens pessoais
mensagens. Corria o boato de que até mesmo um ou dois negócios de drogas haviam sido feitos sobre alguns dos
IMPs no norte da Califórnia. Ainda assim, batendo no ARPANET para buscar um barbeador
linhas internacionais era um pouco como ser clandestino em um porta-aviões.
Afinal, o ARPANET era um centro de pesquisa federal oficial e não algo para ser
brincou com. Kleinrock teve a sensação de que a façanha que fizera estava um pouco fora dos limites.
“Foi uma emoção. Eu senti que estava esticando a Net. ”
O ARPANET não foi concebido como um sistema de mensagens. Na mente de seus inventores, o
rede foi planejada para compartilhamento de recursos, ponto final. Isso muito pouco de sua capacidade era
realmente usado para compartilhamento de recursos foi um fato logo submerso na maré da eletrônica
enviar. Entre 1972 e o início da década de 1980, e-mail ou correio de rede, como era conhecido,
foi descoberto por milhares de primeiros usuários. A década deu origem a muitos dos
características duradouras da cultura digital moderna: chamas, emoticons, o sinal @, debates sobre
liberdade de expressão e privacidade, e uma busca insone por melhorias técnicas e
acordos sobre os fundamentos técnicos de tudo. No início, o e-mail era difícil de usar,
mas, no final da década de 1970, os grandes problemas foram resolvidos. O grande aumento da mensagem
o tráfego se tornaria a maior força inicial no crescimento e desenvolvimento da rede. E-
o correio era para a ARPANET o que a Compra da Louisiana era para os jovens Estados Unidos.
As coisas só melhoraram à medida que a rede cresceu e a tecnologia convergiu com a torrencial
tendência humana de falar.
O correio eletrônico se tornaria o recorde do ciberespaço. Assim como o LP foi
inventado para conhecedores e audiófilos, mas gerou toda uma indústria, o correio eletrônico
cresceu primeiro entre a comunidade de elite de cientistas da computação na ARPANET, depois
floresceu como plâncton em toda a Internet. Era mais ou menos na época em que Kleinrock estava alcançando
para sua navalha, que os tabus estavam caindo e o tom do tráfego de mensagens na Internet começou
Se soltando.
Como artefato cultural, o correio eletrônico pertence a uma categoria entre a arte encontrada
e acidentes de sorte. Os criadores da ARPANET não tinham uma grande visão para o
invenção de um sistema de tratamento de mensagens que circula a terra. Mas uma vez que o primeiro par de
dezenas de nós foram instalados, os primeiros usuários transformaram o sistema de computadores conectados em um
ferramenta de comunicação pessoal e profissional. Usando o ARPANET como um
sistema de e-mail sofisticado era simplesmente um bom hack. Naqueles dias, o hacking não tinha nada a ver
fazer com comportamento malicioso ou destrutivo; um bom hack era um pouco criativo ou inspirado de
programação. Os melhores hackers eram profissionais. Rede intrometida e maliciosa

Página 123
usuários, dos quais não havia praticamente nenhum no início, foram referidos inicialmente como "rede
randoms "ou" net randoms "ou simplesmente" randoms ". Seria mais uma década antes
hacking recebeu um nome ruim.
Na década anterior à ARPANET, cientistas da computação desenvolveram maneiras de trocar
mensagens eletrônicas em um sistema de compartilhamento de tempo. Pesquisadores ao mesmo tempo,
compartilhando
cada sistema tinha um arquivo designado, como uma caixa de entrada, na máquina central. Colegas
poderia enviar mensagens eletrônicas curtas para a caixa de outra pessoa, onde apenas o destinatário
poderia lê-los. As mensagens podem ser descartadas e recolhidas a qualquer momento. isso foi
conveniente, dados os horários estranhos que as pessoas cumpriam. Pessoas dentro de um único laboratório enviaram
desfiles de
one-liners para frente e para trás, bem como memorandos mais longos e rascunhos de documentos.
O primeiro desses programas, denominadoMAILBOX, foi instalado no início dos anos 1960 no
Sistema de compartilhamento de tempo compatível no MIT. Caixas de correio semelhantes se tornaram um recurso
padrão
de quase todos os sistemas de compartilhamento de tempo desenvolvidos posteriormente. Em lugares onde as pessoas
estavam espalhadas
fora, programadores trabalhando a centenas de metros de distância poderiam trocar mensagens sem
tendo que se levantar de suas mesas. Mas, muitas vezes, a troca de mensagens em uma única máquina, ou
domínio, tornou-se um exercício supérfluo - como duas pessoas usando walkie-talkies para conversar
em uma cabine de um cômodo. As pessoas ainda se levantaram de suas mesas e caminharam pelo corredor para
conversar.
Disse um usuário: "Nunca vou esquecer um colega que, enquanto trabalhava no escritório ao lado,
constantemente me enviam e-mails e nunca deixava de surpreendê-lo quando eu me levantava e caminhava
ao lado para responder a ele. ”
Em virtude de seu alcance geográfico, a rede ARPA mudou tudo isso, passando a ser eletrônica
e-mail de um brinquedo interessante em uma ferramenta útil. As tendências de
a comunidade ARPANET funcionou fortemente democrática, com uma veia algo de anárquica.
Os primeiros usuários da ARPANET estavam constantemente gerando um fluxo constante de novas ideias,
mexendo com os antigos, empurrando, puxando ou estimulando sua rede para fazer isso ou aquilo,
gerando uma atmosfera de caos criativo. A arte da programação de computadores deu-lhes
espaço para riffs sem fim e variações sobre qualquer tema. Um dos temas principais tornou-se
Correio eletrônico.
A primeira entrega de correio eletrônico envolvendo duas máquinas foi feita um dia em 1972 por um
engenheiro silencioso, Ray Tomlinson da BBN. Algum tempo antes, Tomlinson havia escrito um e-mail
programa para Tenex, o sistema operacional desenvolvido pela BBN que, agora, estava rodando na maioria
das máquinas PDP-10 da ARPANET. O programa de e-mail foi escrito em duas partes: Para
enviar mensagens, você usaria um programa chamado SNDMSG; para receber e-mails, você usaria o
outra parte chamadaREADMAIL. Ele não pretendia que o programa fosse usado em
theARPANET. Como outros programas de caixa de correio da época, foi criado para compartilhamento de tempo
sistemas e projetado apenas para lidar com correio localmente, dentro de PDP-10s individuais, não entre
eles.
Mas Tomlinson, um experimentador inveterado, decidiu aproveitar a vantagem de ter dois
Computadores PDP-10 configurados no escritório de Cambridge; na verdade, eram as mesmas máquinas
A BBN estava usando para se conectar à ARPANET. Semanas antes, Tomlinson havia escrito um
protocolo experimental de transferência de arquivos chamado CPYNET. Agora ele modificou o programa para que
ele pode carregar uma mensagem de correio de uma máquina e soltá-la em um arquivo em outra. Quando

Página 124
ele tentou e enviou e-mail de um PDP-10 para o outro, o pequeno hack funcionou e até
embora seu e-mail não tenha realmente saído para a rede aberta, ele cruzou um
importante divisão histórica. O CPYNEThack de Tomlinson foi um avanço; agora lá
nada impedia o e-mail de cruzar a rede mais ampla. Embora em técnica
Em termos gerais, o programa de Tomlinson era trivial, culturalmente era revolucionário.
“SENDMSG abriu a porta”, disse Dave Crocker, o irmão mais novo de Steve Crocker
e um pioneiro do e-mail. “Ele criou a primeira interconectividade, então todo mundo tirou
há."
Mas como fazer com que essa invenção se esgote na rede? A resposta está no arquivo
protocolo de transferência. Em julho de 1972, uma noite na Tech Square no MIT, como Abhay Bhushan
estava escrevendo as especificações finais para o protocolo de transferência de arquivos ARPANET, alguém
sugeriu adicionar os programas de e-mail de Tomlinson ao produto final. Por que não? E se
mensagens eletrônicas podem andar naCPYNET, elas podem muito bem andar no arquivo-
protocolo de transferência. Bhushan e outros fizeram algumas modificações. Em agosto, quando
Jon Postel recebeu uma RFC descrevendo o recurso de e-mail, ele pensou consigo mesmo: “Agora
há um bom hack. ” Os primeiros gêmeos do ARPANET no manuseio de correio eletrônico, chamados MAIL
e MLFL, ganhou vida.
Tomlinson tornou-se conhecido por SNDMSG e CPYNET. Mas ele se tornou mais conhecido
por uma decisão brilhante (ele chamou de óbvia) que ele tomou enquanto escrevia aqueles programas. Ele
precisava de uma forma de separar, no endereço de e-mail, o nome do usuário da máquina
o usuário estava ligado. Como isso deve ser denotado? Ele queria um personagem que não,
sob quaisquer circunstâncias concebíveis, ser encontrado no nome do usuário. Ele olhou para baixo
o teclado que ele estava usando, um Teletipo Modelo 33, que quase todo mundo na Net
usado também. Além das letras e números, havia cerca de uma dúzia de pontuação
marcas. “Eu cheguei lá primeiro, então pude escolher qualquer pontuação que eu quisesse”, disse Tomlinson. "EU
escolheu o sinal @. ” O personagem também tinha a vantagem de significar "no" designado
instituição. Ele não tinha ideia de que estava criando um ícone para o mundo conectado.
Stephen Lukasik, um físico que dirigiu a ARPA de 1971 a 1975, foi um dos primeiros
usuários e grandes defensores do correio de rede. Sua parte favorita da ARPA, na verdade, era Larry
Escritório de técnicas de processamento de informações de Roberts. Lukasik havia começado sua carreira no
1950 trabalhando para a BBN e MIT como estudante de pós-graduação. Ele ingressou na ARPA em 1966 para
trabalhar na detecção de teste nuclear, e ele assistiu à criação da ARPANET.
sua ascensão à diretoria, Lukasik lutou especialmente para proteger o computador
financiamento da comunidade científica. O ARPA estava sob pressão para realizar trabalhos relacionados à defesa.
Ele
via a computação como uma tecnologia mais fundamental, mas importante, e a defendia como tal
antes do Congresso.
Mas às vezes as coisas iam longe demais. Como diretor, ele andava muito, aparecendo
nas pessoas em seus escritórios. Um dia ele estava no IPT Office quando percebeu uma pasta
deitado em cima de um arquivo. Sua capa laranja (“não é minha cor favorita”) chamou sua atenção.
A pasta tinha o nome “Coreografia Assistida por Computador”. Continha relatórios de progresso
em um projeto que usava movimentos de dançarinos para mapear movimentos humanos por computador. "Eu fui

Página 125
balístico ”, disse ele. Ele podia imaginar a manchete: PENTÁGONO FUNDS DANÇA
PESQUISA.
Lukasik disse a sua equipe para dizer aos cientistas, se "você vai fazer algo que parece
está a quarenta mil milhas de distância da defesa, por favor, deixe nosso nome fora disso. ” Ele
entendeu a pesquisa e não se importou se eles fizeram, mas não queria que eles se gabassem
sobre isso. Steve Crocker, agora um gerente de programa IPTO trabalhando para Roberts, estava feliz
ele não era o único supervisionando o projeto de automação da dança. Mas ele tinha um pequeno
problema próprio com os pesquisadores que ele estava financiando na Inteligência Artificial de Stanford
Lab. “Em visitas aleatórias não anunciadas, eles me mostravam com orgulho o laboratório
simulação quadrifônica de uma mosca zumbindo - que consumiu 25 por cento do
recursos de computação lá ”, disse Crocker.
Uma das primeiras coisas que Lukasik fez ao ser nomeado chefe da agência foi obter
Roberts deu a ele um endereço de e-mail e acesso à ARPANET. Era incomum para
alguém que não era um cientista da computação para se interessar em usar o correio de rede e
mais incomum para alguém ficar tão dependente dela quanto Lukasik.
Um passageiro frequente, Lukasik raramente embarcou em um avião sem arrastar a bordo de seu
Terminal "portátil" da Texas Instruments com um acoplador acústico, para que ele pudesse discar e
verifique suas mensagens da estrada. “Eu realmente o usei para gerenciar o ARPA”, lembrou Lukasik.
“Eu estava em uma reunião e a cada hora ligava para o meu correio. Eu encorajei
todos à vista para usá-lo. ” Ele empurrou para todos os diretores de seu escritório e eles empurraram
outras. Os gerentes do ARPA perceberam que o e-mail era a maneira mais fácil de se comunicar com o
chefe, e a maneira mais rápida de obter sua aprovação rápida nas coisas.
Lukasik e Roberts tinham um relacionamento excelente, em parte porque ambos eram
pensadores analíticos, e em parte porque Roberts sempre foi rápido em responder a quaisquer perguntas
Lukasik sabia sobre seus projetos. “Se tivéssemos uma reunião na terça à tarde e eu enviasse
Larry saiu com algumas perguntas para responder, ele voltaria no dia seguinte para outro
encontro com mais do que apenas respostas. Ele teria tendências e projeções e
comparações. ”
Então Lukasik descobriu o que estava acontecendo e a utilidade do e-mail ficou mais clara
do que nunca. Normalmente, Roberts deixava o escritório de Lukasik, voltava para seu próprio escritório e
enviar mensagens para os especialistas no assunto em questão, que por sua vez rejeitaram as perguntas
fora de seus alunos de graduação. Vinte e quatro horas e uma enxurrada de e-mails depois, o problema
geralmente tinha sido resolvido várias vezes. “A forma como Larry trabalhava era
argumento fundamental em favor de uma rede de computadores ”, disse Lukasik. Durante o Lukasik's
mandato, o orçamento anual de Roberts quase dobrou, de $ 27 milhões para $ 44 milhões.
Em 1973, Lukasik encomendou um estudo ARPA que descobriu que três quartos de todos
o tráfego no ARPANET era e-mail. Na época, enviar e-mail era uma tarefa simples e quase
processo sem problemas. No entanto, tentar ler ou responder a isso era outra coisa:
funcional, mas nem um pouco fácil. O texto acabou de ser derramado na tela ou para fora da impressora e
nada separava as mensagens. Para chegar ao último, você teve que percorrer todos eles
novamente. Para muitos usuários, a única maneira de ler e-mails era ligar o teletipo e imprimir
fluxos de texto. Escrever mensagens era realmente um aborrecimento, porque ferramentas para texto

Página 126
edição eram primitivas. E não havia função de “resposta” para e-mail; para responder, você tinha
para começar uma nova mensagem do zero.
Lukasik, que odiava jogar tudo fora, estava começando a ficar frustrado com o
volume de e-mails acumulando em sua caixa de entrada. Ele foi para Roberts. “Eu disse: 'Larry, este e-mail
é ótimo, mas é uma bagunça! '”, lembrou Lukasik. “No típico estilo de Larry, ele veio na próxima
dia e disse: 'Steve, escrevi um código para você que pode ajudar.' E ele me mostrou como
para obter um menu de mensagens, arquive-as ou exclua-as. ” Roberts tinha acabado de escrever o primeiro
software gerenciador de correio.
Roberts chamou seu programa de DR, para "ler". Todos no ARPANET adoraram e
quase todo mundo criou variações para o DR - um ajuste aqui e outro ali. UMA
cascata de novos programas de manuseio de correio baseados no sistema operacional Tenex fluiu para
a rede: NRD, WRD, BANANARD (“banana” era a gíria do programador para “legal” ou
“Hip”), HG, MAILSYS, XMAIL. . . e eles continuaram vindo. Em breve, o principal da rede
os operadores estavam começando a suar. Eles eram como malabaristas que tinham vomitado muito
no ar. Eles precisavam de mais uniformidade nesses programas. Ninguém estava pagando
atenção aos padrões?
Por razões não relacionadas ao e-mail, mas aparentes para todos os que usam a rede diariamente,
ocasionalmente, a rede simplesmente enlouquecia. Ou, como uma pessoa disse, tornou-se
“Enrugado.” Problemas em uma máquina podem causar um efeito dominó em todo o sistema. Caso em questão:
o dia de Natal de 1973, fechamento. O Harvard IMP desenvolveu uma falha de hardware que
o efeito bizarro de ler todos os zeros nas tabelas de roteamento, informando assim outros
IMPs em todo o país que Harvard tinha acabado de se tornar o caminho mais curto - sem saltos - para
qualquer destino na ARPANET. A corrida de pacotes para Harvard foi de tirar o fôlego.
Os usuários notariam uma falha como essa. Tudo parou. “Harvard se tornou uma negra
buraco ”, disse John McQuillan, então um estudante de graduação em Harvard. “Todo o tráfego foi para
Harvard, e como um buraco negro, nenhuma informação saiu. ” McQuillan tinha sido
apresentado às operações de rede por Ben Barker e ajudou a conectar o PDP-
1. Ao terminar seu doutorado, McQuillan foi contratado para melhorar o software da BBN
Centro de controle de rede. No dia de Natal, quando os zeros de Harvard foram enviados para
tabelas de roteamento em todo o país, até mesmo o tráfego de controle usado pela BBN para diagnosticar e
debug o sistema foi sugado para a “órbita gravitacional” do IMP defeituoso de Harvard. o
Os operadores da BBN tiveram que "cauterizar" - cortar essa parte - da rede, depurá-la e então
traga-o de volta.
Como uma empresa de serviços públicos, a BBN estava desenvolvendo rapidamente os meios para lidar com tais
ocorrências. E houve relativamente poucos travamentos em toda a rede, nenhum durando muito tempo.
Às terças, os dias em que a BBN tinha o ARPANET reservado para tarefas domésticas,
McQuillan chegou às seis da manhã. Crowther e Walden pararam de programar os IMPs.
Entre 1972 e 1974, McQuillan assumiu a responsabilidade primária pela revisão do
códigos e concepção dos procedimentos de liberação. Ele liderou a equipe que escreveu todos os novos IMP
software e fez os lançamentos na rede. Ele construiu redes de teste "bastante elaboradas"

Página 127
no laboratório da BBN, onde simulou cenários de falha, forçando a rede de teste a
falhar para que ele pudesse aprender a tornar o ARPANETmais à prova de falhas.
“Você só sabe que os computadores vão encontrar tempestades com raios e energia
falhas e bugs de software e bugs de hardware, e o zelador vai tropeçar no
cabo de alimentação e qualquer coisa que você possa imaginar pode acontecer ”, disse McQuillan. Mas de tudo
os problemas potenciais, o problema no algoritmo de roteamento foi considerado o pior.
Apesar de toda a sua elegância e simplicidade, o algoritmo de roteamento original escrito por Crowther
era falho, pois embora fosse enxuto, em certo sentido o esquema era muito primitivo para
tráfego. Era um problema conhecido, mas não importava até que a rede chegasse a um ponto
quando o uso pesado e um grande número de nós começaram a sobrecarregar o esquema de roteamento. "Este
não começou a acontecer até que a rede cresceu ”, disse McQuillan. “Quando era bem pequeno,
todos os protocolos básicos funcionaram. Mas quando é pequeno, quase tudo funciona. ” Eles
sabia que quando o sistema atingisse cinquenta ou sessenta nós, o antigo algoritmo não seria
capaz de fornecer atualizações de roteamento rápido o suficiente, e eles teriam uma grande confusão em seus
mãos. McQuillan assumiu como missão "completamente à prova de balas" o cálculo para que
iria “continuar trabalhando em face de problemas 'impossíveis'.”
Em dois anos, com muitos lançamentos, McQuillan substituiu os algoritmos de roteamento, a forma
agradecimentos funcionou e, eventualmente, todo o programa operacional IMP. Ele construiu um
algoritmo completamente diferente para inundar informações sobre mudanças na rede
muito rapidamente para todos os IMPs para que não tomem decisões de roteamento erradas. E ele
eliminou cenários de impasse, em parte eliminando os infames RFNMs do
equação.
“Eu conhecia todos os computadores da rede”, disse McQuillan. “Eu sabia onde eles estavam e
quais eram seus números e quem estava lá e eu os conhecia pelo nome. ” Agora lá
foram quase cinquenta IMPs na ARPANET.
•••
Algo sobre um sistema de correio, digital ou não, é convidativo para aqueles com um certo
temperamento inconformista. Talvez porque deve haver regras, algumas pessoas vão
sempre tente dobrá-los. Houve o sujeito inteligente, por exemplo, que fugiu com
usando o serviço postal dos EUA para enviar tijolos, um por um, para o Alasca, até que ele tivesse o suficiente
lá para construir uma casa; era a maneira mais barata de despachá-los dos quarenta
oito estados. Ou há tia Em, que embeleza seus pacotes para suas sobrinhas distantes
e sobrinhos com ilustrações fantásticas, para a provável diversão ao invés de
consternação dos carteiros. Em algum lugar em um livro grosso de letras pequenas estão os oficiais
regulamentos postais relativos ao correio dos EUA - o que pode ser enviado, o que não pode e como. Mas
dentro dos limites, todos os tipos de pacotes são entregues, porque os funcionários do correio podem ajustar
a uma latitude bastante ampla de não conformidade.
Mas imagine um correio local em algum lugar que decidiu seguir sozinho, criando o seu próprio
regras para endereçamento, embalagem, carimbo e classificação de correspondência. Imagine se aquela postagem
desonesta
escritório decidiu inventar seu próprio conjunto de códigos postais. Imagine qualquer número de correios
assumindo a responsabilidade de inventar novas regras. Imagine uma confusão generalizada. Enviar

Página 128
o manuseio implora por uma certa quantidade de conformidade, e porque os computadores são menos problemáticos
tolerante que os seres humanos, o e-mail implora em voz alta.
As primeiras disputas no ARPANET sobre as tentativas de impor cabeçalhos de mensagem padrão
foi típico de outros debates sobre os padrões da indústria de computadores que vieram depois. Mas
porque a luta pelos padrões de e-mail foi uma das primeiras fontes de tensão real em
a comunidade, ela se destacou.
Em 1973, um comitê ad hoc liderado por Bhushan do MIT tentou trazer alguma ordem ao
implementação de novos programas de e-mail. Todos sabiam que, a longo prazo, um
protocolo de transmissão de correio - independente do FTP - era necessário. O correio da rede era
assumindo vida própria. Ele tinha seus próprios problemas técnicos. E não podia ficar colado
para FTP para sempre. Mas, por enquanto, apenas padronizar os cabeçalhos de correio já era uma dor de cabeça
suficiente.
Pacotes de dados no ARPANET já tinham algo chamado cabeçalhos, mas eram
totalmente diferente dos cabeçalhos de e-mail. Os cabeçalhos dos pacotes de dados eram bits codificados lidos
estritamente pelos IMPs, dizendo-lhes como lidar com cada pacote à medida que ele chega. No
contexto do correio eletrônico, no entanto, o cabeçalho se refere a uma grande quantidade de informações no
topo de cada mensagem de e-mail. A ideia era que certas informações deveriam sempre aparecer
no topo das mensagens em um formato especificado, na verdade apenas um elaborado localizador de data e hora,
incluindo informações como a hora em que uma mensagem foi enviada e entregue, a rota
viajou, outros destinatários para os quais foi enviado e muito mais. O comitê de Bhushan também
sugeriu uma sintaxe que tornaria mais fácil ler os cabeçalhos sem a ajuda de muitos
processamento especial de mensagens.
Os cabeçalhos nem sempre foram vistos apenas pelo usuário. Alguns campos de cabeçalho eram
processados por sistemas de recebimento, programados para lidar com significados reservados e muito
sintaxe bem definida. Se o programa receptor de alguma forma interpretou mal o remetente
cabeçalho, os resultados podem ser extremamente frustrantes. O programa leitor pode parar de funcionar
em suas trilhas ou cuspir uma mensagem de erro. As datas, por exemplo, foram especificadas em um
forma particular, e os desvios podem ser ininteligíveis. Ou se você colocar uma vírgula no
lugar errado, a capacidade do seu programa de e-mail de processar mensagens pode falhar. Quando um
gerenciador de correspondência não conseguia analisar cabeçalhos enviados por outros, era como se um funcionário
dos correios em Kenosha,
Wisconsin, estavam sendo solicitados a entregar cartas endereçadas em sânscrito e árabe.
As máquinas no ARPANET encontraram barreiras de linguagem de computador desse tipo
regularmente, e os problemas se multiplicaram com o crescimento tanto do número de correspondências
programas e o número de nós na rede. Dependendo do tipo de sistema de e-mail, um
pode usar para enviar uma mensagem, um programa incompatível ou sistema operacional no
A extremidade receptora “vomitaria” os cabeçalhos, como disse um observador. Se a mensagem foi recebida
através, a pessoa que o recebeu ainda pode ter que lidar com uma tradução truncada ou
formatação confusa. Os destinatários reclamariam do remetente. Um remetente pode
concordar em consertar o problema com um hack ou kludge ("um kludge é um crock que funciona", foi
uma definição), se ele tivesse tempo. Ou, se ele gostou de seu próprio programa de e-mail, ele
pode simplesmente reclamar do destinatário.
Configurar uma troca de e-mail era como convidar alguém para sair. “O e-mail foi visto
como algo entre adultos consentidos ”, disse Brian Reid, um cientista da computação que foi

Página 129
trabalhando em seu Ph.D. na Carnegie-Mellon. Era necessária uma certa compreensão madura.
“Tenho um programa de e-mail, quero enviar e-mails e você deseja recebê-los”, ele
continuou, "e desde que concordemos com o padrão, está tudo bem." Muitos usuários de fax antecipado
máquinas passavam pelo mesmo tipo de trapalhada, certificando-se de que a máquina do remetente
pode se comunicar com o aparelho de fax do destinatário.
O problema ocorreu em grande escala entre máquinas Tenex e não Tenex.
Programadores em alguns sites não Tenex, como aqueles que trabalham com máquinas baseadas no
Sistema operacional Multics, continuou introduzindo programas de e-mail e recursos no
sintaxe de seus próprios sistemas operacionais, e continuaram enviando suas mensagens através do
Internet. Máquinas Tenex, no entanto, não podiam lidar com a sintaxe de outros formatos usados em alguns
sites, então, novamente, conflito e confusão resultariam.
A diversidade de sistemas fora do padrão na Internet causou problemas mesmo com algo como
aparentemente trivial como o sinal @ de Tomlinson. A disputa do sinal @ era longa e
havia muitos lados para isso. Houve desacordo sobre o que deveria ser colocado à esquerda
lado da placa e o que deve ficar à direita. Mas antes disso, houve o debate
sobre se deve ser usado como delimitador entre o usuário e o host
nomes no endereço.
O pessoal do Multics objetou veementemente quando foi usado pela primeira vez, compreensivelmente.
Tomlinson, um hacker Tenex, escolheu o sinal @ sem perceber, talvez, que no
Sistema Multics era o caractere usado para enviar um comando de “eliminação de linha”. Qualquer usuário Multics
quem tentasse enviar um e-mail para “Tomlinson @ bbn-tenex” logo teria problemas.
Multics começava a ler o endereço, encontrava o sinal @ e jogava fora
tudo na linha que foi digitado anteriormente.
Ted Myer e Austin Henderson, do grupo BBN Tenex, decidiram tentar a sorte em
resolvendo um desses problemas de compatibilidade, o problema do cabeçalho. Em abril de 1975, eles emitiram um
nova lista de cabeçalhos “padrão”. O documento, ao qual deram o título, “Mensagem
Transmission Protocol ”, apareceu como RFC 680.
Mas a RFC 680 criou imediatamente uma confusão entre aqueles que pensaram que o esforço também
Orientado para Tenex. Postel, guardião dos RFCs, cuja palavra tranquila era frequentemente final, exerceu
o martelo. O RFC 680, disse ele, era o mais padrão que o correio jamais poderia ter. “É bom que muitos e-mails
ler programas aceitará e-mails que não estejam em conformidade com o padrão ”, disse ele,“ mas
isso não justifica a violação da norma pelos programas de envio de correio. ” Se o padrão é
inadequada, acrescentou, quaisquer propostas para alterá-lo são bem-vindas.
O tiff deixou claro que os sites Tenex, liderados pela BBN, formaram uma cultura dominante no
rede, enquanto os sites "minoritários", com seus diversos sistemas operacionais, colocaram um
contra-movimento potencialmente rebelde. Assim foram plantadas as raízes de um prolongado
conflito que continuou na década seguinte e se tornou conhecido na comunidade como
as guerras de cabeçalho. Muitas dessas batalhas foram travadas na arena de um novo grupo de
conversadores de computador - o “Msg-Group”.

The MsgGroup
Página 130
Em 7 de junho de 1975, Steve Walker, gerente do programa ARPA da IPTO, redigiu uma mensagem
para anunciar a formação de algo novo - um grupo de discussão eletrônico. o
comunidade de rede, escreveu ele, precisa “desenvolver um senso do que é obrigatório, o que é
bom, e o que não é desejável em serviços de mensagem. Nós tivemos muita experiência com
muitos serviços e deve ser capaz de coletar nossas idéias sobre o assunto. Ele acolheu
opiniões de qualquer pessoa disposta a lançá-los e até mesmo fornecer um pouco de financiamento ARPA para
lançá-lo. “Essa coisa toda é uma nova tentativa”, ele continuou. “Espero de tudo isso para
desenvolver uma estratégia de longo prazo para onde os serviços de mensagem devem ir na ARPANET e
na verdade, no DOD. Vamos começar. ”
No estilo verbal truncado que permeia a cultura da computação, o Message Services
Grupo foi apelidado de MsgGroup.
Dave Farber da UC Irvine se ofereceu para ser o arquivista do MsgGroup; e Farber
ofereceu a ajuda de um colega, um consultor chamado Einar Stefferud. Em pouco tempo, o
grande parte das tarefas domésticas diárias coube a Stefferud, que começou no trabalho mantendo
a lista de participantes do MsgGroup, inscrevendo recém-chegados, persuadindo-os a postar
biografias introdutórias de si mesmos e classificação de correspondências devolvidas. Stefferud iria
torne-se o moderador do MsgGroup e o homem por trás da cortina. Servindo como o go-
entre eles, ele recebia mensagens para postagem e as reenviava manualmente para todos no
a lista. Foi um processo árduo que posteriormente se automatizou.
Nem todos conduziam seus negócios no mercado ao ar livre do MsgGroup; houve
tanto ou mais tráfego de e-mail privado entre os programadores. Mas todos no
mundo envolvido na implementação de sistemas de correio eventualmente participou ou pelo menos conheceu
o que aconteceu no grupo. A discussão duraria dez anos. Com o tempo, milhares de
mensagens, e centenas de milhares de palavras, foram trocadas por cerca de cem
Participantes do MsgGroup.
O MsgGroup estava entre as primeiras listas de mala direta da rede. Havia outras listas de discussão,
a maioria deles não sancionada, em torno dos sites educacionais. O primeiro amplamente popular
A lista não oficial, chamada SF-Lovers, era dedicada aos fãs de ficção científica.
As guerras de cabeçalhos trouxeram à tona os traços teimosos e obstinados dos programadores.
Os conflitos operacionais entre as máquinas eram apenas a metade. Problemas de cabeçalho também foram
enraizado na discordância humana sobre a quantidade e o tipo de informação que deve ser
apresentado no topo das mensagens. As pessoas diferiam amplamente sobre a quantidade de cabeçalho
informações com as quais eles se preocupavam em lidar ao examinar suas correspondências.
Alguns programadores e programas de e-mail incluíram muito mais em seus campos de cabeçalho do que
outros fizeram. Eles cobriram o bolo com contagens de personagens, palavras-chave e vários aspectos esotéricos.
Enquanto isso, os críticos defendiam fortemente a economia, opondo-se a uma sobrecarga de informações.
Eles viram muitos cabeçalhos gordos e frívolos - o equivalente eletrônico de observar o
conteúdo de trapos de algodão de uma folha de papelaria. Mensagens curtas com cabeçalhos complicados
sempre parecia pesado na parte superior, fora de equilíbrio, enfatizando o cabeçalho em vez do
mensagem. Brian Reid da Carnegie-Mellon, que muitas vezes fez soar a voz da razão no

Página 131
MsgGroup, estava no campo do cabeçalho curto. Um dia ele recebeu uma mensagem sarcástica de
um colega e postou no MsgGroup:
Data: 7 de abril de 1977 1712-EST
De: Bob Chansler em CMU-10A
Responder a: Cheese Coop em CMU-10A
Assunto: Re: Fechar, mas sem charuto
Para: BRIAN. REID em CMU-10A
CC: Chansler @ CMU-10A
Remetente: BOB.CHANSLER em CMU-10A
ID da mensagem: [CMU-10A] 7 de abril de 1977 17:12:49 Bob Chansler em resposta-
Para: Sua mensagem de 6 de abril de 1977
My-Seq- #: 39492094
Yr-Seq- #: 4992488
Classe A
Subclasse: MCMXLVII
Autor: RC12
Datilógrafo: Fred
Terminal: TTY88
FE-L #: 44
Motivo: Godzilla precisava de um motivo?
Válido: não antes de 12 de abril de 1977 1321Z
Suspender: após 19 de abril de 1977 0000Z
Erros de grafia desta mensagem: 0
Erros de ortografia até o momento: 23
Tempo: chuva fraca, nevoeiro
Previsão: Clareira pela manhã

Página 132
Avaliação psicológica do remetente: Ligeiramente instável
Nível de segurança: Público
Subnível de segurança: 0
Autoridade para enviar: Geral
Autoridade para rcv: Geral
# -pessoas-na-sala-terminal: 12
XGP: cortador UP não funciona
Remetente Ht / Wt: 76/205
Máquinas: M & Ms disponíveis, mas a máquina de amêndoa está vazia
M & Ms-Last Nickel: 17
HDR-chksum: 032114567101
-------------------------------------------------- ---------
Brian,
Não entendo sua preocupação com o tamanho
de cabeçalhos de mensagens.
Prumo.
Por que não podemos configurar cabeçalhos para imprimir apenas as partes do cabeçalho que escolhemos ler?
Reid perguntou. “Vá em frente e coloque trinta e quatro campos de cabeçalho diferentes”, disse ele. “Tudo que eu
sempre
realmente quero ver é 'desde' e 'data'. ”Outros concordaram. O programa ideal permitiria
os usuários projetem seus próprios cabeçalhos. Pelo menos um sistema de e-mail elaborado, Doug
O NLS JOURNAL MAIL de Engelbart ofereceu um recurso de "informação invisível" que
permitiu a visualização seletiva de uma grande quantidade de dados de cabeçalho.
Em 12 de maio de 1977, Ken Pogran, John Vittal, Dave Crocker e Austin Henderson
lançou um golpe de correio do computador. Eles anunciaram “finalmente” a conclusão de uma nova correspondência
padrão, RFC 724, “Um padrão oficial proposto para o formato da rede ARPA
Mensagens. ” O padrão que eles estavam propondo continha mais de vinte páginas de
especificações - formalidades sintáticas, semânticas e lexicais. O RFC explicou que o
receptor de uma mensagem poderia exercer um controle extraordinário sobre o
aparência da mensagem, dependendo das capacidades do sistema de leitura de correspondência.
Nos dias após a publicação do RFC 724, a resposta da comunidade de computação foi em
melhor legal para o novo protocolo. Alex McKenzie, da BBN, foi particularmente franco. Postel,

Página 133
que tinha sido um defensor do antigo RFC 680, foi o que menos se impressionou com o novo
proposta. Ele foi duro com a afirmação de que este seria um ARPA oficial
padrão. “Até onde sei, nenhum protocolo ARPANET em qualquer nível foi carimbado como
oficial pela ARPA ”, disse. “Quem são os funcionários, afinal? Por que esta coleção
de organizações de pesquisa em computação recebem ordens de alguém? ” Havia muito
ênfase no oficialismo e não o suficiente na cooperação e aperfeiçoamento do sistema. "EU
prefere ver a situação como uma espécie de evolução passo a passo ", disse ele," onde
documentos como RFCs 561, 680 e 724 registram as etapas. Para fazer um grande ponto de
oficialidade sobre um passo pode tornar muito difícil dar o próximo passo. ”
A equipe RFC 724 absorveu as críticas. Seis meses depois, sob o comando de Dave Crocker e
A liderança de JohnVittal, uma edição final revisada do RFC 724 foi publicada como RFC 733.
Esta especificação foi concebida "estritamente como uma definição" do que deveria ser aprovado
entreARPANEThosts. Eles não pretendiam ditar a aparência da mensagem
programas ou os recursos que eles podem oferecer suporte. Menos foi exigido do que o permitido pelo
padrão, eles disseram, então aqui estava. E lá estava ele.
Vários desenvolvedores escreveram ou revisaram programas de e-mail para se adequarem às novas
diretrizes, mas dentro de um ano da publicação da RFC 733, o conflito persistente começou
novamente. De particular preocupação, os cabeçalhos RFC 733 eram incompatíveis com um programa de e-mail
chamado MSG (apesar de seu autor, JohnVittal, ter ajudado a escrever RFC
733) .MSG era de longe o programa de e-mail mais popular da ARPANET.
Um hacker de hacker, Vittal escreveu o programa MSG em 1975 por puro amor ao
work.MSG nunca foi formalmente financiado ou apoiado, "exceto por mim em meu tempo livre",
ele explicou. Mas logo, MSG tinha uma comunidade de usuários de mais de mil pessoas,
o que naquela época significava uma grande parte do mundo conectado. Vittal tinha usado
O programa Roberts'sRDmail, que era ótimo para lidar com duas ou três mensagens ao mesmo tempo,
ou até mesmo uma pequena pilha de mensagens, mas Vittal estava recebendo vinte mensagens por dia agora e
queria um programa para gerenciá-los com maior facilidade. “WhatMSGdid foi fechar o ciclo,”
ele disse, “para que você pudesse dividir as mensagens em vários outros arquivos, chamados de pastas, e
em última análise, responda e encaminhe. ”
Vittal, de fato, tornou-se amplamente conhecido por colocar a palavra "resposta" no léxico de e-
enviar. Ele inventou o comando RESPOSTA, que tornava as respostas às mensagens muito fáceis.
Vittal relembrou: “Eu estava pensando: 'Ei, com um comando de resposta não preciso redigitar -
ou digite errado! —um endereço ou endereços de retorno. '”
Um modelo inspirador, MSGspawned toda uma nova geração de sistemas de correio
incluindo MH, MM, MS e um projeto patrocinado pelo Pentágono fortemente financiado na BBN
chamado HERMES.MSG era o "aplicativo matador" original - um aplicativo de software que pegou o
mundo pela tempestade. Embora nunca tenha havido nada oficial sobre isso, MSG claramente tinha o
mais amplo apoio popular. Estava em toda a rede; até mesmo as principais pessoas do ARPA no
O Pentágono o usou. Se alguma coisa era o padrão mais amplamente aceito, era o MSG, que
reinou por um longo tempo. (Algumas pessoas na BBN ainda usavam o MSG na década de 1990.)
Vittal'sMSG e seuANSWERcommand o tornaram uma figura lendária nos círculos de e-mail.
“Foi por causa da Vittal que todos nós assimilamos a correspondência de rede em nossas medulas espinhais”,

Página 134
lembrou Brian Reid. “Quando o conheci anos depois, lembro-me de ter ficado desapontado - como
muitas vezes é quando encontramos uma lenda viva - ver que ele tinha dois braços e duas pernas
e nenhum foguete nas costas. ”
Mais do que apenas um grande hack, MSG foi a melhor prova até hoje de que nas regras ARPANET
pode ser feito, mas certamente não prevaleceu. Proclamações de oficialidade não
promover a Internet quase tanto quanto lançar tecnologia na Internet para ver o que
funcionou. E quando algo funcionou, foi adotado.

Aventura e Quasar: a rede aberta

e liberdade de expressão
Quanto mais as pessoas usavam o ARPANET para e-mail, mais relaxadas ficavam sobre
o que eles disseram. Houve mensagens anti-guerra e, durante o auge do Watergate
crise, um estudante da ARPANET defendeu o impeachment de Nixon.
Não apenas a rede estava se expandindo, ela estava se abrindo para novos usos e criando novos
conexões entre as pessoas. E isso era puro Licklider. Um dos mais deslumbrantes
exemplos disso começaram com um dos caras originais do IMP - Will Crowther.
Um pequeno círculo de amigos da BBN ficou viciado em Dungeons and Dragons, e
RPG elaborado de fantasia em que um jogador inventa um cenário e o povoa
com monstros e quebra-cabeças, e os outros jogadores então seguem seu caminho através desse cenário.
Todo o jogo existe apenas no papel e na mente dos jogadores.
Dave Walden teve sua introdução ao jogo uma noite em 1975, quando Eric Roberts, um
aluno de uma aula que ele estava ensinando em Harvard, o levou a uma sessão de D&D. Walden
imediatamente reuniu um grupo de amigos da equipe ARPANET para continuar
sessões. Roberts criou o Mirkwood Tales, uma versão elaborada de Dungeons e
Dragões colocados na Terra Média de JRR Tolkien. O jogo se estendeu para a melhor parte
de um ano e foi tocado principalmente no chão da sala de Walden. Um dos regulares era
Will Crowther. Onde a outra dúzia de jogadores escolheu nomes como Zandar, Klarf ou Groan
para seus personagens, Crowther era simplesmente Willie, um ladrão furtivo.
Crowther também era um ardente explorador de cavernas. E sua esposa Pat alcançou renome entre
espeleólogos por terem feito parte de um pequeno grupo que descobriu o primeiro elo conhecido entre
as cavernas Mammoth e Flint Ridge em Kentucky. O sistema combinado de 144 milhas foi
a caverna mais longa conhecida do mundo. Crowther foi o cartógrafo da Caverna
Fundação de Pesquisa. Ele usava suas horas de folga para traçar mapas subterrâneos intrincados em uma BBN
computador.
No início de 1976, Will e Pat se divorciaram. Procurando por algo que ele pudesse fazer com seus dois
filhos, ele teve uma ideia que uniu Will, o programador, com Willie, o imaginário
ladrão: uma versão simplificada de Dungeons and Dragons para computador chamada Adventure.
Embora o jogo não usasse mapas reais das cavernas de Kentucky, Crowther baseou o
geometria da aventura em imagens mentais gritantes dessas câmaras subterrâneas. O ferro

Página 135
grade através da qual os jogadores passaram no início do jogo foi modelada naquelas
instalado pelo Park Service nas entradas do sistema Flint Ridge. Ele até incluiu um
desmoronando em uma ou duas piadas; o “Y2” inscrito em uma pedra em um ponto do jogo é espeleólogo
abreviação para uma entrada secundária.
Crowther terminou o programa ao longo de três ou quatro fins de semana. Seus filhos - idades
sete e cinco anos - adorei, e Crowther começou a mostrá-lo aos amigos. Mas a separação de
seu casamento havia minado o espírito de Crowther, e ele nunca conseguiu refinar o jogo.
Bob Taylor, agora diretor do Laboratório de Ciência da Computação em Palo Alto da Xerox Corporation
Centro de Pesquisa, persuadiu primeiro Severo Ornstein, depois Will Crowther, a se juntar a ele, e
quando Crowther se mudou para a Califórnia em 1976, ele deixou o programa Adventure para trás em um
arquivo em um computador BBN. Embora o jogo fosse pouco polido, a palavra de aventura tinha
filtrada pela comunidade da rede.
Um estudante de graduação de Stanford chamado Don Woods ouviu sobre Adventure por meio de um amigo
que encontrou uma cópia no computador da Stanford Medical School e fez o download
o jogo a partir daí. Mas Woods teve dificuldade em fazer Adventure correr no início, e
quando o fez, descobriu que estava cheio de insetos. Ainda assim, ele foi fisgado. “Usuários de aventura
sentem que estão interagindo mais com o computador ”, disse Woods. “Parecia ser
respondendo mais ao que você digitou, em vez de apenas fazer seus próprios movimentos como um
oponente. Acho que isso atraiu muitos jogadores que, de outra forma, teriam sido desligados
pela ideia de jogar 'contra' um computador. Isso era brincar 'com' um computador. ”
O jogo listou Will Crowther como o autor, e Woods decidiu rastrear Crowther
para obter o código-fonte para que pudesse começar a fazer reparos no pequeno programa rudimentar.
Ele enviou um e-mail para cada host da rede procurando por Crowther e, finalmente, encontrou
ele no PARC. Crowther entregou o código alegremente. Demorou vários meses para retrabalhar,
durante o qual o programa simples dobrou de tamanho. Woods criou novos obstáculos, adicionou um
pirata, distorceu ainda mais os labirintos e acrescentou vários tesouros que exigiam algum problema
resolvendo antes de serem encontrados.
Quando a aventura terminou, Woods criou uma conta de convidado no computador do
Stanford AI Lab para permitir que as pessoas joguem e muitos convidados fazem login. A aventura se espalha
como bambolês, quando as pessoas enviam o programa umas para as outras pela rede. Porque
Crowther o havia escrito em FORTRAN, ele poderia ser adaptado para muitos computadores diferentes
com relativa facilidade. Crowther e Woods encorajaram os programadores a piratear o
jogo e incluiu seus endereços de e-mail para quem procura ajuda para instalar, jogar,
ou copiando o jogo.
As pessoas ficaram com os olhos turvos em busca de tesouros até altas horas da madrugada. "Eu tenho
há muito tempo perdi a conta dos programadores que me disseram que a experiência que os levou
comecei a usar computadores estava jogando Adventure ”, disse Woods. O jogo inspirou
centenas de imitações, o que acabou gerando uma indústria inteira.
Adventure demonstrou o apelo de uma cultura de rede aberta. E a ênfase em
a abertura cresceu com o tempo. Havia poucas portas fechadas na rede e um espírito livre
prevaleceu nas atitudes das pessoas sobre quem poderia entrar e passar por eles, e para quê

Página 136
finalidades. Qualquer pessoa que tente restringir a população de estudantes de graduação de usar livremente o
rede teria interpretado mal a mentalidade da ciência da computação
comunidade. O ARPANET era propriedade oficial do governo federal, mas o correio da rede
estava sendo usado para todos os tipos de conversa diária.
Então, na primavera de 1977, a Quasar entrou pela porta. Sua chegada marcou o início de
o primeiro debate sobre a liberdade de expressão no ciberespaço. A polêmica centrou-se em um incomum
dispositivo feito pela Quasar Industries e explodiu em uma discussão sobre o uso do contribuinte
fundedARPANETpara falar, em termos abertamente críticos, sobre uma empresa privada.
Idealizado pelas Indústrias Quasar, o dispositivo tinha um metro e sessenta e um centímetros e pesava
duzentas e quarenta libras. Era chamado de robô doméstico Android, um programável
ajudante que poderia realizar uma dúzia de tarefas domésticas básicas, como limpar o chão,
cortando a grama, lavando pratos e servindo coquetéis. Ele veio equipado com um
personalidade e fala, para que pudesse “interagir em qualquer situação humana”. Poderia “ensinar
as crianças francês ”e“ continuem a ensiná-los, enquanto dormem ”. Pelo preço anunciado
de $ 4.000, a coisa parecia um roubo.
Phil Karlton da Carnegie-Mellon foi o primeiro a alertar o Msg-Group, em 26 de maio de 1977.
Seu site no ARPANET estava fortemente envolvido na exploração de inteligência artificial, fala
reconhecimento e problemas de pesquisa relacionados, então ele sabia uma coisa ou duas sobre robôs. o
android e seu inventor atraíram bastante atenção da imprensa nacional, a maior parte
favorável. O discurso de vendas da Quasar também chamou a atenção da Consumer Reports, que
publicou um item cético sobre isso na edição de junho, recém-lançado.
No início, o Quasar parecia nada mais que uma diversão divertida do principal grupo do MsgGroup
o negócio. Todos no grupo sabiam que a coisa era uma farsa, e por um tempo isso pareceu
o suficiente. Mas então surgiu um senso de dever cívico. Dave Farber disse que estava em Boca Raton,
Flórida, e ouvir no rádio que o departamento de polícia do condado de Dade estava
considerando a compra de um robô de guarda Quasar para a prisão do condado, por $ 7.000. Em março
o Boston Globe publicou uma matéria citando Marvin Minsky do MIT e outros céticos especialistas em IA.
Mas o artigo adotou a atitude geral, disse um membro do MsgGroup, de que "apenas vai para
mostrar, esses acadêmicos não podem fazer nada prático, e tudo que você precisa é de um cara
trabalhando na parte de trás de uma garagem para envergonhá-los. ” A saga deixou um rastro de descrença em
a comunidade de pesquisa de inteligência artificial.
Brian Reid e um colega, Mark Fox, da Carnegie-Mellon Artificial Intelligence
Lab, postou um relatório incomum para todos no MsgGroup, dando-lhes um
conta de sua inspeção do robô doméstico, "Sam Strugglegear", em um grande
loja de departamentos no centro de Pittsburgh. Pessoas na comunidade de pesquisa, conhecendo
O trabalho pioneiro de IA da CMU ligou para o laboratório para perguntar como era possível para
O robô do Quasar é muito melhor em reconhecimento de voz do que qualquer coisa que o CMU tinha
produzido. Enfrentando o desafio, uma equipe de quatro membros da CMU fez o
trabalho de campo.
“Eles encontraram uma visão assustadora”, relataram Reid e Fox. No departamento masculino,
entre os ternos de três peças, havia uma "lata de aerossol sobre rodas de cinco pés e duas polegadas, falando
animadamente ”para uma multidão. Motores elétricos e um sistema de engrenagens moviam os braços do dispositivo.

Página 137
O robô parecia familiarizado com qualquer assunto, reconhecia as características físicas de
clientes e se moviam livremente em qualquer direção. A multidão ficou encantada.
Mas os cientistas estavam céticos. Eles procuraram por alguma evidência de um controle remoto
controlador. “Veja só, a cerca de três metros do robô, parado no meio da multidão, encontramos
um homem em um terno azul com a mão levada contemplativamente à boca como Aristóteles
contemplando o busto de Homero na famosa pintura de Rembrandt. ” Reid e os outros
assisti por um tempo e percebi que sempre que o robô estava falando, o homem
o terno azul - murmurando em sua mão. O homem tinha um fio pendurado suspeitamente
sua cintura.
A discussão sobre o robô Quasar continuou por alguns anos até que em
no início de 1979, Einar Stefferud, o moderador do MsgGroup, e Dave Farber, que havia sido
espreitando à margem do comentário, enviou uma nota de cautela ao MsgGroup. "Nós
estão pedindo problemas em potencial ”, alertaram,“ quando criticamos o robô Quasar ”.
Usar as instalações do governo dos EUA para lançar calúnias contra uma empresa, disseram eles, poderia
tiro pela culatra na comunidade de pesquisa ARPA. Eles exortaram seus pares a impor cuidadosa
autocensura, para relatar apenas fatos de interesse técnico à comunidade. Nem todos
concordou, e com isso o MsgGroup se envolveu em uma troca de exame de consciência.
John McCarthy, que trabalhou no Laboratório de Inteligência Artificial de Stanford, estava entre os
mais ofendido com as afirmações do Quasar. Ele disse ao grupo que não seria dissuadido por
especulação de que Quasar pode processar. “Eu acho que alguém parece estar com medo de seu
sombra ”, disse McCarthy. “Nunca foi costume dos vendedores de óleo de cobra no carnaval
processar seus críticos. ” Minsky e Reid também deixaram claro que contariam a qualquer repórter
que perguntou se eles acreditavam que o robô era uma piada, e eles já expressaram que
opinião a mais de uma dezena de jornalistas.
“Não tenho medo de ser processado”, respondeu Farber. “No entanto, estamos usando um veículo público
chamado ARPANET. Assim, expomos ARPA, DOD e nosso futuro acesso e uso de
a rede para certos perigos quando usamos esse veículo para material potencialmente difamatório. ”
Farber pediu moderação novamente.
Reid entrou na conversa, dizendo: "[o] MsgGroup é o mais próximo que temos de uma empresa nacional
fórum da comunidade de ciência da computação ”. Reid começou a notar que o Grupo de Mensagens
era como um clube social. Eles discutiram tanto um com o outro que se tornaram
amigos. Restringir a discussão não seria natural. Além disso, Reid teve uma visão mais liberal
da liberdade de expressão, raciocinando que a experiência em comunicação sofreria se os tópicos
foram restritos. “Até que as pessoas comecem a sugerir a derrubada de nosso
governo ”, disse ele,“ não acho que nenhum tópico sensato deva estar fora dos limites ”.
Alguém sugeriu anexar uma isenção de responsabilidade às comunicações pessoais em
theARPANETpara que opiniões pessoais não sejam confundidas com negócios oficiais.
Outra pessoa admitiu: “Quem nunca usou o correio da Internet para comunicação pessoal? Who
não gastou tempo jogando algum novo jogo na Internet? Seja honesto." A paixão em
a defesa da liberdade de expressão foi acompanhada por uma vontade igualmente forte de autoproteção; o caminho
proteger a própria rede não era atrair supervisão indesejada do governo.

Página 138
Depois de alguns dias, a discussão se esgotou sem resolução e o MsgGroup
continuou com os negócios normalmente.
O que emergiu do debate foi uma forte evidência de que a comunidade de rede sentiu um
aposta profunda na criação da Net, com ou sem financiamento do ARPA, e estava tentando
zelosamente guardar seu direito de determinar seu futuro. Em um reino onde, de certa forma, pessoal
a identidade é definida inteiramente pelas palavras que as pessoas escolhem, a liberdade de expressão parecia apenas
a segunda
a preocupação com a sobrevivência do próprio reino.

Umbilicais de cobre
Para o primeiro trimestre de 1976, os relatórios de tráfego mostraram que o volume do ARPANETmail,
em comparação com o volume do correio normal dos Estados Unidos, era uma mera trilha de formigas no caminho
de um
manada de elefantes. O Laboratório de Inteligência Artificial do MIT, por exemplo, passou cerca de 9.925
mensagens durante o período. (Em 1996, em comparação, alguns sites estavam processando
150.000 mensagens de e-mail todos os dias.) O MIT era um site típico e, por extrapolação, se houver
máquina processou cerca de cem peças de e-mail por dia, multiplicado por um fator de 98 ou
então (o número de hosts na rede) o correio eletrônico ainda não parecia representar uma ameaça
para o sistema postal dos EUA. Os correios lidaram com mais de 50 bilhões de peças de primeira
correio da classe por ano. Mas a curva de crescimento acentuada do e-mail não passou despercebida.
No setor privado, as empresas estavam preparadas para o conceito de serviço de correio eletrônico para
descolar. A Computer Corporation of America logo começou a vender um dos primeiros
pacotes de software de e-mail disponíveis comercialmente, um produto de $ 40.000 chamado COMET,
projetado para o minicomputador PDP-11. Outro programa chamado MESSENGER,
desenvolvido para computadores IBM 360 e 370, logo foi disponibilizado por uma empresa chamada
On-Line Software International, por $ 18.000. Os custos estavam caindo, e alguns
os analistas projetaram um impacto “devastador” nos negócios de primeira classe dos Correios dos Estados Unidos.
“Estamos sendo ultrapassados tecnologicamente”, relatou um postmaster geral assistente dos EUA em
início de 1976. A tendência de crescimento e o potencial óbvio da nova tecnologia eram
na verdade, bastante dramático. Algumas versões dos programas ARPANETmail mais sofisticados
comoMSG, HERMES e SRI'sNLS JOURNAL MAIL, estavam chegando às mãos
de não pesquisadores. Várias grandes organizações, incluindo o US Geological Survey,
Departamento de Comércio, Agência de Segurança Nacional e Gulf Oil começaram a usar
e-mail em redes locais.
O governo estava olhando de perto o futuro do serviço de e-mail. Um relatório para o
Escritório de Política de Telecomunicações da Casa Branca pela empresa de consultoria Arthur D.
Little estimou que 30 por cento de toda a correspondência de primeira classe provavelmente seria enviada
eletronicamente
dentro de alguns anos. O serviço postal reagiu a essa previsão concedendo à RCA US $ 2,2
contrato de milhões para avaliar a viabilidade técnica e econômica do fornecimento de e-mail
serviço. Em seu relatório, a RCA defendeu a inclusão do e-mail nos serviços dos correios. A USPS
o painel consultivo também analisou de perto. Eles recomendaram fazer um "firme e contínuo
compromisso ”com o correio eletrônico, no mesmo nível do programa espacial tripulado da NASA.

Página 139
A campanha presidencial de Jimmy Carter usou e-mail várias vezes ao dia no outono de
1976. O sistema que eles estavam usando era um programa básico de caixa de correio, uma tecnologia que já
com mais de uma década. Mas para uma campanha política, este foi um golpe revolucionário em
comunicações. Com base nisso, Carter foi rotulado de "candidato orientado por computador".
Em 1979, o presidente Carter estava apoiando uma proposta dos correios para oferecer um tipo limitado de
serviço de mensagens eletrônicas para a nação. O esquema híbrido funcionou mais como um telegrama
serviço do que um sistema de comunicações eletrônicas de última geração. As mensagens seriam
transmitido eletronicamente entre os correios durante a noite, e depois entregue no
as portas dos destinatários no dia seguinte. A proposta foi notável principalmente por quão cautelosa
parecia em vista das possibilidades tecnológicas.
Stefferud e outros no MsgGroup - a comunidade com mais experiência com e-
correio - imediatamente vi as falhas no plano dos Correios dos EUA, que envolviam
converter mensagens de mídia eletrônica digital para papel e, em seguida, entregá-las
mão como se fosse uma correspondência normal. Essa abordagem não custaria apenas mais do que o e-mail,
mas nunca seria rápido o suficiente para competir com o e-mail, contanto que dependesse de
Força de pé tradicional do USPS para as etapas finais para a caixa de correio. Computadores desktop
“Fará a caixa de correio perfeita”, previu Stefferud, e contornaria os correios
inteiramente. Uma analogia poderia ser feita com a noção outrora ridícula de lixo automatizado
coleção, que era impensável até a invenção do "porco elétrico", o nome antigo
dado para o descarte na pia. “A chave não está em automatizar o saco / lata / caminhão / pessoa
mecanismo ”, disse Stefferud. “É contorná-los completamente.”
O USPS, como a AT&T antes, nunca realmente se libertou da mentalidade que guarda seus
negócios tradicionais, provavelmente porque ambos eram entidades monopolistas. Eventualmente, o
O Departamento de Justiça dos EUA, a FCC e até mesmo a Comissão de Taxa Postal se opuseram a qualquer
papel significativo do governo nos serviços de e-mail, preferindo deixá-los para o mercado livre.
Nenhum problema era pequeno demais para uma longa discussão no MsgGroup. A velocidade e facilidade de
o meio abriu perspectivas para uma conversa casual e espontânea. Era evidente pelo
final da década para pessoas como Licklider e Baran que uma revolução que ajudaram
o início estava em andamento.
“Amanhã, os sistemas de comunicação por computador serão a regra para a colaboração remota”
entre os autores, escreveu Baran e Dave Farber da UC Irvine. Os comentários apareceram em um
papel escrito em conjunto, por e-mail, com quinhentas milhas entre eles. isso foi
“Publicado” eletronicamente no MsgGroup em 1977. Eles continuaram: “Como computador
sistemas de comunicação se tornam mais poderosos, mais humanos, mais complacentes e superiores
todos, mais baratos, eles se tornarão onipresentes. ” Reservas automatizadas de hotéis, verificação de crédito,
transações financeiras em tempo real, acesso a seguros e registros médicos, em geral
recuperação de informações e controle de estoque em tempo real nas empresas viriam.
No final da década de 1970, o relatório final do Information Processing Techniques Office para ARPA
a gestão na conclusão do programa de pesquisa ARPANET concluiu de forma semelhante:
“A maior surpresa do programa ARPANET foi a incrível popularidade
e sucesso do correio de rede. Não há dúvida de que as técnicas de correio de rede

Página 140
desenvolvidos em conexão com o programa ARPANET vão varrer o país e
mudar drasticamente as técnicas de intercomunicação no setor público e privado
setores. ”
Para os membros do MsgGroup, o correio eletrônico era tão envolvente quanto um diamante preso a
a luz. Os membros do MsgGroup investigaram todos os detalhes. Eles eram viciados em tecnologia.
A questão dos carimbos de hora e data, por exemplo, era clássica. “O chefe do chefe do meu chefe
reclama dos delírios dos madrugados ”, disse alguém. “Ele pode dizer a partir do tempo
carimbar (e os hábitos do remetente) até que ponto levar a mensagem a sério. ”
“Talvez devêssemos marcar a hora com a fase da lua, além da data e hora,”
disse outro. (Em pouco tempo, alguém escreveu um programa de e-mail que fazia exatamente isso.)
“Eu realmente gosto de ver um carimbo de hora preciso”, disse outra pessoa. “É bom ser capaz de
desvendar a sequência de comentários recebidos em ordem codificada. ”
“Algumas pessoas usam isso abertamente como uma espécie de vantagem. 'Eu trabalho mais horas do que você
Faz.'"
Os membros do MsgGroup podem discutir sobre qualquer coisa. Houve momentos em que você juraria
você acabara de visitar um grupo acalorado de advogados, gramáticos ou rabinos.
Os estranhos caíram casualmente no diálogo ou, como alguém chamou, no "polílogo". Enquanto o
regulares tornaram-se familiares uns com os outros, amizades rápidas foram cimentadas, às vezes anos
antes que as pessoas se conhecessem. De muitas maneiras, os valores básicos da comunidade ARPANET eram
tradicional - liberdade de expressão, igualdade de acesso, privacidade pessoal. No entanto, o e-mail também foi
desinibidor, criando referenciais inteiramente próprios, uma sociedade virtual, com modos,
valores e comportamentos aceitáveis - a prática de "flaming", por exemplo - estranhos para o
resto do mundo.
A familiaridade no MsgGroup ocasionalmente cria a linguagem do desprezo. O primeiro real
"Flamejante" (uma forma de diálogo inflamada e muitas vezes abusiva) na ARPANET havia explodido no
meados da década de 1970. O médium gerou respostas precipitadas e brigas verbais. Ainda em chamas pesadas
foi mantido relativamente sob controle no MsgGroup, que se considerava civilizado. Stefferud
quase sozinho e com a cabeça fria mantiveram o grupo unido quando as coisas começaram
particularmente rouco e contencioso. Ele trabalhou como escravo para manter o MsgGroup funcionando,
analisar cabeçalhos difíceis quando necessário ou eliminar mal-entendidos, tornando
Certifique-se de que o humor do grupo e seu tráfego nunca fiquem muito complicados. Sobre o pior que ele já disse,
quando assolado por problemas técnicos, era que alguns cabeçalhos apresentavam "mau hálito".
Em comparação, havia um grupo de discussão na porta ao lado (metaforicamente falando), chamado
Header People, com fama de ser um inferno. “Normalmente usamos roupas íntimas de amianto”, disse
um participante. Com base no MIT, a Header People foi fundada por Ken Harrenstien em
1976. O grupo não era oficial, mas mais importante, não era moderado (o que significa que tinha
nenhum filtro humano como Stefferud). Harrenstien decidiu recrutar pelo menos um desenvolvedor
de todo tipo de sistema na ARPANET, e em nenhum momento os conflitos no cabeçalho
As pessoas elevaram o debate sobre cabeçalhos ao nível de uma guerra santa antes de explodir. "UMA
bando de preguiçosos corajosos ", disse Harrenstien," batendo um cadáver equino para
pedacinhos. ” Os dois grupos orientados para e-mail se sobrepuseram consideravelmente; mesmo em civilizado

Página 141
Empresa do Msg-Group, os ânimos aumentavam periodicamente. Os ataques ácidos e o nível de
discurso exclusivo para comunicação on-line, inaceitavelmente anti-social em qualquer outro contexto,
era estranhamente normativo na ARPANET. As chamas podem começar a qualquer momento sobre qualquer coisa,
e eles podiam durar uma mensagem ou cem.
A controvérsia FINGER, um debate sobre privacidade na Internet, ocorreu no início de 1979 e
envolveu algumas das piores chamas na experiência do MsgGroup. A luta acabou
a introdução, na Carnegie-Mellon, de um widget eletrônico que permitia aos usuários espiar
nos hábitos on-line de outros usuários na Internet. O comando FINGER foi criado
no início da década de 1970 por um cientista da computação chamado Les Earnest no Stanford's Artificial
Laboratório de inteligência. “As pessoas geralmente trabalhavam longas horas lá, muitas vezes com imprevisíveis
horários ”, disse Earnest. “Quando você queria se encontrar com algum grupo, era importante
para saber quem estava lá e quando os outros provavelmente reapareceriam. Também era importante
ser capaz de localizar jogadores de vôlei em potencial quando você quisesse jogar, comida chinesa
aberrações quando você queria comer e usuários de computador anti-sociais quando parecia que
algo estranho estava acontecendo no sistema. ”FINGER não permite que você leia
mensagens de outra pessoa, mas você pode dizer a data e hora do último logon da pessoa
e quando foi a última vez que ele leu a correspondência. Algumas pessoas têm problemas com isso.
Em um esforço para respeitar a privacidade, Ivor Durham da CMU alterou a configuração padrão do FINGER;
ele adicionou alguns bits que podem ser ligados ou desligados, para que as informações sejam
oculto, a menos que um usuário decida revelá-lo. Durham foi inflamado sem piedade. Ele era
chamou tudo, de covarde a irresponsável socialmente a um político mesquinho, e
pior, mas não para proteger a privacidade. Ele foi criticado por manipular o
abertura da rede.
O debate começou como um diálogo interno na CMU, mas vazou para
theARPANETpor Dave Farber, que queria ver o que aconteceria se ele o revelasse para
o mundo exterior. O festival de chamas que se seguiu consumiu mais de 400 mensagens.
No auge do debate do FINGER, uma pessoa saiu do Msg-Group em desgosto com o
flamejante. Como no debate sobre Quasar, a controvérsia FINGER terminou de forma inconclusiva. Mas
ambos os debates ensinaram aos usuários maiores lições sobre o meio que estavam usando. A velocidade de
o correio eletrônico promoveu o flaming, disseram alguns; qualquer pessoa quente poderia disparar uma réplica no
local, e sem o fator moderador de ter que olhar o alvo nos olhos.
No final da década, o tom do MsgGroup, que havia começado rígido, era um
expansivo livre para todos. Stefferud sempre tentou fazer com que os recém-chegados se apresentassem
eletronicamente quando eles se juntaram ao grupo; ao sair, alguns se despedem apenas para virar
novamente mais tarde em outros sites; apenas uma ou duas pessoas bufaram, bastante cerimoniosamente,
um festival de chamas ou alguma outra indignidade percebida.
Um dos eminentes estadistas do MsgGroup, Dave Crocker, às vezes investigava a Internet
com a curiosidade de um sociólogo. Um dia, por exemplo, ele enviou uma nota para aproximadamente 130
pessoas em todo o país por volta das cinco horas da noite, só para ver quão rápido as pessoas
iria receber a mensagem e responder. As estatísticas de resposta, relatou ele, foram “um pouco
assustador." Sete pessoas responderam em noventa minutos. Dentro de vinte e quatro horas ele tinha
recebeu vinte e oito respostas. Os tempos de resposta e os números desse pedido podem parecer

Página 142
dificilmente digno de nota em uma cultura que, desde então, elevou e reduziu suas expectativas sobre o
velocidade, facilidade e alcance da tecnologia da informação. Mas na década de 1970 “era absolutamente
experiência surpreendente ", disse Crocker, por ter obtido tantas respostas, tão rapidamente,
facilmente, como isso.
Em 12 de abril de 1979, um recém-chegado ao MsgGroup chamado Kevin MacKenzie
angustiado abertamente com a “perda de sentido” neste meio eletrônico e textualmente vinculado.
Inquestionavelmente, o e-mail permitiu uma troca verbal espontânea, mas ele estava preocupado com
sua incapacidade de transmitir gestos humanos, expressões faciais e tom de voz - todos
que vêm naturalmente ao falar e expressam todo um vocabulário de nuances na fala
e pensamento, incluindo ironia e sarcasmo. Talvez, disse ele, pudéssemos estender o conjunto de
pontuação em mensagens de e-mail. A fim de indicar que uma determinada frase se destina a
ser irônico, ele propôs inserir um hífen e parênteses no final do
frase, assim: -).
MacKenzie confessou que a ideia não era inteiramente dele; foi provocado por algo
ele havia lido sobre um assunto diferente em uma cópia antiga do Reader’s Digest. Cerca de uma hora depois,
ele foi inflamado, ou melhor, chamuscado. Foi-lhe dito que sua sugestão era "ingênua, mas não estúpida".
Ele recebeu uma breve palestra sobre o domínio de Shakespeare da língua sem auxiliar
notação. “Aqueles que não aprenderem a usar bem este instrumento não podem ser salvos por um
alfabeto expandido; eles só vão nos afligir com jargões expandidos. ” O que
Shakespeare sabe? ;-) Emoticons e smileys :-), içados pelo hoi polloi sem dúvida,
cresceu no e-mail e na iconografia de nosso tempo.
É um pouco difícil identificar quando ou por quê - talvez fosse exaustão, talvez houvesse
agora havia muitos novos participantes no MsgGroup - mas no início dos anos 1980, nota por nota,
a orquestra que estava se apresentando magnificamente e que tinha criado coletivamente e-
mail ao longo de uma década, começou a abandonar a pontuação, quase imperceptivelmente no início. Uma chave
a voz desapareceria aqui, outra desapareceria ali. Em vez de acordes, ruído branco
parecia ultrapassar gradualmente o MsgGroup.
Em certo sentido, isso não importava. O próprio diálogo no Msg-Group sempre foi
mais importante do que os resultados. Criar os mecanismos de e-mail importava, é claro,
mas o MsgGroup também criou algo totalmente diferente - uma comunidade de iguais, muitos dos
que nunca se conheceram ainda que agiam como se se conhecessem
a vida deles. Foi o primeiro lugar que encontraram algo que procuravam desde
o ARPANET passou a existir. O MsgGroup foi talvez o primeiro virtual
comunidade.
O romance da Net não veio de como foi construída ou como funcionou, mas de como
foi usado. Em 1980, a Internet era muito mais do que uma coleção de computadores e linhas alugadas.
Era um lugar para compartilhar trabalho e construir amizades e um método mais aberto de
comunicação. O romance da América com o sistema de rodovias, por analogia, foi criado
não tanto pela primeira pessoa que descobriu como nivelar uma estrada ou fazer asfalto ou
pinte uma faixa no meio, mas pela primeira pessoa que descobrir que você pode dirigir um
conversível pela Rota 66 como James Dean e tocar seu rádio alto e ter um ótimo
Tempo.

Página 143

8
Um foguete em nossas mãos
Bob Kahn deixou a BBN e foi trabalhar para Larry Roberts em 1972. Ele havia adiado seu
chegada a Washington por um ano para ficar em Cambridge e planejar a demonstração do ICCC.
Depois de passar seis anos ininterruptos focado em redes de computadores, ele agora estava pronto
para fazer uma ruptura limpa. Ele não queria executar um projeto de rede. Então ele e Roberts
concordou que Kahn estabeleceria um novo programa em técnicas de manufatura automatizadas.
Mas o Congresso cancelou o projeto antes da chegada de Kahn. Até agora, o ARPA tinha sido
alterado para DARPA - a Agência de Projetos de Pesquisa Avançada de Defesa. Como Kahn uma vez
coloquei, o D sempre esteve lá, mas agora não estava mais silencioso. o
nameARPANETremained.
Com o projeto de manufatura encerrado, Kahn foi chamado de volta ao campo em que havia
especialista crescido. Mas ele queria trabalhar nos experimentos mais recentes.
O início dos anos 1970 foi uma época de intensa experimentação com redes de computadores. UMA
poucas pessoas estavam começando a pensar em novos tipos de redes de pacotes. O básico
os princípios de comutação de pacotes provavelmente não seriam melhorados drasticamente. E a
protocolos, interfaces e algoritmos de roteamento para tratamento de mensagens estavam crescendo mais
refinado. Uma área que ainda precisa ser explorada, entretanto, é o meio pelo qual os dados viajam.
A rede existente de linhas telefônicas da AT&T foi a primeira escolha óbvia. Mas por que
não faz uma rede sem fio transmitindo pacotes de dados “no ar” como ondas de rádio?
Em 1969, antes de Bob Taylor deixar a ARPA, ele montou um financiamento para uma rádio local
rede a ser construída na Universidade do Havaí. Foi desenhado por um professor chamado
Norm Abramson e vários colegas. Eles construíram um sistema simples usando rádios
para transmitir dados para frente e para trás entre sete computadores estacionados em quatro ilhas.
Abramson chamou isso de ALOHA.
O ALOHANET usava rádios pequenos, idênticos aos usados por táxis, compartilhando
frequência em vez de canais separados. O sistema empregou um protocolo muito relaxado.
A ideia central era fazer com que cada terminal transmitisse quando quisesse. Mas se os dados
colidiu com a transmissão de outra pessoa (o que aconteceu quando havia muitos
tráfego), os receptores não seriam capazes de decodificar nenhuma das transmissões corretamente. Então se o
o rádio de origem não obteve um reconhecimento, ele assumiu que o pacote havia sido truncado; isto
retransmitiu o pacote posteriormente em um intervalo aleatório. O sistema ALOHA era como um
serviço telefônico que disse a você, depois que você tentou falar, e não até então, que a linha
Estava ocupado.
Roberts e Kahn gostaram da ideia geral de links de rádio entre computadores. Porque não fazer
algo ainda mais desafiador: conceber pequenos "sites" para computadores portáteis transportados
em veículos ou mesmo manualmente, conectados em uma rede de comutação de pacotes? Em 1972
Roberts delineou o esquema. Ele imaginou uma rede em que um minicomputador central

Página 144
situado em uma estação de rádio potente se comunicaria com um computador móvel menor
sites. Roberts pediu ao SRI que estudasse o problema e elaborasse um sistema prático.
O conceito de sites de computadores móveis teve um apelo óbvio para o Exército. Campo de batalha
computadores instalados em veículos ou aeronaves - alvos móveis - seriam menos vulneráveis
e mais útil do que instalações fixas. Ainda assim, a destruição do único mais crucial
elemento - o computador mestre estacionário em um sistema centralizado - tiraria um
toda a rede. A necessidade de se defender desse perigo foi o que levou Paul Baran a
conceber redes distribuídas em primeiro lugar. Portanto, do ponto de vista de sobrevivência e
de fácil implantação, a rede de pacotes de rádio foi concebida como uma versão sem fio de
theARPANET, distribuída em vez de centralizada. Ao longo dos anos, o rádio pacote
programa foi implantado em um punhado de locais militares, mas problemas técnicos o tornaram
caro, e eventualmente foi desativado.
O alcance limitado dos sinais de rádio tornou necessário que as redes de pacotes de rádio usassem
sites de retransmissão separados por não mais do que algumas dezenas de quilômetros. Mas um link acima da terra
teria
sem tais restrições. Tal relé “veria” quase um hemisfério inteiro da Terra.
Enquanto supervisionava os projetos de rádio de pacote, Kahn começou a pensar em redes vinculadas
por satélites acessíveis em amplos domínios - de e para navios no mar, remotos baseados em terra
estações e aeronaves voando em quase qualquer lugar do mundo.
No início dos anos 1970, muitos satélites de comunicações - a maioria deles militares - estavam em
órbita. Apropriadamente equipado, esse satélite pode servir como um relé de comunicação.
Com as enormes distâncias envolvidas nas comunicações por satélite, os sinais seriam atrasados.
A viagem média de um pacote ao seu destino levaria cerca de um terço de segundo,
várias vezes mais do que os atrasos host-a-host na ARPANET. Como resultado, o pacote
as redes de satélite seriam lentas.
Ainda assim, a ideia de que as redes comutadas por pacotes e seus computadores conectados podem ser ligados
por ondas de rádio refletidas por um satélite era atraente, não apenas para o americano
governo, mas também para os europeus, porque os circuitos terrestres transatlânticos da época
eram caros e sujeitos a erros. A rede de satélite foi apelidada de SATNET.
Pesquisadores nos Estados Unidos se juntaram a britânicos e noruegueses computador
cientistas, e em pouco tempo links de satélite foram estabelecidos para a Itália e Alemanha também.
Por um tempo, SATNET fez bem. Com o tempo, no entanto, a companhia telefônica atualizou seu
linhas transatlânticas de cobre para cabos de fibra óptica de alta velocidade, eliminando a necessidade de
o mais complicado link SATNET.
As lições técnicas dos experimentos de rádio e satélite foram menos significativas do que o
ideias de networking mais amplas que inspiraram. Era óbvio que haveria mais redes.
Vários governos estrangeiros estavam construindo sistemas de dados e um número crescente de grandes
as corporações estavam começando a desenvolver suas próprias idéias de networking. Kahn começou
questionando sobre a possibilidade de ligar as diferentes redes entre si.
O problema ocorreu a ele pela primeira vez quando estava trabalhando no projeto de rádio em pacotes em 1972.
“Minha primeira pergunta foi: 'Como vou ligar este sistema de rádio de pacote a qualquer
recursos computacionais de interesse? '”, disse Kahn. “Bem, minha resposta foi: 'Vamos vinculá-lo a

Página 145
theARPANET, 'exceto que estas eram duas redes radicalmente diferentes em muitos aspectos. ”
No ano seguinte, outro esforço do ARPA, denominado Projeto Internetting, nasceu.
Na época da demonstração da ICCC de 1972 em Washington, os líderes de vários
projetos de rede nacionais formaram um Grupo de Trabalho de Rede Internacional
(INWG), com Vint Cerf no comando. Projetos de rede de comutação de pacotes na França e
A Inglaterra estava produzindo resultados favoráveis. O trabalho de Donald Davies no UK's National
O Laboratório Físico estava indo esplendidamente. Na França, um cientista da computação chamado
Louis Pouzin estava construindo Cyclades, uma versão francesa da ARPANET. Ambos Pouzin
e Davies compareceu à demonstração do ICCC em Washington. “O espírito depois
ICCC ", disse Alex McKenzie, representante da BBN para o INWG," foi, 'Nós mostramos
que a comutação de pacotes realmente funciona nacionalmente. Vamos assumir a liderança na criação de um
rede internacional de redes. '”
Larry Roberts estava entusiasmado com o INWG porque queria estender o alcance da
o ARPANET além do mundo financiado pelo DARPA. Os britânicos e os franceses eram
igualmente entusiasmados com a expansão do alcance de suas redes nacionais de pesquisa.
“Desenvolver tecnologia de interconexão de rede foi uma maneira de perceber isso”, disse
McKenzie. O INWG começou a buscar o que chamou de “Rede Concatenada”,
orCATENET; em resumo, uma interconexão transparente de redes de diferentes
tecnologias e velocidades.

Uma Internet
A colaboração que Bob Kahn caracterizaria anos depois como a mais satisfatória de
sua carreira profissional durou vários meses em 1973. Kahn e Vint Cerf tiveram
se conheceram durante as semanas de testes na UCLA no início de 1970, quando forçaram o
recém-nascido ARPANETem catatonia ao sobrecarregar os IMPs com tráfego de teste. Eles tinham
permaneceram colegas próximos, e agora ambos estavam pensando muito sobre o que
levar para criar uma conexão contínua entre redes diferentes. “Nessa época”, Cerf
relembrou: “Bob começou a dizer: 'Olha, meu problema é como consigo um computador que está em um
rede de satélite e um computador em uma rede de rádio e um computador na ARPANET para
comunicar-se uniformemente entre si sem perceber o que está acontecendo no meio? '”
Cerf ficou intrigado com o problema.
Em algum momento durante a primavera de 1973, Cerf estava participando de uma conferência em San Francisco
hotel, sentado no saguão esperando o início de uma sessão, quando ele começou a rabiscar alguns
Ideias. A essa altura, ele e Kahn já estavam conversando há vários meses sobre o que seria necessário
para construir uma rede de redes, e ambos trocavam ideias com outros
membros do Grupo de Trabalho da Rede Internacional. Ocorreu a Cerf e Kahn que
o que eles precisavam era de um "gateway", um computador de roteamento entre cada um desses
várias redes para passar mensagens de um sistema para outro. Mas isso foi mais facil
dito do que feito. “Nós sabíamos que não podíamos mudar nenhuma das redes de pacotes”, Cerf
disse. “Eles fizeram tudo o que fizeram porque foram otimizados para aquele ambiente.” Como
no que diz respeito a cada rede, o gateway deve se parecer com um host comum.
Enquanto esperava no saguão, ele desenhou este diagrama:

Página 146
Reprodução das primeiras idéias de design da Internet
“Nossa ideia era que, claramente, cada gateway deveria saber como se comunicar com cada rede
ao qual estava conectado ”, disse Cerf. “Digamos que você esteja conectando a rede de rádio de pacotes com
theARPANET. A máquina de gateway possui um software que a faz parecer um host para
theARPANETIMPs. Mas também se parece com um host na rede de rádio de pacotes. ”
Com a noção de um gateway agora definida, o próximo quebra-cabeça foi a transmissão de pacotes. Como
com a ARPANET, o caminho real que os pacotes percorrem em uma internet deve ser
imaterial. O mais importante é que os pacotes cheguem intactos. Mas houve uma irritante
problema: todas essas redes - packet radio, SATNET e theARPANET - tinham diferentes
interfaces, diferentes tamanhos máximos de pacotes e diferentes taxas de transmissão. Como pôde
todas essas diferenças sejam padronizadas para fazer o transporte de pacotes entre as redes? UMA
a segunda questão dizia respeito à confiabilidade das redes. A dinâmica do rádio e
a transmissão via satélite não permitiria a confiabilidade que foi tão laboriosamente construída em
theARPANET. Os americanos olharam para Pouzin na França, que havia escolhido deliberadamente
uma abordagem para Cyclades que exigia que os hosts em vez dos nós da rede recuperassem
de erros de transmissão, transferindo o fardo da confiabilidade para os hosts.
Ficou claro que o protocolo de controle de rede host-a-host, que foi projetado para corresponder
as especificações da ARPANET, teriam que ser substituídas por uma mais independente
protocolo. O desafio para o Grupo de Trabalho da Rede Internacional era conceber
protocolos que podem lidar com redes autônomas operando sob suas próprias regras,
ao mesmo tempo em que estabelece padrões que permitiriam aos hosts nas diferentes redes falar
um para o outro. Por exemplo, CATENET permaneceria um sistema de forma independente
redes administradas, cada uma administrada por seu próprio pessoal com suas próprias regras. Mas quando tempo
veio para uma rede para trocar dados com, digamos, a ARPANET, a internetworking
protocolos operariam. Os computadores gateway que lidam com a transmissão não se importaram
sobre a complexidade local enterrada dentro de cada rede. Sua única tarefa seria obter
pacotes através da rede para o host de destino do outro lado, fazendo um assim chamado
link ponta a ponta.

Página 147
Uma vez que a estrutura conceitual foi estabelecida, Cerf e Kahn passaram a primavera e
verão de 1973 elaborando os detalhes. Cerf apresentou o problema ao seu Stanford
alunos de pós-graduação, e ele e Kahn se juntaram a eles no ataque. Eles realizaram um seminário que
concentrado nos detalhes do desenvolvimento do protocolo host-a-host em um padrão
permitindo que o tráfego de dados flua pelas redes. O seminário de Stanford ajudou a estruturar
problemas, e lançou as bases para soluções que surgiriam vários anos depois.
Cerf visitava frequentemente os escritórios da DARPA em Arlington, Virgínia, onde ele e Kahn
discutiu o problema por horas a fio. Durante uma sessão de maratona, os dois ficaram acordados
a noite toda, rabiscando alternadamente no quadro-negro de Kahn e andando pelo deserto
ruas suburbanas, antes de terminar no Marriott local para o café da manhã. Eles começaram
colaborando em um papel e conduzindo sua próxima sessão maratona no Cerf's
bairro, trabalhando noite adentro no Hyatt em Palo Alto.
Em setembro daquele ano, Kahn e Cerf apresentaram seu artigo junto com suas idéias sobre o
novo protocolo para o Grupo de Trabalho da Rede Internacional, reunindo-se simultaneamente com um
conferência de comunicações na Universidade de Sussex em Brighton. Cerf estava atrasado
chegando à Inglaterra porque seu primeiro filho acabara de nascer. “Eu cheguei no meio da sessão
e fui saudado com aplausos porque a notícia do nascimento me precedeu por e-mail, ”Cerf
recordado. Durante a reunião de Sussex, Cerf descreveu as idéias que ele e Kahn e o
Seminário de Stanford gerou. As ideias foram refinadas ainda mais em Sussex, por muito tempo
discussões com pesquisadores dos laboratórios de Davies e Pouzin.
Quando Kahn e Cerf voltaram da Inglaterra, eles refinaram seu jornal. Ambos os homens tiveram um
lado teimoso. “Entrávamos nesse estado argumentativo, então recuávamos e dizíamos: 'Vamos encontrar
sobre o que estamos realmente discutindo. ' ”Cerf gostava de ter tudo organizado
antes de começar a escrever; Kahn preferia sentar e escrever tudo o que pudesse
pense, em sua própria ordem lógica; a reorganização veio depois. A escrita colaborativa
processo foi intenso. Cerf relembrou: “Era um de nós digitando e o outro respirando
pelo pescoço, compondo à medida que avançávamos, quase como duas mãos em uma caneta. ”
No final de 1973, Cerf e Kahn concluíram seu artigo, “A Protocol for Packet
Intercomunicação de rede. ” Eles jogaram uma moeda para determinar qual nome deveria
aparecer primeiro, e Cerf ganhou o sorteio. O jornal apareceu em uma revista de engenharia amplamente lida
diário na primavera seguinte.
Como o primeiro artigo de Roberts delineando a proposta ARPANET sete anos antes, o Cerf-
O artigo de Kahn de maio de 1974 descreveu algo revolucionário. Sob a estrutura
descrito no papel, as mensagens devem ser encapsuladas e desencapsuladas em "dados
gramas ”, da mesma forma que uma carta é colocada e retirada de um envelope e enviada de ponta a ponta
pacotes. Essas mensagens seriam chamadas de protocolo de controle de transmissão, ou TCP,
mensagens. O artigo também introduziu a noção de gateways, que leria apenas o
envelope para que apenas os hosts de recebimento leiam o conteúdo.
O protocolo TCP também resolveu os problemas de confiabilidade da rede. Na ARPANET, o
O IMP de destino foi responsável por remontar todos os pacotes de uma mensagem quando
chegou. Os IMPs trabalharam duro para garantir que todos os pacotes de uma mensagem passassem pelo
rede, usando confirmações e retransmissão salto a salto. Os IMPs também fizeram

Página 148
certificar-se de que mensagens separadas foram mantidas em ordem. Por causa de todo esse trabalho feito pelos
IMPs, o
antigo protocolo de controle de rede foi construído em torno do pressuposto de que a base
rede era totalmente confiável.
O novo protocolo de controle de transmissão, com uma reverência a Cyclades, assumiu que
theCATENET era completamente não confiável. Unidades de informação podem ser perdidas, outras podem
ser duplicado. Se um pacote não chegou ou foi truncado durante a transmissão, e o
o host de envio não recebeu confirmação, um gêmeo idêntico foi transmitido.
A ideia geral por trás do novo protocolo era mudar a confiabilidade da rede para
os hosts de destino. “Nós nos concentramos na confiabilidade de ponta a ponta”, lembra Cerf. ”Não confie
em qualquer coisa dentro dessas redes. A única coisa que pedimos que a rede faça é pegar esta
pedaço de bits e passe-o pela rede. É tudo o que pedimos. Basta pegar este datagrama e
faça o seu melhor para entregá-lo. ”
O novo esquema funcionava quase da mesma maneira que os contêineres de transporte são usados para
transferir mercadorias. As caixas têm tamanho e formato padrão. Eles podem ser preenchidos com
qualquer coisa, desde televisores a roupas íntimas e automóveis - o conteúdo não importa. Eles
mover por navio, trem ou caminhão. Um contêiner típico de carga viaja por todos os três modos em
várias etapas para chegar ao seu destino. A única coisa necessária para garantir o cruzamento
compatibilidade é o equipamento especializado usado para transferir os recipientes de um modo
de transporte para o próximo. A carga em si não sai do contêiner até chegar ao seu
destino.
A invenção do TCP seria absolutamente crucial para a rede. Sem TCP,
a comunicação através das redes não poderia acontecer. Se o TCP pudesse ser aperfeiçoado, qualquer um
poderia construir uma rede de qualquer tamanho ou forma, e desde que essa rede tivesse um gateway
computador que pode interpretar e rotear pacotes, pode se comunicar com qualquer outro
rede. Com o TCP no horizonte, agora era óbvio que a rede tinha um futuro bem
além da ARPANET experimental. O poder potencial e alcance do que não só
Cerf e Kahn, mas Louis Pouzin na França e outros, estavam inventando e começando a
ocorrer às pessoas. Se eles pudessem resolver todos os detalhes, o TCP pode ser o mecanismo que
abriria mundos.
À medida que mais recursos se tornam disponíveis na ARPANET e mais pessoas nos sites
tornou-se familiarizado com eles, o uso da Internet aumentou. Para notícias do mundo, início da Net
regulares regularmente logados em uma máquina no SRI, que estava conectado ao Associado
Imprensa fio de notícias. Durante os horários de pico, os alunos do MIT se conectavam a algum outro computador
a Internet para fazer seu trabalho. Imagens acústicas e holográficas produzidas na UC Santa
Bárbara foi digitalizada em máquinas da USC e trazida de volta pela Internet para uma imagem
processador na UCSB, onde poderiam ser manipulados posteriormente. O laboratório da UCSB foi
equipado com equipamentos de processamento de imagem personalizados e pesquisadores da UCSB
traduziu matemática de alto nível em produção gráfica para outros sites. Em agosto de 1973,
enquanto o TCP ainda estava em fase de projeto, o tráfego cresceu para uma média diária de 3,2
milhões de pacotes.

Página 149
De 1973 a 1975, a Rede se expandiu à taxa de cerca de um novo nó a cada mês.
O crescimento estava ocorrendo em linha com a visão original de Larry Roberts, na qual a rede
foi deliberadamente sobrecarregado com grandes fornecedores de recursos. A este respeito, a DARPA tinha
teve um sucesso maravilhoso. Mas o efeito foi um desequilíbrio de oferta e demanda; há
havia muitos provedores de recursos e clientes insuficientes. A introdução de
IMPs terminais, primeiro em Mitre, depois no Ames Research Center da NASA e no National
O Bureau of Standards, com até sessenta e três terminais cada, ajudou a acertar o equilíbrio.
O acesso aos próprios sites de host estava ficando mais fraco. A máquina host em UCSB, para
por exemplo, estava ligado a minicomputadores nas áreas de ciência política, física e química
departamentos. Padrões semelhantes estavam se revelando no mapa da rede.
Como a maioria dos primeiros sites de host ARPANET, o Center for Advanced Computation no
A Universidade de Illinois foi escolhida principalmente pelos recursos que seria capaz de oferecer
outros usuários da Internet. Na época em que Roberts estava mapeando a rede, Illinois estava programada para
torne-se o lar do novo e poderoso ILLIAC IV, um enorme e único de alta velocidade
computador em construção na Burroughs Corporation em Paoli, Pensilvânia. o
máquina tinha a garantia de atrair pesquisadores de todo o país.
Uma reviravolta inesperada das circunstâncias, no entanto, levou a Universidade de Illinois a se tornar
o primeiro consumidor em grande escala da rede em vez de um fornecedor de recursos. Alunos no
O campus Urbana estava convencido de que o ILLIAC IV seria usado para simular
cenários de bombardeio para a Guerra do Vietnã e para realizar pesquisas ultrassecretas no campus.
Conforme os protestos do campus irromperam sobre a instalação iminente, os funcionários da universidade cresceram
preocupados com sua capacidade de proteger o ILLIAC IV. Quando Burroughs terminou
construção da máquina, ele foi enviado para uma instalação mais segura administrada pela NASA.
Mas o Centro de Computação Avançada já tinha seu IMP e acesso total ao
rede. Os pesquisadores adotaram rapidamente a nova capacidade de explorar
recursos de computação - tão rapidamente, na verdade, que o Centro encerrou os $ 40.000 mensais
alugar seu próprio Burroughs B6700 de alta potência. Em seu lugar, a universidade começou
contratação de serviços informáticos através da ARPANET. Ao fazer isso, o cálculo
center cortou sua conta de computador quase pela metade. Esta foi a economia de escala idealizada por
Roberts, levado a um nível além das expectativas de qualquer pessoa. Logo, o Centro estava obtendo
mais de 90 por cento de seus recursos de computador através da rede.
Grandes bancos de dados espalhados pela Internet estavam crescendo em popularidade. O computador
Corporation of America tinha uma máquina chamada Datacomputer que era essencialmente um
armazém de informações, com dados meteorológicos e sísmicos alimentados na máquina ao redor do
relógio. Centenas de pessoas faziam login todas as semanas, tornando-o o site mais movimentado do
rede há vários anos.
Incentivado por novos dados, o ARPANET estava começando a atrair a atenção de
pesquisadores da computação em uma variedade de campos. O acesso à rede ainda estava limitado a sites
com contratos DARPA, mas a diversidade de usuários nesses sites estava criando um
comunidade de usuários distinta dos engenheiros e cientistas da computação que construíram
theARPANET. Os programadores que ajudam a projetar estudos médicos podem vincular-se ao

Página 150
Rico banco de dados MEDLINE da National Library of Medicine. Escola Pública da UCLA
A Health criou um banco de dados experimental de avaliações de programas de saúde mental.
Para servir à crescente comunidade de usuários, os pesquisadores SRI estabeleceram um recurso exclusivo
chamado de ARPANETNews em março de 1973. Distribuído mensalmente em formato de tinta no papel, o
jornal também estava disponível na Internet. Uma mistura de listas de conferências, atualizações de sites e
resumos de artigos técnicos, o boletim informativo parecia uma fofoca de cidade pequena cheia de
jargão da informática. Um dos itens mais importantes da ARPANETNews foi o
Série “Site em destaque”, na qual os gerentes de sistema da lista crescente de computadores host
descreveu o que eles tinham a oferecer. Em maio de 1973, a Case Western Reserve University, que
estava vendendo serviços de computador para usuários de rede, descreveu seu PDP-10 em termos que
soava totalmente como um anúncio da seção Personals: “O caso está aberto para colaboração
proposições envolvendo permutas de tempo com outros sites para trabalhos relacionados aos interesses aqui,
e vendas de tempo como serviço. ”
A comunicação por computador e o uso de recursos remotos ainda eram complicados
processos. Na maior parte, a Internet permaneceu um ambiente hostil ao usuário, exigindo
conhecimento de programação relativamente sofisticado e uma compreensão dos diversos
sistemas em execução nos hosts. A demanda estava crescendo entre os usuários de "nível superior"
programas de aplicativos destinados a ajudar os usuários a aproveitar a variedade de recursos agora
acessível. Os programas de transferência de arquivos e Telnet existiam, mas a comunidade de usuários queria
mais ferramentas, como editores comuns e esquemas de contabilidade.
O Network Information Center da SRI estimou o número de usuários em cerca de dois mil.
Mas um grupo de interesse de usuários recém-formado, chamado USING, estava convencido de que havia uma
lacuna
entre o design dos recursos de rede e as necessidades das pessoas que tentam usar
esses recursos. Visualizando-se como um grupo de lobby, um sindicato de consumidores
mesmo, USING começou imediatamente a traçar planos e recomendações para melhorar
a prestação de serviços informáticos através da ARPANET.
Mas a DARPA não viu necessidade de compartilhar autoridade com um pequeno grupo de vigilância auto-nomeado
formado por pessoas que a agência via como passageiros de seu veículo experimental. o
iniciativa morreu após cerca de nove meses com um memorando conciso de um programa da DARPA
gerente chamado Craig Fields, avisando o grupo de que havia ultrapassado seus limites. Com
nem financiamento nem apoio oficial para o seu esforço futuro, os membros colocaram
um estado de animação suspensa do qual nunca emergiu.
Outros problemas surgiram para a DARPA conforme o perfil da rede começou a se elevar. Gostar
theUSINGinsurgency, a maioria eram assuntos relativamente menores. Mas juntos eles ilustraram o
tensões em curso relacionadas com a administração da rede da DARPA. Uma área de tensão
teve a ver com os mestres do Pentágono da DARPA. IPTO, em particular, conseguiu evitar
a pesquisa militar mais gritante. Mas enquanto os alunos de Illinois estavam errados sobre o
ILLIAC IV sendo usado para missões de bombardeio simuladas contra o Vietnã do Norte,
lá estavam os planos de usá-lo para cenários de ataque nuclear contra a União Soviética. Similarmente,
pesquisadores de todos os tipos usaram informações sísmicas armazenadas na Computer Corporation de
Servidor de banco de dados da América (CCA), informações que estavam sendo coletadas para apoiar
Projetos do Pentágono envolvendo testes atômicos subterrâneos.

Página 151
No final dos anos 1960, a crescente agitação política - violenta e não violenta - pegou os EUA
militar de surpresa. A inteligência do exército sabia tudo sobre Praga, Berlim e Moscou, mas
agora o Pentágono estava contemplando Newark, Detroit e Chicago. O Exército reuniu
informações de dezenas de cidades dos EUA sobre a localização de delegacias de polícia e bombeiros,
hospitais e assim por diante. Alguém no Pentágono achou que seria uma boa ideia manter
rastrear os encrenqueiros locais também.
Em 1972, o clamor público eclodiu sobre a coleta de informações do Exército, e a ordem foi
para que os arquivos sejam destruídos imediatamente. Mas três anos depois, surgiram alegações
que os oficiais de inteligência do Exército, em vez disso, usaram o ARPANET para mover os arquivos para um novo
localização. Quando a história estourou, o fato de que algo como ARPANET existia era
notícias para a maioria dos americanos. Que a história foi relatada da forma mais draconiana, manto-e-
termos de punhal apenas aumentaram a reação tempestuosa. O resultado foi uma investigação do Senado em
qual a DARPA foi chamada para explicar como estava usando aARPANET.
A DARPA acabou provando que os arquivos do Exército não haviam sido transferidos para a ARPANET por
revisando centenas de rolos de impressões de teletipo que foram armazenados em um rastreamento empoeirado
espaço na BBN. A DARPA foi justificada, mas um aparente envolvimento com o Exército
operações clandestinas era a última coisa de que a ARPANET precisava.

Mudanças na DARPA
Discussões sobre como a DARPA acabaria por se desfazer da responsabilidade operacional pelo
rede já havia começado por volta de 1971. A DARPA havia estabelecido para vincular o processamento de núcleo
recursos nos principais centros de pesquisa de ciência da computação da América, e até a agência
agora estava preocupado, tinha conseguido isso. Sua missão era pesquisar. Não foi
supostamente no negócio de operar uma rede. Agora que o sistema estava funcionando e
correndo, estava se tornando um dreno em outras prioridades. Era hora de a DARPA se livrar do
papel do provedor de serviços.
Lidar com a transição era uma questão delicada. O ARPANET era agora uma ferramenta valiosa, e
O objetivo de Roberts era garantir seu desenvolvimento contínuo. Ele encomendou vários
estudos para ajudar a determinar a melhor opção. O melhor caminho, parecia, era manter um
esforço de pesquisa de rede, mas vender a própria rede para um contratante privado. Mas venda
a quem? O mercado de redes de comunicação de dados ainda estava em grande parte desconhecido, e
as grandes empresas de comunicação permaneceram tão céticas como sempre sobre o DARPA
tecnologia.
Quando Roberts entrou em contato com a AT&T para ver se ela queria assumir a ARPANET, a AT&T
formou um comitê de funcionários corporativos e da Bell Labs e estudou a ideia por meses.
A AT&T poderia ter possuído a rede como um serviço de monopólio, mas no final declinou.
“Eles finalmente concluíram que a tecnologia de pacotes era incompatível com a AT&T
rede ”, disse Roberts.
Outros não estavam tão cegos às perspectivas das redes de computadores. Em julho de 1972 três
engenheiros deixaram a BBN para formar uma empresa que comercializaria uma rede comercial chamada
Packet Communications Incorporated. E a própria BBN conversou com Roberts sobre

Página 152
comprar a rede e abrir uma subsidiária para operá-la. Pequeno, especializado,
transportadoras comerciais como essas eram a solução óbvia para o problema da DARPA.
Mas logo Roberts teve um novo problema. No início de 1973, a BBN o recrutou para administrar um novo
subsidiária chamadaTELENET (não deve ser confundida com Telnet, o programa para log remoto
ins), que comercializaria um serviço privado de comutação de pacotes. Agora não posso recomendar
uma venda do governo para a TELENET, Roberts conseguiu
a ARPANET transferida temporariamente para a Agência de Comunicações de Defesa - a
mesma agência que Baran se recusou a deixar construir sua rede dez anos antes. o
generais, majores e capitães ainda eram apenas um pouco mais receptivos à ideia de um
rede comutada por pacotes do que a AT&T, mas Roberts esperava que isso fosse apenas um
arranjo.
Tendo decidido aceitar o cargo emTELENET, Roberts agora tinha a tarefa de encontrar um
sucessor. O Escritório de Técnicas de Processamento de Informações da DARPA, no entanto, não funcionou mais
o apelo que uma vez teve para os acadêmicos. Roberts abordou alguns de seus diretores
investigadores em universidades, mas as pessoas que tinham programas de pesquisa ativos não queriam
Deixe-os. Outros estavam preocupados com os cortes salariais que teriam de sofrer para chegar
para o escritório da DARPA.
Quando Licklider soube do problema que Roberts estava tendo, ele se ofereceu para voltar se Roberts
precisava dele. Roberts sabia que era apenas um gesto da parte de Licklider. Lick agora estava feliz
entrincheirado de volta no MIT. Mas depois de seis meses de pesquisa, Roberts decidiu que não
tem uma escolha. Quando Roberts ligou para o escritório de Lick no MIT, foi informado que Lick estava em um
passeio a pé na Inglaterra. Roberts o localizou no meio do País de Gales e perguntou
ele se ele estava falando sério sobre aceitar o trabalho. Licklider disse que sim. “Eu nunca vi Larry tão
muito feliz quando finalmente conseguiu seu substituto, porque ele estava pronto para ir ”, lembrou um
colega de Roberts. “Acho que um pouco de seu deleite era também o fato de que Lick estava indo
pegue, porque ele gostava dele. Todo mundo fez. ”
Um dos primeiros problemas que Lick enfrentou ao retornar foi um problema estranho envolvendo a BBN,
seu antigo empregador. BBN se recusava a liberar o código-fonte IMP - o original
programa operacional escrito pelo IMP Guys cinco anos antes.
O aparente impulso da BBN de controlar todos os aspectos da rede criou uma certa tensão
do começo. Len Kleinrock e seu grupo na Network Measurement da UCLA
Center achou isso particularmente frustrante. O trabalho do centro era encontrar problemas no
rede, mas quando o fizeram, a BBN se recusou a ajudar. “Sempre que encontramos um bug de software ou
ineficiência, alertaríamos o Heart especificamente, e a resposta que obtivemos foi normalmente quase um
braço rígido ”, disse Kleinrock. “Ele dizia: 'Olha, a rede está funcionando, eu tenho uma rede
para continuar funcionando e colocaremos seu comentário na fila. ' Não podíamos consertar
nós mesmos porque não tínhamos o código-fonte. ”
A questão da propriedade intelectual finalmente explodiu quando os engenheiros que deixaram a BBN para
iniciar sua própria empresa fez um pedido direto para seu antigo empregador entregar
o código-fonte IMP. Quando a BBN se recusou, eles apelaram para a DARPA. Enquanto mantém
o código-fonte proprietário geralmente é prerrogativa da empresa que o desenvolve, a
O código-fonte do IMP era diferente, pois havia sido desenvolvido pela BBN com fundos federais.

Página 153
Além disso, a BBN estava no meio do início da subsidiáriaTELENET, que seria
competir com a empresa iniciada pelos engenheiros. Houve alguma preocupação em
DARPA que se alguém no Congresso ou corpo de imprensa se agarrou ao fato de que a BBN
subsidiária e ninguém mais teve acesso ao IMP patrocinado pelo Departamento de Defesa
tecnologia, a agência pode ter um grande problema em suas mãos.
Frank Heart e Dave Walden da BBN argumentaram que desde que o código-fonte foi alterado
frequentemente para melhorar o desempenho ou corrigir bugs, a empresa ficava desconfortável com
distribuir software que se tornaria obsoleto. A empresa se manteve firme.
Steve Crocker, então gerente de programa da DARPA que supervisionava a maior parte da BBN
contratos, encarregou-se da situação. Ele tinha o controle de cerca de US $ 6 milhões em trabalho
por ano na BBN, cerca de um quarto da receita bruta da empresa. “Eu considerei seriamente
movendo todo o trabalho que estávamos apoiando na BBN para outros lugares porque não podíamos
chegar a um acordo com eles sobre os direitos de dados para o código IMP ”, disse ele. E ele deixou a BBN
sabe o que ele estava pensando.
Lick tinha uma longa associação com a BBN e tinha grande consideração pelas pessoas de lá, mas
ele ficou consternado com a postura deles. A reação em toda a comunidade de computadores foi
quase o mesmo. Finalmente, em resposta direta à ameaça de Crocker, a BBN concordou em fornecer o
código para quem o solicitou, cobrando uma taxa de manuseio nominal. “Este foi apenas um início
versão de problemas de direitos de propriedade intelectual muito mais sérios que surgiram em todo o
indústria nas próximas décadas ”, disse Crocker.
Com a ajuda de Bob Kahn, Licklider também terminou o trabalho de separar a rede para o
Agência de Comunicações de Defesa. As primeiras investigações de Roberts para vender a rede
não obstante, as regras federais exigiam que um recurso tão rico como o ARPANET não pudesse
apenas ser vendido a um terceiro até que o Departamento de Defesa determinasse se ele tinha um
necessidade da Rede na Defesa. A agência acabou decidindo que sim. No verão de
1975, DCA assumiu o trabalho de gerenciamento de rede da DARPA. Agora DCA definido
política operacional da rede. DCA decidiu coisas como onde e quando novo
nós seriam instalados e qual deveria ser a configuração das linhas de dados. E BBN
manteve o contrato de operação de rede, o que significava que a empresa realizava o
decisões tomadas pelo DCA. Logo após a transição ter sido feita, Lick voltou para
MIT, onde passaria o resto de sua carreira.
Logo todos na BBN notaram um número crescente de formulários que precisavam ser preenchidos,
mesmo para o menor dos trabalhos. A burocracia DCA abalou muitos universitários,
também. “A agência gerou uma enxurrada de memorandos de coronéis e generais sobre
coisas que você podia ou não podia fazer ”, relembrou Brian Reid. Alguns meses depois
DCA assumiu a ARPANET, vários dos alunos de graduação no computador de Stanford
o departamento de ciências veio a uma festa de Halloween vestidos de coronéis.
Livre das tarefas de gestão do dia-a-dia, a DARPA agora era capaz de se concentrar em
desenvolver os novos protocolos CATENET. Em 1975, Yogen Dalal, graduado em Stanford
estudante, havia polido o Protocolo de Controle de Transmissão de Cerf e Kahn de 1974
papel em um conjunto de especificações concretas. A especificação TCP foi enviada para três

Página 154
lugares separados para implementação simultânea: BBN, laboratório de informática de Cerf em Stanford,
e University College, Londres.
Mais ou menos na mesma época, Kahn e Steve Crocker começaram a conversar com Cerf sobre aceitar um emprego
como gerente do programa DARPA em Washington. “Eu voei lá e pousei em um grande
tempestade de neve e pensei, não quero viver nesta parte do país ”, lembrou Cerf.
“Então eu disse não. Mas o verdadeiro motivo era que eu estava com medo de não fazer um trabalho muito bom. Eu
pensei que seria uma posição muito visível e se eu errasse, todos saberiam. ”
Um ano depois, Kahn e Crocker tentaram novamente. Desta vez, Cerf aceitou. “Eu estava recebendo um
pouco cansado de ser tão fragmentado em Stanford. Não consegui fazer nenhuma pesquisa. Então eu
pensei, por que não ir para a DARPA e ter um impacto maior, porque em vez do pequeno
pequenos orçamentos que recebi em Stanford para o meu trabalho, na DARPA eu teria a oportunidade de ter um
maior impacto com mais dinheiro para gastar. ”
Como gerente de programa, Cerf ficou responsável pelo rádio de pacote, satélite de pacote,
e programas de pesquisa no que agora era simplesmente chamado de ARPA Internet. Cerf também
continuou trabalhando intensamente no refinamento da especificação TCP. Um marco ocorreu em
Outubro de 1977, quando Cerf e Kahn e uma dúzia de outros demonstraram os primeiros três
sistema de rede com pacote de rádio, ARPANET e SATNET, todos funcionando em
show. Mensagens viajaram da área da Baía de São Francisco por meio de uma rede de rádio de pacotes,
em seguida, a ARPANET e, em seguida, um link de satélite dedicado para Londres, de volta ao pacote-
rede de satélites e através da ARPANET novamente e, finalmente, para a Universidade de
Instituto de Ciências da Informação (ISI) do sul da Califórnia em Marina del Rey. Os pacotes
viajou 94.000 milhas sem cair um único bit.
Durante um intervalo de uma reunião, Cerf presidiu a ISI para discutir o TCP no início de 1978, Cerf,
Postel e Danny Cohen, um colega de Postel no ISI, iniciaram uma discussão em um corredor.
“Estávamos desenhando diagramas em um grande pedaço de papelão que encostamos no
parede no corredor, ”Postel lembrou. Quando a reunião recomeçou, o trio apresentou um
ideia para o grupo: quebrar a parte do Protocolo de Controle de Transmissão que trata
com pacotes de roteamento e forma um protocolo de Internet ou IP separado.
Após a divisão, o TCP seria responsável por dividir as mensagens em datagramas,
remontá-los na outra extremidade, detectar erros, reenviar qualquer coisa que se perdeu e
colocando os pacotes de volta na ordem certa. O protocolo da Internet, ou IP, seria o responsável
para roteamento de datagramas individuais.
“Lembro-me de ter uma orientação geral sobre o que entrava em IP e o que estava em
TCP ”, lembrou Postel. “A regra era 'Os gateways precisam dessas informações para
mover o pacote? 'Se não, essa informação não vai para o IP. ” Esta reviravolta no
protocolo foi inspirado por um grupo de engenheiros de Palo Alto, da Xerox Corporation
Centro de Pesquisa que participou do seminário de Stanford. A equipe da Xerox havia resolvido
problemas semelhantes em uma escala menor e proprietária, definindo uma família de protocolos chamada de
PARC Universal Packet, ou PUP. Depois que Postel decidiu que a criação de um protocolo separado
era a coisa certa a fazer, ele se preocupou em garantir que fosse feito. Com uma separação limpa de
os protocolos, agora era possível construir gateways rápidos e relativamente baratos,

Página 155
o que, por sua vez, alimentaria o crescimento da internetworking. Em 1978, o TCP oficialmente
torne-se TCP / IP.

ETHERNET
Em 1973, apenas quando Cerf e Kahn começaram a colaborar no conceito de
internetworking, Bob Metcalfe da Xerox PARC estava inventando a tecnologia
bases para um novo tipo de rede. Ligou para uma rede de curta distância ou de área local,
A rede de Metcalfe conectaria computadores não em cidades diferentes, mas em salas diferentes.
Metcalfe recebeu seus diplomas de graduação em engenharia elétrica e
gestão do MIT e matriculado em Harvard para a pós-graduação. Mas ele odiava
Harvard imediatamente. “Harvard está cheia de gente velha”, disse ele. “O MIT está cheio de não
dinheiro. Foi uma coisa de classe. ”
Metcalfe conseguiu um emprego no MIT, onde se sentiu mais confortável. O Instituto estava prestes a
juntou-se à ARPANET, e ele foi designado para construir a interface entre o PDP-10 do MIT
e seu IMP. Harvard também tinha um PDP-10 e Metcalfe se ofereceu para fazer uma cópia
interface para dar a Harvard. Mas o pessoal de networking de Harvard recusou a oferta.
“Eles disseram que não podiam deixar um aluno de pós-graduação fazer algo tão importante”,
disse Metcalfe. Funcionários de Harvard decidiram que a BBN fizesse isso. A BBN, por sua vez, deu o trabalho a
seu estudante residente de pós-graduação, Ben Barker, que recrutou John McQuillan, um colega
Estudante de pós-graduação em Harvard, para ajudá-lo.
Embora matriculado em Harvard, Metcalfe permaneceu no MIT para trabalhar em sua dissertação, e
exame da ARPANET. Quando Metcalfe apresentou o trabalho, Harvard rejeitou o
terminou a dissertação como insuficientemente teórica (engenharia demais e não o suficiente
ciência, foi-lhe dito). A rejeição foi constrangedora para Metcalfe, que acabara de fazer um
trabalho no Palo Alto Research Center da Xerox Corporation depois de persuadir sua esposa a sair
seu trabalho para se juntar a ele. Ele foi ao Xerox PARC de qualquer maneira e começou a procurar por mais
tópico teórico para sua tese.
Então, em 1972, enquanto fazia negócios relacionados ao DARPA para o PARC, Metcalfe permaneceu no
Washington casa de seu amigo Steve Crocker. Crocker reuniu alguns dos
melhores técnicos dos primeiros sites para auxiliar novos sites e ligou para essas pessoas
“Facilitadores de rede”. Metcalfe, que se tornou uma espécie de especialista da ARPANET em
MIT, foi um deles.
Crocker acabara de ser visitado por Norm Abramson, o arquiteto principal da
theALOHAnetwork da Universidade do Havaí. Na noite da visita de Metcalfe, Crocker
deixou um dos papéis de Abramson sobre a rede ALOHA de fora. Metcalfe pegou e
leia antes de dormir. O jornal o manteve acordado boa parte da noite. “A matemática no
o papel não era apenas familiar, mas irritante ", disse ele," porque tornava o típico
suposições imprecisas que as pessoas fazem para que seus modelos funcionem. ”
O encontro casual de Metcalfe com o artigo de Abramson mudou sua vida. “Eu me propus a
fazer um novo modelo para o sistema ALOHA. ” Dentro de algumas semanas, ele estava em uma Xerox

Página 156
viagem financiada para a Universidade do Havaí. Ele ficou um mês, e antes de voltar para casa teve
adicionou uma extensa análise do sistema ALOHA à sua tese. Era apenas o teórico
impulsionar a dissertação necessária. Quando ele reenviou o trabalho, ele foi aceito.
Mas o sistema ALOHA deu a Metcalfe muito mais do que um doutorado. Xerox PARC estava no
processo de desenvolvimento de um dos primeiros computadores pessoais, denominado Alto. A empresa
vi que os clientes gostariam de conectar as máquinas, então Metcalfe, um dos residentes
especialistas em redes, foi atribuída a tarefa de amarrar os Altos juntos. Sem uma loja-
modelo and-forward, impedindo a colisão de pacotes de dados era impossível. Mas simplesmente
reduzindo a ARPANET através da construção de uma sub-rede de armazenamento e encaminhamento do tipo IMP
computadores teriam sido proibitivamente caros para um sistema projetado para funcionar em um
Prédio comercial.
Metcalfe teve uma ideia, emprestada diretamente do ALOHANET - na verdade, ele a chamaria
Rede Alto Aloha: Deixe os pacotes de dados colidirem e, em seguida, retransmita em um momento aleatório.
Mas a ideia de Metcalfe diferia em vários aspectos do sistema havaiano. Por uma coisa,
sua rede seria mil vezes mais rápida que a ALOHANET. Também incluiria
detecção de colisão. Mas talvez o mais importante, a rede de Metcalfe seria conectada,
funcionando não por ondas de rádio, mas por cabos conectando computadores em salas diferentes, ou
entre aglomerados de edifícios.
Um computador que deseja enviar um pacote de dados para outra máquina - digamos, um desktop
estação de trabalho enviando para uma impressora - escuta o tráfego no cabo. Se o computador detectar
transmissões conflitantes, ele espera, geralmente por alguns milésimos de segundo. Quando o
cabo está silencioso, o computador começa a transmitir seu pacote. Se, durante a transmissão,
detecta uma colisão, ele para e espera antes de tentar novamente - geralmente algumas centenas
microssegundos. Em ambos os casos, o computador escolhe o atraso aleatoriamente, minimizando
a possibilidade de tentar novamente no mesmo instante selecionado por qualquer dispositivo que enviou o sinal
que causou a colisão. Conforme a rede fica mais ocupada, os computadores desligam e tentam novamente
intervalos aleatórios mais longos. Isso mantém o processo eficiente e o canal intacto.
“Imagine que você está em uma festa e várias pessoas estão em volta, dando uma
conversa ”, disse Butler Lampson, que ajudou Metcalfe a desenvolver a ideia, descrevendo
o sistema. “Uma pessoa para de falar e outra quer falar. Bem, não há
garantir que apenas uma pessoa queira falar; talvez vários o façam. Não é incomum para
duas pessoas para começar a falar ao mesmo tempo. Mas o que normalmente acontece? Normalmente, os dois param,
há um pouco de hesitação e, em seguida, começa novamente. ”
Metcalfe e Lampson, junto com os pesquisadores da Xerox David Boggs e Chuck Thacker,
construiu seu primeiro sistema Alto Aloha no laboratório de Bob Taylor no Xerox PARC. Para seu ótimo
delícia, funcionou. Em maio de 1973, Metcalfe sugeriu um nome, lembrando o hipotético
meio luminífero inventado por físicos do século XIX para explicar como a luz
passa pelo espaço vazio. Ele rebatizou o sistema Ethernet.

CSNET
Página 157
DCA, o zelador da ARPANET, não foi a única agência de P&D em Washington a ter
tornou-se burocrático. Em nenhum lugar em Washington você poderia entrar no escritório do seu chefe
mais com uma ideia brilhante para um projeto e saia vinte minutos depois com um milhão
dólares em suporte. Em meados da década de 1970, a única organização que tinha alguma semelhança com
o antigo ARPA era a National Science Foundation. A fundação foi criada em
1950 para promover o progresso da ciência por meio do financiamento da pesquisa básica e do fortalecimento
educação em ciências. No final da década de 1970, a NSF estava em ascensão no campo da computação.
A NSF não era apenas uma nova fonte provável de fundos suficientes, mas também a única
organização cujos funcionários poderiam agir em nome de toda a comunidade científica.
A DARPA forneceu a base de pesquisa e a nova tecnologia. Agora NSF iria carregá-lo
encaminhar para uma comunidade maior.
Funcionários da NSF estavam interessados em criar uma rede para o computador acadêmico
comunidade científica por algum tempo. Em um relatório de 1974, um comitê consultivo da NSF
concluiu que tal serviço "criaria um ambiente de fronteira que ofereceria
comunicação avançada, colaboração e compartilhamento de recursos entre
pesquisadores separados geograficamente ou isolados. ” Nesse ponto, a NSF era principalmente
preocupada em estimular o desenvolvimento do que ainda era uma disciplina incipiente. Possivelmente
porque a ciência da computação ainda era um campo emergente na maioria dos campi, quase nada
veio da noção.
No final da década de 1970, os departamentos de ciência da computação cresceram rapidamente. As vantagens de
o ARPANET agora estava limpo. Comunicação eletrônica rápida e fácil com colegas
o compartilhamento de recursos significava que tarefas que normalmente levavam semanas agora podiam ser
concluídas em horas.
O correio eletrônico criou um novo mundo de samizdat rápido, substituindo os lentos serviços postais
e conferências raras. A rede se tornou tão essencial para a ciência da computação
pesquisas como os telescópios eram para os astrônomos.
Mas o ARPANET estava ameaçando dividir a comunidade de pesquisadores de computação em
ricos e pobres. Em 1979, havia cerca de 120 ciência da computação acadêmica
departamentos em todo o país, mas apenas quinze dos sessenta e um ARPANETsites eram
localizados em universidades. Candidatos ao corpo docente e alunos de pós-graduação estavam começando a
aceitar ou recusar ofertas com base no fato de uma escola ter ou não acesso à Internet, colocando
instituições de pesquisa sem um nó ARPANET em desvantagem na corrida para pousar no topo
acadêmicos e as bolsas de pesquisa que os seguiram.
Mais importante, um êxodo de talentos da computação da academia para a indústria causou um
em todo o país temem que os Estados Unidos não sejam capazes de treinar sua próxima geração de
Cientistas da computação. A atração pelos salários do setor privado era parte do problema. Mas
os cientistas não estavam apenas sendo puxados para a indústria; eles também estavam sendo empurrados.
Computador
as instalações de muitas universidades estavam obsoletas ou com pouca energia, tornando-se difícil para as pessoas
nos campi para ficar a par das rápidas mudanças no campo da informática.
Pouco poderia ser feito sobre as discrepâncias salariais entre a academia e a indústria. Mas
o problema de recursos era essencialmente o mesmo que a DARPA enfrentou uma década
mais cedo. Uma rede para cientistas da computação reduziria a necessidade de esforços duplicados.

Página 158
E se essa rede fosse aberta a sites de pesquisa privados, haveria menos pressão sobre
pesquisadores deixarem as universidades para acompanharem sua disciplina.
Embora a solução parecesse clara, implementá-la provou ser outro assunto. Ligando o
departamentos de informática da ARPANET estava fora de questão. Para ser atribuído a um
local, as universidades tiveram que se envolver em tipos específicos de pesquisa financiada pelo governo,
tipicamente relacionado à defesa. Mesmo assim, era caro alocar novos
sites.ARPANETconnections veio em apenas um tamanho: extra grande. O sistema usado caro
linhas telefônicas alugadas, e cada nó tinha que manter dois ou mais links para outros sites. Como
como resultado, a manutenção de um site ARPANET custa mais de $ 100.000 por ano, independentemente do
o tráfego gerado.
Os cientistas da computação tiveram que inventar outra maneira. Em maio de 1979, Larry Landweber, chefe
do departamento de ciência da computação da Universidade de Wisconsin, convidado
representantes de seis universidades a Madison para discutir a possibilidade de construir um novo
Rede de Pesquisa em Ciência da Computação, a ser denominada CSNET. Embora DARPA não pudesse
fornecer suporte financeiro, a agência enviou Bob Kahn para a reunião como consultor. NSF,
que levantou a questão da rede acadêmica cinco anos antes, enviou Kent Curtis, o chefe
de sua divisão de pesquisa em computador. Após a reunião, Landweber passou o verão
trabalhando com Peter Denning de Purdue, Dave Farber da University of Delaware,
e Tony Hearn, que havia recentemente deixado a Universidade de Utah pela RAND Corporation,
para elaborar uma proposta detalhada para a nova rede.
Sua proposta previa uma rede aberta a pesquisadores de ciência da computação na academia,
governo e indústria. O meio subjacente seria um serviço comercial
provedor likeTELENET. Porque CSNET estaria usando links mais lentos do que aqueles usados por
theARPANET, e não insistisse em ligações redundantes, o sistema seria muito menos
caro. A rede seria administrada por um consórcio de onze universidades, em um
custo estimado de cinco anos de $ 3 milhões. Por causa da política DCA
restringindo o acesso do ARPANET apenas aos contratantes do DOD, a proposta não continha nenhum portal
entre as duas redes. Um rascunho da proposta circulado pelo grupo recebeu
elogios entusiásticos. Eles enviaram a versão final para a NSF em novembro de 1979.
Mas depois de quase quatro meses de revisão por pares, a NSF rejeitou a proposta, embora
permaneceu entusiasmado com o CSNETidea. Então, a NSF patrocinou um workshop para superar
as deficiências que os revisores da NSF encontraram na proposta preliminar. Landweber e
empresa voltou às suas pranchetas.
No verão de 1980, o comitê de Landweber voltou com uma maneira de adaptar o
arquitetura do CSNET para fornecer acesso acessível até mesmo ao menor laboratório. Eles
propôs uma estrutura de três camadas envolvendo ARPANET, sistema baseado em aTELENET, e um
serviço apenas de e-mail denominado PhoneNet. Gateways conectariam as camadas em um sistema integrado
todo.
De acordo com a nova proposta, a NSF apoiaria o CSNET por um período de inicialização de cinco anos, após
que deveria ser totalmente financiado por taxas de usuário. Custos anuais de uma universidade, uma combinação
de taxas e encargos de conexão, variando de alguns milhares de dólares para o serviço PhoneNet
(principalmente para conexões telefônicas de longa distância) até $ 21.000 para aTELENETsite.

Página 159
Quanto à forma como a rede seria gerenciada - uma preocupação do National Science Board, o
Órgão administrativo da NSF - o plano teve uma abordagem inovadora. Pelos primeiros dois anos, a NSF
ela própria desempenharia o papel de gestora do consórcio universitário. Depois disso,
a responsabilidade seria transferida para a University Corporation for Atmospheric
Pesquisa. A UCAR estava familiarizada com o trabalho de computação avançada e tinha experiência para
lidar com um projeto envolvendo tantas instituições acadêmicas. Mais importante, a Ciência
O Conselho conhecia a UCAR e confiava em suas habilidades de gerenciamento. O Conselho concordou em fornecer
quase $ 5 milhões para o projeto CSNET.
Em junho de 1983, mais de setenta sites estavam on-line, obtendo serviços completos e pagando
taxas anuais. No final do período de cinco anos de apoio da NSF em 1986, quase todos os
departamentos de informática do país, bem como um grande número de computadores privados
sites de pesquisa, foram conectados. A rede era financeiramente estável e financeiramente independente
suficiente.
A experiência que a NSF ganhou no processo de inicialização do CSNET pavimentou o caminho para
mais empreendimentos da NSF em redes de computadores.
Em meados da década de 1980, na esteira do sucesso da CSNET, mais redes começaram a surgir. 1,
chamada BITNET (a Rede Because It's Time), era uma rede cooperativa entre a IBM
sistemas sem restrições de adesão. Outro, chamado UUCP, foi construído em Bell
Laboratórios para transferência de arquivos e execução de comando remoto. USENET, que começou em
1980 como meio de comunicação entre duas máquinas (uma na Universidade de
Carolina do Norte e outra na Duke University), floresceu em uma rede de notícias distribuída
usando UUCP. A NASA tinha sua própria rede chamada Rede de Análise de Física Espacial, ou
PERÍODO. Porque esse crescente conglomerado de redes foi capaz de se comunicar usando
os protocolos TCP / IP, a coleção de redes gradualmente passou a ser chamada de
“Internet”, pegando emprestada a primeira palavra de “Protocolo da Internet”.
Até agora, surgiu uma distinção entre "internet" com um i minúsculo e "Internet" com um
capital I. Oficialmente, a distinção era simples: "internet" significava qualquer rede usando
TCP / IP, enquanto "Internet" significava a rede pública subsidiada pelo governo federal que era composta
de muitas redes vinculadas, todas executando os protocolos TCP / IP. Grosso modo, um
“Internet” é privada e a “Internet” é pública. A distinção realmente não importava até
em meados da década de 1980, quando os fornecedores de roteadores começaram a vender equipamentos para
construir internets privados.
Mas a distinção rapidamente se desfez à medida que os internets privados construíam portais para o público
Internet.
Ao mesmo tempo, empresas privadas e instituições de pesquisa estavam construindo
redes que usavam TCP / IP. O mercado se abriu para roteadores. Gateways eram os
variação de internetworking em IMPs, enquanto os roteadores eram a versão produzida em massa de
gateways, conectando redes locais à ARPANET. Em algum momento no início dos anos 1980, a
o vice-presidente de marketing da BBN foi abordado por Alex McKenzie e outro BBN
engenheiro que achava que a empresa deveria entrar no ramo de construção de roteadores. isto
fez sentido. A BBN construiu os IMPs e os TIPs, e até mesmo o primeiro gateway para o
Internet como parte do programa de rádio em pacotes. Mas o homem de marketing, depois de fazer alguns

Página 160
cálculos rápidos em sua cabeça, decidiu que não havia muita promessa em roteadores. Ele era
errado.
Também em meados da década de 1980, várias redes de pesquisa acadêmica na Europa surgiram para
vida. No Canadá, houve o CDNet. Gradualmente, no entanto, cada rede construiu um gateway para
a Internet e as fronteiras patrocinadas pelo governo dos EUA começaram a se dissolver. E gradualmente
a Internet passou a significar a matriz frouxa de redes TCP / IP interconectadas em todo o mundo.
Até agora, todos os cientistas pesquisadores com suporte da NSF - não apenas cientistas da computação, mas
oceanógrafos, astrônomos, químicos e outros - passaram a acreditar que estavam em um
desvantagem competitiva, a menos que tenham acesso à rede. AndCSNET, que era para ser
usado apenas por departamentos acadêmicos de ciência da computação, não era a resposta. ButCSNET era
o trampolim para a maior realização da NSF, a NSFNET.
O modelo da CSNET convenceu a NSF da importância do networking para o científico
comunidade. As vantagens profissionais a serem obtidas com a capacidade de comunicação
com os colegas era incalculável. E como a agência trabalhava tão de perto
com os cientistas da computação, havia várias pessoas internamente que entenderam
rede e foram capazes de ajudar a gerenciar programas. Mas a NSF não tinha meios para
construir uma rede nacional. Manter o ARPANET sozinho custa milhões de dólares por ano.
A criação em 1985 de cinco centros de supercomputadores espalhados pelos Estados Unidos
ofereceu uma solução. Físicos e outros estavam agitando por uma "espinha dorsal" para interconectar
os centros de supercomputadores. A NSF concordou em construir a rede de backbone, para ser
chamado NSFNET. Ao mesmo tempo, a NSF ofereceu que, se as instituições acadêmicas em um
região geográfica montada em uma rede comunitária, a agência daria o
acesso da rede da comunidade à rede de backbone. A ideia não era só oferecer
acesso, mas também para dar às redes regionais acesso umas às outras. Com este arranjo,
qualquer computador pode se comunicar com qualquer outro por meio de uma série de links.
Em resposta, uma dúzia ou mais de redes regionais foram formadas em todo o país. Cada um tinha
a franquia exclusiva naquela região para se conectar ao backbone NSFNET. Em Upstate
New York, NYSERNET (para New York State Educational Research Network) foi formada.
Em San Diego, havia a Rede de Pesquisa Educacional da Califórnia, ou CERFnet
(embora Vint Cerf não tivesse nenhum relacionamento com a rede, os fundadores da CERFnet o convidaram
à sua inauguração). O financiamento para as redes regionais viria do membro
as próprias empresas. A NSF forneceu a espinha dorsal essencialmente como um "produto gratuito" para
a comunidade acadêmica no sentido de que as redes regionais não pagaram para usá-lo. Em
por outro lado, a NSF concede a universidades para conectar seus campi aos regionais
rede foram sempre concessões de dois anos, estritamente não renováveis. Isso significava que depois de dois
anos, as universidades estavam pagando o custo da conexão regional por conta própria
bolsos. Encargos típicos eram entre $ 20.000 e $ 50.000 por ano para uma alta velocidade
conexão.

TCP / IP versus OSI

Página 161
Em 1982, Vint Cerf anunciou que deixaria a ARPA para trabalhar na MCI.
No início daquele ano, ele conheceu um executivo da MCI cujo trabalho era colocar a MCI nos dados
o negócio. “A ideia dele era construir uma agência postal digital”, lembra Cerf. “Eu fui imediatamente
agarrado pela ideia. ” A reação à partida de Cerf foi de choque. Um colega chorou.
“Vint era o mais próximo de um general quanto nós”, disse outro.
Cerf estava saindo em um momento crítico para a rede. A ARPANET estava prestes a fazer seu
transição oficial para TCP / IP, mas ninguém sabia ao certo se o governo dos EUA
estava falando sério sobre abraçá-lo. O Departamento de Defesa havia aprovado o TCP / IP, mas o
ramo civil do governo, não. E havia uma preocupação crescente de que o
National Bureau of Standards decidiria apoiar um padrão rival emergente para
interconexão de rede chamada Modelo de Referência OSI.
Vários anos antes, a Organização Internacional para Padronização, ISO, havia começado
para desenvolver seu próprio modelo de "referência" de internetworking, chamado OSI, ou sistemas abertos
interconexão. Desde a década de 1940, a ISO especificou padrões mundiais para coisas
variando de taças de degustação de vinho a cartões de crédito, filmes fotográficos e computadores. Eles
esperava que seu modelo OSI se tornasse tão onipresente para os computadores quanto as baterias duplo A
foram para rádios portáteis.
Uma espécie de batalha estava se formando ao longo de linhas familiares, lembrando o confronto entre
AT&T e os inventores da comutação de pacotes durante o nascimento da ARPANET. No OSI
lado estava a burocracia entrincheirada, com uma forte atitude de quem sabe melhor, condescendente e
ocasionalmente desdenhoso. “Havia uma certa atitude entre certas partes do OSI
comunidade cuja mensagem foi: 'Hora de enrolar sua rede acadêmica de brinquedos' ”, lembrou
um fervoroso devoto de TCP / IP. “Eles pensaram que TCP / IP e Internet eram apenas isso - um
brinquedo acadêmico. ” Ninguém jamais afirmou que o que começou com o Network Working
Grupo e continuado em toda a comunidade acadêmica por anos tinha sido qualquer coisa
mas ad hoc. Alguém havia escrito a primeira RFC em um banheiro, pelo amor de Deus. Não somente
se a série RFC nunca tivesse sido oficialmente comissionada pela ARPA, mas algumas das RFCs
eram, literalmente, piadas.
Mas a comunidade da Internet - pessoas como Cerf, Kahn e Postel, que passaram anos
trabalhando em TCP / IP - opôs-se ao modelo OSI desde o início. Primeiro foram os técnicos
diferenças, a principal delas é que o OSI tinha uma forma mais complicada e compartimentada
Projeto. E foi um projeto, nunca tentei. No que diz respeito ao público da Internet, eles
tinha implementado TCP / IP várias vezes, enquanto o modelo OSI nunca
foram colocados à prova de uso diário e tentativa e erro.
Na verdade, no que diz respeito à comunidade da Internet, o modelo OSI nada mais era do que um
coleção de abstrações. “Tudo sobre o OSI foi descrito de forma muito abstrata,
forma acadêmica ”, disse Cerf. “A linguagem que eles usavam era incrivelmente túrgida. Vocês
não poderia ler um documento OSI se sua vida dependesse disso. ”
O TCP / IP, por outro lado, reflete a experiência. Estava instalado e funcionando em um
rede. “Poderíamos experimentar coisas”, disse Cerf. “Na verdade, nos sentimos compelidos a experimentar,
porque no final não havia sentido em especificar algo se você não fosse

Página 162
construa. Tínhamos esse feedback pragmático constante sobre se as coisas funcionavam ou
não. ”
Cerf e outros argumentaram que o TCP / IP não poderia ter sido inventado em qualquer lugar, exceto no
mundo da pesquisa colaborativa, que foi precisamente o que o tornou tão bem sucedido, enquanto um
um camelo como o OSI não poderia ter sido inventado em nenhum lugar a não ser em mil comitês.
Talvez o mais importante, o Departamento de Defesa já havia anunciado sua escolha de
TCP e IP como os protocolos que seriam executados em computadores militares.
As reuniões da ISO, que muitas vezes eram realizadas no exterior na década de 1980, eram ocasionalmente dolorosas
experiências para pessoas como Cerf e Postel. Eles assistiram a eles apenas para se sentirem como o rei
Canuto gritando com a maré vazante. “Eu era o cara que estava sempre escrevendo o contador
papel ”, lembra Cerf.
Se alguém podia reclamar o crédito por ter trabalhado incansavelmente para promover o TCP / IP, esse alguém foi
Cerf.
A magia da Internet era que seus computadores usavam uma comunicação muito simples
protocolo. E a magia de Vint Cerf, um colega comentou uma vez, foi que ele persuadiu e
negociou e instou as comunidades de usuários a adotá-lo.
Enquanto estava na MCI em 1983, construindo o que viria a ser o MCI Mail, Cerf tentou obter a IBM,
Digital e Hewlett-Packard para oferecer suporte a TCP / IP, mas eles se recusaram e adotaram OSI
em vez de. A Digital, em particular, havia investido uma grande quantidade de dinheiro em sua rede DECNET,
baseado em OSI. TCP / IP, eles argumentaram, era "uma coisa de pesquisa". Cerf ficou desapontado e um
um pouco irritado. “Eles disseram que não iriam fazer produtos com isso. Então eu tive que construir o MCI
Correio do café da manhã de um cachorro de protocolos. ” Cerf remendado MCI Mail de
protocolos existentes que estavam sendo usados internamente pela Digital e IBM, e desenvolveu um
alguns mais especificamente para MCI Mail. “Eu entendi por que eles tomaram a posição que tomaram,
mas ainda me incomodava. ”

O interruptor
Em 1o de janeiro de 1983, o ARPANET faria sua transição oficial para TCP / IP.
Todo usuário ARPANET deveria ter feito a troca do Controle de Rede
Protocolo para TCP / IP. Naquele dia, o protocolo que regia a ARPANET seria
desativado, para que apenas as máquinas que executam os novos protocolos pudessem se comunicar
pela rede. Alguns sites que ainda não fizeram a transição pleitearam seu caso para
Postel ou seu colega Dan Lynch, ou, para Bob Kahn, que supervisionava a transição,
e geralmente ganhou um período de carência. Mas na primavera de 1983, ou você tinha feito o
conversão ou sua máquina caiu da rede.
Em termos de marcos, a transição para TCP / IP foi talvez o evento mais importante que
ocorreria no desenvolvimento da Internet nos próximos anos. Depois que o TCP / IP foi
instalada, a rede pode ramificar em qualquer lugar; os protocolos fizeram a transmissão de
dados de uma rede para outra uma tarefa trivial. "Para pegar uma frase emprestada", disse Cerf, "agora
poderia ir aonde nenhuma rede tinha ido antes. ” Uma impressionante variedade de redes agora
existia - da ARPANET aTELENET a Cyclades. Havia tantos, na verdade, que

Página 163
na tentativa de impor alguma ordem, Jon Postel emitiu um RFC atribuindo números aos
redes.
Em 1983, a Agência de Comunicações de Defesa decidiu que a ARPANET havia crescido
grande o suficiente para que a segurança agora fosse uma preocupação. A agência dividiu a rede em duas
partes: theMILNET, para sites que transportam informações militares não classificadas, e
theARPANETpara a comunidade de pesquisa em computação. Antes da separação, havia 113
nós na rede combinada. Posteriormente, 45 nós permaneceram com a ARPANET, e
o resto foi para MILNET. Administrativa e operacionalmente, havia dois diferentes
redes, mas com gateways conectando-as, os usuários não sabiam. O antigo ARPANET tinha
tornar-se uma Internet completa.
Em 1988, cinco anos após a transição de 1983 ARPANET para TCP / IP, a ISO finalmente
produziu padrões para Interconexão de Sistemas Abertos e o Governo dos EUA
adotou imediatamente os protocolos OSI rivais como seu padrão oficial. Parecia que OSI
pode prevalecer sobre o TCP / IP. Na Europa, onde os governos nacionais decretam os padrões,
parecia uma questão de fé que o OSI era a solução.
Por outro lado, uma cultura americana da Internet estava crescendo exponencialmente, e seu
a base era TCP / IP. E enquanto os governos de toda a Europa ungiam o OSI,
algo como um movimento underground surgiu nas universidades europeias para implementar
TCP / IP.
Um desenvolvimento fundamental na determinação do resultado entre TCP / IP e OSI acabou sendo
ser a popularidade do sistema operacional UNIX, que havia sido desenvolvido na AT&T
Bell Laboratories em 1969.
Os programadores gostaram do UNIX por duas razões principais: sua flexibilidade permite que eles o adaptem para
qualquer programa em que estivessem trabalhando, e era "portátil", o que significa que poderia ser
feito para funcionar em muitos computadores diferentes. No final da década de 1970, programadores em Berkeley
desenvolveu sua própria marca de UNIX e semeou a comunidade da ciência da computação com ela.
Berkeley UNIX eventualmente se tornou um elemento fixo em universidades e instituições de pesquisa, todas
pelo mundo. Por volta de 1981, Bill Joy, um UNIXhacker em Berkeley, conseguiu financiamento ARPA para
escrever TCP / IP em uma versão do BerkeleyUNIX. BBN já havia escrito uma versão
da UNIX com TCP / IP, mas Joy não gostou e decidiu fazer do seu jeito.
Então, em 1982, Joy se juntou a um casal de graduados da Stanford Business School que estavam
começando uma nova empresa para construir e vender "estações de trabalho" poderosas, computadores que eram de
uma ordem de magnitude mais poderosa do que computadores pessoais. Joy foi trazida como
theUNIX expert. Eles chamaram sua empresa de Sun (de Stanford University Network)
Microsystems. As primeiras máquinas Sun foram enviadas com a versão Berkeley do UNIX,
completo com TCP / IP. BerkeleyUNIX com TCP / IP seria crucial para o crescimento do
Internet. Quando a Sun incluiu software de rede como parte de cada máquina, ela vendeu e não
cobrar separadamente por isso, a rede explodiu.
Ele cresceu ainda mais por causa da Ethernet.

Página 164
Enquanto o packet rádio e o SATNET estimularam a reflexão sobre uma estrutura conceitual para
internetworking, eles eram amplamente experimentais. Ethernet - a rede local
projetado por Bob Metcalfe e seus colegas da Xerox PARC em 1973 - era um
solução prática para o problema de como ligar computadores, seja em um campus ou
em uma empresa. A Xerox começou a vender Ethernet como um produto comercial em 1980. Por volta de
ao mesmo tempo, a divisão de Bob Taylor na Xerox PARC concedeu uma bolsa para pesquisas importantes
universidades na forma de equipamentos Ethernet, computadores poderosos e impressoras a laser. isto
somaram milhões de dólares em hardware. Em seguida, uma pequena empresa de rede
chamado Ungermann-Bass vendeu Ethernet como uma conexão entre terminais e host
computadores. E Metcalfe abriu sua própria empresa, 3Com, para vender Ethernet para
computadores comerciais, incluindo máquinas Sun.
Ao longo do início dos anos 1980, as redes locais eram a moda. Cada universidade viciada
suas estações de trabalho às redes locais. Em vez de se conectar a um único computador grande,
universidades queriam conectar toda a sua rede local - ou LAN - para
theARPANET.
A Ethernet tornou isso possível. Ethernets eram simples e, em comparação com as linhas de 50 kilobit
da ARPANET, eles eram tremendamente poderosos. Seu rápido crescimento na universidade
e a comunidade de pesquisa impulsionou a demanda por interconexão de rede. Se o seu todo
universidade não estava conectada à ARPANET, o CSNET deu a você uma maneira de conectar uma
computador da sua universidade para a ARPANET. Mas foi a Ethernet que criou um enorme
constituinte de rede.
Nas principais universidades de pesquisa, haveria uma rede de centenas de computadores que
todos poderiam se comunicar através de uma rede Ethernet. Para enviar tráfego de uma Ethernet em
digamos, San Diego, para outra Ethernet em Buffalo, você a enviou pelo ARPANEThub. No
assim, a ARPANET foi a peça central do que se chamou ARPA Internet. E
durante a primeira metade da década de 1980, a ARPA Internet parecia uma estrela, com vários
redes em torno daARPANET no centro.
Talvez o que o TCP / IP mais recomendasse fosse o fato de que era infalivelmente
"abrir." Todo o seu design foi um processo aberto, seguindo um caminho inicialmente traçado por Steve
Crocker e o Grupo de Trabalho de Rede e continuando na Internet.
A ARPANET, e mais tarde a Internet, cresceu tanto com a disponibilidade gratuita de
software e documentação como de qualquer outra coisa. (Em contraste, Digital
Equipment'sDECNET era uma rede proprietária.) A Internet também suportava uma ampla
gama de tecnologias de rede. Embora as redes de satélite e de rádio de pacote tivessem
vida útil finita, eles ajudaram a abrir os olhos dos desenvolvedores para a necessidade de lidar com uma infinidade de
redes diferentes.

Reforma do e-mail
Os padrões TCP e IP não foram a única grande renovação da rede no início
1980s. Durante anos, cada programa de e-mail escrito para o ARPANET dependia do
protocolo de transferência de arquivo original para servir como sua barca para transportar o correio para frente e para
trás.
Pode ter sido um truque legal anexar os comandos de e-mail ao protocolo de transferência de arquivos em

Página 165
primeiro, mas o processamento de e-mail ficou mais complicado. Em uma mensagem para seu
colegas na lista de discussão do MsgGroup um dia no final de agosto de 1982, Postel disse: “Se você
realmente dê uma olhada nas especificações do FTP, você verá que os comandos de e-mail são realmente algum tipo
de verruga. " Postel e muitos outros sentiram que era hora de construir uma transferência completamente separada
mecanismo de correio.
Uma vez que a rede estava passando por uma reorganização massiva de qualquer maneira com a mudança para
TCP / IP, parecia um momento apropriado para lançar o novo padrão. Postel e seu
colegas o chamaram de protocolo de transferência de correio simples (SMTP). Esclareceu existente
práticas, ao adicionar alguns novos recursos de controle.
Ao mesmo tempo, o crescimento da rede deu origem a um novo problema. “Quando chegamos
para cerca de dois mil hosts, foi quando as coisas realmente começaram a desmoronar ”, disse Craig
Partridge, um programador da BBN. “Em vez de ter um grande mainframe com vinte
mil pessoas nele, de repente estávamos sendo inundados com máquinas individuais. ”
Cada máquina host tinha um determinado nome, "e todos queriam ser chamados de Frodo",
Partridge se lembrou.
Classificar os Frodos da Internet não era diferente de classificar os Jones de Cleveland
ou os Smiths de Smithville. Onde morava, precisamente, era importante na diferenciação
quem era. Por anos, resolver isso foi uma das formas mais problemáticas e confusas
questões para a Internet, até que finalmente um grupo formou um esquema viável, chamado de
sistema de nomes de domínio ou DNS.
O núcleo da equipe DNS era Jon Postel e Paul Mockapetris da ISI, e Craig da BBN
Perdiz. Eles passaram três meses trabalhando nos detalhes do novo esquema de endereçamento
e em novembro de 1983 apresentou duas RFCs que descrevem o sistema de nomes de domínio.
“O DNS foi uma mudança muito significativa na maneira como pensamos sobre o sistema ser
organizado ”, disse Postel. “Ramificação de árvores” foi a metáfora norteadora. Cada endereço seria
têm uma estrutura hierárquica. Do tronco para os galhos e de fora para as folhas,
cada endereço incluiria níveis de informação representando, em progressão, um menor,
parte mais específica do endereço de rede.
Mas isso gerou um debate sobre a sequência da hierarquia; o que deve vir primeiro ou
último. Postel e outros finalmente decidiram por um esquema de endereçamento específico para geral. o
A comunidade da Internet também discutiu sobre como nomear os domínios, atrasando
qualquer implementação por cerca de um ano. Foi afirmado por alguns, de forma não convincente, que
nomes de domínio devem refletir fontes de financiamento específicas - MIT, DARPA, por exemplo.
Eventualmente, um comitê concordou com sete domínios de "nível superior": edu, com, gov, mil, net,
org e int. Agora pode haver sete Frodos: um computador chamado Frodo em uma universidade
(edu), um em um site do governo (gov), uma empresa (com), um site militar (mil), uma organização sem fins
lucrativos
organização (org), um provedor de serviços de rede (net) ou uma entidade de tratado internacional (int).
A DARPA começou a pressionar as pessoas a adotar endereços DNS em 1985. Em janeiro de 1986, a
grande reunião de cúpula ocorreu na costa oeste, reunindo representantes de
todas as principais redes. Quando a cúpula acabou, todos concordaram que sim,
eles realmente acreditaram no conceito de DNS. “E sim, aqui estava como íamos fazer
funciona ”, lembrou Partridge,“ E sim, temos a tecnologia para fazer tudo voar ”.

Página 166

Puxando o plugue
A primeira pista que Cerf teve de que a Internet seria adotada por um mundo fora do
comunidades científicas e acadêmicas surgiram em 1989, quando ele caminhou para a exposição
andar na Interop, uma feira comercial iniciada por Dan Lynch em 1986 para promover a interconectividade
por meio de TCP / IP. Em seus primeiros anos, a Interop teve a participação de algumas centenas
pessoas de rede hardcore. Em 1989, o show estava repleto de homens e mulheres em
traje de negócios. “Foi uma epifania entrar na Interop e ver o grande dinheiro sendo
gastos em exposições com grandes demonstrações organizadas ”, disse Cerf. “Eu percebi, oh meu Deus,
as pessoas estão gastando muito dinheiro nisso ”. Os expositores tinham nomes como Novell,
Sinópticos e Rede Geral. “Começamos a olhar para as estatísticas da rede e
percebemos que tínhamos um foguete em nossas mãos. ” Por anos Cerf viu a Internet como um
experimento satisfatório e bem-sucedido. Ocasionalmente, ele esperava que a Internet pudesse alcançar um
mundo mais amplo de usuários. Agora, aqui estava a evidência de que estava fazendo exatamente isso.
Nessa época, praticamente todo mundo estava usando TCP / IP. E houve um aumento cada vez maior
infra-estrutura construída sobre TCP / IP na Europa. TCP / IP era tão difundido e tantos
as pessoas dependiam disso, que derrubá-lo e recomeçar parecia impensável. De
em virtude de sua dinâmica silenciosa, o TCP / IP prevaleceu sobre o padrão OSI oficial. Está
o sucesso proporcionou uma lição prática em tecnologia e como ela avança. “Os padrões deveriam
ser descoberto, não decretado ”, disse um cientista da computação da facção TCP / IP. Raramente
funcionou de outra maneira.
No final da década de 1980, a Internet não era mais uma estrela com a ARPANET como seu centro; era um
mesh, muito parecido com o próprio ARPANET. O programa NSFNET tinha redes democratizadas
como nem mesmo CSNET. Agora, qualquer pessoa no campus de uma faculdade com conexão à Internet
poderia se tornar um usuário da Internet. A NSFNET estava se tornando rapidamente a espinha dorsal da Internet,
rodando em linhas que eram mais de 25 vezes mais rápidas do que as linhas ARPANET. Comercial
agora tinha uma escolha entre conectar-se ao ARPANET ou ao backbone NSFNET.
Muitos escolheram o último, não apenas por sua velocidade, mas porque era muito mais fácil de conectar
para.
Conforme a década de 1990 se aproximava, o número de computadores no mundo que estavam conectados a
um ao outro através do NSFNETfar ultrapassou o número de computadores conectados a um
outro via ARPANET. A ARPANET era agora apenas uma das centenas de ARPA
Redes de Internet, e um dinossauro, incapaz de evoluir tão rapidamente quanto o resto da Internet.
Bob Kahn, o único campeão remanescente de networking da DARPA, havia deixado a agência em
1985 para formar a Corporation for National Research Initiatives, uma empresa sem fins lucrativos
cujo estatuto era fomentar a pesquisa e o desenvolvimento de uma “informação nacional
a infraestrutura." As pessoas que agora dirigem a DARPA não estavam particularmente interessadas em
networking. Em sua opinião, todos os problemas interessantes foram resolvidos. Além disso, o
a agência foi distraída pelo programa Star Wars do presidente Ronald Reagan.

Página 167
O próprio ARPANET, que custou à ARPA US $ 14 milhões por ano para ser executado, parecia artrítico ao lado de
o NSFNET de alta velocidade. A administração da DARPA decidiu que a ARPANET havia sobrevivido ao seu
utilidade. Era hora de desligá-lo.
Mark Pullen, gerente de programa da DARPA que agora dirigia o projeto de rede, era
dada a tarefa de descomissionamento da ARPANET. Exatamente quem deu o pedido de
nos alcances mais elevados da DARPA nunca ficou muito claro. “Ninguém queria ser o
ghoul que desligou a ARPANET ", disse Pullen," então me tornei a fonte da política. "
O plano de Pullen era retirar sites da ARPANET e colocá-los no backbone NSFNET.
Foi difícil contar a Bob Kahn sobre o plano de desativação da rede. Kahn teve
contratou Pullen, e agora Pullen era o carrasco. "Tive a sensação de que ele poderia sentir que eu estava
desligando sua maior conquista ”, disse Pullen. “Aquele que parecia machucá-lo
pior foi quando desliguei o antigo SATNET. ”O SATNET era lento, caro e
antiquado. “Sem dúvida ele deve ter pensado que era seu próprio filho. Por razões válidas. Mas
depois de pensar sobre isso, ele concordou que eu estava fazendo a coisa certa. ” (Como se viu, o
dinheiro que a DARPA economizou desativando o novo projeto de Kahn do fundo auxiliado pelo ARPANET.)
Um por um, Pullen desligou os IMPs e TIPs que ainda estavam no coração do original
rede. Houve uma certa tristeza em sua morte que trouxe à mente a cena de
2001 de Arthur C. Clarke : Uma Odisséia no Espaço, onde o computador fictício de quinta geração
A HAL está ameaçando sua missão e deve ser desmontada circuito por circuito. Como HAL
gradualmente perde sua "mente", faz apelos patéticos por sua "vida" a Dave, o astronauta,
quem está desmontando.
No caso da ARPANET, a rede morreu, mas seus pedaços sobreviveram. “Não foi tudo isso
diferente da separação de Ma Bell ”, lembra Pullen. “Envolveu a localização de clusters
dos locais ARPANET e encontrar alguém para controlá-los. ” Na maioria dos casos, Pullen
transferiu cada site da ARPANET para uma das redes regionais e facilitou a transição
subsidiando o custo por um tempo. Com exceção de dois sites que passaram a
theMILNET, todos os sites foram para uma ou outra das redes regionais. "Eu nunca tive
qualquer um se opõe tão alto ”, disse Pullen. “Acho que todos sabiam que havia chegado a hora.”
Um local de cada vez, Pullen encontrou novos lares para eles. Onde não havia uma casa,
DARPA e NSF ajudaram a criar um. Vários locais ARPANET no sul da Califórnia
rapidamente formou sua própria rede regional e a chamou de Los Nettos; era dirigido por Danny
Cohen e Jon Postel. Os próprios IMPs foram desligados, desbloqueados e enviados
longe. A maioria foi simplesmente descartada. Outros entraram em serviço naMILNET. o
O Museu do Computador em Boston ganhou um, e Len Klein-rock colocou o IMP número um
exposição para visitantes da UCLA. O último IMP a desaparecer foi na Universidade de Maryland. De
coincidência, Trusted Information Systems, uma empresa em Maryland onde Steve Crocker
agora funcionou, estava conectado a esse IMP. Crocker estava lá no nascimento e ele estava
lá na morte.
No final de 1989, o ARPANET havia desaparecido. TheNSFNET e as redes regionais
tinha gerado tornou-se a espinha dorsal principal. Naquele ano, para marcar tanto a ARPANET
vigésimo aniversário e seu fim, a UCLA patrocinou um simpósio e o chamou de “Ato
1."

Página 168
Em seu discurso, Danny Cohen encontrou uma fonte de inspiração e disse o seguinte:
“No início, o ARPA criou a ARPANET.
“E o ARPANET era sem forma e vazio.
“E a escuridão estava nas profundezas.
“E o espírito da ARPA mudou para a face da rede e a ARPA disse: 'Vamos lá
ser um protocolo ', e havia um protocolo. E o ARPA viu que era bom.
“E o ARPA disse: 'Que haja mais protocolos', e assim foi. E o ARPA viu que era
Boa.
“E o ARPA disse: 'Que haja mais redes', e assim foi.”

Epílogo
Setembro de 1994
A festa foi ideia da BBN: reunir algumas dezenas de jogadores importantes em Boston e comemorar
o vigésimo quinto aniversário da instalação do primeiro ARPANETnode na UCLA. De
agora, a Internet havia crescido muito além de um experimento de pesquisa. Quanto mais pessoas
descobriu sua utilidade, estava se tornando uma palavra familiar. A Net prometeu ser para o
século XXI o que o telefone fora para o século XX. Sua existência era
já alcançando quase todos os aspectos da cultura americana - desde a publicação até
socializando. Para muitos, o e-mail se tornou uma parte indispensável da vida diária. Recluso em casa
idosos usavam para encontrar companhia; algumas famílias distantes o usaram como cola. Mais
a cada dia, as pessoas se conectavam para realizar negócios ou encontrar entretenimento na Internet.
Os analistas consideram a Internet a próxima grande oportunidade de marketing.
A decolagem estava apenas começando. Em 1990, a World Wide Web, um ramo multimídia da
a Internet, foi criada por pesquisadores do CERN, o Laboratório Europeu para
Física de Partículas perto de Genebra. Usando o protocolo HTTP de Tim Berners-Lee, computador
cientistas de todo o mundo começaram a tornar a Internet mais fácil de navegar com pontos e
clique em programas. Esses navegadores foram modelados com base no original de Berners-Lee e, geralmente,
com base na biblioteca de códigos CERN. Um navegador em particular, chamado Mosaic, criado em
1993 por alguns alunos da Universidade de Illinois, ajudaria a popularizar a Web e
portanto, a Internet como nenhuma ferramenta de software ainda tinha feito.
A rede da década de 1970 há muito foi suplantada por algo mais uma vez
sofisticado e mais pesado. No entanto, de dezenas de maneiras, a Net de 1994 ainda refletia
as personalidades e tendências daqueles que o construíram. Larry Roberts continuou colocando pedaços de
a fundação para a grande casa errante que se tornou a Internet. Frank Heart
atitude pragmática em relação à invenção técnica - construí-la, jogá-la na Internet e corrigi-la

Página 169
se quebrar - a sensibilidade Net permeada por anos depois. Abertura no protocolo
processo iniciado com o primeiro RFC de Steve Crocker para o Network Working Group, e
continuou na Internet. Enquanto estava na DARPA, Bob Kahn fez uma escolha notável para
manter a abertura. Vint Cerf deu à Net sua civilidade. E os criadores da Internet ainda funcionavam
a Internet Society e participou de reuniões da Internet Engineering Task Force.
Assim que os planos do partido começaram, a BBN contratou um novo CEO. George
Conrades, um veterano de marketing da IBM, foi recrutado pela BBN
presidente Steve Levy para reformular os negócios da empresa. Conrades adorou a ideia da festa.
Ele o considerou um veículo de marketing perfeito. Conrades ficou apaixonado pela BBN
papel pioneiro. A BBN era a empresa de Internet original, ele decidiu, uma reivindicação à fama da
empresa ainda tinha que explorar. Faça a festa grande e pródiga. Alugue o Copley Plaza Hotel.
Comemore os pioneiros da rede como se eles tivessem sido os primeiros a pisar na superfície da lua.
Convide personalidades da indústria de informática. E convide a imprensa.
A BBN precisava de um impulso. Ao longo da década de 1980, as fortunas da empresa praticamente diminuíram.
À medida que a Internet se tornava mais popular, a BBN, que repetidamente falhou
comercializar em seus esforços de pesquisa, caiu em relativa obscuridade. Em 1993 o
empresa perdeu US $ 32 milhões em US $ 233 milhões em vendas. O ano seguinte não foi muito melhor,
com uma perda de $ 8 milhões em vendas menores.
A empresa havia perdido sua maior oportunidade quando não conseguiu entrar no mercado de
roteadores - dos quais IMPs foram os progenitores. A BBN não conseguiu ver o potencial dos roteadores
tanto quanto a AT&T se recusou a reconhecer a troca de pacotes. Quem quiser
conectar uma rede de área local - da qual agora havia centenas de milhares - para o
A Internet precisava de um roteador. Em 1994, o negócio de roteadores era uma indústria multibilionária.
Mais de uma década antes, alguns caras de informática da própria BBN haviam tentado empurrar o
empresa para o negócio de roteadores, e eles foram descartados por um vice de marketing
Presidente.
Os problemas da BBN foram além das oportunidades de mercado fracassadas. Em 1980 o governo federal
acusou a empresa de conspirar para cobrar demais do governo por seus contratos durante
o período de 1972 a 1978 e da alteração das planilhas de ponto para ocultar as cobranças excessivas. o
prática foi descoberta quando, no decorrer de uma auditoria de rotina no final dos anos 1970, a BBN
os funcionários foram menos do que francos com um auditor do governo. (“A BBN obteve muito
arrogante ”, disse um funcionário de longa data.) Uma investigação federal durou mais de dois
anos. Os auditores mudaram-se para a sede da empresa em Cambridge. Funcionários seniores da BBN
foram chamados perante um grande júri. Nenhum dos caras do IMP foi implicado. Mas em 1980 dois
dos executivos financeiros de alto escalão da empresa negociaram a saída de um
carga de cem contagens. Eles receberam penas suspensas e multados em US $ 20.000 cada.
A empresa concordou em pagar uma multa de US $ 700.000.
Na época, a BBN dependia de contratos do governo para quase 80% de suas receitas.
Dada a certeza de que todas as concessões de contratos governamentais à BBN teriam sido
suspensa durante o curso de qualquer defesa legal longa, se nenhum acordo tivesse sido alcançado,
as acusações poderiam ter arruinado a empresa. As pessoas na empresa sentiram que
o governo havia reagido exageradamente a práticas contábeis incorretas. BBN, eles disseram, tinha

Página 170
sempre deu ao governo federal muito mais do que seu dinheiro em contrato
P&D.
O grupo de rede da BBN, apenas minimamente envolvido na investigação do governo,
estava oferecendo simultaneamente provas positivas de que a ciência financiada pelo governo pode suportar
fruta esplêndida. A ARPANET foi a Exposição A. Financiada inteiramente pela ARPA, seus criadores
com rédea solta, a rede era a evidência de uma confiança norte-americana outrora difusa
em ciência. A rede foi construída em uma época em que Washington fornecia um pouco de orientação
e muita fé.
Em 1994, o contato da BBN com os auditores do governo foi esquecido. Infelizmente, então
foi o papel da empresa na construção da ARPANET. Apenas aqueles insiders que foram
familiarizado com a história, associou a empresa à recém-popular Internet. Quando
Conrades chegou, ele decidiu que era hora de polir a imagem da BBN. E uma prata
A festa de aniversário da ARPANET foi a oportunidade perfeita.
A lista de convidados para a festa foi tão examinada quanto uma lista de convites para uma Casa Branca
jantar. Alguns nomes eram óbvios, é claro; mas muitas pessoas tiveram uma participação
construindo a ARPANET, e ainda mais pessoas, de todo o mundo, foram
envolvidos com a Internet. Heart, Walden e outros enviaram sugestões.
O presidente Al Gore, defensor da superestrada da informação, foi convidado. Ed também
Markey, um congressista democrata de Massachusetts que também colocou a Internet em
sua agenda política; ele aceitou o convite. Bill Gates foi convidado, embora o
O presidente da Microsoft ainda não reconheceu a Internet como uma ferramenta útil. Ele recusou.
Paul Baran, cujo papel foi minimizado na BBN, quase não foi convidado. Com o tempo, o
lista aumentou para quinhentos convidados.
Conrades queria que isso fosse tanto um sinal para o futuro quanto uma celebração do passado. Ele
estava planejando que a BBN expandisse seu papel um tanto reduzido em assuntos relacionados à Internet
negócios. A BBN já possuía e operava a NEARnet, a regional da Nova Inglaterra
rede. Uma de suas primeiras ações depois de chegar foi comprar BARRnet, a regional
rede na área da Baía de São Francisco. E ele estava de olho na SURAnet, a regional
rede para o Sudeste.
Em busca de um tema elevado, a empresa de relações públicas que a BBN contratou para aumentar seu próprio RP
departamento criou um: “História do Futuro”. É adequado aos planos de Conrades para
BBN perfeitamente. Conrades também contratou uma produtora para montar um elaborado
apresentação de vídeo que incluiria entrevistas com um grupo central de pioneiros - Larry
Roberts, Bob Kahn, Steve Crocker, Len Kleinrock, Frank Heart e Vint Cerf.
Bob Metcalfe, o inventor da Ethernet, era agora editor de uma empresa de informática
jornal chamado InfoWorld. Ele escreveu uma coluna de opinião sobre o próximo evento que ele
intitulado "Old Fogies to Duke It Out for Credit at Internet's 25th Anniversary". "Eu estarei lá
para ver velhos amigos, para renovar algumas antigas animosidades e para se juntar à disputa por crédito -
das quais há muito para circular ”, escreveu Metcalfe. “Vou começar certificando-me
os participantes da festa percebem que a maior parte do tráfego TCP / IP é transportada pela Ethernet, que eu
inventei. . . Como
o pico da festa, verei quanto crédito posso tirar de Vint Cerf e Bob Kahn pelo

Página 171
invenção de internetworking. . . Se falhar, verei se consigo sorrir para entrar no grupo
foto dos inventores da comutação de pacotes. ”
Semanas e dias antes do evento, a empresa de relações públicas da BBN publicou histórias em
revistas e jornais. A Newsweek publicou um longo artigo sobre os pioneiros do ARPANET, e
o Boston Globe também. A BBN preparou um videoclipe, que foi ao ar em mais
de cem noticiários locais. Ray Tomlinson, cujo escrutínio de seu teclado em um
momento oportuno produziu o sinal @, foi celebrado como um herói folclórico em uma história
transmitido na Rádio Pública Nacional na noite da festa.
Os convidados de honra começaram a chegar na sexta-feira, 9 de setembro, e se reuniram para uma recepção
seguido por uma conferência de imprensa no Copley Plaza naquela tarde. De brincadeira, Wes Clark,
agora um consultor em Nova York, prendeu o crachá de Larry Roberts em seu próprio casaco esporte.
Na conferência de imprensa, vários dos pioneiros do ARPANET, que superaram os
jornalistas, discursos proferidos. Em seu discurso, Bob Taylor observou ironicamente que as pessoas
quem tinha sido convidado mandou seus avós em seu lugar.
A ausência mais notável foi a de Licklider, que morreu em 1990, mas sua esposa, Louise,
aceitou o convite. Bernie Cosell, o depurador ace da equipe IMP, que agora morava em
ruralVirginia e ovelhas criadas (“Muitas pessoas, poucas ovelhas”, leia o e-mail de Cosell
assinatura), não pôde comparecer devido ao custo. Outros recusaram. Notoriamente avesso
para festas, Will Crowther recusou o convite; telefonemas repetidos de outros IMP
Caras não podiam mudar sua mente.
Em um buffet mexicano após a entrevista coletiva, todos se misturaram. Alguns
as pessoas tinham se visto alguns dias antes, ou alguns meses antes, mas outras não
nos vemos há anos, ou mesmo décadas. Novos cônjuges, antigos cônjuges e prematuros
envelhecimento foram discretamente comentados. Larry Roberts, agora administrando uma pequena empresa que
estava
construindo uma nova geração de switch, morava em Woodside, Califórnia, um bem de vida
comunidade na península de São Francisco. Agora com cinquenta e oito anos, Roberts estava em um diário
regime de "drogas inteligentes" (Deprenyl, usado para tratar a doença de Parkinson, era um; a melatonina era
outro) para recuperar os poderes de concentração que possuía aos vinte e oito anos. Com
intensidade característica, ele mergulhou no assunto. Ele leu centenas de pesquisas
relatórios e até produziu uma fita de vídeo “anti-envelhecimento”.
Em 1983, Taylor deixou o Palo Alto Research Center da Xerox. Sua partida provocou um
onda de demissões de pesquisadores leais, que o seguiram até a Digital Equipment
Corp., onde montou um laboratório de pesquisa a apenas alguns quilômetros do Xerox PARC. Por anos ele
morava na esquina de Larry Roberts e nenhum dos dois sabia disso. Um dia um pedaço de
correspondência endereçada a Lawrence G. Roberts foi entregue na casa de Taylor, e os dois
descobriu que eles viviam a algumas centenas de metros um do outro.
No segundo dia da festa da BBN, na manhã de sábado, aconteceram as sessões de fotos, uma após a outra.
Primeiro foi a foto oficial do grupo. O grupo era grande, cerca de vinte e cinco pessoas. Quando
Len Kleinrock perdeu a primeira sessão de fotos oficial, outra teve que ser arranjada. Para
outra pose, o grupo principal do IMP Guys foi solicitado a posar exatamente como no original
Foto de IMP Guys tirada em 1969. “Vocês poderiam perder algum peso?” Cerf chamou
o fotógrafo tentou posicionar todos na foto.

Página 172
Depois, os cientistas foram levados de ônibus a dois quarteirões de distância para o Centro de Ciência Cristã por
uma sessão de fotos da revista Wired . Corajosamente, os dezenove homens se espremeram em um
ponte estreita no Mapparium do Centro. Sendo engenheiros, eles não podiam deixar de oferecer
alguns conselhos para o fotógrafo, que estava tendo um pouco de dificuldade para encaixá-los todos no
tiro: tente um ângulo diferente. Experimente uma configuração diferente. Experimente uma lente diferente.
Experimente um
câmera diferente. Mais tarde, alguns no grupo reclamaram sobre os hangers terem aparecido
para a foto, mas na maior parte, o bom humor geral do fim de semana estava começando
para infectar todos eles.
As múltiplas reivindicações de paternidade na Internet (não só cada homem esteve lá no
começar, mas cada um deu uma contribuição que considerou imensurável) saiu mais
visivelmente naquela tarde, durante uma entrevista em grupo com a Associated Press. o
a entrevista foi feita por viva-voz em uma suíte do hotel. Kahn, Heart, Engelbart,
e Kleinrock sentou-se curvado ao telefone enquanto o repórter da AP fazia perguntas. Antes
Por muito tempo, a entrevista se transformou em um estudo sobre gestão de crédito. Taylor chegou atrasado, mas
não é tarde demais para se envolver em alguma briga com Bob Kahn, que alertou a AP
repórter para ter certeza de distinguir entre os primeiros dias da ARPANET e o
Internet, e que foi a invenção do TCP / IP que marcou o verdadeiro início da
internetworking. Não é verdade, disse Taylor. As raízes da Internet certamente estão
theARPANET. O grupo ao redor do telefone ficou desconfortável. "E se
mulheres?" perguntou o repórter, talvez para quebrar o silêncio. “Há alguma mulher
pioneiros? ” Mais silêncio.
O fim de semana foi tão marcante para quem não esteve presente quanto para quem esteve. Tim Berners-
Lee, o inventor da World Wide Web, acabara de se mudar de Genebra para Boston para ingressar
Laboratório de Ciência da Computação do MIT. Ele não foi convidado, nem foi Marc Andreessen,
o co-programador da Mosaic, que acabara de deixar Illinois para desenvolver uma versão comercial
de seu navegador da Web. Concedido, eles não desempenharam papéis no nascimento de qualquer
theARPANETor the Internet (Andreessen nem nasceu até 1972, após o
primeirosARPANETnodes foram instalados) e não podiam ser tecnicamente contados como fundadores.
Mas eles estavam por trás das duas invenções que já estavam dando à Internet seu maior
alcançar a vida cotidiana.
Três anos antes, a NSF suspendeu as restrições ao uso comercial da Internet,
e agora você pode ficar rico não apenas inventando um portal para a Internet, mas tomando
o próprio negócio na Internet. Quando os repórteres pediram que comentassem sobre isso, alguns dos
os construtores ARPANET originais disseram que encontraram a nova comercialização da rede
lamentável. Outros deram boas-vindas.
Poucos pioneiros ficaram ricos. A invenção da Ethernet por Metcalfe o fez
um multimilionário. Em seus quase trinta anos como professor de ciência da computação na UCLA,
Kleinrock comandou um exército de Ph.D. alunos, muitos dos quais se tornaram
luminares no domínio das redes informáticas. Ainda ensinando na UCLA, Kleinrock dirigiu um
negócios de seminário de sucesso ao lado. Mas do outro lado do espectro estava Jon
Postel, o herói anônimo do networking. Ele observou o fim de semana de celebração em silêncio,
tanto quanto ele trabalhou por anos como detentor das RFCs e árbitro final em técnicas

Página 173
importa quando o consenso não pode ser alcançado. Postel acreditava que as decisões que tomou
no curso de seu trabalho ao longo dos anos tinha sido para o bem da comunidade, e que
iniciar uma empresa para lucrar com essas atividades seria considerado uma violação de
confiança publica.
A maioria dos caras do IMP acabou na alta administração da BBN. Walden depois serviu
como chefe de Heart, e Barker passou a comandar uma das divisões da BBN. A maioria
Uma exceção notável a isso foi Crowther, que permaneceu um programador. Por anos
Heart tinha sido o campeão de Crowther, fazendo lobby para que a empresa deixasse Crowther ser
Crowther e pensar em ideias engenhosas à sua maneira sonhadora. Nos anos seguintes ao
Projeto IMP, Crowther buscou algumas idéias incomuns sobre o processamento de linguagem natural,
e trabalhou extensivamente na tecnologia de comutação de pacotes de alta velocidade.
Severo Ornstein deixou a BBN na década de 1970 para a Xerox PARC, e enquanto lá ele começou
Profissionais de informática para responsabilidade social. Quando ele se aposentou da Xerox, ele e
sua esposa mudou-se para um dos cantos mais remotos da área da baía de São Francisco. Por anos
Ornstein ficou fora da Internet e por anos evitou o e-mail.
De todos, Vint Cerf foi talvez o mais comemorado neste fim de semana. Ele era a pessoa
a maior parte da imprensa recorreu para citações sobre as origens da Internet. No início de 1994 ele havia deixado
Kahn's Corporation for National Research Initiatives para retornar à MCI como um vice sênior
presidente e ajudar a construir os negócios da empresa na Internet. A reputação dele era boa
conhecido em toda a empresa. Em um centro de operações da MCI na Carolina do Norte, alguém
penduraram uma placa: “Vint Cerf é o Pai da Internet, mas somos as mães que têm
para fazer funcionar! ”
À medida que o jantar de sábado se aproximava, houve uma grande correria de última hora para garantir que
o roteiro da noite teria o tom certo. Conrades era para ser mestre de cerimônias para
o evento principal. Ninguém deve ser desprezado às custas de ninguém. Era um
tarefa quase impossível. No último minuto, as atribuições dos assentos foram embaralhadas novamente.
Quando o jantar finalmente começou, cerca de 250 pessoas lotaram o Grand Ballroom.
Fazendo lobby por um projeto de lei de telecomunicações que estava pendente, o congressista Markey deu um
discurso humorístico. Cerf apresentou dois prêmios e Kahn foi escolhido para o resto da vida
de realização. Louise Licklider, frágil e idosa, levantou-se para receber uma rodada prolongada
de aplausos em nome de seu falecido marido.
A celebração teve uma pungência especial para Heart, agora com sessenta e cinco anos, que recentemente
aposentou-se como presidente da Divisão de Sistemas e Tecnologia da BBN. Ele estava na BBN por
vinte e oito anos. Steve Levy, o presidente da BBN, chamou Heart ao pódio e
Heart fez um discurso no qual apontou as razões do projeto ARPANET
teve sucesso. “O projeto foi um exemplo do que pode ser realizado rapidamente, com um
liderança sofisticada realmente forte, recursos adequados e uma evitação de muitos
tipos de tolices burocráticas que podem afetar tantos projetos. ” Roberts cuidou de
aquele. Coração terminou em alta. “Apenas uma pequena fração dos treinados tecnicamente
a população tem a chance de pilotar um foguete tecnológico e, em seguida, vê essa revolução
mudar o mundo." A revolução da rede, disse Heart, ficaria entre um pequeno

Página 174
número das mudanças tecnológicas mais importantes do século. E naquela noite, em
aquele quarto, parecia que ele poderia estar certo.
Na manhã seguinte, um por um, os pioneiros do ARPANET se despediram e checaram
fora do hotel. Todo mundo ainda estava voando alto, pelo menos um pouco. Não tinha sido ruim
alguns dias.

Notas do Capítulo
Capítulo um
A descrição da formação da Agência de Projetos de Pesquisa Avançada e seus
O Information Processing Techniques Office é derivado de entrevistas pessoais, dois
livros escritos pelo consultor científico de Eisenhower, James Killian (ver bibliografia),
artigos de revistas e de uma excelente e completa história da agência
encomendado pela DARPA e escrito por Richard J. Barber Associates em 1975. O
a descrição dos primeiros anos de Licklider é baseada em palestras proferidas em sua homenagem, em entrevistas
com Louise Licklider e Bill McGill, e em um obituário escrito por Karl D. Kryter. o
a descrição da introdução de Licklider aos computadores é baseada em entrevistas pessoais com
Wes Clark e Jack Ruina, e na entrevista de Licklider com Charles Babbage
Institute, bem como o relatório Barber Associates.

Capítulo dois
A descrição do trabalho de Paul Baran em comunicações distribuídas é baseada em dados pessoais
entrevistas com Baran, bem como várias entrevistas realizadas pelo Instituto Babbage.
A descrição do trabalho inicial de Donald Davies sobre comutação de pacotes é baseada em
entrevistas e correspondência com Donald Davies, e em Martin Campbell-Kelly's
artigos e entrevistas. O incrível relatório de Arthur Norberg e Judy O'Neill, “A History
do Escritório de Técnicas de Processamento de Informação da Pesquisa Avançada de Defesa
Agência de Projetos ”também nos guiou através de material biográfico e através dos primeiros
anos de IPTO. O relatório serviu de base para seu livro Transforming Computer
Tecnologia: Processamento de Informações para o Pentágono, 1962 - de 1986 (Johns Hopkins
University Press, 1996).
Paul Baran e o professor Manley Irwin forneceram as informações sobre AT&T
ações judiciais contra partes que se acredita estarem privando a AT&T de receitas.
A patente de Doug Engelbart para seu mouse veio em 17 de novembro de 1970. É a patente nº
3.541.541.

Capítulo três
Página 175
A história de Bolt Beranek e Newman foi baseada em entrevistas pessoais com Dick
Bolt e Leo Beranek. A descrição do Lincoln Laboratory foi baseada em entrevistas
com Wes Clark, Frank Heart, Larry Roberts e Len Kleinrock. A descrição de
eventos em torno da solicitação de propostas para o processador de mensagens de interface foi
baseado em entrevistas com Jerome Elkind, Frank Heart, Dave Walden e Severo Ornstein,
bem como várias entrevistas realizadas pelo Instituto Charles Babbage.

Capítulo quatro
A descrição da construção do Interface Message Processor foi baseada em
entrevistas com Dave Walden, Ben Barker, Severo Ornstein, Bob Kahn, Frank Heart,
Alex McKenzie e Will Crowther. Também contamos com a solicitação de propostas do ARPA e
na proposta da BBN.

Capítulo Cinco
A descrição dos preparativos da UCLA para e recebimento do IMP Number One é baseada
em entrevistas com Len Kleinrock, Steve Crocker, Mike Wingfield e Vint Cerf. o
a descrição do trabalho inicial do Network Working Group em protocolos em camadas foi baseada
em entrevistas com Steve Crocker, Jon Postel e Vint Cerf. A descrição do primeiro
sessão de login entre UCLA e SRI foi baseada em entrevistas com Len Kleinrock e
Charley Kline. A descrição dos testes de travamento realizados no início de 1970 foi baseada
em entrevistas com Bob Kahn, Dave Walden e Vint Cerf.
John Melvin nos ajudou em nossa busca malsucedida por quem poderia ter estado no
outra extremidade da sessão de login inicial entre UCLA e SRI. Agora sabemos quem foi
não. Ainda estamos ansiosos para saber quem foi.

Capítulo Seis
A descrição dos primeiros sites ARPANET foi baseada na técnica trimestral da BBN
relatórios, artigos técnicos e entrevistas com John Melvin e John Day. Alex
McKenzie forneceu informações sobre os primeiros dias do Network Operations Center. o
descrição dos problemas de manutenção do IMP e resolução subsequente foi baseada em
entrevistas com Ben Barker, Frank Heart, Severo Ornstein e Alex McKenzie. o
a descrição da demonstração ICCC '72 da ARPANET foi baseada em entrevistas
com Al Vezza, Bob Kahn, Steve Crocker, Len Kleinrock, Jon Postel, Alex McKenzie,
e Larry Roberts. “PARRY Encounters the Doctor” foi publicado na íntegra como um
RFC e publicado na revista Datamation , em julho de 1973.
Capítulo Sete
Página 176
A descrição do hack original de e-mail de Ray Tomlinson e sua escolha do sinal @ como
um separador - e um problema para os usuários do UNIX - foi baseado em entrevistas com Tomlinson
e JohnVittal.
Partes dos arquivos do MsgGroup foram enviadas para nós pela primeira vez por Ed Vielmetti. Einar Stefferud
salvou todos eles e os depositou no Boston Computer Museum. Ken Harrenstien
nos ajudou a esclarecer um pouco da história da lista de discussão. Ned Freed nos forneceu
números comparativos sobre o uso de e-mail.
A descrição das origens do Adventure foi baseada em entrevistas com Don Woods,
Will Crowther e Dave Walden. Lembranças da aventura de madeiras também aparecem em A
Unix Book of Games, de Janice Winsor, Prentice-Hall Computer Books, 1996.
As observações na página 208 sobre as proclamações de oficialidade na Internet vêm de
“How Anarchy Works,” por Paulina Borsook, revista Wired , outubro de 1995. A história
do programa de dedo veio de Les Earnest.

Capítulo Oito
As descrições dos programas de rádio de pacote e satélite de pacote foram baseadas em vários
artigos técnicos (ver bibliografia), bem como entrevistas pessoais com Vint Cerf, Alex
McKenzie e Bob Kahn. Parte do material foi retirado de entrevistas realizadas pelo
Instituto Charles Babbage. A descrição da evolução do TCP / IP foi baseada em
entrevistas com Vint Cerf, Bob Kahn, John Shoch, Alex McKenzie e Jon Postel.
A descrição das origens da Ethernet foi baseada em entrevistas com Bob Metcalfe.
A descrição da Ethernet por Butler Lampson foi tirada de Fumbling the Future, de Douglas
Smith e Robert C. Alexander (William Morrow, 1988), p. 97
Artigo de Ole Jacobsen, “The Trouble with OSI,” ConneXions, volume 6, no. 5 de maio de 1992,
particularmente a referência a pilhas AA duplas, ajudou a guiar a seção sobre OSI vs.
TCP / IP. O livro de Peter Salus, Casting the Net, (Addison-Wesley, 1995), e seu artigo
“Protocol Wars: Is OSI finally Dead?” em ConneXions, volume 9, no. 8 de agosto de 1995, também
ajudou a enquadrar o debate.
Danny Cohen nos deu permissão para editar um pouco e reimprimir o poema que leu para
aqueles reunidos no Act One Symposium na UCLA em 1989.

Bibliografia
Livros
Alexander, Charles C. Holding the Line: The Eisenhower Era, 1952–1961. Bloomington:
Indiana University Press, 1975.

Página 177
Baran, Paul. "Troca de pacotes." Em Fundamentos de Digital Switching. 2d ed. Editado por
John C. McDonald. Nova York: Plenum Press, 1990.
Barry, John A. Technobabble. Cambridge: MIT Press, 1991.
Bell, C. Gordon, Alan Kotok, Thomas N. Hastings e Richard Hill. “A Evolução de
o DEC System-10. ” Em Engenharia da Computação: Uma Visão DEC de Sistemas de Hardware
Projeto. Editado por C. Gordon Bell, J. Craig Mudge e John E. McNamara. Bedford,
Mass .: Digital Equipment Corporation, 1978.
Bell, C. Gordon, Gerald Butler, Robert Gray, John E. McNamara, Donald Vonada e
Ronald Wilson. “O PDP-1 e outros computadores de 18 bits.” Em Engenharia da Computação: A
Visão do DEC do projeto de sistemas de hardware. Editado por C. Gordon Bell, J. Craig Mudge e
John E. McNamara. Bedford, Mass .: Digital Equipment Corporation, 1978.
Bergaust, Erik. Wernher von Braun. Washington, DC: National Space Institute, 1976.
Blanc, Robert P. e Ira W. Cotton, eds. Rede de computadores. Nova York: IEEE Press,
1976.
Brendon, Piers. Ike: sua vida e tempos. Nova York: Harper & Row, 1986.
Brooks, John. Telefone: os primeiros cem anos. Nova York: Harper & Row, 1976.
Brucker, Roger W. e Richard A. Watson. A caverna mais longa. Nova York: Alfred A.
Knopf, 1976.
Clarke, Arthur C., et al. O primeiro século do telefone - e além: ensaios sobre o
Ocasião do 100º Aniversário da Comunicação Telefônica. Nova York: Thomas Y.
Crowell Company, 1977
Ciência da Computação, Análise Numérica e Computação. Laboratório Físico Nacional,
Engineering Sciences Group, Research 1971. London: Her Majesty's Stationery Office,
1972.
Froehlich, Fritz E., Allen Kent e Carolyn M. Hall, eds. “ARPANET, the Defense Data
Rede e Internet." Em The Froehlich / Kent Encyclopedia of Telecommunications. Novo
York: Marcel Dekker, Inc., 1991.
Goldstein, Jack S. Um tipo diferente de tempo: a vida de Jerrold R. Zacharias. Cambridge
MIT Press, 1992.
Halberstam, David. Os anos cinquenta. Nova York: Villard Books, 1993.
Hall, Mark e John Barry. Sunburst: The Ascent of Sun Microsystems. Chicago:
Contemporary Books, 1990.

Página 178
Hammond, William M. Public Affairs: The Military and the Media, 1962–
1968. Washington, DC: Centro de História Militar, Exército dos EUA, Superintendente de
Documentos, US Government Printing Office, 1968.
Hamner, W. Clay. “O serviço postal dos Estados Unidos: estará pronto para o ano
2000? ” No Futuro dos Correios. Editado por Joel L. Fleishman. Nova york:
Praeger, 1983.
Holzmann, Gerard J. e Björn Pehrson. The Early History of Data Network. Los
Alamitos, Califórnia: IEEE Computer Society Press, 1995.
Kidder, Tracy. A alma de uma nova máquina. Boston: Little, Brown, 1981.
Killian, James R., Jr. Sputnik, Scientists e Eisenhower: A Memoir of the First Special
Assistente do Presidente de Ciência e Tecnologia. Cambridge: MIT Press, 1977.
———. A educação de um presidente de faculdade: uma memória. Cambridge: MIT Press, 1985.
Kleinrock, Leonard. Redes de comunicação: fluxo e atraso de mensagens estocásticas. Novo
York: McGraw-Hill, 1964.
———. Sistemas de enfileiramento. 2 vols. Nova York: John Wiley & Sons, 1974–1976.
Langdon-Davies, John. NPL: Livro do Jubileu do Laboratório Nacional de Física. Londres:
His Majesty's Stationery Office, 1951.
Lebow, Irwin. Rodovias e vias de informação: do telégrafo ao
século 21. Nova York: IEEE Press, 1995.
Licklider, JCR “Computers and Government.” Na era do computador: Vinte anos
Ver, editado por Michael L. Dertouzos e Joel Moses. Série do bicentenário do MIT.
Cambridge: MIT Press, 1979.
———. Bibliotecas do futuro. Cambridge: MIT Press, 1965.
Padlipsky, MA The Elements of Networking Style and Other Essays & Animadversions
da Arte da Rede de Intercomputadores. Englewood Cliffs, NJ: Prentice-Hall, Inc., 1985.
Proceedings of the Fifth Data Communications Symposium. IEEE Computer Society,
Snowbird, Utah, 27–29 de setembro de 1977.
Pyatt, Edward. O Laboratório Físico Nacional: Uma História. Bristol, Inglaterra: Adam
Hilger Ltd., 1983.
Redmond, Kent C. e Thomas M. Smith. O Projeto Whirlwind: A História de um
Pioneer Computer. Bedford, Mass .: Digital Press, 1980.
Rheingold, Howard. A Comunidade Virtual. Nova York: Harper Perennial, 1994.

Página 179
———. Ferramentas para o pensamento: as pessoas e as ideias por trás do próximo computador
Revolução. Nova York: Simon & Schuster, 1988.
Roberts, Lawrence G. “The ARPANET and Computer Networks.” Em uma história de
Estações de trabalho pessoais, editado por Adele Goldberg. Leitura, Massa: ACM Press (Addison-
Wesley), 1988.
Rose, Marshall T. A mensagem da Internet: fechando o livro com a eletrônica
Enviar. Englewood Cliffs, NJ: PTR Prentice Hall, 1993.
Sherman, Kenneth. Comunicações de dados: um guia do usuário. Reston, Virginia: Reston
Editora, 1981.
Smith, Douglas K. e Robert C. Alexander. Atrapalhando o futuro: como a Xerox inventou,
em seguida, Ignorado, o primeiro computador pessoal. Nova York: William Morrow, 1988.
Udall, Stewart L. The Myths of August: A Personal Exploration of Our TragicCold War
Caso com o Atom. Nova York: Pantheon, 1994.
Wildes, Karl L. e Nilo A. Lindgren. Um Século de Engenharia Elétrica e Computador
Science at MIT, 1882–1982. Cambridge, Mass .: MIT Press, 1985.
Vencedor, Langdon. A baleia e o reator: uma busca por limites em uma era de alta
Tecnologia. Chicago: University of Chicago Press, 1986.

Jornal, revista e jornal

Artigos
Abramson, Norman. “Desenvolvimento do Alohanet.” IEEE Transactions onInformation
Teoria, janeiro de 1985.
Anderson, Christopher. “The Accidental Superhighway.” The Economist, 1 de julho de 1995.
Baran, Paul. “Em Redes de Comunicações Distribuídas.” Transações IEEE em
Communications Systems, 1 de março de 1964.
———. “Sistemas de comunicação digital confiáveis usando repetidor de rede não confiável
Nós. ” RAND Corporation Mathematics Division Report No. P-1995, 27 de maio de 1960.
Boggs, David R., John F. Shoch, Edward A. Taft e Robert M. Metcalfe. “PUP: um
Arquitetura de rede. ” IEEE Transactions on Communications, abril de 1980.
“Bolt Beranek acusado pelo governo de cobranças excessivas de contrato”. Dow Jones News
Service– Wall Street Journal combinado stories, 27 de outubro de 1980.
“Bolt Beranek and Newman: Two Aides Plead Guilty to US Charge.” Dow Jones News
Service– Wall Street Journal combinado histórias, 12 de novembro de 1980.

Página 180
“Bolt Beranek, assessores acusados de trapacear os EUA em vários empregos.” The WallStreet
Journal, 28 de outubro de 1980.
Bulkeley, William M. “Can He Transform Big Ideas in Big Sales?” The WallStreet
Journal, 12 de setembro de 1994.
Bush, Vannevar. “Como podemos pensar.” Atlantic Monthly, julho de 1945.
Campbell-Kelly, Martin. “Data Communications at the National Physical Laboratory:
1965-1975. ” Annals of the History of Computing 9, no. 3/4, 1988.
Cerf, Vinton G. e Peter T. Kirstein. “Problemas na Rede de Pacotes
Interconexão. ” Proceedings of the IEEE, novembro de 1979.
Cerf, Vinton G. e Robert E. Kahn. “Um protocolo para rede de pacotes
Intercomunicação." IEEE Transactions on Communications, maio de 1974.
Cerf, Vinton. “PARRY encontra o médico: conversa entre um simulado
Paranóico e um psiquiatra simulado. ” Datamation, julho de 1973.
Clark, David D. “The Design Philosophy of the DARPA Internet Protocols.” Processos
da Association for Computing Machinery SigcommSymposium on Data
Communications, agosto de 1988.
Clark, David D., Kenneth T. Pogran e David P. Reed. “Uma introdução à área local
Redes. ” Proceedings of the IEEE, novembro de 1979.
Comer, Douglas. “The Computer Science Research Network CSNET: A History and
Relatório de status. ” Comunicações da ACM, outubro de 1983.
Crowther, WR, FE Heart, AA McKenzie, JM McQuillan e DC
Walden. “Issues in Packet Switching Networking Design.” Proceedings ofthe 1975
National Computer Conference, 1975.
Denning, Peter J. “The Science of Computing: TheARPANETAfter Twenty
Anos." American Scientist, novembro-dezembro de 1989.
Denning, Peter J., Anthony Hearn e C. William Kern. “História e Visão Geral de
CSNET. “Proceedings of the Association for Computing Machinery Sigcomm Symposium
on Data Communications, março de 1983.
“Dr. JCR Licklider recebe prêmio bienal na reunião do State College. ” O jornal
da Acoustical Society of America, novembro de 1950.
Engelbart, Douglas C. “Coordinated Information Services for a Discipline-or Mission-
Comunidade Orientada. ” Proceedings of the Second AnnualComputer Communications
Conferência, janeiro de 1972.

Página 181
———. “Implicações Intelectuais de Redes de Computadores Multi-Acesso”. Processos de
a Conferência Interdisciplinar sobre Redes de Computadores com Múltiplos Acessos, Austin, Texas,
Abril de 1970.
Ericson, Raymond. “Philharmonic Hall Acoustics Start Rumors Flying.” NewYork
Times, 4 de dezembro de 1962.
Finucane, Martin. “Creators of the Internet Forerunner Gather in Boston.” Leitura (missa)
Daily Times Herald, 12 de setembro de 1994.
Fisher, Sharon. “The Largest Computer Network: Internet Links UNIX Computers
No mundo todo." InfoWorld, 25 de abril de 1988.
Hines, William. "Enviar." Chicago Sun-Times, 29 de março de 1978.
Haughney, Joseph F. “Anatomy of a Packet-Switching
Revisão. ” DataCommunications, junho de 1982.
Holusha, John. “Computer Tied Carter, Mondale Campaigns: The Bethesda
Conexão." Washington Star, 21 de novembro de 1976.
Jacobs, Irwin M., Richard Binder e EstilV. Hoversten. “Pacote de Uso Geral
Redes de satélite. ” Proceedings of the IEEE, novembro de 1978.
Jennings, Dennis M., Lawrence H. Landweber, Ira H. Fuchs, David J. Farber e W.
Richards Adrion. “Redes de computadores para cientistas”. Science, 22 de fevereiro de 1986.
Kahn, Robert E. “O Papel do Governo na Evolução do
Internet." Comunicações da ACM, agosto de 1994.
Kahn, Robert E., Steven A. Gronemeyer, Jerry Burchfiel e Ronald C. Kunzelman.
“Advances in Packet Radio Technology.” Proceedings of theIEEE, novembro de 1978.
Kantrowitz, Barbara e Adam Rogers. “O nascimento da Internet.” Newsweek, 8 de agosto
1994.
Kleinrock, Leonard. “Princípios e lições em comunicações de pacotes.” Processos de
o IEEE, novembro de 1978.
Landweber, Lawrence H., Dennis M. Jennings e Ira Fuchs. “Computador de Pesquisa
Redes e sua interconexão. ” IEEE CommunicationsMagazine, junho de 1986.
Lee, JAN e Robert F. Rosin. “The CTSS Interviews.” Anais IEEE da História de
Computing 14, no. 1, 1992.
———. “The Project MAC Interviews.” Anais de História da Computação do IEEE 14, no.
2, 1992.

Página 182
Licklider, JCR "A Gridless, Wireless Rat-Shocker." Journal of Comparativeand
Physiological Psychology 44, 1951.
———. “Simbiose Homem-Computador”. Reimprimir. In Memoriam: JCR Licklider. Digital
Equipment Corporation Systems Research Center, 7 de agosto de 1990.
Licklider, JCR e Albert Vezza. “Aplicações de Informação
Redes. ” Proceedings of the IEEE, novembro de 1978.
Licklider, JCR e Robert W. Taylor. “O computador como dispositivo de comunicação”.
Reimprimir. In Memoriam: JCR Licklider. Sistemas Digital Equipment Corporation
Centro de Pesquisa, 7 de agosto de 1990.
Markoff, John. “Up from the Computer Underground.” The NewYork Times, 27 de agosto
1993.
McKenzie, Alexander A. e BP Cosell, JM McQuillan, MJ Thrope. "O
Centro de controle de rede para a rede ARPA. ” Proceedings of theIEEE, 1972.
Mier, Edwin E. “Rede de Preparação do Departamento de Defesa
Muralhas. ” DataCommunications, outubro de 1983.
Mills, Jeffrey. "Correio eletrônico." Associated Press, 4 de janeiro de 1976.
---."Correio eletrônico." Associated Press, 19 de junho de 1976.
———. “O serviço postal testa o serviço de mensagem eletrônica”. Associated Press, 28 de março
1978.
Mills, Kay. “The Public Concern: Mail.” Newhouse News Service, 27 de julho de 1976.
Mohl, Bruce A. “2 Bolt, Beranek Officials Collapse in Federal Court.” TheBoston
Globe, 31 de outubro de 1980.
Pallesen, Gayle. “Consultant Firm on PBIA Faces Criminal Charges.” Palm Beach
(Flórida) Post, 8 de novembro de 1980.
Pearse, Ben. “Chefe da Defesa na Era do Sputnik.” The NewYork Times Magazine, 10
Novembro de 1957.
Piscina, Bob. “Inventing the Future: UCLA Scientist Who Helped Create Internet Isn't
Feito ainda. ” Los Angeles Times, 11 de agosto de 1994.
Quarterman, John S. e Josiah C. Hoskins. “Computador Notável
Redes. ” Comunicações da ACM, outubro de 1986.
Roberts, Lawrence G. “ARPA Network Implications.” Educom, Boletim do
Conselho Interuniversitário de Comunicações, outono de 1971.
Salus, Peter. “Pioneiros da Internet.” Internet World, setembro de 1994.

Página 183
“Scanning the Issues,” IEEE Spectrum, agosto de 1964.
Schonberg, Harold C. “4 Acoustics Experts to Urge Revisions in Auditorium.” o
NewYork Times, 4 de abril de 1963.
———. “Acoustics Again: Philharmonic Hall tem alguns defeitos, mas também tem uma poesia
Própria. ” The NewYork Times, 9 de dezembro de 1962.
Vendendo. Consumer Reports, junho de 1977.
Agências Espaciais. “ARPA Shapes Military Space Research.” Aviation Week, 16 de junho de 1958.
Sterling, Bruce. "Internet." Fantasy and Science Fiction, fevereiro de 1993.
Swartzlander, Earl. “Time-Sharing at MIT.” Anais da História da Computação 14 do IEEE ,
não. 1, 1992.
“Transforming BB&N: ARPANET's Architect Targets Non-Military Networks.” Dados
Communications, abril de 1984.
Wilson, David McKay. “BBN Executives Collapse in Court.” Cambridge (Massachusetts)
Chronicle, 6 de novembro de 1980.
———. “Consulting Co. Admits Overcharge.” Cambridge (Mass.) Chronicle, 30 de outubro
1980.
Zitner, Aaron. “A Quiet Leap Forward in Cyberspace.” The Boston Globe, 11 de setembro
1994.
Zuckerman, Laurence. “A BBN sai das sombras e entra no centro das atenções.” o
NewYork Times, 17 de julho de 1995.

Artigos não publicados, entrevistas de

Fontes secundárias e outras
Documentos
”Ato Um.” Simpósio sobre a história da ARPANET realizado na Universidade de
Califórnia em Los Angeles, 17 de agosto de 1989. Transcrição.
ARPA Network Information Center, Stanford Research Institute, Menlo Park, Califórnia.
“Cenários de uso da ARPANET.” Livreto. Preparado para a Conferência Internacional
on Computer Communication, Washington, DC, outubro de 1972.

Página 184
Baran, Paul. Entrevista por Judy O'Neill. Instituto Charles Babbage, DARPA / IPTO Oral
Coleção de História, Centro de História da Informação da Universidade de Minnesota
Processing, Minneapolis, Minn., 5 de março de 1990.
Barlow, John Perry. “Crime e perplexidade.” Pinedale, Wyo., Junho de 1990.
BBN Systems and Technologies Corporation. “Relatório Anual da Ciência
Programa de Desenvolvimento." Cambridge, Massachusetts, 1988.
Bhushan, AK “Comentários sobre o protocolo de transferência de arquivos”. Solicitação de comentários 385.
Stanford Research Institute, Menlo Park, Califórnia, agosto de 1972.
———. “O Protocolo de Transferência de Arquivos.” Solicitação de comentários 354. Stanford Research
Institute, Menlo Park, Califórnia, julho de 1972.
Bhushan, Abhay, Ken Pogran, Ray Tomlinson e Jim White. “Rede de Padronização
Cabeçalhos de correio. ” Pedido de Comentários 561. MIT, Cambridge, Mass., 5 de setembro de 1973.
Azul, Allan. Entrevista por William Aspray. Instituto Charles Babbage, DARPA / IPTO
Coleção de História Oral, Centro de História da Informação da Universidade de Minnesota
Processing, Minneapolis, Minn., 12 de junho de 1989.
Bolt Beranek and Newman Inc. “ARPANETCompletion Report: Draft.” Cambridge,
Missa, setembro de 1977.
———. “Proposta BBN nº IMP P69-IST-5: Interface de Processadores de Mensagens para o ARPA
Rede de Computadores. ” Proposta de projeto. Enviado ao Departamento do Exército,
Serviço de Fornecimento de Defesa, em resposta ao RFQ Nº DAHC15 69 Q 0002. Washington, DC,
6 de setembro de 1968.
———. “Relatório BBN nº 1763: Design inicial para processadores de mensagens de interface para o
Rede de Computadores ARPA. ” Proposta de projeto. Submetido à Pesquisa Avançada
Agência de Projetos sob o contrato nº. DAHC 15-69-C-0179. Washington, DC, 6 de janeiro
1969.
———. “BBN Report No. 1822: Interface Message Processor.” Relatório técnico.
Cambridge, Massachusetts, 1969.
———. “Interface Message Processors for the ARPA Computer Network.” Trimestral
relatórios técnicos. Enviado para a Agência de Projetos de Pesquisa Avançada sob contrato
não. DAHC 15-69-C-0179 e contrato no. F08606-73-C-0027. Washington, DC, 1969-
1973.
———. “Manual de operação para processadores de mensagens de interface: 516 IMP, 316 IMP, TEP.”
Revisado. Apresentado à Agência de Projetos de Pesquisa Avançada sob o pedido ARPA nº.
1260, contrato nº DAHC15-69-C-0179. Arlington, Va., Abril de 1973.
———. “Relatório No. 4799: A History of theARPANET: The First Decade.” Submetido para
Agência de Projetos de Pesquisa Avançada de Defesa. Arlington, Va., Abril de 1981.

Página 185
———. “O Plano de Quatro Cidades.” Projecto de proposta e análise de custos para manutenção de IMPs
e TIPs em Boston, Washington, Los Angeles e San Francisco. Artigos da BBN
Divisão 6. Cambridge, Massachusetts, abril de 1974.
———. Memorandos internos e documentos relacionados ao trabalho da Divisão 6. Cambridge,
Mass., 1971–1972.
Carr, C. Stephen, Stephen D. Crocker e Vinton G. Cerf. “HOST-HOST
Protocolo de comunicação na rede ARPA. ” Artigo apresentado na Spring Joint
Conferência de Informática da Federação Americana de Sociedades de Processamento de Informação,
1970.
Catton, Major General, USAF, Jack. Carta para FR Collbohm da RAND Corporation, 11
Outubro de 1965. Referindo-se ao plano de desenvolvimento técnico preliminar para o bloco de mensagens
rede para a Agência de Comunicações de Defesa.
Cerf, Vinton G. “Confessions of a Hearing-Dischack Engineer.” Não publicado.
———. “PARRY encontra o médico.” Solicitação de comentários 439 (NIC 13771).
Network Working Group, 21 de janeiro de 1973.
Cerf, Vinton G. e Jonathan B. Postel. “Especificação de Transmissão Internetwork
Protocolo de controle: TCP versão 3. ” Instituto de Ciências da Informação, University of Southern
Califórnia, janeiro de 1978.
Cerf, Vinton G. Entrevista por Judy O'Neill. Instituto Charles Babbage, DARPA / IPTO
Coleção de História Oral, Centro de História da Informação da Universidade de Minnesota
Processing, Minneapolis, Minn., 24 de abril de 1990.
Cerf, Vinton G. e Robert Kahn. “Protocolos de nível HOST e PROCESS para
Comunicação entre redes. ” Notas do Grupo de Trabalho 39 da Rede Internacional,
13 de setembro de 1973.
Clark, Wesley. Entrevista por Judy O'Neill. Instituto Charles Babbage, DARPA / IPTO Oral
Coleção de História, Centro de História da Informação da Universidade de Minnesota
Processing, Minneapolis, Minn., 3 de maio de 1990.
Crocker, David H. “Padrão para o formato de mensagens de texto da Internet ARPA.” Solicitação
para comentários 822. Departamento de Engenharia Elétrica, Universidade de Delaware, 13
Agosto de 1982.
Crocker, David H., John J. Vittal, Kenneth T. Pogran e D. Austin Henderson Jr.
“Padrão para o formato de mensagens de texto da rede ARPA.” Solicitação de comentários 733.
The RAND Corporation, Santa Monica, Calif., 21 de novembro de 1977.
Crowther, William. Entrevista por Judy O'Neill. Instituto Charles Babbage, DARPA / IPTO
Coleção de História Oral, Centro de História da Informação da Universidade de Minnesota
Processing, Minneapolis, Minn., 12 de março de 1990.

Página 186
Crowther, William e David Walden. “CurrentViews of Timing.” Memorando para
Frank E. Heart, Cambridge, Massachusetts, 8 de julho de 1969.
Davies, Donald W. “Further Speculations on Data Transmission.” Papéis privados. Londres,
16 de novembro de 1965.
———. “Proposta para uma Rede de Comunicação Digital.” Artigos privados, fotocopiados
e amplamente divulgado. Londres, junho de 1966.
———. “Proposta para o Desenvolvimento de um Serviço Nacional de Comunicações para On-
Processamento de dados em linha. ” Papéis privados. Londres, 15 de dezembro de 1965.
———. “Processamento remoto de dados on-line e suas necessidades de comunicação”. Privado
papéis. Londres, 10 de novembro de 1965.
Davies, Donald W. Entrevista por Martin Campbell-Kelly. Laboratório Físico Nacional,
Reino Unido, 17 de março de 1986.
Davies, Donald W., Keith Bartlett, Roger Scantlebury e Peter Wilkinson. “A Digital
Rede de comunicações para computadores que oferecem resposta rápida em terminais remotos. ”
Artigo apresentado no Association for Computing Machinery Symposium on Operating
System Principles, Gatlinburg, Tenn., Outubro de 1967.
Davis, Ruth M. “Comentários e recomendações sobre a rede ARPA.”
Centro de Ciências e Tecnologia da Computação, Escritório Nacional de Padrões dos EUA, 6
Outubro de 1971.
Digital Equipment Corporation. “Interface de Processadores de Mensagens para o Computador ARPA
Rede." Proposta de projeto. Enviado ao Departamento do Exército, Suprimento de Defesa
Serviço, no RFQ no. DAHC15 69 Q 002, 5 de setembro de 1968.
Frank, Howard. Entrevista por Judy O'Neill. Instituto Charles Babbage, DARPA / IPTO
Coleção de História Oral, Centro de História da Informação da Universidade de Minnesota
Processing, Minneapolis, Minn., 30 de março de 1990.
Goldstein, Paul. “The PropostaARPANETDivestiture: Legal Issues and Economic
Problemas." Documento de trabalho, Cabledata Associates, Inc., CAWP no. 101, 27 de julho de 1973.
Hauben, Michael e Ronda Hauben. A página Netizens Netbook pode ser encontrada em
http://www.columbia.edu/~hauben/netbook/. O trabalho de Haubens também apareceu em
o Boletim Informativo Amador de Computador, disponível em
ftp://wuarchive.wustl.edu/doc/misc/acn/.
Heart, FE, RE Kahn, SM Ornstein, WR Crowther e DC Walden. "O
Processador de mensagens de interface para a rede de computadores ARPA. ” Trabalho apresentado no
Spring Joint Computer Conference da American Federation of Information Processing
Societies, 1970.

Página 187
Heart, Frank E. Entrevista por Judy O'Neill. Instituto Charles Babbage, DARPA / IPTO
Coleção de História Oral, Centro de História da Informação da Universidade de Minnesota
Processing, Minneapolis, Minn., 13 de março de 1990.
Herzfeld, Charles. Entrevista com Arthur Norberg. Charles Babbage Institute,
Coleção de História Oral DARPA / IPTO, Centro de História da Universidade de Minnesota
Information Processing, Minneapolis, Minn., 6 de agosto de 1990.
Honeywell, Inc. “Honeywell at Bolt Beranek and Newman, Inc.” Folheto. Publicado por
a demonstração da Rede ARPA na Conferência Internacional de Computação
Comunicação, Washington, DC, outubro de 1972.
Instituto de Ciências da Informação, University of Southern California. “Padrão DOD
Protocolo de Controle de Transmissão." Pedido de Comentários 761. Preparado para a Defesa
Agência de Projetos de Pesquisa Avançada, Escritório de Técnicas de Processamento de Informação,
Arlington, Va., Janeiro de 1980.
International Data Corporation. “ARPA Computer Network Provides Communications
Tecnologia para computador / interação de computador dentro da comunidade de pesquisa especial. ”
Relatório da indústria e análise do mercado. Newtonville, Mass., 3 de março de 1972.
Kahn, Robert. Entrevista por Judy O'Neill. Instituto Charles Babbage, DARPA / IPTO Oral
Coleção de História, Centro de História da Informação da Universidade de Minnesota
Processing, Minneapolis, Minn., 24 de abril de 1990.
Kahn, Robert. Entrevista por William Aspray. Instituto Charles Babbage, DARPA / IPTO
Coleção de História Oral, Centro de História da Informação da Universidade de Minnesota
Processing, Minneapolis, Minn., 22 de março de 1989.
Kleinrock, Leonard. Entrevista por Judy O'Neill. Charles Babbage Institute,
Coleção de História Oral DARPA / IPTO, Centro de História da Universidade de Minnesota
Information Processing, Minneapolis, Minn., 3 de abril de 1990.
Kryter, Karl D. “Lick as a Psychoacoustician and Physioacoustician.” Apresentação
homenageando JCR Licklider na Reunião da Acoustical Society of America,
Baltimore, Md., 30 de abril de 1991.
———. Obituário de JCR Licklider, Journal of the Acoustical Society
da América, dezembro de 1990.
Licklider, JCR e Welden E. Clark. “Comunicação Homem-Computador On-Line.”
Artigo apresentado na Spring Joint Computer Conference da American Federation of
Information Processing Societies, 1962.
Licklider, JCR Entrevista por William Aspray. Charles Babbage Institute,
Coleção de História Oral DARPA / IPTO, Centro de História da Universidade de Minnesota
Information Processing, Minneapolis, Minn., 28 de outubro de 1988.

Página 188
Lukasik, Stephen. Entrevista por Judy O'Neill. Instituto Charles Babbage, DARPA / IPTO
Coleção de História Oral, Centro de História da Informação da Universidade de Minnesota
Processing, Minneapolis, Minn., 17 de outubro de 1991.
Marill, Thomas e Lawrence G. Roberts. “Em direção a uma rede cooperativa de tempo
Computadores compartilhados. ” Artigo apresentado na Fall Joint Computer Conference of the
American Federation of Information Processing Societies, 1966.
McCarthy, J., S. Boilen, E. Fredkin e JCR Licklider. “A Time-Sharing Debugging
Sistema para um pequeno computador. ” Artigo apresentado na Spring Joint Computer Conference
da American Federation of Information Processing Societies, 1963.
McKenzie, Alexander A. “The ARPA Network Control Center.” Trabalho apresentado no
Quarto Simpósio de Comunicação de Dados do Instituto de Elétrica e Eletrônica
Engenheiros, outubro de 1975.
McKenzie, Alexander A. Entrevista por Judy O'Neill. Charles Babbage Institute,
Coleção de História Oral DARPA / IPTO, Centro de História da Universidade de Minnesota
Information Processing, Minneapolis, Minn., 13 de março de 1990.
Grupo de mensagens. O texto completo de mais de 2.600 mensagens de e-mail enviadas por membros do
o Message Group (ou MsgGroup), uma das primeiras listas de mala direta, relativa ao
desenvolvimento de e-mail. The Computer Museum, Boston, Massachusetts, junho de 1975 a junho de 1986.
Documento eletrônico. (http://www.tcm.org/msgroup)
Metcalfe, Robert. “Alguns momentos históricos em rede.” Solicitação de comentários 89.
Network Working Group, 19 de janeiro de 1971.
Myer, TH e DA Henderson. “Protocolo de transmissão de mensagem.” Pedido para
Comentários 680. Stanford Research Institute, Menlo Park, Califórnia, 1975.
Conselho Nacional de Pesquisa, Comissão de Engenharia e Sistemas Técnicos.
“Protocolos de Transporte para Redes de Dados do Departamento de Defesa”. Reporte ao
Departamento de Defesa e o National Bureau of Standards, Board on
Telecommunication and Computer Applications, 1985.
Neigus, NJ “Protocolo de Transferência de Arquivos”. Pedido de Comentários 542. Bolt Beranek e
Newman Inc., Cambridge, Massachusetts, 12 de julho de 1973.
Norberg, Arthur L. e Judy E. O'Neill. “Uma História do Processamento de Informação
Escritório de Técnicas da Agência de Projetos de Pesquisa Avançada de Defesa. ” Charles
Babbage Institute, University of Minnesota, Minneapolis, Minn., 1992.
Ornstein, Severo M., FE Heart, WR Crowther, HK Rising, SB Russell e A.
Michel. “O Terminal IMP para a rede ARPA.” Artigo apresentado na Spring Joint
Conferência de Informática da Federação Americana de Sociedades de Processamento de Informação,
Atlantic City, NJ, maio de 1972.

Página 189
Ornstein, Severo. Entrevista por Judy O'Neill. Instituto Charles Babbage, DARPA / IPTO
Coleção de História Oral, Centro de História da Informação da Universidade de Minnesota
Processing, Minneapolis, Minn., 6 de março de 1990.
Pogran, Ken, John Vittal, Dave Crowther e Austin Henderson. “Oficial proposto
Padrão para o formato de mensagens de rede ARPA. ” Pedido de Comentários 724. MIT,
Cambridge, Massachusetts, 12 de maio de 1977.
Postel, Jonathan B. “Simple Mail Transfer Protocol.” Solicitação de comentários 821.
Instituto de Ciências da Informação, University of Southern California, agosto de 1982.
———. “Especificação do protocolo de controle de transmissão entre redes: TCP Versão 4.”
Instituto de Ciências da Informação, University of Southern California, setembro de 1978.
———. “TCP e IP Bake Off.” Solicitação de comentários 1025. Grupo de Trabalho da Rede,
Setembro de 1987.
Pouzin, Louis. “Protocolos de rede.” Notas do Grupo de Trabalho da Rede Internacional
50, setembro de 1973.
———. “Apresentação e Aspectos Principais do Projeto da Rede de Computadores Cyclades.”
Artigo apresentado no IEEE Third Data Communications Symposium (Data Networks:
Analysis and Design), novembro de 1973.
———. “Protocolo de comunicação experimental: quadro de mensagem básico.” Notas do
International Network Working Group 48, janeiro de 1974.
———. “Interconexão de Redes de Comutação de Pacotes.” Notas do Internacional
Network Working Group 42, outubro de 1973.
———. “Arquitetura e componentes de rede”. Notas da Rede Internacional
Grupo de Trabalho 49, agosto de 1973.
RAND Corporation. “Desenvolvimento do Bloco de Mensagens Adaptativo Distribuído
Rede." Recomendação ao Estado-Maior da Aeronáutica, 30 de agosto de 1965.
RCA Service Company, Government Services Division. “ARPANETStudy Final
Relatório." Apresentado sob o contrato no. F08606-73-C-0018. 24 de novembro de 1972.
Richard J. Barber Associates, Inc. “The Advanced Research Projects Agency: 1958–
1974. ” Um estudo para a Agência de Projetos de Pesquisa Avançada sob o contrato nº. MDA-
903-74-C-0096. Washington, DC, dezembro de 1975. Fotocópia.
Roberts, Lawrence G. “Extensions of Packet Communications Technology to a Hand-
Terminal pessoal mantido. ” Artigo apresentado na Spring Joint Computer Conference of
a American Federation of Information Processing Societies, maio de 1972.

Página 190
———. “Multiple Computer Networks and Intercomputer Communication.” Papel
apresentado no Association for Computing Machinery Symposium on Operating System
Princípios, outubro de 1967.
Roberts, Lawrence G. e Barry D. Wessler. “Desenvolvimento de Redes de Computadores para
Consiga o Compartilhamento de Recursos. ” Artigo apresentado na Spring Joint Computer Conference of
a Federação Americana de Sociedades de Processamento de Informação, 1970.
Roberts, Lawrence G. Entrevista por Arthur Norberg. Charles Babbage Institute,
Coleção de História Oral DARPA / IPTO, Centro de História da Universidade de Minnesota
Information Processing, Minneapolis, Minn., 4 de abril de 1989.
Ruina, Jack. Entrevista por William Aspray. Instituto Charles Babbage, DARPA / IPTO
Coleção de História Oral, Centro de História da Informação da Universidade de Minnesota
Processing, Minneapolis, Minn., 20 de abril de 1989.
Sutherland, Ivan. Entrevista por William Aspray. Charles Babbage Institute DARPA / IPTO
Coleção de História Oral, Centro de História da Informação da Universidade de Minnesota
Processing, Minneapolis, Minn., 1 de maio de 1989.
Taylor, Robert. Entrevista por William Aspray. Instituto Charles Babbage, DARPA / IPTO
Coleção de História Oral, Centro de História da Informação da Universidade de Minnesota
Processing, Minneapolis, Minn., 28 de fevereiro de 1989.
Serviço Postal dos EUA. “Electronic Message Systems for the US Postal Service.” Relatorio de
o Painel de Apoio do USPS, Comitê de Telecomunicações, Washington, DC,
Janeiro de 1977.
Walden, David C. “Experiências na construção, operação e uso da rede ARPA.”
Artigo apresentado na Segunda Conferência de Computadores EUA-Japão, Tóquio, Japão, agosto
1975.
Walden, David. Entrevista por Judy O'Neill. Instituto Charles Babbage, DARPA / IPTO
Coleção de História Oral, Centro de História da Informação da Universidade de Minnesota
Processing, Minneapolis, Minn., 6 de fevereiro de 1990.
Walker, Stephen T. “Relatório de Conclusão: Desenvolvimento da Rede ARPA.” Defesa
Agência de Projetos de Pesquisa Avançada, Escritório de Técnicas de Processamento de Informação,
Washington, DC, 4 de janeiro de 1978.
Weik, Martin H. “A Third Survey of Domestic Electronic Digital Computing Systems.”
Laboratórios de Pesquisa Balística, relatório no. 1115, março de 1961.
Branco, Jim. “Protocolo de Correio Proposto.” Solicitação de comentários 524. Stanford Research
Institute, Menlo Park, Califórnia, 13 de junho de 1973.
Zimmermann, H. e M. Elie. “Protocolo Host-Host padrão proposto para
Redes de computadores heterogêneas: protocolo de transporte. ” Notas do Internacional
Network Working Group 43, dezembro de 1973.

Página 191

Arquivos Eletrônicos
Charles Babbage Institute, Center for the History of Information Processing, University
de Minnesota. Grande coleção de arquivos relacionada à história da computação. Mais
informações podem ser obtidas através do site da CBI em
http://cbi.itdean.umn.edu/cbi/welcome.html ou via e-mail endereçado a
bruce@fs1.itdean.umn.edu.
Museu do Computador, Boston, Massachusetts. Grande coleção relativa à história de
computação, incluindo os arquivos do Grupo de Mensagens sobre os primeiros
desenvolvimento de e-mail. O arquivo está disponível na página inicial em
http://www.tcm.org/msgroup.
Instituto de Ciências da Informação, University of Southern California. A coleção inclui até
índices e testes atualizados de padrões, protocolos, solicitações de comentários (RFCs) da Internet,
e várias outras notas técnicas disponíveis no site da ISI: http://www.isi.edu. Alguns
das RFCs anteriores não estão disponíveis eletronicamente, mas são arquivadas off-line em
moda meticulosa pelo editor da RFC Jon Postel. Um arquivo pesquisável é mantido em
http://info.internet.isi.edu:80/in-notes/rfc.
Ohio State University, Departamento de Ciência da Computação e da Informação. The CIS Web
O servidor oferece acesso a RFCs e vários outros documentos técnicos e históricos relacionados
para a Internet via http: //www.cis. ohio-state.edu:80/hypertext/information/rfc.html.

Agradecimentos
Este livro surgiu de uma ideia que se originou com engenheiros da Bolt Beranek e
Novo homem. As memórias estavam ficando confusas no final de 1993, quando começamos a pensar
sobre fazer um livro, e Frank Heart e outros estavam interessados em ter o BBN
papel considerável na criação do ARPANET original gravado. Não só
empresa abriu seus arquivos para nós e cooperou em todos os sentidos, mas ajudou a financiar o projeto
também, concordando em não exercer nenhum controle sobre o conteúdo do livro. Mariana
Bremer, então bibliotecário-chefe da BBN, fez o telefonema inicial que levou ao livro. Cary
Lu e John Markoff nos incentivaram a assumir o projeto.
Helen Samuels e o pessoal dos arquivos do MIT foram extremamente úteis, assim como Kevin
Corbitt, arquivista assistente do Charles Babbage Institute, Center for the History of
Processamento de Informações, na Universidade de Minnesota. Somos gratos a John Day,
Larry Roberts, Al Vezza e John Shoch por vasculhar caixas velhas para nós.
Deborah Melone e Bob Menk enviaram fotos e arquivos da BBN. Kevin kelly
e Martha Baer, da revista Wired , nos focou na história do e-mail. Noel Chiappa,
tutor afável, passava horas ao telefone explicando, entre outros pontos técnicos,
como as tabelas de roteamento e RFNMs funcionam.

Página 192
As seguintes pessoas nos permitiram entrevistá-los longamente: Wes Clark, Vint Cerf, Bob
Kahn, Severo Ornstein, Bob Taylor, Larry Roberts, Jon Postel, Frank Heart, Alex
McKenzie, Dave Walden, Ben Barker, Donald Davies, Paul Baran, Len Kleinrock, Steve
Lukasik, Steve Crocker e Bob Metcalfe. Louise Licklider, Bill McGill, John Swets,
e Karl Kryter compartilharam suas memórias de JCR Licklider conosco, e Mitch Waldrop
ajudou a preencher alguns espaços em branco. Phil Patton nos confiou sua cópia do Barber Associates
estudo, pelo qual somos gratos. Brian Reid, Gary Chapman, Kevin Buckley, Dave
Farber e o Coronel Clair Shirey nos deixaram escolher seus cérebros sobre vários tópicos relevantes.
Marsha Longshore do IEEE enviou artigos técnicos em nossa direção, e Earl Swartzlander nos emprestou
suas cópias dos anais da história do computador do IEEE. Steve Wolff nos ajudou a entender o
eventos frequentemente labirínticos que ocorreram na década de 1980, particularmente em relação ao papel da NSF
no desenvolvimento da Internet.
O manuscrito foi lido total ou parcialmente em vários estágios de conclusão por Vint Cerf,
Lyman Chapin, Steve Crocker, Peter Denning, Frank Heart, Bob Kahn, John Kelley,
Larry Landweber, Steven Levy, Hank Long, Paul McJones, Alex McKenzie, Peter Preuss,
Larry Roberts, Einar Stefferud, Bob Taylor, John Vittal, Dave Walden e Susan
Zacharias. Everett Hafner, perfeccionista e burro de carga, nos manteve honestos. O manuscrito
beneficiou-se tremendamente da mente perspicaz e da caneta cuidadosa de Richard Lyon.
A responsabilidade pelos erros, é claro, é nossa.
Jon Coifman, nosso grande assistente de pesquisa, ajudou imensamente com os estágios finais do
preparação do manuscrito, e Andrea Perry foi uma revisora cuidadosa. Julian Darley
ajudou a digitar as alterações. Denise Bugg transcreveu muitas fitas. Pete Lewis salvou o dia
com sua caneta Wacom Tablet. Sigrid Cerf nos forneceu histórias coloridas e muita sabedoria
adendo. Matt Pallakoff, que escreveu Retrieve It !, ajudou a economizar horas de nossas semanas de trabalho.
E obrigado a John Aielli, quem sabe por quê.
Zoë Mark Lyon, embora ocupada com seu próprio livro, tirou um tempo de sua programação a cada
único dia para fortalecer nossos espíritos e nos fazer rir. Denny Lyon, Amy Goodwin, Kelly
McRee, Ellen Lyon e Jeremy Lyon corajosamente assumiram o cuidado extra das crianças. Sherry Turkle,
Sarah Hafner, Teresa Carpenter, Terry Evers, Robert Wallich, Tony Bianco e Carol
Flake emprestou um ouvido simpático. Ladd Hanson e Mark McFarland ajudaram com técnicas
problemas. George Hackett e Bob Berdahl eram chefes sofredores, contra seus
melhor julgamento. Ann Walther, Lindsey Lane e Tom Ferguson (guardião da postagem
metro) veio ao resgate mais de uma vez. Paulina Borsook ofereceu seu costume
insights inestimáveis.
Durante nossas viagens, Chris Paine, Katherine Magraw, Holly Myers, Kirk Neely, Lisa Van
Dusen, Candace Thille, Julie Graham, Debbie Yager, Katherine e Irving Gottsegen,
Jane e Frank Heart, Barry Muhlfelder, Jane Anderson e Eric Ponteri colocaram um telhado
nossas cabeças.
Como de costume, os agentes literários John Brockman e Katinka Matson sabiam que havia um livro
há. Bob Bender, nosso maravilhoso editor na Simon & Schuster, sabia o que aquele livro
deveria estar. Sua maravilhosa assistente, Johanna Li, nunca nos decepcionou.

Página 193
—Katie Hafner
katieh @ zilker.net
—Matthew Lyon
m_lyon @ utxvms.cc.utexas.edu
Texto original
Cyberpunk: Outlaws and Hackers on the Computer Frontier(with John Markoff)
Sugerir uma tradução melhor