Sequenced Packet Exchange (SPX)

Sequenced Packet Exchange (SPX)

Novell developed SPX as a Transport layer protocol to provide end-to-end data transport and to add reliability to IPX deliveries within NetWare networks. In designing SPX, Novell used the Xerox Packet Protocol (XPP) as the foundation for this protocol. The SPX layer (layer 4) sits on top of the IPX layer (layer 3) to provide connection-oriented services between two nodes on the network. SPX and SAP are the two most important protocols that operate in the Transport layer.

Client/server applications, such as print servers, are the primary users of SPX. Most communications on a network, such as workstation connections and the NetWare print server and Remote Console (RCONSOLE), use the SPX protocol.

SPX Packet Communications

SPX is concerned with addressing, segment development (division and combination), and connection services (segment sequencing, error control, and end-to-end flow control). SPX provides guaranteed packet delivery and delivers the packets in their proper sequence by locating the SPX message within the IPX packet, and then transporting it using the IPX datagram delivery service.

When a user or resource on the network sends a transmission, SPX first sends a control packet to establish a connection, and then associates a connection ID for that virtual circuit. After the packet transmission, SPX requests verification from the destination that it received the data. The packet destination must correctly acknowledge receipt of the packet(s). If an acknowledgment request brings no response within a specified time, SPX retransmits the packet. After a reasonable number of retransmissions fail to return a receipt acknowledgment, SPX assumes that the connection has failed and warns the operator of the failure.

If SPX determines that packets were lost en route, SPX resends lost packets and uses the sequencing numbers to ensure that the packets arrive in the proper order without duplication. SPX uses a timeout algorithm to decide when it should retransmit a packet. SPX dynamically adjusts the timeout based on the delay experienced in packet transmission. If a packet times out too early, SPX increases its value by 50%. This process can continue until it reaches a maximum timeout value or the timeout value stabilizes. To verify that a session is still active when there is no data activity, SPX sends probe packets to verify the connection.

The number of available listen buffers determines and provides the flow control. SPX can send messages in a given direction only until the number of unacknowledged messages is equal to the number of listen buffers available on the receiving side. As the number of buffers varies, SPX is able to also vary the number of messages that it will send before receiving an acknowledgment. This ensures that the incoming data does not arrive too rapidly and thus overrun the destination node buffers.

If the destination source acknowledges receipt of the packet, the SPX verification must include a value that matches the value calculated from the data before transmission. By comparing these values, SPX ensures not only that the data packet arrived at the destination, but also that it arrived intact. The values include the sequencing numbers of the packet, which the receiving side uses to check for missing, duplicate, or out-of-sequence messages. If the recipient received the packets successfully, it acknowledges by returning the next expected sequence number in the Acknowledgment Number field of a message that is sent back to the sender. At the end of data transmission, SPX sends an explicit control packet to break the connection.

One disadvantage of using a connection-oriented protocol such as SPX is in the handling of broadcast packets. In this instance, the protocol must establish a connection with every destination before it can send the packet, which can amount to a time- and resource-consuming process. To avoid this situation, you can use higher-level NetWare protocols, such as NCP, to bypass SPX and communicate with IPX.

SPX Packet Structure

Although SPX guarantees delivery of every packet it sends, it is slower than IPX alone. This is because the SPX header includes the IPX header and adds an additional 12 bytes of sequencing, flow control, connection, and acknowledgment information.

SPX packets contain the same header fields that IPX packets contain, but add a 12-byte SPX header in the Data field at the end of the header. The SPX header can contain at the most 534 bytes of data, whereas the normal IPX packet format allows 576 bytes. Table 32.4 outlines the packet structure for an SPX packet header.

Table 32.4. SPX Packet Structure

Sequenced Packet Exchange II (SPXII)

Novell 4.0 and later includes SPXII as a backward-compatible enhancement to SPX, and features a true sliding-window flow-control mechanism. With this mechanism, the sender and receiver can initially negotiate in the window without receiving any acknowledgments. Each sent packet decreases the window, and each acknowledged packet increases the window. In this way, the receiver can acknowledge groups of packets simultaneously .

Note The concept of sliding windows is not specific to SPX. TCP/IP has included this concept from the earliest days to allow for delayed acknowledgments so that multiple network packets can be sent before an acknowledgment is received. Using a slow-start algorithm, TCP/IP can begin to scale up the communications link to allow for more unacknowledged packets, depending on the quality of the network link. When congestion or other network problems result in dropped network packets, TCP/IP can adjust and slow down the transmission and later begin to increase the "sliding window."

SPXII also improves the negative acknowledgment (NAK) capability. A NAK speeds up the recovery process by allowing the sender to retransmit missing or erroneous packets immediately instead of waiting until the end of the transmission. In addition, SPXII does away with the 576-byte limitation and allows for a packet size as large as is supported on a system. SPXII also provides new option-management functions such as permitting the application to negotiate network transport options and allowing for future expansion for the protocol.