Xerox Network Systems ( XNS ) — это набор протоколов компьютерных сетей , разработанный Xerox в рамках архитектуры Xerox Network Systems . Он обеспечивал сетевые коммуникации общего назначения, межсетевую маршрутизацию и доставку пакетов, а также функции более высокого уровня, такие как надежный поток и удаленные вызовы процедур . 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, echo XNS помещает команду непосредственно в базовый пакет IDP. [2] Того же самого можно добиться в IP, расширив поле протокола ICMP заголовка IP.
Существует два основных протокола транспортного уровня, оба сильно отличаются от своего предшественника Pup:
XNS, как и Pup, также использует EP , Error Protocol , как систему отчетности о проблемах, таких как отброшенные пакеты. Это предоставило уникальный набор пакетов, которые можно отфильтровать для поиска проблем. [2]
В оригинальной концепции Xerox протоколы приложений, такие как удаленная печать, архивация, почтовая рассылка и т. д., использовали протокол удаленного вызова процедур под названием Courier . Courier содержал примитивы для реализации большинства функций вызовов функций языка программирования Mesa компании Xerox . Приложениям приходилось вручную сериализовать и десериализовать вызовы функций в Courier; не было автоматического средства для перевода кадра активации функции в RPC (т. е. не было «компилятора RPC»). Поскольку Courier использовался всеми приложениями, в документах протокола приложений XNS были указаны только интерфейсы вызова функций Courier и кортежи связывания модуль+функция. В Courier была специальная возможность, позволяющая вызову функции отправлять или получать объемные данные. [2]
Первоначально определение местоположения сервиса XNS выполнялось посредством широковещательной передачи удаленных вызовов процедур с использованием серии широковещательных рассылок расширяющегося кольца (совместно с локальным маршрутизатором для получения сетей на увеличивающихся расстояниях). Позднее для определения местоположения сервиса была создана служба каталогов 3-го уровня Clearinghouse Protocol, а широковещательные рассылки расширяющегося кольца использовались только для определения местоположения начального Clearinghouse. [2]
Из-за тесной интеграции с Mesa в качестве базовой технологии многие из традиционных протоколов более высокого уровня не были частью самой системы XNS. Это означало, что поставщики, использующие протоколы XNS, все создавали свои собственные решения для обмена файлами и поддержки принтеров . Хотя многие из этих сторонних продуктов теоретически могли общаться друг с другом на уровне пакетов, возможности вызывать службы приложений друг друга были ограничены или отсутствовали. Это привело к полной фрагментации рынка XNS и было названо одной из причин, по которой IP легко вытеснил его. [1]
Протоколы XNS также включали протокол аутентификации и службу аутентификации для его поддержки. Его «сильные учетные данные» были основаны на том же протоколе Needham–Schroeder , который позже использовался Kerberos . После обращения к службе аутентификации за учетными данными этот протокол предоставлял легкий способ цифровой подписи вызовов процедур Courier, так что получатели могли проверять подпись и аутентифицировать отправителей через интернет XNS, без необходимости снова обращаться к службе аутентификации на протяжении всего сеанса связи протокола. [3]
Язык печати Xerox, Interpress , был двоичным форматированным стандартом для управления лазерными принтерами. Разработчики этого языка, Джон Уорнок и Чак Гешке, позже покинули Xerox PARC, чтобы основать Adobe Systems . Перед уходом они осознали сложность указания двоичного языка печати, где функции для сериализации задания печати были громоздкими и что затрудняло отладку ошибочных заданий печати. Чтобы осознать ценность указания как программируемого, так и легко отлаживаемого задания печати в ASCII, Уорнок и Гешке создали язык Postscript как один из своих первых продуктов в Adobe.
Поскольку все 8000+ машин в корпоративной интрасети Xerox работали на архитектуре Wildflower (разработанной Батлером Лэмпсоном), существовал протокол удаленной отладки для микрокода. По сути, функция peek and poke могла останавливать и управлять состоянием микрокода машины серии C или D в любой точке мира, а затем перезапускать машину.
Также существовал протокол удаленной отладки для отладчика обмена мирами. [4] Этот протокол мог через отладчик "nub" заморозить рабочую станцию, а затем просмотреть и просканировать различные части памяти, изменить переменные и продолжить выполнение. Если бы были доступны символы отладки, то сломанную машину можно было бы удаленно отладить из любой точки мира.
На последнем году обучения в Гарвардском университете Боб Меткалф начал проходить собеседования в ряде компаний и был тепло принят Джерри Элкиндом и Бобом Тейлором в Xerox PARC , которые начинали работать над сетевыми компьютерными рабочими станциями, которые впоследствии стали Xerox Alto . Он согласился присоединиться к PARC в июле, после защиты своей диссертации. В 1970 году, находясь на диване у Стива Крокера дома во время посещения конференции, Меткалф взял со стола копию Трудов осенней совместной компьютерной конференции, намереваясь заснуть во время чтения. Вместо этого он увлекся статьей об ALOHAnet , более ранней системе широкополосных сетей. К июню он разработал собственные теории о сетях и представил их своим профессорам, которые отвергли их, и его «вышвырнули на улицу». [5]
Меткалф был принят в PARC, несмотря на его неудачную диссертацию, и вскоре начал разработку того, что тогда называлось «ALOHAnet in a wire». Он объединился с Дэвидом Боггсом , чтобы помочь с электронной реализацией, и к концу 1973 года они создали работающее оборудование на скорости 3 Мбит/с. Затем пара начала работать над простым протоколом, который мог бы работать в системе. Это привело к разработке системы PARC Universal Packet (Pup), и к концу 1974 года они успешно запустили Pup в Ethernet. Они подали патент на концепции, причем Меткалф добавил несколько других имен, поскольку считал, что они заслуживают упоминания, а затем представил статью о концепции в Communications of the ACM на тему «Ethernet: Распределенная коммутация пакетов для локальных компьютерных сетей», опубликованную в июле 1976 года. [5]
К 1975 году, задолго до завершения PUP, Меткалф уже был раздражен жестким руководством Xerox. Он считал, что компания должна немедленно запустить Ethernet в производство, но не нашел большого интереса среди высшего руководства. Знаменательное событие произошло, когда профессора из знаменитой Лаборатории искусственного интеллекта Массачусетского технологического института обратились в Xerox в 1974 году с намерением купить Ethernet для использования в своей лаборатории. Руководство Xerox отказалось, посчитав, что Ethernet лучше использовать для продажи собственного оборудования. Затем Лаборатория искусственного интеллекта продолжила разработку собственной версии Ethernet, Chaosnet . [6]
В конце концов Меткалф покинул Xerox в ноябре 1975 года, перейдя в Transaction Technology, подразделение Citibank, занимавшееся разработкой передовых продуктов. Однако семь месяцев спустя его переманил обратно в Xerox Дэвид Лиддл , который недавно организовал в Xerox Отдел разработки систем специально для вывода концепций PARC на рынок. Меткалф немедленно начал перепроектировать Ethernet для работы на скорости 20 Мбит/с и начал попытки переписать Pup в версию производственного качества. В поисках помощи по Pup Меткалф обратился к Йогену Далалу , который в то время завершал свою докторскую диссертацию под руководством Винта Серфа в Стэнфордском университете . Далала также активно набирала команда Боба Кана ARPANET ( работавшая над TCP/IP), но когда Серф ушел, чтобы присоединиться к DARPA , Далал согласился перейти в PARC и начал там работать в 1977 году. [7]
Далал собрал команду, в которую вошли Уильям Кроутер и Хэл Мюррей, и начал с полного обзора Pup. Далал также пытался остаться вовлечённым в усилия по TCP, которые велись в DARPA, но в конечном итоге сдался и полностью сосредоточился на Pup. Далал объединил свой опыт работы с ARPANET с концепциями из Pup, и к концу 1977 года они опубликовали первый проект спецификации Xerox Network System. По сути, это была версия Pup с абсолютными 48-битными идентификаторами хостов и 3-сторонним рукопожатием TCP в протоколе последовательных пакетов. [8]
К началу 1978 года новая система заработала, но руководство все еще не предпринимало никаких шагов для ее коммерциализации. Как выразился Меткалф:
Когда я вернулся в Xerox в 1976 году, до поставки продукции оставалось около двух с половиной лет, а в 1978 году до поставки продукции оставалось около двух с половиной лет. [7]
Поскольку никаких дальнейших действий не последовало, Меткалф покинул компанию в конце 1978 года. [7]
Последний раз Xerox использовал его для связи с DocuTech 135 Publishing System, но сейчас XNS больше не используется из-за повсеместного распространения IP. Тем не менее, он сыграл важную роль в развитии сетевых технологий в 1980-х годах, повлияв на поставщиков программного и аппаратного обеспечения, заставив их серьезно задуматься о необходимости поддержки вычислительными платформами более одного стека сетевых протоколов одновременно.
Широкий спектр фирменных сетевых систем был напрямую основан на XNS или предлагал незначительные вариации на эту тему. Среди них были Net/One, 3+, [1] Banyan VINES [9] и Novell's 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 Network Systems Architecture General Information Manual (XNSG 068504). [13]
Серия из шестнадцати отдельных описаний протоколов приведена в Каталоге литературы Института систем Xerox . [12] Возможно, более поздние версии этих стандартов: