Современная электроника №5/2025

СОВРЕМЕННЫЕ ТЕХНОЛОГИИ 45 WWW.CTA.RU СОВРЕМЕННАЯ ЭЛЕКТРОНИКА • № 5 / 2025 стала подопытной и постепенно улуч- шалась. BBN справилась с этим в рам- ках бюджета и в пределах годового срока контракта. Ларри Робертс и ARPA, без- условно, были очень довольны про- грессом. К концу года ARPA заключила новый контракт с BBN на расширение сети до 19 узлов. Прежде чем обсудить, как проект мас- штабировался, давайте коротко рас- смотрим рабочие отношения Ларри Робертса с командой BBN. Робертс был очень активнымменеджером в проекте ARPAnet, а не только его финансистом. Работа с Ларри Робертсом При подготовке запроса на предло- жение (RFP) для ARPAnet Робертс тща- тельно изучил множество технических аспектов и проконсультировался с веду- щими специалистами вычислительно- го сообщества. В результате он принял несколько ключевых решений ещё до того, как контракт оказался в руках BBN. Как сказал Фрэнк Херт: «Они [DARPA] выбрали скорость передачи 50 кило- бит, выбрали сайты, решили вопросы, связанные с контрольными суммами. Множество работы было проделано DARPA заранее» . Как выразился Дэйв Уолден, BBN без- условно можно считать оператором ARPAnet и основным драйвером инже- нерных работ, но ARPA была высоко­ уровневым управляющим. Вся эта опе- рация, сам ARPAnet, была задумана для того, чтобы предоставить новые возможности подрядчикам ARPAnet. Таким образом, постоянное руковод- ство со стороны Робертса было вполне логичным. Кроме того, в ARPA работа- ли некоторые из лучших умов, которые могли подсказать команде BBN техниче- ские решения. Поэтому Робертс и ARPA, когда это было необходимо, организо- вывали встречи между BBN, подрядчи- ками узлов и другими заинтересован- ными сторонами. Теперь уже известная NetworkWorking Group , которая обсуж- дала множество идей, относящихся к ARPAnet, таких как будущие протоколы TCP/IP, является плодом таких усилий. Когда проект был запущен, Робертс в основном оставил принятие ежеднев- ных решений на ответственности BBN. Команда не должна была запрашивать его одобрение по многим вопросам. Однако он продолжал держать руку на пульсе проекта и время от времени высказывал свои возражения. Робертс мог теоретически использовать свою власть как финансирующая сторона проекта, но на практике такая система не работала. Если Робертс не соглашался с подходом команды к какой-то пробле- ме, они обсуждали это по телефону или лично, пока не приходили к какому-то соглашению. В случае спорных вопросов это могло занять несколько дней. Но в большинстве случаев соглашение быва- ло достигнуто достаточно быстро. Команда BBN проявляла огромное уважение к Робертсу как к инженеру. В свою очередь, Робертс, похоже, также сильно уважал команду BBN. У Роберт- са была прямая линия связи не только с Хертом, но и с людьми, ответственными за отдельные компоненты технологий в команде, такими как Северо Орнстайн. По словам Херта, обычно не проходило и недели, чтобы Робертс не поговорил с кем-то из команды. Орнстайн, который был особенно непринуждённым, сказал, что он просто беседовал с Робертсом так же, как и с любым другим коллегой. Начало масштабирования сети Первоначальный контракт на соз- дание сети из четырёх узлов оказался успешным (рис. 6). Поэтому ARPA реши- ла предоставить BBN новый контракт для руководства проектом по расшире- нию сети до 19 узлов. А в начале 1970-х годов сама BBN стала пятым узлом ARPAnet, поскольку сеть продолжала расширяться со скоростью примерно один узел в месяц (рис. 7). Масштабирование сети С продолжением проекта по расши- рению сети возникали новые инже- нерные проблемы. Несмотря на то что Фрэнк Херт был известен своей край- не осторожной инженерной позици- ей, нельзя было ожидать, что всё будет работать идеально. Этот проект был экспериментом, уникальной сетью, и в этом контексте можно было быть осто- рожным только до определённой сте- пени, иначе весь прогресс был бы при- остановлен. Во многих областях команда BBN рас- сматривала технологии, которые изна- чально считались вполне достаточ- ными, с пониманием, что они смогут продолжать совершенствовать компо- ненты технологии в процессе работы. Одним из таких случаев стали сетевые протоколы. Начальные протоколыNCP были признаныNetworkWorking Group недостаточно оптимальными. С годами протоколыNCP улучшались до тех пор, пока не были полностью заменены на знаменитые теперь протоколы TCP/IP, разработанные Каном и Серфом. Как отмечается в отчёте о завершении проекта ARPAnet, порой проблемы, воз- никавшие в рабочей сети, были гораздо более серьёзными, чем просто мелкие сбои. В 1970 году была продемонстриро- вана серьёзная проблема с управлени- ем потоком IMP и распределением памя- ти. Если узловые хосты не учитывали ошибки, это могло случайно остановить всюработу сети. Однако несмотря на то что BBN и другие потратили несколь- ко месяцев на решение этой проблемы, ARPAnet продолжал обеспечивать ста- бильную работу для своих узлов. Вот как об этом вспоминает Дэйв Уол- ден: «…почти сразу стало очевидно для всех, кто раньше в это не верил, чтото, что мы изначально реализовали, было недостаточно. И то, что мы специфи- цировали для хостов, и что они реализо- вали, имеломного последствий. Теперь это было сделано, но работало не так хорошо. Так что в первые год или два, довольно долгое время, существовали неформальные правила в сети: не зака- чивайте данные в сеть с хостов слиш- комбыстро, чтобы не “положить” сеть. Потому что мы все знали, что алго- ритмы не работали, они явно лома- лись, когда вы слишком сильно нагружа- ли их. И поэтому это промежуточное решение работало в сети – вот что не могут себе представить те, кто рабо- тает над доказательством правиль- ности программ. На самом деле это было довольно полезно в те ранние дни экспериментов, потому что все дого- Рис. 5. Фрэнк Херт с одной из первых IMP