[ Bottom of Page | Previous Page | Next Page | Contents | Index | Library Home | Legal | Search ]

Communications Programming Concepts

Xerox Network Systems

Xerox Network Systems (XNS) is the network architecture developed by the Xerox Corporation in the 1970s. The XNS Internet protocol suite is similar to the TCP/IP suite. However, different packet formats and terminology are used.

XNS protocols establish a means of transport for data across an interconnection of network or Internet. A sample library provides user applications for XNS, such as the courier, associate printing, filing, and clearinghouse protocols.

For a more thorough description of the XNS protocol, refer to the following:


The socket interface in the NS protocol or domain family implements the XNS protocol suite through:

The XNS Protocols figure (Figure 48) illustrates how these protocols relate to each other as well as how they interface with the layers above and below them.

Figure 48. XNS Protocols. This diagram shows XNS Protocols and how each layer relates to the other. A line representing Public Domain Free Source divides the diagram into a top section and a bottom section. The top section shows the following: Print Server, File Server, and Clearinghouse (Name Server) are side-by-side, and each has its own two-way arrow to Courier (RPC). The bottom section shows the following: Socket Services borders the line representing Public Domain Free Source; the Socket Services connects with the second layer via a two-way arrow. The second layer section contains the following (side-by-side): Echo, Error, Sequenced Packet, Packet Exchange, Routing Information. A two-way arrow stretches between Error (in the bottom section) and Courier (in the top section) as well as Sequenced Packet (in the bottom section) and Courier (in the top section). The bottom section contains three more layers connected to the second layer and each other via two-way arrows: Internetwork Datagram, Network Interface Modules, Communication Device Driver (Ethernet, IEEE 802.3).

IDP forms the basis for the level-1 transport protocol in the XNS architecture and is responsible for the Internet packet format, Internet addressing, and routing, which correspond to the network layer (layer 3) of the Open Systems Interconnection (OSI) protocol architecture. The SPP is a level-2 transport protocol layered on top of IDP and corresponding to the OSI transport layer (layer 4). The SPP provides reliable transmission to guarantee delivery, data integration, and sequential delivery of data.

The Error protocol, which reports errors, is used as a diagnostic tool as well as a means of improving performance and is not normally accessed by users. The Echo protocol causes a host to echo the packet it receives and is often used to test the accessibility of another site on the Internet. If no user application is attached to the echo port, the kernel automatically responds to the echo request from another host. The XNSrouted daemon uses RIP to exchange route data and collect adjacent route information.

The SPP is used to support the operation of both stream and sequenced packet sockets created in the Network Services (NS) domain. The standard datagram service, PEP, is implemented by a user-level library, using IDP datagram sockets. Raw access to the Error Protocol and IDP is possible through raw sockets.

For each SPP- or IDP-based socket, an NS protocol control block is created to hold NS information similar to that found in the Internet control block. Also, like the Transmission Control Protocol (TCP), the SPP creates a control block to hold the protocol state information necessary for its implementation. Unlike those in the Internet domain, the NS protocol control blocks for all protocols are maintained on one doubly-linked list.

In the NS domain, packet demultiplexing at the network-protocol level is done first according to the network address and port numbers and then according to the communication protocol. The linkage between the socket data structures and the protocol-specific data structures is identical to that found in the Internet communication domain.

The SPP uses the spcb parameter as the SPP protocol control block and m parameter as the memory buffer (mbuf) chain that contains the data to be sent.

All NS protocol input is received by the NS interrupt routine, nsintr, which is invoked at software-interrupt level when a network interface receives a message to be processed by an NS protocol module. The interrupt routine performs consistency checks on the packet, and then determines whether to receive, forward, or discard the packet. If the packet is to be received, the nsintr routine locates the NS protocol control block for the receiving socket according to the sender's address and the destination port number. The routine then passes the packet to the receiving protocol.

The SPP and IDP pr_ctloutput routines provide access to NS-specific options that control the behavior of the SPP and IDP in processing data transmitted and received through a socket. The following options are usable with both SPP and IDP protocols:

SO_HEADERS_ON_INPUT Returns protocol headers on each message with data.
SO_MTU Sets the maximum size of a message that is sent or received.
SO_DEFAULT_HEADERS Establishes a default header for outgoing messages.

System Configuration

Two separate network interfaces for the XNS protocol can be implemented, the IEEE 802.3 Ethernet interface and the Standard Ethernet interface, which both run on 10Mbps Ethernet hardware. The host ID in the XNS address uses the Ethernet address. Multiple Ethernet hardware interfaces are supported in the same system. However, to simplify the design, one host ID for each Ethernet interface is used. Even though multiple host IDs are used in the same system, packets destined for a specific host ID are received and processed accordingly.

The ifconfig command configures the network interface for XNS either during run time or at system startup. If the interface is configured at system startup, the /etc/rc.net file needs to be edited to include the ifconfig command. The netns kernel extension is loaded into the system when the first XNS network interface is configured.

Because multiple hosts are supported, the host ID should be specified each time a network interface is configured.

The following ifconfig command syntax:

ifconfig en0 ns 010:

configures Ethernet interface en0 on network 010 at host


If your environment allows access to networks not directly attached to your host, you need to set up a routing table to properly route packets. Two schemes are supported by the system.

It is possible to combine both of the above facilities, allowing you to update the routing table manually with the route command and automatically with the XNSrouted daemon. Use the netstat command to display routing table contents as well as various routing-oriented statistics. For example:

netstat -r

displays the contents of the routing tables.

The current implementation of XNS automatically forwards all incoming XNS Internet packets to the appropriate router or network, as long as the packet is not destined for the local host and the destination network information is maintained in the routing table. Indirectly, the local host can be used as a router.

XNS Addresses

An XNS address occupies 12 bytes and is comprised of three parts:

The host ID is an absolute number that must be unique to all XNS Internets. The operating system implementation uses the 48-bit Ethernet address as host ID. With unique host IDs, the network ID is redundant but is required for routing purposes.

XNS addresses can be represented by several means, as can be seen in the following examples:

The first example is in decimal format, and the second example, using - (minus signs), is separated into groups of three digits each. The 0x and H examples are in hex format. Finally, the 0 in front of the last example indicates that the number preceding the colon is in octal format.

[ Top of Page | Previous Page | Next Page | Contents | Index | Library Home | Legal | Search ]