Desktop Protocols

Desktop Protocols

Xerox Network Systems Protocol

Xerox developed the Xerox Network Systems (XNS) protocols in the late 1970s and early 1980s. As the first to reach popularity and hit the market, XNS became the model adopted by other NOS vendors, such as 3Com Banyan and Novell. Eventually, the other NOS vendor’s software became more popular and replaced XNS.

XNS was defined on a five-layer model that generally followed the same principles of OSI’s seven-layer reference model. Layer 1, the network layer, is called the Internet Datagram Protocol (IDP). A unique host and network number identified each host and each network in an XNS network. XNS used the Routing Information Protocol (RIP) for routing XNS packets through an internetwork.

DECnet Protocol

DECnet was originally developed in 1975 by Digital Equipment Corporation (DEC) as a series of protocols used to connect two PDP-1 1 minicomputers directly to each other. Subsequent releases of DECnet added support for other proprietary and standard protocols while still maintaining backward compatibility. DECnet Phase IV and V were the last most popular versions of DECnet.

DECnet implemented an eight-layer network model, as opposed to OSI’s seven-layer model; it was one of the few protocols to incorporate network management into its network protocol definition.

Unique to DECnet Phase TV’s implementation was its network addressing. DECnet addresses were not associated with the physical networks to which the nodes were connected. Instead, DECnet located hosts using area/node address pairs. When implementing routers in a DECnet network, this design meant that each interface on the router had the same logical and physical Media Access Control (MAC) layer address. Phase V opened the door for migration to TCP/IP by implementing DECnet’s upper four layers on a regular TCP/IP stack.

Routing Phase IV traffic involved implementing the DECnet Routing Protocol (DRP). Phase V combined DRP with the 051 routing protocolâ€'hence, Phase V’s other name, DECnet OSI.

AppleTalk Protocol

Apple Computers developed a protocol suite called AppleTalk in the mid 1980s in conjunction with its Macintosh computer. AppleTalk’s purpose was to let multiple users share resources such as printers and files. Clients were the computers that access the resources, and servers were the computers that make the resources available for sharing. AppleTalk was one of the early protocols developed explicitly for distributed client/server networking.

AppleTalk was designed with a transparent network interface. Users needed little interaction to get their computers talking to other computers, and the network protocols were invisible to the user.

AppleTalk had two phases before eventually being replaced by TCP/IP. Strictly fot workgroup use, Phase 1 was limited to 127 hosts and 127 servers on a network. Phase 2 was developed to operate on larger internetworks and included features that made it more extensible and appropriate for quickly growing user networks.

An AppleTalk node was a device connected to an AppleTalk network. An AppleTalk network consisted of a single logical cable with multiple nodes attached. AppleTalk zones were logical groups of nodes or networks that were defined when the network administrator configured the network. Zones did not need to be physically contiguous.

One of the unique aspects of AppleTalk was how nodes automatically retrieve their network addresses. It was not necessary to statically define an AppleTalk address; instead a node was automatically assigned an address when it connected to the network.

The routing of AppleTalk traffic was more complex than other routing protocols. Routers had to maintain and transport not only network routing information, but also other information such as name lookup and zone information.

The Routing Table Maintenance Protocol (RTMP) was the primary routing protocol, based on the RIP. RTMP advertisements contained information from each router on the networks it could reach.

Routers also had to be aware of other protocols such as the Name Binding Protocol, Zone Information Protocol, Printer Access Protocol, and AppleTalk Filing Protocol. This awareness was necessary so that when a user opened a chooser menu, he would be able to see the other Apple resources on the network.

Banyan VINES Protocol

Banyan VINES was ahead of its time. Banyan was a company (no longer in business) who created a distributed network operating system on a proprietary set of protocols based loosely on the XNS protocols. The network operated similarly to XNS but included the first implementation of directory services that truly set the trend for future directory services. With a single logon, a user could access any network resource, file server, or printer by name. It was fast and efficient when implemented correctly. In this author’s opinion, Banyan suffered from ineffective marketing and failed to keep up with the growth and scaling demands of its customers.

The Novell juggernaut at the time overwhelmed Banyan with its sheer marketing muscle and managed to finally release a scalable and working directory services 10 years after Banyan. Banyan quietly went out of business, leaving Microsoft and Novell to duke it out. Microsoft eventually won.

Novell NetWare

Novell developed NetWare in the early 1980s. NetWare, like VINES, was based on the XNS networking protocols.

The NetWare Layer 3 protocol is called Internetwork Packet Exchange (IPX) and is connectionless similar to IP’s User Datagram Protocol (UDP). A network number assigned by a network administrator identifies each network. Initially, routers exchanged routing information using a RIP protocol, but with NetWare 4.x, Novell added support for an OSPF-like link-state protocol called Network Layer Security Protocol (NLSP). Later, Novell added support for NetWare/IP, in which IPX datagrams were encapsulated in standard IP UDP packets.

As with AppleTalk and VINES, users did not need to statically configure node addresses for their machines. Instead, when a NetWare PC attached to the network, it looked for the nearest server and automatically received a network and node number.

In addition to exchanging routing information, NetWare servers also exchanged Service Advertising Protocol (SAP) packets. SAPs contained information about available network resources such as printers and file servers. Therefore, if a client wanted a network resource available from a distant server, the local server gave the address of the resource to the client, and the client then contacted the distant server directly.