Hubbry Logo
Xerox Network SystemsXerox Network SystemsMain
Open search
Xerox Network Systems
Community hub
Xerox Network Systems
logo
7 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Xerox Network Systems
Xerox Network Systems
Xerox Network Systems
View on Wikipedia
from Wikipedia
XNS
Protocol stack
PurposeLAN
Developer(s)Xerox
Introduction1977; 48 years ago (1977)
Influenced3+Share, Net/One, IPX/SPX, VINES
HardwareEthernet

Xerox Network Systems (XNS) is a computer networking protocol suite developed by Xerox within the Xerox Network Systems Architecture. It provided general purpose network communications, internetwork routing and packet delivery, and higher level functions such as a reliable stream, and remote procedure calls. XNS predated and influenced the development of the Open Systems Interconnection (OSI) networking model, and was very influential in local area networking designs during the 1980s.

XNS was developed by the Xerox Systems Development Department in the early 1980s, who were charged with bringing Xerox PARC's research to market. XNS was based on the earlier (and equally influential) PARC Universal Packet (PUP) suite from the late 1970s. Some of the protocols in the XNS suite were lightly modified versions of the ones in the Pup suite. XNS added the concept of a network number, allowing larger networks to be constructed from multiple smaller ones, with routers controlling the flow of information between the networks.

The protocol suite specifications for XNS were placed in the public domain in 1977. This helped XNS become the canonical local area networking protocol, copied to various degrees by practically all networking systems in use into the 1990s. XNS was used unchanged by 3Com's 3+Share and Ungermann-Bass's Net/One. It was also used, with modifications, as the basis for Novell NetWare, and Banyan VINES. XNS was used as the basis for the AppleNet system, but this was never commercialized; a number of XNS's solutions to common problems were used in AppleNet's replacement, AppleTalk.

Description

[edit]

Overall design

[edit]

In comparison to the OSI model's 7 layers, XNS is a five-layer system,[1] like the later Internet protocol suite.

The Physical and Data Link layers of the OSI model correspond to the Physical layer (layer 0) in XNS, which was designed to use the transport mechanism of the underlying hardware and did not separate the data link. Specifically, XNS's Physical layer is really the Ethernet local area network system, also being developed by Xerox at the same time, and a number of its design decisions reflect that fact.[1] The system was designed to allow Ethernet to be replaced by some other system, but that was not defined by the protocol (nor had to be).

The primary part of XNS is its definition of the Internal Transport layer (layer 1), which corresponds to OSI's Network layer, and it is here that the primary internetworking protocol, IDP, is defined. XNS combined the OSI's Session and Transport layers into the single Interprocess Communications layer (layer 2). Layer 3 was Resource Control, similar to the OSI's Presentation.[1][2]

Finally, on top of both models, is the Application layer, although these layers were not defined in the XNS standard.[1]

Basic internetwork protocol

[edit]

The main internetwork layer protocol is the Internet Datagram Protocol (IDP). IDP is a close descendant of Pup's internetwork protocol, and roughly corresponds to the Internet Protocol (IP) layer in the Internet protocol suite.[1]

IDP uses Ethernet's 48-bit address as the basis for its own network addressing, generally using the machine's MAC address as the primary unique identifier. To this is added another 48-bit address section provided by the networking equipment; 32 bits are provided by routers to identify the network number in the internetwork, and another 16 bits define a socket number for service selection within a single host. The network number portion of the address also includes a special value which meant "this network", for use by hosts which did not (yet) know their network number.[2]

Unlike TCP/IP, socket numbers are part of the full network address in the IDP header, so that upper-layer protocols do not need to implement demultiplexing; IDP also supplies packet types (again, unlike IP). IDP also contains a checksum covering the entire packet, but it is optional, not mandatory. This reflects the fact that LANs generally have low-error rates, so XNS removed error correction from the lower-level protocols in order to improve performance. Error correction could be optionally added at higher levels in the protocol stack, for instance, in XNS's own SPP protocol. XNS was widely regarded as faster than IP due to this design note.[1]

In keeping with the low-latency LAN connections it runs on, XNS uses a short packet size, which improves performance in the case of low error rates and short turnaround times. IDP packets are up to 576 bytes long, including the 30 byte IDP header.[2] In comparison, IP requires all hosts to support at least 576, but supports packets of up to 65K bytes. Individual XNS host pairs on a particular network might use larger packets, but no XNS router is required to handle them, and no mechanism is defined to discover if the intervening routers support larger packets. Also, packets can not be fragmented, as they can in IP.

The Routing Information Protocol (RIP), a descendant of Pup's Gateway Information Protocol, is used as the router information-exchange system, and (slightly modified to match the syntax of addresses of other protocol suites), remains in use today in other protocol suites, such as the Internet protocol suite.[2]

XNS also implements a simple echo protocol at the internetwork layer, similar to IP's ping, but operating at a lower level in the networking stack. Instead of adding the ICMP data as payload in an IP packet, as in ping, XNS's echo placed the command directly within the underlying IDP packet.[2] The same might be achieved in IP by expanding the ICMP Protocol field of the IP header.

Transport layer protocols

[edit]

There are two primary transport layer protocols, both very different from their Pup predecessor:

  • Sequenced Packet Protocol (SPP) is an acknowledgment transport protocol, with a 3-way handshake analogous to TCP; one chief technical difference is that the sequence numbers count packets, and not the bytes as in TCP and PUP's BSP; it is the direct antecedent to Novell's IPX/SPX.
  • Packet Exchange Protocol (PEP) is a connectionless non-reliable protocol similar in nature to UDP and the antecedent to Novell's PXP.

XNS, like Pup, also uses EP, the Error Protocol, as a reporting system for problems such as dropped packets. This provided a unique set of packets which can be filtered to look for problems.[2]

Application protocols

[edit]

Courier RPC

[edit]

In the original Xerox concept, application protocols such as remote printing, filing, and mailing, etc., employed a remote procedure call protocol named Courier. Courier contained primitives to implement most of the features of Xerox's Mesa programming language function calls. Applications had to manually serialize and de-serialize function calls in Courier; there was no automatic facility to translate a function activation frame into an RPC (i.e. no "RPC compiler" was available). Because Courier was used by all applications, the XNS application protocol documents specified only courier function-call interfaces, and module+function binding tuples. There was a special facility in Courier to allow a function call to send or receive bulk data.[2]

Initially, XNS service location was performed via broadcasting remote procedure-calls using a series of expanding ring broadcasts (in consultation with the local router, to get networks at increasing distances.) Later, the Clearinghouse Protocol 3-level directory service was created to perform service location, and the expanding-ring broadcasts were used only to locate an initial Clearinghouse.[2]

Due to its tight integration with Mesa as an underlying technology, many of the traditional higher-level protocols were not part of the XNS system itself. This meant that vendors using the XNS protocols all created their own solutions for file sharing and printer support. While many of these 3rd party products theoretically could talk to each other at a packet level, there was little or no capability to call each other's application services. This led to complete fragmentation of the XNS market, and has been cited as one of the reasons that IP easily displaced it.[1]

Authentication

[edit]

The XNS protocols also included an Authentication Protocol and an Authentication Service to support it. Its "Strong credentials" were based on the same Needham–Schroeder protocol that was later used by Kerberos. After contacting the authentication service for credentials, this protocol provided a lightweight way to digitally sign Courier procedure calls, so that receivers could verify the signature and authenticate senders over the XNS internet, without having to contact the Authentication service again for the length of the protocol communication session.[3]

Printing

[edit]

Xerox's printing language, Interpress, was a binary-formatted standard for controlling laser printers. The designers of this language, John Warnock and Chuck Geschke, later left Xerox PARC to start Adobe Systems. Before leaving, they realized the difficulty of specifying a binary print language, where functions to serialize the print job were cumbersome and which made it difficult to debug errant printing jobs. To realize the value of specifying both a programmable and easily debug-able print job in ASCII, Warnock and Geschke created the Postscript language as one of their first products at Adobe.

Remote Debug Protocols

[edit]

Because all 8000+ machines in the Xerox corporate Intranet ran the Wildflower architecture (designed by Butler Lampson), there was a remote-debug protocol for microcode. Basically, a peek and poke function could halt and manipulate the microcode state of a C-series or D-series machine, anywhere on earth, and then restart the machine.

Also, there was a remote debug protocol for the world-swap debugger.[4] This protocol could, via the debugger "nub", freeze a workstation and then peek and poke various parts of memory, change variables, and continue execution. If debugging symbols were available, a crashed machine could be remote debugged from anywhere on earth.

History

[edit]

Origins in Ethernet and PUP

[edit]

In his final year at Harvard University, Bob Metcalfe began interviewing at a number of companies and was given a warm welcome by Jerry Elkind and Bob Taylor at Xerox PARC, who were beginning to work on the networked computer workstations that would become the Xerox Alto. He agreed to join PARC in July, after defending his thesis. In 1970, while couch surfing at Steve Crocker's home while attending a conference, Metcalfe picked up a copy Proceedings of the Fall Joint Computer Conference off the table with the aim of falling asleep while reading it. Instead, he became fascinated by an article on ALOHAnet, an earlier wide-area networking system. By June he had developed his own theories on networking and presented them to his professors, who rejected it and he was "thrown out on my ass."[5]

Metcalfe was welcomed at PARC in spite of his unsuccessful thesis, and soon started development of what was then referred to as "ALOHAnet in a wire". He teamed up with David Boggs to help with the electronic implementation, and by the end of 1973 they were building working hardware at 3 Mbit/s. The pair then began working on a simple protocol that would run on the system. This led to the development of the PARC Universal Packet (Pup) system, and by late 1974 the two had Pup successfully running on Ethernet. They filed a patent on the concepts, with Metcalfe adding several other names because he believed they deserved mention, and then submitted a paper on the concept to Communications of the ACM on "Ethernet: Distributed Packet Switching for Local Computer Networks", published in July 1976.[5]

PUP to XNS

[edit]

By 1975, long before PUP was complete, Metcalfe was already chafing under the stiff Xerox management. He believed the company should immediately put Ethernet into production, but found little interest among upper management. A seminal event took place when professors from MIT's famed Artificial Intelligence Laboratory approached Xerox in 1974 with the intention of buying Ethernet for use in their lab. Xerox management declined, believing Ethernet was better used to help sell their own equipment. The AI Lab would then go on to make their own version of Ethernet, Chaosnet.[6]

Metcalfe eventually left Xerox November 1975 for Transaction Technology, a division of Citibank tasked with advanced product development. However, he was lured back to Xerox seven months later by David Liddle, who had recently organized the Systems Development Division within Xerox specifically to bring PARCs concepts to market. Metcalfe immediately began re-designing Ethernet to work at 20 Mbit/s and started an effort to re-write Pup in a production quality version. Looking for help on Pup, Metcalfe approached Yogen Dalal, who was at that time completing his PhD thesis under Vint Cerf at Stanford University. Dalal was also being heavily recruited by Bob Kahn's ARPANET team (working on TCP/IP), but when Cerf left to join DARPA, Dalal agreed to move to PARC and started there in 1977.[7]

Dalal built a team including William Crowther and Hal Murray, and started with a complete review of Pup. Dalal also attempted to remain involved in the TCP efforts underway at DARPA, but eventually gave up and focussed fully on Pup. Dalal combined his experience with ARPANET with the concepts from Pup and by the end of 1977 they had published the first draft of the Xerox Network System specification. This was essentially a version of Pup with absolute 48-bit host IDs, and TCP's 3-Way handshake in the Sequenced Packet Protocol.[8]

By early 1978 the new system was working, but management was still not making any move to commercialize it. As Metcalfe put it:

When I came back to Xerox in 1976, we were about two and a half years from product shipment and in 1978 we were about two and a half years from product shipment.[7]

When no further action was forthcoming, Metcalfe left the company at the end of 1978.[7]

Impact

[edit]

Last used by Xerox for communication with the DocuTech 135 Publishing System, XNS is no longer in use, due to the ubiquity of IP. However, it played an important role in the development of networking technology in the 1980s, by influencing software and hardware vendors to seriously consider the need for computing platforms to support more than one network protocol stack simultaneously.

A wide variety of proprietary networking systems were directly based on XNS or offered minor variations on the theme. Among these were Net/One, 3+,[1] Banyan VINES[9] and Novell's IPX/SPX.[10] These systems added their own concepts on top of the XNS addressing and routing system; VINES added a directory service among other services, while Novell NetWare added a number of user-facing services like printing and file sharing. AppleTalk used XNS-like routing, but had incompatible addresses using shorter numbers.

XNS also helped to validate the design of the 4.2BSD network subsystem by providing a second protocol suite, one which was significantly different from the Internet protocols; by implementing both stacks in the same kernel, Berkeley researchers demonstrated that the design was suitable for more than just IP.[11] Additional BSD modifications were eventually necessary to support the full range of Open Systems Interconnection (OSI) protocols.

Literature

[edit]

Xerox Network Systems Architecture Introduction to Xerox Network Systems (XNSG 058504) is "a general discussion meant for those who want to know how office people can become more effective and productive by using the Xerox Network Systems."[12]: p.5 

The components of Xerox Network Systems Architecture are briefly described in Xerox Network Systems Architecture General Information Manual (XNSG 068504).[13]

A series of sixteen individual protocol descriptions are listed in the Xerox Systems Institute Literature Catalog.[12] Possibly more recent versions of these standards are:

  • Authentication Protocol (XSIS 098404)[3]
  • Bulk Data Transfer (Appendix f to Courier), April 1984 (XNSS 038112/XSIS 038112)
  • Character Code Standard, May 1986 (XNSS 058605)
  • Clearinghouse Protocol, April 1984 (XNSS 078404/XSIS 078404)
  • Clearinghouse Entry Formats, April 1984 (XNSS 168404/XSIS 168404)[14]
  • Courier: The Remote Procedure Call Protocol, December 1981 (XNSS 038112/XSIS 038112)[15]
  • The Ethernet. A Local Area Network: Data Link Layer and Physical Layer Specifications (Blue Book, Version 2.0), November 1982 (XNSS 018211/XSIS 018211)[16]
  • Filing Protocol, May 1986 (XNSS 108605)[17]
  • Font Interchange Standard, December 1985 (XNSS 238512)[18]
  • Internet Transport Protocols, December 1981 (XNSS 028112/XSIS 028112)[19]
  • Interpress Electronic Printing Standard, Version 3.0, January 1986 (XNSS 048601)[20]
  • Print Service Integration Standard, June 1985 (XNSS 198506)
  • Printing Protocol, April 1984 (XNSS 118404/XSIS 118404)
  • Raster Encoding Standard, June 1985 (XNSS 178506)
  • Synchronous Point-to-Point Protocol, December 1984 (XNSS 158412)
  • Time Protocol, April 1984 (XNSS 088404/XSIS 088404)

See also

[edit]

References

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Xerox Network Systems

View on Grokipedia
from Grokipedia
Xerox Network Systems (XNS) is a suite of proprietary computer networking protocols developed by Corporation in the late and early to enable efficient communication and resource sharing in distributed office environments, particularly for document creation, storage, printing, and transmission. Designed primarily for local area networks using Ethernet at 10 Mbps over , XNS provided a layered that aligned with emerging standards like the ISO Open Systems Interconnection (, separating functions such as from end-to-end transport to support scalable across multiple networks. The system originated from research at Xerox's Palo Alto Research Center (PARC) and Systems Development Division (SDD), building on earlier protocols like the PARC Universal Packet (PUP) to address the needs of integrated systems. Key protocols in XNS included the Internet Datagram Protocol (IDP) at the network layer for logical addressing and unreliable datagram delivery using 32-bit network numbers and 48-bit host addresses, and the Sequenced Packet Protocol (SPP) at the for reliable, connection-oriented communication with flow control and up to 576-byte packets. Additional transport options like the Packet Exchange Protocol (PEP) supported request-response interactions, while upper-layer protocols such as facilitated remote procedure calls, and application-specific ones handled filing, printing via Interpress, and electronic mail aligned with CCITT standards. Core components encompassed workstations like the and 8010 Professional Workstation, servers for file, print, and mail services, and support services including the Clearinghouse for directory functions and Authentication for security. XNS's development began with initial specifications drafted in by Yogen K. Dalal, emphasizing the role of local area networks in broader , and was publicly disclosed starting in 1981 after over a decade of internal refinement. It played a pivotal role in commercializing Ethernet—co-developed by with and DEC and later standardized as —and influenced subsequent networking technologies, including Novell NetWare's IPX/SPX protocols, by demonstrating practical datagram-based designs for multivendor environments. Although largely superseded by TCP/IP and OSI-based systems by the late 1980s, XNS's emphasis on , security, and office-centric applications left a lasting legacy in the evolution of modern networks.

Overview

Architectural Principles

Xerox Network Systems (XNS) is a five-layer protocol suite designed to provide reliable, simple, and extensible networking for Xerox's office automation environments, enabling efficient communication among personal computers, printers, and file servers in local area networks (LANs). Developed to support distributed computing tasks such as document sharing and printing, XNS emphasized modularity to accommodate diverse hardware and software configurations without requiring proprietary implementations. Its architecture prioritizes end-to-end process communication over rigid network management, fostering interoperability in heterogeneous settings. At its core, XNS employs connectionless datagram delivery through the Internet Datagram Protocol (IDP), which forms the foundation for routing and addressing across networks, while offering optional reliable transport via protocols like the Sequenced Packet Protocol (SPP) for applications needing error recovery and ordering. The suite utilizes 48-bit host addresses derived from Ethernet hardware addressing, combined with 32-bit network numbers and 16-bit socket identifiers, to enable scalable identification without frequent reconfiguration. To maintain simplicity and performance, XNS avoids complex fragmentation mechanisms, instead relying on small, fixed-size packets (up to 576 bytes) that reduce overhead in LAN environments and minimize retransmission needs. The design goals outlined in Xerox's 1977 specifications focused on supporting heterogeneous devices, such as varying processors and media types, to create a unified framework for office workflows. This included optimizing for efficient LAN communication over high-speed links like Ethernet, where gateways could handle traffic at rates of 400-1000 kbps with low latency, laying the groundwork for applications. XNS specifications were publicly disclosed in 1981, encouraging adoption and extensibility beyond its own systems. XNS served as a precursor to the OSI reference model, mapping its five layers to OSI's seven without enforcing strict boundaries between session and functions, and it built upon the earlier PUP (Parc Universal Packet) while leveraging Ethernet as the primary foundation.

Protocol Stack Layers

Xerox Network Systems (XNS) organizes its protocols into a layered that facilitates modular communication across heterogeneous networks. The stack begins at the , which relies on Ethernet technology for connectivity, using 10 Mbps signaling over and supporting additional media such as fiber optics, , and leased lines. This layer handles bit-stream transmission and media via CSMA/CD, with Ethernet ranging from 64 to 1518 bytes, including 48-bit addresses and CRC for error detection. Above the physical layer lies the internal transport layer, implemented by the Internet Datagram Protocol (IDP), which operates as the network layer equivalent. IDP manages datagram delivery, logical addressing, and internetwork , enabling packets to traverse multiple local networks without higher-layer awareness of underlying . It supports connectionless service, with a maximum datagram size of 576 bytes to accommodate early Ethernet constraints and ensure fragmentation avoidance in most cases. The interprocess communications layer builds on IDP with end-to-end transport protocols, primarily the Sequenced Packet Protocol (SPP) and Packet Exchange Protocol (PEP). SPP provides reliable, connection-oriented delivery with sequencing, flow control, and retransmission, encapsulating application data into IDP datagrams for transmission. PEP, in contrast, offers a lightweight, connectionless alternative for simple request-response exchanges, also leveraging IDP for routing. These protocols add reliability options atop IDP's best-effort service, supporting dialogues through bottom-up data encapsulation and top-down decapsulation. Resource control functions span session-like management, including the Clearinghouse for name-to-address resolution and the Internetwork Routing Service for dynamic path selection across networks. This layer oversees session establishment, security checks, and resource monitoring, integrating with lower layers to maintain network-wide consistency. Finally, the application layer encompasses higher services such as filing, printing, and remote procedure calls via protocols like , which structure data independently of transport details. A key enabler across layers is XNS's unique addressing scheme, comprising a 48-bit host identifier (derived from Ethernet MAC addresses), a 32-bit network number for internetwork , and a 16-bit socket number to specify processes within a host. This 96-bit structure supports scalable addressing in large, distributed environments, with sockets allowing multiple concurrent communications per host. Layer interactions emphasize encapsulation: application data passes downward, gaining headers from each layer—such as IDP for and SPP for reliability—before physical transmission, and reverses upward upon receipt. This design promotes simplicity and interoperability, influencing later models like the OSI reference architecture.

Core Protocols

Internet Datagram Protocol

The Internet Datagram Protocol (IDP) serves as the core network-layer protocol in Xerox Network Systems (XNS), providing connectionless, of datagrams across internetworks composed of diverse local networks. It defines the fundamental packet format for internet communication, enabling routing between networks while abstracting underlying physical and link-layer technologies, such as Ethernet. IDP operates without establishing connections, relying on destination addressing to forward packets hop-by-hop through gateways, and it forms the base upon which higher-layer protocols in the XNS stack are built. The IDP header is fixed at 30 bytes, preceding variable-length data up to a nominal (MTU) of 576 bytes to ensure compatibility with early Ethernet frames and simplify implementation across heterogeneous networks. This MTU limit aligns with the minimum supported size in contemporary internet protocols, preventing excessive fragmentation at lower layers. The header encapsulates source and destination addresses in a hierarchical format: a 32-bit network number, 48-bit host number, and 16-bit socket number, allowing for up to approximately 4.3 billion networks and vast host addressing within each. If the total packet length is odd, a single garbage byte is appended after the data for computation but excluded from the length field. Key fields in the IDP header are summarized in the following table:
FieldSize (bits)Description
16Optional 16-bit one's complement sum over the entire packet (header and data); set to all ones (0xFFFF) if not used. Computed and verified end-to-end, with incremental updates at each hop if the packet is modified (e.g., hop count increment).
16Total packet length in bytes, including header and data (minimum 30 bytes).
Transport Control8Includes a 4-bit hop offset (incremented by each gateway, discarded after 16 hops) and 4 reserved bits for future use, such as packet lifetime or prioritization hints.
Packet Type8Identifies the higher-layer (Level 2) protocol or data format in the (e.g., 6 for Sequenced Packet Protocol).
Destination Network32Unique identifier of the target network.
Destination Host48Identifier of the target host within the network (often derived from link-layer addresses like Ethernet MAC).
Destination Socket16Port-like identifier for the destination or service.
Source Network32Unique identifier of the originating network.
Source Host48Identifier of the originating host.
Source Socket16Port-like identifier for the source .
This structure supports , , and broadcast addressing modes, with the socket field enabling demultiplexing to specific applications. Routing in IDP is connectionless and datagram-oriented, with gateways using the destination network number to forward packets based on tables populated via the XNS (RIP), a distance-vector protocol that exchanges network reachability information every 30 seconds. RIP employs a hop count metric (up to 15, with 16 indicating unreachable) and supports split horizon to prevent loops, ensuring scalable path selection across multi-network environments. An optional subfield within Transport Control allows gateways to prioritize packets based on rudimentary quality-of-service needs, though implementations varied. Packets are discarded if the hop count exceeds limits, with no built-in . Error handling in IDP emphasizes simplicity, with the optional providing end-to-end integrity detection but no automatic recovery or retransmission, deferring reliability to transport layers. There is no fragmentation or reassembly mechanism at the network layer; oversized datagrams are handled by lower-level protocols or rejected, reducing hardware complexity in early implementations. Unreachable destinations or routing errors trigger notifications via the separate Error Protocol, which encapsulates the offending IDP packet in an error message for diagnostic purposes. These design choices prioritized efficiency in resource-constrained hardware, influencing subsequent protocols like IP.

Transport Layer Protocols

The Sequenced Packet Protocol (SPP) served as the primary reliable transport protocol in Xerox Network Systems (XNS), providing connection-oriented communication atop the Internet Datagram Protocol (IDP). It ensured end-to-end data delivery through mechanisms including packet sequencing, acknowledgments, and retransmission of lost packets, while detecting duplicates via sequence numbers. Flow control was achieved using a sliding window mechanism to manage sender and receiver rates, preventing . SPP employed a three-way for connection establishment and teardown, similar to contemporary protocols, and included retransmission timers to handle timeouts efficiently. In contrast, the Packet Exchange Protocol (PEP) offered a lightweight, connectionless alternative for unreliable data transfer, also built directly on IDP with minimal header additions to reduce overhead. Designed for applications such as broadcasting or simple request-response exchanges, PEP provided without sequencing, acknowledgments, or flow control, making it suitable for low-latency scenarios where reliability could be managed at higher layers. Unlike SPP, PEP lacked duplicate detection and retransmission, prioritizing efficiency over guaranteed transmission. Key differences between SPP and PEP lay in their reliability and orientation: SPP's connection-oriented approach with 32-bit sequence numbers and window-based flow control supported robust, ordered streams, while PEP's connectionless design reused IDP structures for quick, unreliable exchanges. Both protocols adhered to a of 576 bytes minus headers, though SPP allowed negotiation of larger sizes during connection setup. SPP's design principles, including its sequencing and flow control, directly influenced the development of the Transmission Control Protocol (TCP) in the TCP/IP suite.

Application Protocols

Remote Procedure Calls

Courier served as the primary remote procedure call (RPC) mechanism within Network Systems (XNS), providing a protocol for abstractions across heterogeneous endpoints. Defined in the Xerox System Integration Standard XSIS 038112 in December 1981, Courier standardized the request/reply discipline used by many XNS application protocols, enabling client-server interactions through a procedure call metaphor that abstracted underlying network complexities. It operated at the session and layers, facilitating invocations over the Sequenced Packet Protocol (SPP) for reliable, ordered, and flow-controlled transport. The protocol employed a strict request-response model, where a client issued a call message containing the procedure identifier and marshalled parameters, awaiting a server response in the form of a return (for success), reject (for protocol errors), or abort (for application errors). Only one outstanding call was permitted per connection, enforcing synchronous semantics by , though implementations could support asynchronous patterns at higher levels. Parameter marshalling involved encoding as a stream of typed objects in network byte order, using fixed-size representations such as 16-bit booleans and 32-bit to ensure portability; composite types like records and arrays were simply concatenated without delimiters, relying on compile-time type knowledge for decoding. Error handling utilized 16-bit unsigned codes for specific conditions, such as resource unavailability, with optional arguments in abort messages to provide context. Binding and invocation relied on dynamic socket resolution, with servers listening on well-known socket 5 (decimal) for connections established via SPP virtual circuits. During connection setup, a 32-bit version negotiation occurred—comprising 16-bit minimum and maximum supported versions—to ensure compatibility; mismatches triggered a reject with the server's implemented range, supporting interface evolution through incremental versioning starting from 1. This design promoted robustness in distributed environments, where programs could evolve without breaking existing clients. 's network-order encoding further addressed heterogeneity by aligning data on 16-bit boundaries for efficient processing, though it prioritized simplicity over compression. Courier's influence extended beyond XNS, notably serving as a model for ' Open Network Computing (ONC) RPC protocol developed in the early 1980s. It could integrate with XNS authentication mechanisms for secure invocations, though the core protocol focused on invocation mechanics rather than security primitives.

Authentication and Security

The Xerox Network Systems (XNS) Authentication Protocol, specified in XSIS 098404 from April 1984, provides a mechanism for secure identification and of principals across the network. It employs a challenge-response approach based on shared secrets to verify identities without transmitting passwords in clear text, thereby protecting user credentials during . At its core, the protocol uses the to encrypt tickets and strong credentials, ensuring confidentiality and integrity of exchanges. Principals are identified through fully qualified names, such as "George::," which denote unique entities within the XNS domain, allowing precise attribution of actions and access rights. This identification integrates with the broader XNS architecture to support authenticated remote procedure calls (RPCs) via the protocol, enabling secure invocation of services. Key distribution in the protocol is managed by centralized Authentication Servers, which issue session-specific tickets containing conversation keys encrypted with DES. These tickets are valid for limited durations, and verifiers incorporate timestamps to prevent replay attacks, ensuring that authentication exchanges remain fresh and non-reusable. The protocol supports , allowing authenticated principals—particularly those with elevated privileges—to issue sub-tickets on behalf of others for chained operations. It is designed for between client and server, confirming both parties' identities, but does not incorporate a full (PKI), relying instead on symmetric . XNS's security model depends on trusted gateways and a secure Service to mediate access, assuming the integrity of these central components.

Printing and Resource Management

Xerox Network Systems (XNS) incorporated specialized protocols for and resource management to support document-centric workflows in networked office environments. The Protocol served as the primary mechanism for client-server interactions, enabling users to submit print jobs to remote Print Services over the network. This protocol utilized the language for remote procedure calls to handle requests such as job submission, status inquiries, and cancellation, while the Bulk Data Transfer Protocol managed the transmission of large documents like Interpress masters using efficient third-party or immediate transfer modes. Central to printing was Interpress, Xerox's electronic printing standard introduced in June 1983 as , which functioned as a device-independent page-description language for generating high-quality, final-form documents. Interpress supported both raster output, such as arrays via operators like MASKPIXEL, and vector output, including strokes with MASKSTROKE and filled outlines with MASKFILL, allowing precise control over text, graphics, and typography across diverse printers. It integrated with XNS and Ethernet for networked printing, where documents were transmitted as masters containing page descriptions and Instructions to specify parameters like copies, finishing options, and required resources such as fonts or files. The protocol's stack-oriented, postfix model facilitated multi-page documents and geometric transformations for scaling, rotation, and positioning, ensuring consistent output without dependence on specific hardware. Resource management in XNS relied on the Clearinghouse Protocol, a decentralized and replicated that acted as the Resource Control Facility for locating and accessing printers and other network entities. This facility employed a three-level —LocalName:Domain:Organization—to resolve resource identifiers to network addresses and properties, supporting features like aliases, wildcards, and property-based searches for efficient discovery. Session establishment for printing occurred through the Printing Protocol's initial requests, authenticated via the Filing Protocol's log-on procedures, while the Clearinghouse enabled load balancing by distributing queries across replicated servers and allowing clients to select available printers based on resolved locations and capabilities. Queue management was handled by the Print Service, which spooled Interpress masters in a holding area, processed jobs in arrival order, and supported priority queuing with high, medium, or low levels to optimize resource allocation. Job control features ensured reliable operation, with each print request assigned a unique Print Request Identifier for tracking progress through phases of , formatting, and marking. The Sequenced Packet Protocol (SPP) provided the underlying reliable, sequenced transport for these interactions, supporting calls and Bulk Data transfers while enabling error reporting through standardized abort messages and condition codes in the Protocol. For instance, clients could query job status or receive notifications of issues like resource unavailability, with the Error Protocol standardizing communications for faults across the system. This integration allowed seamless spooler interactions, where jobs were held securely with release keys if needed, and options like two-sided or copy counts were specified at submission.

Filing Protocol

The Filing Protocol in XNS provided file storage, retrieval, and services, enabling interactions between clients and file servers for document handling and archiving. Defined in standards such as XSIS 108210 (October 1982, revised December 1984), it layered above the protocol with sub-layers for session (including and log-on/log-off), file operations (e.g., create, read, write, delete), directory services (), and search capabilities (e.g., wildcard matching). Key features included support for like name, size, and access controls, bulk data transfer for large files, and integration with via a printer subset for storing scanned images or Interpress masters. It ensured secure access through the and enforced access rights on file "drawers," facilitating centralized file services in office environments.

Mail Protocol

The Mail Protocol in XNS supported electronic mail transport, delivery, and retrieval, aligning with CCITT standards (particularly X.420 P2 for interpersonal messaging) to enable interoperable messaging. It consisted of the Mail Transport Protocol for sending and receiving messages to/from mail servers and the Inbasket Protocol for clients to fetch messages from personal inbaskets. Messages were structured with envelopes (e.g., recipients, postmarks) and content supporting diverse formats like documents and , posted to servers rather than directly to recipients for distributed handling. Key features included instant delivery, distribution lists, multi-level encapsulation, and server-based global access to mailboxes, using procedures for RPC interactions. This design provided a robust, standards-compatible system within XNS networks.

History

Origins in PARC and PUP

The development of Xerox Network Systems (XNS) originated at the Xerox Palo Alto Research Center (PARC), where in 1973 Bob Metcalfe and his team began exploring networked office environments to interconnect the innovative personal workstations. This initiative addressed the need for efficient local area networking in a research setting, focusing on shared resources like laser printers and file servers among distributed computing systems. Metcalfe, drawing from experiences, assembled a small group including David Boggs to prototype a high-speed local network, marking the foundational step toward what would become XNS. Central to these efforts was the PARC Universal Packet (PUP), an experimental internetworking protocol suite developed from to 1976, which introduced a datagram-based model for packet delivery across heterogeneous networks. PUP was designed to operate over the emerging , enabling reliable communication in a broadcast environment. The first PUP implementation emerged in late on an Ethernet prototype running at 3 megabits per second, with fuller deployment by 1975 supporting basic services like and remote access on systems. Key milestones included PUP's role in overcoming early challenges, such as in shared media, where the protocol incorporated mechanisms for with (CSMA/CD) to manage contention and ensure efficient transmission retries. This work directly influenced the Ethernet patent filed by in 1975 and detailed in a seminal 1976 publication. Initially employing 16-bit addresses (combining 8-bit network and host fields), PUP evolved to demonstrate scalability, powering demos with over 100 nodes across PARC's facilities by mid-1975. These experiments laid the groundwork for Ethernet as the physical enabler of XNS, paving the way for its formal standardization in the late 1970s.

Evolution to XNS Standard

In 1977, Xerox transitioned from the PARC Universal Packet (PUP) protocol to the Xerox Network Systems (XNS) specifications, refining PUP's datagram architecture to support higher-speed Ethernet networks and larger-scale deployments. Yogen Dalal, who joined Xerox's Systems Development Division that year, played a central role in this evolution by reengineering PUP to separate routing functions in an internet sublayer from end-to-end communication in a network-specific sublayer, enabling more flexible internetworking across multiple heterogeneous networks. This addressed PUP's limitations in handling diverse network types beyond the initial PARC environment. By late 1977, the first draft of XNS specifications, including XNS 1.0, was published internally, introducing expanded addressing with 48-bit host identifiers, 32-bit network numbers, and 16-bit sockets to enhance scalability for enterprise networks supporting thousands of devices. Xerox's standardization efforts focused on internal documentation, including the XNSG series through the , which detailed the , including layered models aligned with emerging ISO OSI references. These documents formalized XNS as an , made partially publicly available starting in 1981 (lower-layer protocols) to encourage adoption, complemented by licensing programs in the early to promote among third-party implementations. Dalal's contributions to this process were further outlined in his 1982 IEEE paper on XNS communication, emphasizing the protocol's support for multiple transport options, such as datagrams and virtual circuits, to meet diverse application needs. Key milestones included 1978 interoperability tests that validated XNS across experimental internetworks, as documented in contemporary reports, demonstrating reliable packet routing and delivery in multi-vendor setups. Throughout the 1980s, refinements to XNS supported the rollout of Xerox's NS product line, incorporating enhancements like integration with IEEE 802.3 Ethernet standards by 1985 and bulk data transfer protocols to bolster performance in commercial office environments. These developments positioned XNS as a scalable foundation for distributed systems, extending beyond PARC's prototype scale to enterprise-wide connectivity.

Commercial Deployments and Decline

Xerox Network Systems (XNS) saw its primary commercial deployments within Xerox's own product ecosystem, beginning with the integration into the 8010 workstations released in 1981. These workstations, part of the Xerox 8000 Network System, utilized XNS to enable networked features such as electronic mail, , and printing across Ethernet-connected devices. The 8000-series file servers further supported these capabilities, offering up to 300 MB of storage and facilitating communication between Xerox workstations and compatible systems like DEC VAX minicomputers. By the mid-1980s, XNS had achieved widespread adoption in corporate environments, connecting thousands of nodes in Xerox's internal and customer networks, particularly for tasks. To expand beyond proprietary hardware, Xerox licensed elements of XNS to third-party vendors, notably , which developed Ethernet networking software for PCs under this agreement in the early . This licensing aimed to broaden compatibility, allowing XNS-based connectivity for personal computers in mixed environments alongside Xerox systems. Later deployments extended to high-volume printing solutions, where XNS powered network operations in DocuTech production publishers introduced in , enabling job management and resource sharing until the mid-1990s. Despite initial success as an early market leader for local area networking protocols by late , XNS faced significant challenges due to its nature, which restricted widespread third-party adoption and . The protocol's minimal public disclosure—Xerox released only select lower-layer specifications in while retaining higher-layer protocols like filing and printing as trade secrets—limited its ecosystem growth. Competition intensified with the rise of TCP/IP, particularly following the ARPANET's full transition to TCP/IP on January 1, 1983, and the availability of low-cost UNIX implementations bundled with TCP/IP in 1982, which offered broader openness and government backing. XNS's decline accelerated in the 1990s as shifted strategic focus toward IP-based networking to align with emerging standards and customer demands for . The last major commercial use of XNS occurred in DocuTech systems around 1997, after which discontinued active development and support, with no official maintenance provided post-2000. This transition reflected broader industry consolidation around TCP/IP, rendering XNS obsolete in favor of more universal protocols.

Implementations and Derivatives

Xerox Internal Systems

The Xerox Star, released in 1981 as part of the 8000 Network System, served as the first commercial client implementation of XNS, featuring bit-mapped displays, windows, and mouse-driven interfaces for coordinated document creation, centralized printing, and filing across networked workstations. This system enabled interactive publishing with direct user control over document design, integrating XNS for distributed document management in office environments. Building on the Star, ViewPoint software ran on the 6085 Professional Computer System (PCS), providing user-friendly, multilingual interfaces with WYSIWYG document displays and icon-based access to remote services via XNS protocols. Complementing these clients, 8000 NS servers functioned as general-purpose minicomputers programmed for file, print, and mail services, hosting core XNS elements like the Clearinghouse and Authentication protocols while supporting high-level applications such as filing and printing. XNS implementations within Xerox systems embedded the full directly into on workstations and servers, ensuring efficient direct network connectivity without reliance on external intermediaries. These stacks operated over 10 Mbps Ethernet local area networks using and CSMA/CD access, compliant with standards, to interconnect up to 1024 devices per segment. Integration with the Distributed File System (DFS) occurred through the Filing Protocol, which supported hierarchical storage, retrieval, and across networked servers, including attributes like fileID, name, version, type, dataSize, and isDirectory for seamless operations in heterogeneous environments. Deployments evolved from experimental setups at PARC to widespread office use, with the and 8010 systems scaling XNS from prototypes to production environments for global document workflows. The architecture's distributed and replicative design facilitated scalability, supporting networks of over 1000 nodes across campuses through incremental growth and fault-tolerant routing. In the , XNS underpinned Xerox's global network, interconnecting thousands of devices worldwide via the Internetwork Routing Service to link dispersed Ethernets in offices and facilities. High-performance processors were optimized for XNS operations in research and advanced workstations, enhancing efficiency in protocol handling and tasks.

Third-Party Adaptations

In the 1980s, Xerox made the XNS protocol specifications publicly available, enabling third-party vendors to license and adapt them for their networking products without proprietary restrictions. This openness facilitated widespread adoption. Notable adaptations included direct implementations and modifications to extend XNS beyond its original Ethernet focus. Novell adapted XNS's Internet Datagram Protocol (IDP) into its (IPX) for the operating system, creating a connectionless protocol that became the foundation for IPX/SPX networking in local area networks during the 1980s and 1990s. IPX retained XNS's addressing and routing concepts but incorporated Novell-specific enhancements for file and print services, powering millions of NetWare installations in enterprise environments. Banyan Systems developed VINES (Virtual Integrated Network Service) as a distributed based on a proprietary protocol family derived from XNS, emphasizing client-server architecture for file, print, and directory services on UNIX-based servers. VINES used XNS-inspired and internetwork protocols, such as its Routing Table Protocol (RTP), while adding features like StreetTalk for global naming; it supported Ethernet and extended XNS's Ethernet dependency by incorporating media access. VINES remained in commercial use through the , with support from major network vendors until its decline in favor of TCP/IP-based alternatives. 3Com implemented XNS unchanged in its 3+Share , which ran on DOS-based servers to provide and client-server connectivity for early Ethernet LANs in the . This direct adoption allowed 3Com products like the 3Server to interoperate seamlessly with other XNS systems, focusing on resource sharing in small workgroups without significant protocol modifications. Ungermann-Bass incorporated XNS at the network layer in its Net/One system, using it for and gateways to connect heterogeneous LANs, including support for bridging between Ethernet segments in enterprise deployments. Net/One's adaptation emphasized , enabling XNS traffic to traverse non-Ethernet links via proprietary extensions while maintaining core delivery. Apple's protocol suite drew inspiration from XNS for its Datagram Delivery Protocol (DDP), a connectionless network-layer protocol analogous to XNS's IDP, which handled socket-to-socket packet delivery over custom hardware like . This design choice allowed to support multiprotocol environments in the , though it diverged with additions for zoning and dynamic addressing tailored to Macintosh ecosystems. Implementations also existed for UNIX systems, including 4.3BSD derivatives, allowing XNS use on non- platforms.

Legacy and Influence

Technical Contributions to Networking

Xerox Network Systems (XNS) pioneered the early adoption of layered protocols, structuring its into modular layers that paralleled the emerging ISO Open Systems Interconnection (, including physical/, network/, and application layers to enhance and scalability across diverse media such as Ethernet and X.25. This design isolated functions for data transmission, allowing higher layers to remain unaffected by underlying changes, which facilitated the integration of multiple protocols and supported flexible network growth from local area networks (LANs) to internetworks. A core innovation was the Internet Datagram Protocol (IDP), a connectionless protocol that served as a precursor to IP by enabling end-to-end with self-contained packets, including source and destination addresses more general than Ethernet's 48-bit host numbers. IDP incorporated a for error detection and supported adaptive via the Internetwork Routing Service (IRS), which provided geographic independence without centralized control, testing in multi-network environments. Addressing in XNS used a hierarchical scheme with 32-bit network numbers, 48-bit host addresses (yielding 281 trillion possibilities), and 16-bit socket numbers to uniquely identify processes, allowing and alias support while pushing the limits of early LAN . For distributed applications, XNS introduced the protocol, an RPC mechanism that standardized request-reply transactions across layers—block stream for data transfer, object stream for structured types, and message stream for calls and returns—enabling reliable, location-independent operations like resource sharing between workstations and servers. This innovation modeled remote interactions as subroutine calls, supporting bulk data and error handling, and laid groundwork for efficient . XNS validated Ethernet's design through real-world 1970s demonstrations at PARC, proving the 10 Mbps CSMA/CD LAN's reliability for high-speed, multi-node communication when paired with protocols like IDP. It influenced the BSD Unix networking stack in the 1980s, with 4.3BSD incorporating the XNS protocol suite to build upon TCP/IP implementations and extend support for LAN protocols. 's publication of open specifications for XNS protocols enabled detailed analysis and adaptation by third parties, fostering broader protocol evaluation and refinement. Enduring concepts, such as socket addressing combining network, host, and port elements for process identification, persist in modern APIs like those in Unix-derived systems.

Impact on Successor Protocols

Xerox Network Systems (XNS) exerted significant influence on the development of TCP/IP, particularly through its core protocols. The Internet Datagram Protocol (IDP), XNS's network-layer protocol, provided a model for datagram-based that paralleled the design of the (IP), with similarities in addressing and fragmentation mechanisms. Similarly, the Sequenced Packet Protocol (SPP), XNS's reliable transport-layer protocol, featured connection-oriented communication with acknowledgments and flow control, directly analogous to the Transmission Control Protocol (TCP), including a three-way handshake for connection establishment. and Bob Kahn, architects of TCP/IP, drew inspiration from Xerox's earlier PUP protocols—which evolved into XNS—during design meetings in the mid-1970s, where PARC engineers contributed insights under legal constraints. XNS also shaped other networking standards, notably the Open Systems Interconnection (OSI) reference model and proprietary protocols. Its layered architecture, separating concerns like datagram routing and transport reliability, predated and informed the OSI model's seven-layer structure, influencing international standardization efforts in the late 1970s and early 1980s. Novell's (IPX), introduced in 1983 as part of , was a near-direct adaptation of XNS's IDP and SPP, retaining much of the addressing scheme and packet formats while adding Novell-specific extensions; IPX remained in widespread use for local area networks through the and into the early . , Apple's networking suite launched in 1984, incorporated XNS-like routing algorithms and datagram concepts but used shorter, incompatible addresses to suit low-cost hardware, phasing out by the late as TCP/IP dominated. In the , XNS underwent evaluations alongside TCP/IP in Department of Defense (DoD) internetworking assessments, highlighting its proprietary nature against TCP/IP's open distribution, which ultimately favored the latter for adoption in 1983. Recent historical analyses, including updates to archival resources, underscore XNS's role in early protocol competition. Today, XNS concepts persist in niche applications, such as open-source emulations for retro computing; for instance, the Dodo project implements XNS protocols in to support emulated workstations like the Star 8010, enabling simulation of environments in the .

References

  1. http://www.bitsavers.org/pdf/xerox/xns/XNSG_068504_Xerox_System_Network_Architecture_General_Information_Manual_Apr85.pdf
  2. https://www.filibeto.org/sun/lib/networking/internetworking_technology_overview/Xerox_Network_Systems_%28XNS%29.pdf
  3. https://historyofcomputercommunications.info/section/8.10/Xerox-Network-System-%28XNS%29-1977-1978/
  4. https://www.filibeto.org/sun/lib/networking/internetworking_technology_overview/Xerox_Network_Systems_(XNS).pdf
  5. https://historyofcomputercommunications.info/section/8.10/Xerox-Network-System-(XNS)-1977-1978/
  6. http://www.bitsavers.org/pdf/xerox/parc/techReports/CSL-79-10_Pup_An_Internetwork_Architecture_Jul79.pdf
  7. http://ftpmirror.your.org/pub/misc/bitsavers/pdf/xerox/xns/standards/XSIS_028112-Internet_Transport_Protocols_198112.pdf
  8. https://www.cisco.com/en/US/docs/internetworking/troubleshooting/guide/tr1914.pdf
  9. https://bitsavers.trailing-edge.com/pdf/xerox/xns/A_Study_of_the_Xerox_XNS_Filing_Protocol_as_Implemented_on_Several_Heterogenous_Systems_Aug86.pdf
  10. http://ftpmirror.your.org/pub/misc/bitsavers/pdf/xerox/xns/standards/XSIS_038112_Courier_The_Remote_Procedure_Call_Protocol_Dec1981.pdf
  11. https://datatracker.ietf.org/wg/oncrpc/about/
  12. http://ftpmirror.your.org/pub/misc/bitsavers/pdf/xerox/xns/standards/XSIS_098404_Authentication_Protocol_Apr1984.pdf
  13. http://www.bitsavers.org/pdf/xerox/interpress/XSIG_038306_Introduction_to_Interpress_Jun1983.pdf
  14. https://historyofcomputercommunications.info/section/8.7/Ethernet-and-Robert-Metcalfe-and-Xerox-PARC-1971-1975/
  15. https://amturing.acm.org/award_winners/metcalfe_3968158.cfm
  16. https://xeroxparcarchive.computerhistory.org/_cd8_/pup/.PUPPAPER.PRESS%211.pdf
  17. http://bitsavers.org/pdf/xerox/xns/XNSG_068504_Xerox_System_Network_Architecture_General_Information_Manual_Apr85.pdf
  18. https://historyofcomputercommunications.info/section/11.8/TCP-IP-and-XNS-1981-1983/
  19. http://bitsavers.informatik.uni-stuttgart.de/pdf/xerox/xns/XNS_Brochure.pdf
  20. https://ethw.org/w/images/d/d0/Ref4-DIX-Ethernet-1980.pdf
  21. https://patents.google.com/patent/US6020973A/en
  22. https://www.devx.com/terms/xerox-network-systems/
  23. https://www.digibarn.com/collections/systems/xerox6085/working/index.html
  24. https://www.novell.com/documentation/nw6p/ipx_enu/data/hjyh8yg8.html
  25. https://www.cisco.com/c/en/us/td/docs/ios/novipx/command/reference/ipx_book.pdf
  26. http://banyan-vines.bamertal.com/Banyan-supplier-help/ArchDef/ArchDef3.htm
  27. https://historyofcomputercommunications.info/section/12.2/3Com/
  28. https://blog.fosketts.net/2007/06/25/storage-history-the-3server/
  29. https://historyofcomputercommunications.info/section/9.15/Ungermann-Bass-Xerox%2C-Broadband-and-Needing-a-Chip/
  30. https://vintageapple.org/macbooks/pdf/Inside_AppleTalk_Second_Edition_1990.pdf
  31. https://akapugs.blog/2020/03/21/680/
  32. https://foldoc.org/Xerox+Network+System
  33. https://docs.freebsd.org/en/books/design-44bsd/
  34. https://www.dsbaral.com.np/subject/network-programming/xns-protocol
  35. http://ps-2.kev009.com/wisclibrary/aix52/usr/share/man/info/en_US/a_doc_lib/aixprggd/progcomc/ch12_xns.htm
  36. https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/qos_nbar/prot_lib/protocol-reference/nbar-protocol-reference/x.pdf
  37. https://ics.upjs.sk/~novotnyr/home/programovanie/c/books/cpc/ch12_xns.htm
  38. https://www.networkworld.com/article/964542/history-of-computers-part-2-tcpip-owes-a-lot-to-xerox-pup.html
  39. https://historyofcomputercommunications.info/section/11.1/Standards-Making-and-the-OSI-Reference-Model/
  40. http://basalgangster.macgui.com/RetroMacComputing/The_Long_View/Entries/2012/3/1_AppleTalk.html
  41. https://github.com/devhawala/dodo
Add your contribution
Related Hubs
User Avatar
No comments yet.