Xerox Network Systems ( XNS ) — это пакет компьютерных сетевых протоколов , разработанный компанией Xerox в рамках архитектуры сетевых систем Xerox . Он обеспечивал сетевую связь общего назначения, межсетевую маршрутизацию и доставку пакетов, а также функции более высокого уровня, такие как надежный поток и удаленные вызовы процедур . XNS предшествовал развитию сетевой модели взаимодействия открытых систем (OSI) и повлиял на нее, а также оказал большое влияние на проекты локальных сетей в 1980-х годах.
XNS был разработан отделом разработки систем Xerox в начале 1980-х годов, которому было поручено вывести на рынок исследования Xerox PARC . XNS был основан на более раннем (и столь же влиятельном) пакете PARC Universal Packet (PUP), выпущенном в конце 1970-х годов. Некоторые протоколы пакета XNS представляли собой слегка модифицированные версии протоколов пакета Pup. В XNS добавлена концепция номера сети, позволяющая создавать более крупные сети из множества меньших, при этом маршрутизаторы контролируют поток информации между сетями.
Спецификации набора протоколов для XNS были размещены в открытом доступе в 1977 году. Это помогло XNS стать каноническим протоколом локальной сети , копируемым в различной степени практически всеми сетевыми системами, использовавшимися в 1990-е годы. XNS использовался без изменений в 3+Share компании 3Com и Net/One компании Ungermann-Bass . Он также использовался, с модификациями, в качестве основы для Novell NetWare и Banyan VINES . XNS использовался в качестве основы для системы AppleNet , но так и не был коммерциализирован; ряд решений XNS распространенных проблем был использован в замене AppleNet, AppleTalk .
По сравнению с 7 уровнями модели OSI , XNS представляет собой пятиуровневую систему, [1] как и более поздний набор протоколов Интернета .
Физический уровень и уровень канала передачи данных модели OSI соответствуют физическому уровню (уровню 0) в XNS, который был разработан для использования транспортного механизма базового оборудования и не разделял канал передачи данных. В частности, физический уровень XNS на самом деле представляет собой систему локальной сети Ethernet , также разрабатываемую Xerox в то же время, и ряд ее проектных решений отражает этот факт. [1] Система была разработана с возможностью замены Ethernet какой-либо другой системой, но это не было определено протоколом (да и не должно было быть таковым).
Основная часть XNS — это определение внутреннего транспортного уровня (уровень 1), который соответствует сетевому уровню OSI, и именно здесь определяется основной протокол межсетевого взаимодействия, IDP. XNS объединил сеансовый и транспортный уровни OSI в единый уровень межпроцессных коммуникаций (уровень 2). Уровень 3 представлял собой управление ресурсами, аналогичный уровню презентации OSI. [1] [2]
Наконец, поверх обеих моделей находится уровень приложения, хотя эти уровни не были определены в стандарте XNS. [1]
Основным протоколом межсетевого уровня является протокол дейтаграмм Интернета ( IDP ). IDP является близким потомком межсетевого протокола Pup и примерно соответствует уровню интернет-протокола (IP) в наборе интернет-протоколов. [1]
IDP использует 48-битный адрес Ethernet в качестве основы для собственной сетевой адресации , обычно используя MAC-адрес машины в качестве основного уникального идентификатора. К этому добавляется еще один 48-битный адресный раздел, предоставляемый сетевым оборудованием; 32 бита предоставляются маршрутизаторами для идентификации номера сети в объединенной сети, а еще 16 бит определяют номер сокета для выбора услуги внутри одного хоста. Часть адреса сети также включает в себя специальное значение, означающее «эта сеть», для использования хостами, которые (еще) не знали своего сетевого номера. [2]
В отличие от TCP/IP, номера сокетов являются частью полного сетевого адреса в заголовке IDP, поэтому протоколам верхнего уровня не требуется реализовывать демультиплексирование; IDP также предоставляет типы пакетов (опять же, в отличие от IP). IDP также содержит контрольную сумму, охватывающую весь пакет, но это необязательно, а не обязательно. Это отражает тот факт, что в локальных сетях обычно низкий уровень ошибок, поэтому XNS удалил исправление ошибок из протоколов нижнего уровня, чтобы повысить производительность. Исправление ошибок может быть дополнительно добавлено на более высоких уровнях стека протоколов, например, в собственный протокол SPP XNS. Из-за этого замечания по конструкции XNS считался более быстрым, чем IP. [1]
В соответствии с LAN-соединениями с малой задержкой, на которых он работает, XNS использует небольшой размер пакета, что повышает производительность за счет низкого уровня ошибок и короткого времени обработки. Пакеты IDP имеют длину до 576 байт, включая 30-байтовый заголовок IDP . [2] Для сравнения, IP требует, чтобы все хосты поддерживали не менее 576, но поддерживают пакеты размером до 65 КБ. Отдельные пары хостов XNS в конкретной сети могут использовать пакеты большего размера, но для их обработки не требуется маршрутизатор XNS, и не определен механизм определения того, поддерживают ли промежуточные маршрутизаторы пакеты большего размера. Кроме того, пакеты не могут быть фрагментированы, как в IP.
Протокол информации о маршрутизации (RIP), потомок протокола информации о шлюзе Pup , используется в качестве системы обмена информацией о маршрутизаторе и (слегка измененный для соответствия синтаксису адресов других наборов протоколов) продолжает использоваться и сегодня в других наборах протоколов. , например набор протоколов Интернета. [2]
XNS также реализует простой протокол эха на межсетевом уровне, аналогичный протоколу ping IP , но работающий на более низком уровне сетевого стека. Вместо добавления данных ICMP в качестве полезной нагрузки в IP-пакет, как в случае с ping, эхо XNS помещало команду непосредственно в базовый пакет IDP. [2] То же самое может быть достигнуто в IP путем расширения поля «Протокол ICMP» заголовка IP.
Существует два основных протокола транспортного уровня, оба сильно отличаются от своего предшественника Pup:
XNS, как и Pup, также использует EP , протокол ошибок , в качестве системы отчетов о таких проблемах, как отброшенные пакеты. Это обеспечило уникальный набор пакетов, которые можно фильтровать для поиска проблем. [2]
В исходной концепции Xerox протоколы приложений, такие как удаленная печать, хранение, отправка по почте и т. д., использовали протокол удаленного вызова процедур под названием Courier . Courier содержал примитивы для реализации большинства функций вызовов функций языка программирования Xerox Mesa . Приложениям приходилось вручную сериализовать и десериализовать вызовы функций в Courier; не было автоматического средства для перевода кадра активации функции в RPC (т.е. не было «компилятора RPC»). Поскольку Courier использовался всеми приложениями, в документах протокола приложения XNS указаны только интерфейсы вызова функций Courier и кортежи привязки модуль+функция. В Courier была специальная возможность, позволяющая вызову функции отправлять или получать большие объемы данных. [2]
Первоначально определение местоположения службы XNS выполнялось посредством широковещательной рассылки удаленных вызовов процедур с использованием серии расширяющихся кольцевых широковещательных рассылок (по согласованию с локальным маршрутизатором, чтобы получить сети на увеличивающихся расстояниях). Позже для выполнения этого была создана трехуровневая служба каталогов Clearinghouse Protocol. местоположение службы, а широковещательная рассылка по расширяющемуся кольцу использовалась только для определения местоположения первоначального информационного центра. [2]
Из-за тесной интеграции с Mesa в качестве базовой технологии многие традиционные протоколы более высокого уровня не были частью самой системы XNS. Это означало, что поставщики, использующие протоколы XNS, создали свои собственные решения для совместного использования файлов и поддержки принтеров . Хотя многие из этих сторонних продуктов теоретически могли взаимодействовать друг с другом на уровне пакетов, возможности вызова служб приложений друг друга были незначительными или вообще отсутствовали. Это привело к полной фрагментации рынка XNS и было названо одной из причин того, что IP легко вытеснил его. [1]
Протоколы XNS также включали протокол аутентификации и службу аутентификации для его поддержки. Его «Надежные полномочия» были основаны на том же протоколе Нидхэма-Шредера , который позже использовался Kerberos . После обращения к службе аутентификации для получения учетных данных этот протокол обеспечивал упрощенный способ цифровой подписи вызовов процедур Courier, чтобы получатели могли проверять подпись и аутентифицировать отправителей через Интернет XNS без необходимости повторно обращаться к службе аутентификации для проверки длины протокола. сеанс связи. [3]
Язык печати Xerox, Interpress , представлял собой стандарт двоичного формата для управления лазерными принтерами. Разработчики этого языка Джон Уорнок и Чак Гешке позже покинули Xerox PARC, чтобы основать Adobe Systems . Прежде чем уйти, они осознали сложность определения двоичного языка печати, в котором функции сериализации задания на печать были громоздкими и что затрудняло отладку ошибочных заданий на печать. Чтобы осознать ценность определения программируемого и легко отлаживаемого задания печати в ASCII, Уорнок и Гешке создали язык Postscript как один из своих первых продуктов в Adobe.
Поскольку все более 8000 машин в корпоративной внутренней сети Xerox работали на архитектуре Wildflower (разработанной Батлером Лэмпсоном), существовал протокол удаленной отладки микрокода. По сути, функция «смотри и тыкай» может останавливать и манипулировать состоянием микрокода машины серии C или D в любой точке мира, а затем перезапускать машину.
Кроме того, существовал протокол удаленной отладки для отладчика подкачки мира. [4] Этот протокол может с помощью отладчика «nub» заморозить рабочую станцию, а затем просмотреть различные части памяти, изменить переменные и продолжить выполнение. Если бы символы отладки были доступны, аварийную машину можно было бы отладить удаленно из любой точки мира.
На последнем году обучения в Гарвардском университете Боб Меткалф начал проходить собеседования в ряде компаний и был тепло встречен Джерри Элкиндом и Бобом Тейлором из Xerox PARC , которые начинали работать над сетевыми компьютерными рабочими станциями, которые впоследствии стали Xerox Alto . Он согласился присоединиться к PARC в июле, после защиты диссертации. В 1970 году, занимаясь серфингом на диване в доме Стива Крокера во время посещения конференции, Меткалф взял со стола экземпляр « Протоколы осенней совместной компьютерной конференции» , чтобы заснуть во время его чтения. Вместо этого он был очарован статьей об ALOHAnet , более ранней глобальной сетевой системе. К июню он разработал свои собственные теории сетей и представил их своим профессорам, которые отвергли их, и его «вышвырнули на задницу». [5]
Меткалфа приветствовали в PARC, несмотря на его неудачную диссертацию, и вскоре он начал разработку того, что тогда называлось «ALOHAnet в проводе». Он объединился с Дэвидом Боггсом , чтобы помочь с электронной реализацией, и к концу 1973 года они создали работающее оборудование со скоростью 3 Мбит/с. Затем пара начала работать над простым протоколом, который будет работать в системе. Это привело к разработке системы PARC Universal Packet (Pup), и к концу 1974 года Pup успешно работал в Ethernet. Они подали патент на эту концепцию, при этом Меткалф добавил несколько других имен, поскольку, по его мнению, они заслуживают упоминания, а затем представили в отдел коммуникаций ACM документ «Ethernet: распределенная коммутация пакетов для локальных компьютерных сетей», опубликованный в июле. 1976. [5]
К 1975 году, задолго до завершения проекта PUP, Меткалф уже раздражался жестким руководством Xerox. Он считал, что компании следует немедленно запустить Ethernet в производство, но не обнаружил особого интереса со стороны высшего руководства. Знаменательное событие произошло, когда в 1974 году профессора знаменитой лаборатории искусственного интеллекта Массачусетского технологического института обратились к Xerox с намерением купить Ethernet для использования в своей лаборатории. Руководство Xerox отказалось, полагая, что Ethernet лучше использовать для продажи собственного оборудования. Затем Лаборатория искусственного интеллекта приступила к созданию собственной версии Ethernet Chaosnet . [6]
В конце концов Меткалф покинул Xerox в ноябре 1975 года и перешел в Transaction Technology, подразделение Citibank , которому было поручено разрабатывать передовые продукты. Однако семь месяцев спустя его снова переманил в Xerox Дэвид Лиддл , который недавно организовал в Xerox отдел разработки систем специально для вывода на рынок концепций PARC. Меткалф немедленно приступил к перепроектированию Ethernet для работы со скоростью 20 Мбит/с и предпринял попытку переписать Pup в версии производственного качества. В поисках помощи по «Пупу» Меткалф обратился к Йогену Далалу , который в то время заканчивал докторскую диссертацию под руководством Винта Серфа в Стэнфордском университете . Далала также активно набирала команда ARPANET Боба Кана ( работавшая над TCP/IP), но когда Серф ушел, чтобы присоединиться к DARPA , Далал согласился перейти в PARC и начал там работать в 1977 году .
Далал собрал команду, в которую вошли Уильям Кроутер и Хэл Мюррей, и начал с полного обзора Pup. Далал также пытался продолжать участвовать в проектах TCP, проводимых в DARPA, но в конце концов сдался и полностью сосредоточился на Pup. Далал объединил свой опыт работы с ARPANET с концепциями Pup, и к концу 1977 года они опубликовали первый проект спецификации сетевой системы Xerox. По сути, это была версия Pup с абсолютными 48-битными идентификаторами хостов и трехсторонним рукопожатием TCP в протоколе последовательных пакетов. [8]
К началу 1978 года новая система заработала, но руководство все еще не предпринимало никаких шагов по ее коммерциализации. Как выразился Меткалф:
Когда я вернулся в Xerox в 1976 году, до поставки продукции оставалось около двух с половиной лет, а в 1978 году — примерно два с половиной года до поставки продукции. [7]
Когда никаких дальнейших действий не последовало, Меткалф покинул компанию в конце 1978 года .
XNS, который последний раз использовался Xerox для связи с издательской системой DocuTech 135, больше не используется из-за повсеместного распространения IP. Тем не менее, он сыграл важную роль в развитии сетевых технологий в 1980-х годах, побудив поставщиков программного и аппаратного обеспечения серьезно задуматься о необходимости поддержки компьютерными платформами более одного стека сетевых протоколов одновременно.
Широкий спектр проприетарных сетевых систем был основан непосредственно на XNS или предлагал небольшие вариации на эту тему. Среди них были Net/One, 3+, [1] Banyan VINES [9] и Novell IPX/SPX . [10] Эти системы добавили свои собственные концепции поверх системы адресации и маршрутизации XNS; VINES добавила службу каталогов среди других служб, а Novell NetWare добавила ряд пользовательских служб, таких как печать и общий доступ к файлам. AppleTalk использовал маршрутизацию, подобную XNS, но имел несовместимые адреса с использованием более коротких номеров.
XNS также помог проверить конструкцию сетевой подсистемы 4.2BSD , предоставив второй набор протоколов, который значительно отличался от протоколов Интернета; реализовав оба стека в одном ядре, исследователи из Беркли продемонстрировали, что такая конструкция подходит не только для IP. [11] В конечном итоге потребовались дополнительные модификации BSD для поддержки всего спектра протоколов взаимодействия открытых систем (OSI).
Архитектура сетевых систем Xerox. Введение в сетевые системы Xerox (XNSG 058504) — это «общее обсуждение, предназначенное для тех, кто хочет знать, как офисные работники могут стать более эффективными и продуктивными с помощью сетевых систем Xerox». [12] : стр.5
Компоненты архитектуры сетевых систем Xerox кратко описаны в Общем информационном руководстве по архитектуре сетевых систем Xerox (XNSG 068504). [13]
Серия из шестнадцати отдельных описаний протоколов приведена в каталоге литературы Xerox Systems Institute . [12] Возможно, более поздние версии этих стандартов: