IPX/SPX
In the mid-1980s, when Novell was working on NetWare, its engineers faced a challenge: creating a network protocol capable of enabling communication between computers distributed throughout the enterprise. They didn't start from scratch. The XNS system that Xerox had developed a few years earlier served as their model. This pragmatic approach gave birth to IPX/SPX, a protocol suite that would leave its mark on an entire decade of network computing.
The era was marked by the first steps in networking. Companies were discovering the value of sharing files and printers across multiple workstations. NetWare offered an answer to these needs with its client-server architecture, where IPX/SPX played the role of messenger between machines. The protocol was structured in two distinct layers: IPX for routing packets from one point to another, SPX for guaranteeing their proper reception.
Novell had found an elegant trick to simplify network configuration. Where other protocols required complex mapping tables, IPX used the network card's MAC address directly as the machine identifier. Each IPX address combined a 32-bit network number, defined by the administrator, with this famous 48-bit MAC address. Ultimately, there was no longer any need for an additional protocol to link the logical and physical identities of the machine.
Routing relied on RIP (Routing Information Protocol), but not IP's RIP. The two protocols shared the name without being compatible. Every minute, IPX routers exchanged their routing tables using a particular metric called a "tick". A tick corresponded to one-eighteenth of a second, providing an estimate of the delay on each link. If two routes showed an identical number of ticks, the hop count would decide.
SAP (Session Announcement Protocol) added an extra dimension to the IPX/SPX ecosystem. This service announcement protocol transformed the network into a vast bulletin board where each server proclaimed its capabilities: file sharing, printing, messaging. As with RIP, announcements repeated every minute. Routers maintained a list of all available services, ready to inform any client seeking a particular resource.
IPX/SPX's adaptability manifested in its ability to coexist with different Ethernet standards. The protocol accepted multiple encapsulation types: Novell's proprietary format, IEEE 802.2 and 802.3 standards, Ethernet II, and SNAP. This flexibility facilitated integration into heterogeneous environments, provided consistency was maintained in the configuration of all equipment.
At the top of the protocol stack, NCP handled business aspects: file access, print control, security. NetBIOS found its place through an emulation layer that allowed existing applications to continue functioning. NLM modules extended the system's possibilities with new protocols, communication services, or database access.
The 1990s saw IPX/SPX flourish in enterprises. Its ease of implementation and good performance made it a natural choice for network administrators. But the Internet was growing and TCP/IP was establishing itself as the universal language of digital communications. Faced with this rise in power, Novell had to revise its strategy.
The company gradually integrated TCP/IP into NetWare. Later versions offered the ability to encapsulate IPX in UDP/IP packets to traverse networks based on the Internet protocol. The arrival of NDS in NetWare 4.0 reduced dependence on the SAP protocol by allowing clients to locate services through a centralized directory.
The transition accelerated in the 2000s. New applications were born with TCP/IP in their DNA, relegating IPX/SPX to the status of legacy technology. Novell eventually abandoned development of its protocol suite to turn toward IP-based solutions.
This evolution shouldn't obscure IPX/SPX's lasting influence. The direct use of MAC addresses, automatic service discovery—these concepts would resurface in more recent technologies. Modern protocols like mDNS or UPnP revisit ideas that SAP had already explored.
The story of IPX/SPX tells the tale of an era when network protocols competed to impose their vision of communication. Faced with the universal standardization of TCP/IP, proprietary solutions, whether technically accomplished or not, could only fade away. This lesson extends beyond the purely technical realm: in an interconnected world, openness and interoperability often prevail over local excellence.
IPX/SPX's fate ultimately illustrates an immutable truth of computing: no technology, however brilliant, survives without adapting to market changes. TCP/IP didn't triumph solely through its intrinsic qualities, but because it became the lingua franca of the Internet. In this battle of protocols, universality had the last word.