DLPI Primitives
DLPI States
•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.
142 | Chapter 2 |