NAME

DL_DATA_REQ - conveys a complete DLSDU from the DLS user to the DLS provider for transmission over the data link connection.

The DLS provider guarantees to deliver each DLSDU to the remote DLS user in the same order as received from the local DLS user. If the DLS provider detects unrecoverable data loss during data transfer, this may be indicated to the DLS user by a DL_RESET_IND, or by a DL_DISCONNECT_IND (if the connection is lost).

SYNOPSIS

The message consists of one or more M_DATA message blocks containing at least one byte of data.

To simplify support of a read/write interface to the data link layer, the DLS provider must recognize and process messages that consist of one or more M_DATA message blocks with no preceding M_PROTO message block. This message type may originate from the write() system call¹.

STATE

The message is valid in state DL_DATAXFER. If it is received in state DL_IDLE or DL_PROV_RESET_PENDING, it should be discarded without generating an error.

NEW STATE

The resulting state is unchanged.

RESPONSE

If the request is valid, no response is generated. If the request is erroneous, a STREAMS M_ERROR message should be issued to the DLS user specifying an errno value of EPROTO. This action should be interpreted as a fatal, unrecoverable, protocol error. A request is considered erroneous under the following conditions:

• The primitive was issued from an invalid state. If the request is issued in state DL_IDLE or DL_PROV_RESET_PENDING, however, it is silently discarded with no fatal error generated.

• The amount of data in the current DLSDU is not within the DLS provider's acceptable bounds as specified by dl_min_sdu and dl_max_sdu in the DL_INFO_ACK.

NOTE

Support of Direct User-Level Access

A STREAMS module would implement "more" field processing itself to support direct user-level access. This module could collect messages and send them in one larger message to the DLS provider, or break large DLSDUs passed to the DLS user into smaller messages. The module would only be pushed if the DLS user was a user-level process.

Footnotes

1.

This does not imply that DLPI will directly support a pure read/write. If such an interface is desired, a STREAMS module could be implemented to be pushed above the DLS provider.