Figure 7-3: IPX packet structure in Objective-C

Encode PDF417 in Objective-C Figure 7-3: IPX packet structure

Checksum This field is unused and always set to FFFFH Length This field is the datagram length in octets Transport Control This field is used by IPX routers

Packet Type This field specifies the type of the protocol header after the IPX header (for example, SPX) Destination Network Number, Node Number, and Socket Number These fields are self-explanatory Source Network Number, Node Number, and Socket Number These fields are self-explanatory Data (variable) This field includes the data If SPX is used, the SPX header will also be encapsulated here

SPX is the transport-layer protocol that performs connection-based services in IPX/SPX It is very similar to TCP: it establishes and terminates sessions, as well as performs flow control using windowing, thereby providing for reliable packet delivery One difference in SPX and TCP, however, is that SPX uses a field called the Connection ID to discriminate between sessions Another difference is in how SPX performs windowing In SPX, windowing is not a dynamic process Window sizes are constant and will not change throughout the session This feature makes SPX a bit less flexible, but also less complex, than TCP Finally, Figure 7-4 shows the structure of an SPX packet An explanation of the fields follows

Connection Control Splits up into sections, and signals functions like acknowledgements and message termination Datastream Type Specifies the type of data contained within the packet Source Connection ID and Destination Connection ID Identifies the session Sequence Number Identifies the number of packets transmitted Acknowledgment Number Identifies the next expected packet (FACK) Allocation Number Identifies the number of packets unacknowledged Data (Variable) This is the actual payload of the message If any upper-layer protocol headers (Application, Presentation, and so on) are used, they will be encapsulated here as well

DIAG is a protocol used to provide functions similar to some of those in ICMP Like ICMP, DIAG is used to check connectivity However, rather than just giving you a success or failure, DIAG can also inform you about which services are running on the remote nodes and which networks the remote nodes are aware of, and it can mass test a group of hosts Overall, DIAG is an extremely useful protocol for testing your IPX network

The Service Advertising Protocol (SAP) has an extremely important use in an IPX network: it locates servers and services provided by those servers It works like this: Servers send out an SAP broadcast at a regular interval (every 60 seconds, by default), advertising the services it has available to all directly connected hosts Other servers receive these broadcasts and update a table, called the SAP table, with the information They then propagate this information in their next SAP broadcast Routers can also play a part in this exchange by keeping, updating, and advertising their own SAP tables, including any server they are aware of At any time, if there is a change to a server's SAP table, the server can (if so configured) broadcast a new update, known as a triggered update The combination of triggered and timed updates allows all servers on the network to acquire and maintain a SAP table with every available server on the entire network, even those spanning multiple subnets This is because, as mentioned previously, the routers build an SAP table and then broadcast that table to other subnets This process allows clients to find any server in the entire IPX network by using another protocol: Get Nearest Server (GNS) When a client wishes to find a server (to log in, for instance), it will broadcast a GNS request GNS finds the closest server offering the service that the client requires The GNS reply is sent back by a server on the same subnet as the client, letting the client know how to reach its closest server From this process, another very important function occurs: the client builds its IPX address When the client receives a GNS reply, it looks at the network portion of the IPX address for the server and uses this address for its IPX network address It then adds its MAC address for the node portion, and it has a complete IPX address SAP updates are used primarily by bindery-based (31 and 4x with bindery emulation) Netware servers to locate resources The bindery is the accounts database in earlier versions of Netware In networks based on Netware Directory Service (NDS) a distributed account database used in Netware 4x and later SAP broadcasts are used by clients only at bootup to find the nearest server and obtain an IPX address, so SAP-related traffic on the LAN is much lower Through this process, an IPX client can locate all needed network services, as well as get a correct and valid IPX address for its specific needs Unfortunately, SAP broadcasts ultimately lead to another problem (aside from traffic): lack of scalability SAP broadcasts can cause major problems over WAN links, where bandwidth is limited For instance, in Figure 7-5, a router is broadcasting SAP updates every 60 seconds to five permanent virtual circuit (PVCs) over a single T1 (1544 Mbps) connection Remember from 3 that most WAN links are NBMA networks, and they cannot use broadcasts Consequently, for every PVC, an individual group of packets containing the SAP update must be sent each time So, assuming your SAP updates take 500KB every 60 seconds, then you are using 2500KB of your T1 simply for SAP updates every 60 seconds

Figure 7-5: SAP broadcasts across a WAN link But wait, it gets worse The other routers on the far side of the PVCs are also broadcasting the same 500KB SAP table every 60 seconds This makes the total used bandwidth 5000KB every 60 seconds Converting this to kilobits, 40,000Kb are being used every 60 seconds for every minute of time, a full 26 seconds of bandwidth is eaten up by SAP updates Admittedly, this example is a bit extreme, but it illustrates the problem Fortunately, some solutions exist The first solution is to use TCP/IP (OK, that was a joke) Seriously, Cisco routers can filter SAP updates across WAN links Therefore, you can choose not to send certain updates over the WAN link, thus reducing the bandwidth You do this by using access list statements (covered in more detail in 27) The trade-off for this solution, however, is the possibility of being unable to locate the required resources Another solution is to disable triggered updates and increase the time between SAP broadcasts to a more reasonable level The trade-off for this solution, however, is slower convergence In other words, it will take the servers much longer to build a complete list of resources or to recognize that a resource has failed Can't have your cake and eat it, too Overall, however, despite their problems, SAP and GNS are integral parts of IPX/ SPX and perform some of the most important functions in the suite

Remote Procedure Call (RPC) is a function most protocol suites use in one form or another RPC allows one device on a network to use a program or service on another device without needing to know the specifics involved with the application (such as directory structures and path statements) on the other device The RPC client simply uses variables (procedure calls) in an RPC message to the RPC server describing what it wants to do The server performs the requested action and submits the result back to the client This process allows a lot of modularity and minimal programming effort for developers They simply make use of the network functions that RPC provides rather than rewriting the book themselves This advantage has made RPC one of the most widely used protocols in most OSs (although other

protocols, such as Distributed Component Object Model (DCOM), are gaining a rapid foothold as well)