For each precedence table, the rows (labeled "PRIM X") correspond to primitives that are on the given queue and the columns (labeled "PRIM Y") correspond to primitives that are about to be placed on that queue. Each pair of primitives (PRIM X, PRIM Y) may be manipulated resulting in:
The precedence rules define the allowed manipulations of a pair of DLPI primitives. Whether these actions are performed is the choice of the DLS provider for user-originated primitives and the choice of the DLS user for provider-originated primitives.
For connection establishment primitives, this table represents the possible pairs of DLPI primitives when connect indications/responses are single-threaded. For the multi-threading scenario, the following rules apply:
PRIM Y | P1 | P2 | P3 | P4 | P5 | P6 | P7 | P8 | P9 | P10 | P11 | P12 | P13 | P14 | P15 |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
PRIM X (on queue) | |||||||||||||||
P1 DL_INFO_REQ | |||||||||||||||
P2 DL_ATTACH_REQ | |||||||||||||||
P3 DL_DETACH_REQ | |||||||||||||||
P4 DL_BIND_REQ | |||||||||||||||
P5 DL_UNBIND_REQ | |||||||||||||||
P6 DL_UNITDATA_REQ | 1 | ||||||||||||||
P7 DL_UDQOS_REQ | |||||||||||||||
P8 DL_CONNECT_REQ | 4 | ||||||||||||||
P9 DL_CONNECT_RES | 3 | 1 | 1 | ||||||||||||
P10 DL_TOKEN_REQ | |||||||||||||||
P11 DL_DISCONNECT_REQ | 1 | ||||||||||||||
P12 DL_DATA_REQ | 5 | 1 | 3 | 3 | |||||||||||
P13 DL_RESET_REQ | 3 | ||||||||||||||
P14 DL_RESET_RES | 3 | 1 | 1 | ||||||||||||
P15 DL_SUBS_BIND_REQ |
KEY:- | |
---|---|
Code | |
"blank" | Empty box indicates a scenario which cannot take place. |
1 | Y has no precedence over X and should be placed on queue behind X. |
2 | Y has precedence over X and may advance ahead of X. |
3 | Y has precedence over X and X must be removed. |
4 | Y has precedence over X and both X and Y must be removed. |
5 | Y may have precedence over X (DLS provider's choice) - if so X must be removed. |
For connection establishment primitives, this table represents the possible pairs of DLPI primitives when connect indications/responses are single-threaded. For the multi-threading scenario, the following rules apply:
If the DLS user is a user-level process, it's read queue is the stream head read queue. Because a user process has no control over the placement of DLS primitives on the stream head read queue, a DLS user cannot straightforwardly initiate the actions specified in the following precedence table. Except for the connection establishment scenario, the DLS user can ignore the precedence rules defined in the table below. This is equivalent to saying the DLS user's read queue contains at most one primitive.
The only exception to this rule is the processing of connect indication/response primitives. A problem arises if a user issues a DL_CONNECT_RES primitive when a DL_DISCONNECT_IND is on the stream head read queue. The DLS provider will not be expecting the connect response because it has forwarded the disconnect indication to the DLS user and is in the DL_IDLE state. It will therefore generate an error upon seeing the DL_CONNECT_RES.To avoid this error, the DLS user should not respond to a DL_CONNECT_IND primitive if the stream head read queue is not empty. The assumption here is a non-empty queue may be holding a disconnect indication that is associated with the connect indication that is being processed.
When connect indications/responses are single-threaded, a non-empty read queue can only contain a DL_DISCONNECT_IND, which must be associated with the outstanding DL_CONNECT_IND. This DL_DISCONNECT_IND primitive indicates to the DLS user that the DL_CONNECT_IND is to be removed. The DLS user should not issue a response to the DL_CONNECT_IND if a DL_DISCONNECT_IND is received.
The multi-threaded scenario is slightly more complex, because multiple DL_CONNECT_IND and DL_DISCONNECT_IND primitives may be interspersed on the stream head read queue. In this scenario, the DLS user should retrieve all indications on the queue before responding to a given connect indication.
If a queued primitive is a DL_CONNECT_IND, it should be stored by the user process for eventual response. If a queued primitive is a DL_DISCONNECT_IND, it should be matched (using the correlation number) against any stored connect indications. The matched connect indication should then be removed, just as is done in the single-threaded scenario.
PRIM Y | P1 | P2 | P3 | P4 | P5 | P6 | P7 | P8 | P9 | P10 | P11 | P12 | P13 | P14 |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
PRIM X (on queue) | ||||||||||||||
P1 DL_INFO_ACK | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | ||||||
P2 DL_BIND_ACK | 1 | 1 | ||||||||||||
P3 DL_UNITDATA_IND | 2 | 1 | 2 | 2 | 2 | |||||||||
P4 DL_UDERROR_IND | 2 | 1 | 1 | 2 | 2 | |||||||||
P5 DL_CONNECT_IND | 2 | 2 | 4 | |||||||||||
P6 DL_CONNECT_CON | 2 | 2 | 3 | 1 | 1 | |||||||||
P7 DL_TOKEN_ACK | 1 | 1 | 1 | 1 | 1 | 1 | ||||||||
P8 DL_DISCONNECT_IND | 2 | 1 | 2 | 2 | ||||||||||
P9 DL_DATA_IND | 2 | 2 | 5 | 1 | 3 | 3 | 2 | |||||||
P10 DL_RESET_IND | 2 | 2 | 3 | 2 | ||||||||||
P11 DL_RESET_CON | 2 | 2 | 3 | 1 | 1 | 2 | ||||||||
P12 DL_OK_ACK | 1 | 1 | 1 | 1 | 1 | 1 | ||||||||
P13 DL_ERROR_ACK | 1 | 1 | 1 | 1 | 1 | 1 | 1 | |||||||
P14 DL_SUBS_BIND_ACK | 1 | 1 |
KEY:- | |
---|---|
Code | |
"blank" | Empty box indicates a scenario which cannot take place. |
1 | Y has no precedence over X and should be placed on queue behind X. |
2 | Y has precedence over X and may advance ahead of X. |
3 | Y has precedence over X and X must be removed. |
4 | Y has precedence over X and both X and Y must be removed. |
5 | Y may have precedence over X (DLS provider's choice) - if so X must be removed. |
Contents | Next section | Index |