DLPI Primitives
DLPI States
•The DLS provider may never generate a primitive that places the interface out of state.
•If the DLS provider generates a STREAMS M_ERROR message upstream, it should free any further primitives processed by its write side put or service procedure.
•The close of a stream is considered an abortive action by the DLS user, and may be executed from any state. The DLS provider must issue appropriate indications to the remote DLS user when a close occurs. For example, if the DLPI state is DL_DATAXFER, a DL_DISCONNECT_IND should be sent to the remote DLS user. The DLS provider should free any resources associated with that stream and reset the stream to its unopened condition.
The following points clarify the state transition table.
•If the DLS provider supports
•The initial and final state for a style 2 DLS provider is
DL_UNATTACHED. However, because a style 1 DLS provider implicitly attaches a PPA to a stream when it is opened, the initial and final DLPI state for a style 1 provider is DL_UNBOUND. The DLS user should not issue DL_ATTACH_REQ or DL_DETACH_REQ primitives to a style 1 DLS provider.
•A DLS provider may have multiple connect indications outstanding (i.e. the DLS user has not responded to them) at one time. As the state transition table points out, the stream on which those indications are outstanding will remain in the DL_INCON_PENDING state until the DLS provider receives a response for all indications.
•The DLPI state associated with a given stream may be transferred to another stream only when the DL_CONNECT_RES primitive indicates this behavior. In this case, the responding stream (where the connection will be established) must be in the DL_IDLE state.
•The labeling of the states DL_PROV_RESET_PENDING and
DL_USER_RESET_PENDING indicate the party that started the local interaction, and does not necessarily indicate the originator of the reset procedure.
Chapter 2 | 141 |