Xerox Hálózati Rendszerek

A Xerox Network Services (XNS) egy protokollkészlet (protocol suite), melyet a Xerox fejlesztett ki a Xerox Network Systems Architecture segítségével. Általános célú hálózati kommunikációt, belsőhálózati útválasztást és csomagtovábbítást biztosít, beleértve olyan magas szintű szolgáltatásokat, mint a megbízható folyamok (reliable stream) és a távoli eljáráshívások. Az XNS előkészítette és befolyásolta az Open Systems Interconnect OSI-modell fejlesztését. Az XNS-t a Xerox PARC-nál fejlesztették a ’80-as évek elején, erősen a korábbi (és rendkívül befolyásoló) PARC Universal Packet (PUP) protokollkészletre alapozva, mely ugyanott készült a ’70-es évek végén; néhány protokoll az XNS készletben a PUP készletben megtalálhatónak kis mértékben módosított változata. Az XNS-t a kutatás/fejlesztés irányultságú PUP kereskedelmi utódának szánták. A protokollkészlet specifikációját közkincccsé nyilvánították. Mivel a public domain része, az XNS általános helyi hálózati (LAN) protokollá vált a ’80-as években, majd különböző mértékben praktikus része lett az összes hálózati rendszereknek a ’90-es évekre. Mindemellett a TCP/IP-re is volt kis hatással. A ’80-as években az XNS-t a 3Com használta és, kis módosításokkal, számos más kereskedelmi rendszer, melyek ismertebbé váltak nála, köztük az Ungermann-Bass Net/One, a Novell NetWare, és a Banyan VINES.

Alap belsőhálózati protokoll

A legfőbb belsőhálózati- réteg (internetwork) protocoll az Internet Datagram Protocol (IDP) volt. Az IDP közeli leszármazottja a PUP belsőhálózati protokollnak (internetwork protocol), és nagyjából összhangban van az Internet Protocol (IP) réteggel a TCP/IP-ben. Kezdettől fogva az Ethernet helyi hálózat (local area network) kiegészítésének készült (melyet szintén a Xerox fejlesztett), a teljes XNS hálózati cím (network address) egy 32 bites hálózati számból, egy 48 bites hostcímből és egy 16 bites socketszámból áll; a hostcím gyakran a host MAC címe (MAC address). A hálózati szám azokban az esetekben, amikor a host (még) nem ismeri a saját hálózati számát, speciális értékkel bír, melynek jelentése: ’ez a hálózat’. A TCP/IP-vel ellentétben az IDP headerben a teljes hálózati cím része a socket mező, így a magasabb szintű protokolloknak nem kell megvalósítaniuk demultiplexelést; az IDP csomagtípusokat is szolgáltat (míg az IP ezt sem). Ráadásul az IDP-ben volt még egy tartalomjegyzék is, mely lefedte a teljes csomagot, de ez opcionális volt, nem kötelező. Az IDP csomagok hossza elérte az 576 byte-ot, tartalmazva a 30 byte-os IDP header-t, ám rövidebb volt, mint az IP-é, melynél minden hosztnak támogatnia kellett a legalább 576 byte-os, de az akár 65K byte-os csomagokat is. Egyes PUP hosztpárok a részhálózatokon akár ennél is nagyobb csomagokat használtak, de egyetlen PUP rauteren sem volt elvárás, hogy kezelje őket, de még mechanizmus sem volt definiálva arra, hogy felderítse, a közbeeső routerek képesek-e kezelni ezeket. És persze a csomagokat nem lehetett feldarabolni, mint az IP-nél. Az XNS is tartalmazott belsőhálózati szinten egy egyszerű echo protokollt, hasonlót, mint az IP pingje, csak ez alacsonyabb szinten működött. A Routing Information Protocol-t (RIP), ami a PUP Gateway Information Protocol leszármazottja, használták routerinformáció-cserélő rendszernek, és (kis módosításokkal, hogy passzoljon más protokollcsomagok címzéseihez) ma is használják más protokollcsomagokban.

Átviteli réteg protokollok

Két fő átviteli réteg protokoll létezett. Mindkettő nagyon eltérő a PUP elődjeiktől (predecessor):

1. A Sequenced Packet Protocol (SPP) visszaigazolásos átviteli protokoll volt, a TCP hasonmása; egyetlen fő technikai különbsége, hogy a szekvencia-számok számolták a csomagokat, nem a byte-ok, mint a TCP-ben és a PUP BSP-jében; ez volt a Novell IPX/SPX közvetlen előzménye.
2. A Packet Exchange Protocol (PEP) kapcsolat nélküli nem megbízható protokoll volt, hasonló viselkedéssel, mint az UDP, és elődje lett a Novell PXP-nek.

Az XNS, mint a PUP, az EP-t, vagyis az Error Protocol-t használta a hibák (mint pl. elveszett csomagok) jelentésére. Ez csomagok egy egyedi, szűrhető halmazát biztosította a hibák kezeléséhez.

Alkalmazások

Az eredeti Xerox elképzelés szerint az alkalmazás-protokollok, mint pl. a távoli nyomtatás vagy a fájlkezelés, egy távoli eljáráshívási protokoll felett futottak volna, amit Courier-nek neveztek. Viszont ezek a Xerox alkalmazás-protokollok sosem kerültek széles körű használatba, mert a legtöbb üzleti szolgáltatás, ami XNS-t használt, mint pl. a Novell Netware, megírták a saját alkalmazás-protokolljaikat.

Hatása

Az XNS-t legutoljára a Xerox és a DocuTech 135 Publishing System közötti kommunikációra használták, azóta az IP kiterjedt jenléte miatt hanyagolják. Mégis meghatározó szerepet játszott a hálózati technológia fejlődésében a ’80-as években az által, hogy felhívta a szoftver- és hardverkereskedők figyelmét a számítási platformok fontos szerepére az egyszerre több hálózati protokoll-köteg szimultán kiszolgálásához. Részben elősegítette a 4.2BSD hálózati alrendszer tervezését azzal, hogy egy második protokollkészletet is szolgáltatott: egy Internet-protokolloktól merőben eltérőt; azzal, hogy mindkét csomagot egy kernelben implementálták, a Berkeley kutatói megmutatták, hogy tervezés többre képes, mint pusztán az internet protokoll. Néhány változtatásra végül szükség volt még ahhoz, hogy az összes Open Systems Interconnection (OSI) protokollt kiadják.

Irodalom

• Xerox System Integration Standard - Internet Transport Protocols (Xerox, Stamford, 1981)
• Xerox System Integration Standard - Courier: The Remote Procedure Call Protocol (Xerox, Stamford, 1981)

• Informatikai portál • összefoglaló, színes tartalomajánló lap