|
|
The SPX driver is a STREAMS driver. Its general characteristics are described below.
The SPX driver checks the state of the transport endpoint when the state is relevant to the action it is to perform. For example, a listen/connect request cannot be performed without a bind, and data cannot be sent without both a bind and a listen/connect request. However, a connection can be closed or unbound in any state.
An outstanding connection request is a connection request that has arrived and been delivered to the application, but to which the application has not yet responded with either a connection request acknowledge (t_accept) or connection request reject (t_snddis).
SPX allows up to a specified number of outstanding connection requests per transport endpoint (the number is the SPX_MAX_LISTENS_PER_SOCKET parameter in the spx_tune.h file). This parameter is currently set to 10. If the application requests more than 10, only 10 are given.
Although the SPX_MAX_LISTENS_PER_SOCKET parameter allows an application to have more than one outstanding connection request, it is recommended that there be only one. If a value greater than 1 is specified in the qlen field during a t_bind, a connection request can arrive from a remote transport endpoint, making the t_listen unblock. If another connection request arrives between the time the t_listen unblocks and the t_accept is issued, the t_accept fails, saying an event has occurred. You cannot call t_accept to accept the connection requests until all pending connection requests have been retrieved off the stream head using t_listen. A t_bind with qlen equal to 1 should be issued to avoid this problem.
If a local transport endpoint receives a disconnection request, the SPX driver sends a disconnection indication to the endpoint with reason set to TLI_SPX_CONNECTION_TERMINATED. SPX then changes the state of the stream to T_IDLE. All data that was queued for or in transit is lost, and the connection is broken.
The SPX watchdog wakes up every two minutes (this value is tunable) to check for dead connections. The SPX watchdog looks for two types of dead connections:
The SPX watchdog begins watching connections when the first device (excluding the NPSD) is opened. The SPX watchdog stops checking connections after the last SPX device is closed.
The system overhead for the SPX watchdog varies with the maximum number of connections, which is tunable. In the best case, it is the time SPX takes to check the maximum number of connection pointers against NULL. In the worst case, it is the time SPX takes to close down all the SPX connections because they have all frozen at the same time.
The SPX watchdog checks only the connections in the T_DATAXFER state.
SPX periodically awakens the watchdog. When the watchdog awakens, it checks how long each connection has been inactive. If a connection has been inactive for a specified time (the default is one minute), the watchdog sends the connection a watchdog packet.
A connection can remain open indefinitely if the remote transport endpoint always acknowledges SPX watchdog packets. This functionality is part of the definition of an SPX connection.
If an application cannot receive data as fast as the sender is sending it, the SPX driver (on the receiving side) acknowledges the last received packet, then queues up a readside-retry procedure that will try again. This time interval is tunable; the default is 0.5 seconds.
If SPX still cannot deliver packets on the second try, it increases the time interval for subsequent retries. It multiplies the previous retry time by 1.5. One of the following values is then used:
The maximum read retry time is tunable. By default, SPX retries five times before generating a disconnect indication with reason set to ENOSTR. This disconnect indication flushes the stream read and write queues before it reaches the stream head.
If the SPX driver is sending data faster than a remote transport endpoint can receive data, the SPX driver stops sending data. The driver then monitors the connection for one of the following conditions: