Berkeley Network , или Berknet , была ранней глобальной сетью , разработанной в Калифорнийском университете в Беркли в 1978 году, в первую очередь Эриком Шмидтом в рамках его магистерской диссертации . [1] Сеть непрерывно соединяла около дюжины компьютеров, работающих под управлением BSD [2], и предоставляла своим пользователям услуги электронной почты , передачи файлов , печати и удаленного выполнения команд , а также была подключена к двум другим основным сетям, которые использовались в то время, ARPANET и UUCPNET . [3]
Сеть работала с использованием высокоскоростных последовательных соединений , 1200 бит/с в первоначальной системе. Ее программная реализация поставлялась с Berkeley Software Distribution, начиная с версии 2.0. [1] Она состояла из дисциплины линии в ядре Unix , [4] набора демонов , которые управляли очередями команд, отправляемых между машинами, и набора программ уровня пользователя, которые ставили в очередь фактические команды. Berkeley Network представила файл .netrc .
Выпуск UUCP как части версии 7 Unix в 1979 году привел к небольшому внешнему интересу к системе; Мэри Энн Хортон отметила в 1984 году, что «Berknets больше нет». [5] Поддержка пользовательской схемы адресации электронной почты Berknet предоставлялась в программе Sendmail до 1993 года. [4]
Разработка того, что стало Berknet, началась с первоначальной концепции, разработанной Бобом Фабри , советником Эрика Шмидта . Шмидт разрабатывал систему до своего ухода на перерыв в мае. Первоначально система была разработана для соединения только двух машин, известных как A и Q, обе машины PDP-11 работали под управлением Unix . [6] Разработка продолжалась до конца семестра в мае. К 1 мая первоначальная система, соединяющая две машины, A и Q, была готова к работе. Поскольку разработка велась в основном на машине A, система также использовалась для распространения кода на Q. Черновая задача переноса кода на Q привела к ранним попыткам автоматизировать систему. [6]
По мере того, как код начал функционировать, он также начал использоваться другими пользователями, и это привело к подключению A к новой машине, C. Это создало новую проблему, заключающуюся в том, что первоначальная реализация требовала одного и того же входа пользователя на обеих машинах, и попытка синхронизировать это между несколькими машинами привела к тому, что файл паролей A стал слишком большим. Первоначально решение этой проблемы было достигнуто путем выделения «бесплатных» учетных записей на обеих машинах, которые использовались Berknet, а также использования файла .netrc для автоматического входа в них при необходимости. [6]
Затем была добавлена третья машина, Cory. [6] Чтобы решить проблему с аккаунтом и управлять физической маршрутизацией, A стал хабом, ответственным за хранение и пересылку любых сообщений между C и Cory. Для управления этим была введена таблица маршрутизации. Именно в таком состоянии Шмидт завершил первую версию в мае. Пока он отсутствовал, Вычислительный центр внес несколько изменений в систему, и это привело к появлению нескольких несовместимых версий Berknet и периодическим сбоям в работе системы, включая неработоспособность системы sendmail. [7]
К тому времени, как Шмидт вернулся в систему в октябре, была добавлена машина VAX 11/780 , что увеличило общее количество поддерживаемых версий Unix до трех. Затем make использовался для сборки и распространения кода на машины, включая использование старой версии кода для загрузки машины Cory, которая работала под управлением Unix версии 6, в то время как другие работали под управлением 7. Дальнейшие изменения привели к созданию стабильной версии и начали документирование, а также было добавлено несколько дополнительных сайтов. Производительность стала проблемой, особенно для машин, которым была поручена пересылка, и требовала ручного обслуживания для поддержания работоспособности системы. [8]
Система имела некоторое сходство с UUCP в том, что она использовала пакетную систему передачи файлов на основе демона Unix , который выполнял реальные передачи, а также определял подходящий простой сетевой протокол для перемещения данных по телефонным каналам. Протокол встроен в приложение net , которое отслеживает появление новых файлов в ряде определенных расположений, представляющих очереди. [8] Когда появляется файл, net запускает терминальное соединение с выбранной удаленной машиной, выдает команды и выполняет передачу файлов, а затем отключает и удаляет локальный файл, если она прошла успешно. [9]
С точки зрения пользователя, существует ряд отдельных приложений, которые составляют систему, одни для чтения и написания почты, одно для перемещения файлов между машинами и т. д. Все они работают, помещая файлы в соответствующие очереди, которые затем автоматически перемещают данные на целевую машину, где они собираются заново и перемещаются обратно в пользовательские каталоги для использования. [8] Наиболее используемым приложением был netcp , который копировал файлы по сети. Он предоставлялся с двумя именами файлов, первое — путь к существующему файлу, а второе — путь к желаемому конечному местоположению. Пути представляли собой комбинацию имени машины, за которым следовало двоеточие, а затем обычный путь Unix, разделенный косой чертой. Например:
netcp testfile.txt Кори:/usr/pascal/sh
скопировал бы файл testfile.txt в папку /usr/pascal/sh на машине Cory . [9]
Аналогично, существующее почтовое приложение было изменено для понимания той же схемы адресации и поддерживалось утилитой mmail , которая автоматически добавляла заголовки, чтобы указать, откуда пришло сообщение. На стороне приема новое приложение netmail использует net для входа на именованную удаленную машину и чтения любой почты, найденной там. После завершения этого процесса prmail копирует сообщения в локальную почту пользователя , где их можно читать и отвечать на них как обычно. Автоматизация этих отдельных задач была быстро введена. [10]
Базовый протокол передачи был организован в три уровня. Верхний был командным протоколом, который определял общую структуру файла, ниже был потоковый протокол, который разбивал файл на несколько пакетов, а в самом низу был аппаратный уровень, использующий последовательные порты . [11]
Уровень команд в основном состоял из формата файла, который начинался с индикатора длины, за которым следовал заголовок, команда для запуска на удаленной машине, а затем любые требуемые данные. Команда net собирала файлы, добавляла индикатор длины, а затем помещала полученный файл в соответствующую очередь. Заголовок содержал имена исходной и целевой машин, имена входа для использования на обеих машинах, номер версии, временные метки и затем «псевдокоманду». Данные заголовка записывались как обычный текст ASCII с полями, разделенными двоеточиями. [11]
Во время передачи файл разбивается на пакеты для исправления ошибок . Пакеты имеют заголовок, состоящий из байта длины, который допускает до 255 байт в пакете, за которым следует двухбайтовый номер пакета, однобайтовый индикатор типа, однобайтовая контрольная сумма и затем данные. [11] Контрольная сумма помещается в начало, поскольку пакеты имеют переменную длину, и это упрощает код. Существует несколько типов пакетов, которые содержат командную информацию или данные. Среди них пакет «сброс», который указывает на начало новой передачи с удаленной машины. Протокол был очень похож на XMODEM по сложности, не имел скользящих окон или потокового подтверждения, функций, которые считались важными для добавления в будущие версии. [12]
На аппаратном уровне система представляла собой просто последовательный порт, соединяющий две машины. Однако существующие системы Unix не могли напрямую обрабатывать 8-битные данные ASCII без значительных накладных расходов, поэтому отправляемые данные кодировались тремя 8-битными байтами, упакованными в четыре 6-битных символа в печатаемом диапазоне. Это приводило к накладным расходам в 33%, что также считалось важной областью для возможного улучшения. [12]