DLPI States

Table 2-1 “DLPI States” describes the states associated with DLPI. It presents the state name used in the state transition table, the corresponding DLPI state name used throughout this specification, a brief description of the state, and an indication of whether the state is valid for connection-oriented data link service (DL_CODLS), connectionless data link service (DL_CLDLS), acknowledged connectionless data link service (ACLDLS) or all.

Table 2-1 DLPI States

State	DLPI State	Description	Service Type
0) UNATTACHED	DL_UNATTACHED	Stream opened but PPA not attached	ALL
1) ATTACH PEND	DL_ATTACH_ PENDING	The DLS user is waiting for an acknowledgment of a DL_ATTACH_REQ	ALL
2) DETACH PEND	DL_DETACH_ PENDING	The DLS user is waiting for an acknowledgment of a DL_DETACH_REQ	ALL
3) UNBOUND	DL_UNBOUND	Stream is attached but not bound to a DLSAP	ALL
4) BIND PEND	DL_BIND_PENDING	The DLS user is waiting for an acknowledgment of a DL_BIND_REQ	ALL
5) UNBIND PEND	DL_UNBIND_ PENDING	The DLS user is waiting for an acknowledgment of a DL_UNBIND_REQ	ALL
6) IDLE	DL_IDLE	The stream is bound and activated for use - connection establishment or connectionless data transfer may take place	ALL
7) UDQOS PEND	DL_UDQOS_ PENDING	The DLS user is waiting for an acknowledgment of a DL_UDQOS_REQ	DL_CLDLS
8) OUTCON PEND	DL_OUTCON_ PENDING	An outgoing connection is pending - the DLS user is waiting for a DL_CONNECT_CON	DL_CODLS
9) INCON PEND	DL_INCON_ PENDING	An incoming connection is pending - the DLS provider is waiting for a DL_CONNECT_RES	DL_CODLS
10) CONN_RES PEND	DL_CONN_RES_ PENDING	The DLS user is waiting for an acknowledgment of a DL_CONNECT_RES	DL_CODLS
11) DATAXFER	DL_DATAXFER	Connection-mode data transfer may take place	DL_CODLS
12) USER RESET PEND	DL_USER_RESET_ PENDING	A user-initiated reset is pending - the DLS user is waiting for a DL_RESET_CON	DL_CODLS
13) PROV RESET PEND	DL_PROV_RESET_ PENDING	A provider-initiated reset is pending - the DLS provider is waiting for a DL_RESET_RES	DL_CODLS
14) RESET_RES PEND	DL_RESET_RES_ PENDING	The DLS user is waiting for an acknowledgment of a DL_RESET_RES	DL_CODLS
15) DISCON 8 PEND	DL_DISCON8_ ENDING	The DLS user is waiting for an acknowledgment of a DL_DISCONNECT_REQ issued from the DL_OUTCON_PENDING state	DL_CODLS
16) DISCON 9 PEND	DL_DISCON9_ PENDING	The DLS user is waiting for an acknowledgement of a DL_DISCONNECT_REQ Issued from the DL_INCON_PENDING state.	DL_CODLS
17) DISCON 11 PEND	DL_DISCON11_ PENDING	The DLS user is waiting for an acknowledgment of a DL_DISCONNECT_REQ issued from the DL_DATAXFER state	DL_CODLS
18) DISCON 12 PEND	DL_DISCON12_ PENDING	The DLS user is waiting for an acknowledgment of a DL_DISCONNECT_REQ issued from the DL_USER_RESET_ PENDING state	DL_CODLS
19) DISCON 13 PEND	DL_DISCON13_ PENDING	The DLS user is waiting for an acknowledgment of a DL_DISCONNECT_REQ issued from the DL_PROV_RESET_ PENDING state	DL_CODLS
20) SUBS_BIND PEND	DL_SUBS_BIND_ PND	The DLS user is waiting for an acknowledgment of a DL_SUBS_BIND_REQ	ALL
21) SUBS_ UNBIND PEND	DL_SUBS_UNBIND_PND	The DLS user is waiting for an acknowledgment of a DL_SUBS_UNBIND_REQ	ALL

The following rules apply to the maintenance of DLPI state:

The DLS provider is responsible for keeping a record of the state of the interface as viewed by the DLS user, to be returned in the DL_INFO_ACK.
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 connection-mode service, the value of the outcnt state variable must be initialized to zero for each stream when that stream is first opened.
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.
A DL_DATA_REQ primitive received by the DLS provider in the state DL_PROV_RESET_PENDING (i.e. after a DL_RESET_IND has been passed to the DLS user) or the state DL_IDLE (i.e. after a data link connection has been released) should be discarded by the DLS provider.
A DL_DATA_IND primitive received by the DLS user after the user has issued a DL_RESET_REQ should be discarded.

To ensure accurate processing of DLPI primitives, the DLS provider must adhere to the following rules concerning the receipt and generation of STREAMS M_FLUSH messages during various state transitions.

The DLS provider must be ready to receive M_FLUSH messages from upstream and flush its queues as specified in the message.
The DLS provider must issue an M_FLUSH message upstream to flush both the read and write queues after receiving a successful DL_UNBIND_REQ primitive but before issuing the DL_OK_ACK.
If an incoming disconnect occurs when the interface is in the DL_DATAXFER, DL_USER_RESET_PENDING, or DL_PROV_RESET_PENDING state, the DLS provider must send up an M_FLUSH message to flush both the read and write queues before sending up a DL_DISCONNECT_IND.
If a DL_DISCONNECT_REQ is issued in the DL_DATAXFER, DL_USER_RESET_PENDING, or DL_PROV_RESET_PENDING states, the DLS provider must issue an M_FLUSH message upstream to flush both the read and write queues after receiving the successful DL_DISCONNECT_REQ but before issuing the DL_OK_ACK.
If a reset occurs when the interface is in the DL_DATAXFER or DL_USER_RESET_PENDING state, the DLS provider must send up an M_FLUSH message to flush both the read and write queues before sending up a DL_RESET_IND or DL_RESET_CON.

DLPI States

Technical documentation

» Table of Contents

» Glossary

» Index