Сетевые системы Xerox

Сетевые системы Xerox ( XNS ) -- это набор протоколов для компьютерных сетей , разработанный Xerox в рамках архитектуры сетевых систем Xerox . Он обеспечивал сетевую связь общего назначения, межсетевую маршрутизацию и доставку пакетов, а также функции более высокого уровня, такие как надежный поток и удаленные вызовы процедур . XNS предшествовала разработке сетевой модели Open Systems Interconnection (OSI) и повлияла на нее, а также оказала большое влияние на проектирование локальных сетей в 1980-х годах.

XNS был разработан отделом разработки систем Xerox в начале 1980-х годов, которому было поручено вывести на рынок исследования Xerox Parc . XNS был основан на более раннем (и столь же влиятельном) пакете PARC Universal Packet (PUP) конца 1970-х годов. Некоторые протоколы пакета XNS были слегка измененными версиями протоколов пакета Pup. XNS добавила концепцию сетевого номера, позволяющую создавать более крупные сети из нескольких более мелких, а маршрутизаторы контролируют поток информации между сетями.

Спецификации набора протоколов для XNS были размещены в открытом доступе в 1977 году. Это помогло XNS стать каноническим протоколом локальной сети , в разной степени скопированным практически всеми сетевыми системами, использовавшимися в 1990-е годы. XNS без изменений использовался 3Com 's 3+Share и Ungermann-Bass 's Net/One. Он также использовался с модификациями в качестве основы для 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 убрала исправление ошибок из протоколов более низкого уровня, чтобы повысить производительность. Исправление ошибок может быть дополнительно добавлено на более высоких уровнях стека протоколов, например, в собственном протоколе XNS SPP. Из-за этого примечания к дизайну XNS считался более быстрым, чем IP. ^[1]

В соответствии с LAN-соединениями с малой задержкой, на которых он работает, XNS использует короткий размер пакета, что повышает производительность в случае низкой частоты ошибок и короткого времени обработки. Пакеты IDP имеют длину до 576 байт, включая 30-байтовый заголовок IDP . ^[2] Для сравнения, IP требует, чтобы все хосты поддерживали как минимум 576, но поддерживает пакеты размером до 65 КБ. Отдельные пары хостов XNS в определенной сети могут использовать более крупные пакеты, но для их обработки не требуется маршрутизатор XNS, и не определен механизм, позволяющий определить, поддерживают ли промежуточные маршрутизаторы более крупные пакеты. Кроме того, пакеты нельзя фрагментировать, как в IP.

Протокол маршрутной информации (RIP), потомок Pup's Gateway Information Protocol , используется в качестве системы обмена информацией о маршрутизаторе и (с небольшими изменениями, чтобы соответствовать синтаксису адресов других наборов протоколов) по-прежнему используется сегодня в других наборах протоколов. , такие как набор интернет-протоколов. ^[2]

XNS также реализует простой эхо-протокол на межсетевом уровне, похожий на ping IP , но работающий на более низком уровне сетевого стека. Вместо добавления данных ICMP в качестве полезной нагрузки в IP-пакет, как при эхо-запросе ping, эхо XNS поместило команду непосредственно в базовый пакет IDP. ^[2] То же самое может быть достигнуто в IP путем расширения поля протокола ICMP в заголовке IP.

Протоколы транспортного уровня

Существует два основных протокола транспортного уровня, оба сильно отличающиеся от своего предшественника Pup:

• Sequenced Packet Protocol ( SPP ) — общепризнанный транспортный протокол, аналог TCP ; одно главное техническое отличие состоит в том, что порядковые номера учитывают пакеты, а не байты, как в TCP и BSP PUP; это прямой предшественник Novell IPX/SPX .
• Протокол обмена пакетами ( PEP ) — это ненадежный протокол без установления соединения, аналогичный по своей природе UDP и предшествующий протоколу Novell PXP.

XNS, как и Pup, также использует EP , протокол ошибок , в качестве системы отчетов о таких проблемах, как отброшенные пакеты. Это обеспечило уникальный набор пакетов, которые можно фильтровать для поиска проблем. ^[2]

Протоколы приложений

Курьер РПК

В исходной концепции Xerox прикладные протоколы, такие как удаленная печать, архивирование, отправка по почте и т. д., использовали протокол удаленного вызова процедур под названием Courier . Courier содержал примитивы для реализации большинства функций вызовов функций языка программирования Xerox Mesa . Приложения должны были вручную сериализовать и десериализовать вызовы функций в Courier; не существовало автоматического средства преобразования кадра активации функции в RPC (т. е. не было «компилятора RPC»). Поскольку Courier использовался всеми приложениями, в документах по протоколу приложений XNS указаны только интерфейсы вызовов функций courier и кортежи привязки модуль+функция. В Courier было специальное средство, позволяющее вызову функции отправлять или получать объемные данные. ^[2]

Первоначально определение местоположения службы XNS выполнялось посредством широковещательной передачи удаленных вызовов процедур с использованием серии расширяющихся кольцевых широковещательных передач (по согласованию с локальным маршрутизатором для получения сетей на увеличивающихся расстояниях). местоположение службы, а широковещательные передачи по расширяющемуся кольцу использовались только для определения местоположения первоначального центра обмена информацией. ^[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" заморозить рабочую станцию, а затем заглянуть в различные части памяти, изменить переменные и продолжить выполнение. Если бы были доступны отладочные символы, неисправную машину можно было бы отладить удаленно из любой точки мира.

История

Истоки в Ethernet и ПНП

На последнем курсе Гарвардского университета Боб Меткалф начал проходить собеседования в ряде компаний и был тепло встречен Джерри Элкиндом и Бобом Тейлором из Xerox PARC , которые начали работать над сетевыми компьютерными рабочими станциями, которые впоследствии стали Xerox Alto . Он согласился присоединиться к PARC в июле, после защиты диссертации. В 1970 году, занимаясь серфингом на диване в доме Стива Крокера во время посещения конференции, Меткалф взял со стола копию Proceedings of the Fall Joint Computer Conference , чтобы заснуть во время ее чтения. Вместо этого он увлекся статьей оALOHAnet , более ранняя система глобальной сети. К июню он разработал свои собственные теории сетей и представил их своим профессорам, которые отвергли их, и его «вышвырнули на задницу». ^[5]

Меткалфа приветствовали в PARC, несмотря на его неудачную диссертацию, и вскоре он начал разработку того, что тогда называлось «ALOHAnet в сети». Он объединился с Дэвидом Боггсом , чтобы помочь с электронной реализацией, и к концу 1973 года они создали работающее оборудование со скоростью 3 Мбит / с. Затем пара начала работать над простым протоколом, который будет работать в системе. Это привело к разработке системы PARC Universal Packet (Pup), и к концу 1974 года Pup успешно работал в сети Ethernet. Они подали патент на концепции, а Меткалф добавил несколько других имен, потому что считал, что они заслуживают упоминания, а затем представил документ о концепции в Communications of ACM.в статье «Ethernet: распределенная коммутация пакетов для локальных компьютерных сетей», опубликованной в июле 1976 г. ^[5]

Щенок в XNS

К 1975 году, задолго до того, как PUP была завершена, Меткалф уже раздражался от жесткого руководства Xerox. Он считал, что компания должна немедленно запустить Ethernet в производство, но не нашел особого интереса у высшего руководства. Знаменательным событием стало то, что в 1974 году профессора знаменитой Лаборатории искусственного интеллекта Массачусетского технологического института обратились к Xerox с намерением купить Ethernet для использования в своей лаборатории. Руководство Xerox отказалось, полагая, что Ethernet лучше использовать для продажи собственного оборудования. Затем лаборатория искусственного интеллекта продолжила работу над собственной версией Ethernet, Chaosnet . ^[6]

В конце концов, в ноябре 1975 года Меткалф покинул Xerox и перешел в Transaction Technology, подразделение Citibank , которому было поручено разработать передовые продукты. Однако семь месяцев спустя его снова переманил в Xerox Дэвид Лиддл , который недавно организовал в Xerox подразделение разработки систем специально для вывода концепций PARC на рынок. Меткалф немедленно приступил к перепроектированию Ethernet для работы на скорости 20 Мбит/с и предпринял усилия по переписыванию Pup в версии производственного качества. В поисках помощи по Pup Меткалф обратился к Йогину Далалу , который в то время заканчивал свою диссертацию под руководством Винта Серфа в Стэнфордском университете . Далал также активно вербовался в ARPANET Боба Кана .(работает над TCP/IP), но когда Серф ушел, чтобы присоединиться к DARPA , Далал согласился перейти в PARC и начал там работать в 1977 году. ^[7]

Далал собрал команду, в которую вошли Уильям Кроутер и Хэл Мюррей, и начал с полного обзора Pup. Далал также пытался продолжать участвовать в проектах TCP, проводимых в DARPA, но в конце концов сдался и полностью сосредоточился на Щенке. Далал объединил свой опыт работы с ARPANET с концепциями Pup, и к концу 1977 года они опубликовали первый проект спецификации Xerox Network System. По сути, это была версия Pup с добавленной концепцией сокетов и межсетевого взаимодействия, которая позволяла маршрутизаторам пересылать пакеты через подключенные сети. ^[8]

К началу 1978 года новая система работала, но руководство по-прежнему не предпринимало никаких шагов для ее коммерциализации. Как выразился Меткалф:

Когда я вернулся в Xerox в 1976 году, у нас было около двух с половиной лет до отгрузки продукта, а в 1978 году у нас было около двух с половиной лет до отгрузки продукта. ^[7]

Когда никаких дальнейших действий не последовало, Меткалф покинул компанию в конце 1978 года ^.

Влияние

XNS, который в последний раз использовался Xerox для связи с издательской системой DocuTech 135, больше не используется из-за повсеместного распространения IP. Тем не менее, он сыграл важную роль в развитии сетевых технологий в 1980-х годах, заставив поставщиков программного и аппаратного обеспечения серьезно задуматься о том, чтобы вычислительные платформы поддерживали более одного стека сетевых протоколов одновременно.

Множество проприетарных сетевых систем были непосредственно основаны на XNS или предлагали незначительные вариации на эту тему. Среди них были Net/One, 3+, ^[1] Banyan VINES ^[9] и IPX/SPX от Novell . ^[10] Эти системы добавили свои собственные концепции поверх системы адресации и маршрутизации XNS; VINES добавила службу каталогов среди других служб, а Novell NetWare добавила ряд пользовательских служб, таких как печать и обмен файлами. AppleTalk использовал маршрутизацию, подобную XNS, но имел несовместимые адреса с более короткими номерами.

XNS также помог проверить дизайн сетевой подсистемы 4.2BSD , предоставив второй набор протоколов, который значительно отличался от интернет-протоколов; Реализовав оба стека в одном ядре, исследователи из Беркли продемонстрировали, что дизайн подходит не только для IP. ^[11] Со временем потребовались дополнительные модификации BSD для поддержки всего спектра протоколов взаимодействия открытых систем (OSI).

Смотрите также

• Протокольные войны

• Стандартный код символов Xerox

использованная литература

Цитаты

Библиография

внешняя ссылка

• Архитектура сетевых систем Xerox: введение в сетевые системы Xerox
• Архитектура сетевых систем Xerox: общее информационное руководство
• Пример реальной реализации в пространстве ядра