IPX/SPX Configuration and Management Manual

Protocol Interfaces and Services for NonStop™
IPX/SPX
IPX/SPX Configuration and Management Manual—425731-001
A-12
IPXPROTO Process
IPXPROTO Process
The IPXPROTO process is implemented as a process pair. Because it relies on the
Queued Input/Output (QIO) subsystem, the IPXPROTO process pair is tied to the
location of the LAN controller. The IPXPROTO process must be configured on the
same processor pair as the ServerNet LAN systems access input/output process (SLSA
IOP). Whenever SLSA switches a processor, the IPXPROTO process also switches the
same processor. Since the IPXPROTO process cannot make a switch on its own, the
SCF SWITCH command is not supported. However, if SLSA is switched, the
IPXPROTO process follows.
The primary IPXPROTO process checkpoints the following information to its backup:
•
Configuration changes
•
Opens by application processes, except for NetWare application program interface
(API) opens
•
State of idle SPX connections (only when a switch occurs and no corruption of the
run-time environment is detected—for example, when the operator issues an SCF
SWITCH command)
IPXMGR Process
The only information that the IPXMGR process checkpoints is the identity of its
openers. When a switch occurs, the open is preserved but the application must retry any
request that was in progress at the time of the switchover.
The IPXMGR process can be run as a NonStop™ process pair. If the primary process
fails, the backup process can continue operating without interruption.
IPX Sockets
An IPX socket that has been opened by an application remains open across processor
switches. The state of the socket is checkpointed and preserved across switches. No
special recovery is required by the application after a switchover. Since the IPX protocol
only provides a best-effort delivery, the application or higher-level protocol must always
deal with potential packet losses.
SPX Sockets
An SPX socket that has been opened by an application remains open across processor
switches. If the switchover is unexpected (the switch occurs because corruption of the
run-time environment has been detected), the application receives an ECONNRESET
error on its next access. The only recovery action is to close and reopen the socket.
If the switchover is voluntary (for example, the operator issues an SCF SWITCH
command), the recovery depends upon whether the connection was idle (no pending
data) or not idle at the time of the switchover. If the connection was idle, there is no
impact on the application other than retrying from a possible FEOWNABORT error. If
the connection was not idle, the application gets an ECONNRESET error on its next
access. The only recovery action is to close and reopen the socket.