- Contact Us
NPI M-bit and D-bit Processing
The Gcom® NPI STREAMS driver serves as the interface between the user's application program and the X.25, SNA and Bisync protocols. This interface is mediated by the Gcom NPI API library. Of the messages exchanged between the API Library and the NPI driver some of message types are used to communicate payload data. The NPI interface protocol makes provision for the case in which the user's message may be larger than the negotiated packet size at the protocol level.
This document describes how this case is treated in Gcom's NPI driver. The document is relative to Gcom software release 1.51 or later.
The NPI message types and DATA_xfer_flags values are defined in the file <gcom/npi.h>. The NPI API functions and constants are defined in the file <gcom/npiapi.h>.
The NPI driver makes no attempt to consolidate incoming packets into larger messages for the user. If an incoming packet has neither the M-bit nor the D-bit set it is forwarded upstream to the user as a simple M_DATA STREAMS message.
If the incoming packet has either the M-bit or D-bit set it is forwarded upstream to the user as an M_PROTO STREAMS message containing an NPI N_DATA_IND message with the payload data attached in an M_DATA STREAMS message. In the NPI N_DATA_IND header, the DATA_xfer_flags field has the N_MORE_DATA_FLAG set if the incoming packet had the M-bit set. It has the N_RC_FLAG set if the incoming packet had the D-bit set.
When receiving such data using the npi_rcv API function the "flags out" parameter will be set to NPIAPI_MORE_DATA and/or NPIAPI_RC_FLAG corresponding to the flags present in the N_DATA_IND header.
Thus, the user's application has the full responsibility of concatenating partial messages into complete messages according to the "more data" indications.
The user application can write messages to NPI that are larger than the negotiated packet size of the underlying connection. NPI breaks these messages into packet sized segments and sets the "M-bit" according to a set of rules. The individual protocols treat these "M-bit" packets according to the dictates of the specifications for the protocol involved.
The appliation program will typically use the NPI API function npi_put_data_proto and pass some value for the "flags" argument. This argument can be zero, which results in a simple M_DATA STREAMS message being sent to NPI. If it is non-zero it can have the logical "or" of the values N_MORE_DATA_FLAG and N_RC_FLAG. This case leads to an M_PROTO STREAMS message with an attached M_DATA being sent to NPI. The M_PROTO will contain an N_DATA_REQ message with the DATA_xfer_flags field set to the "flags" argument passed to npi_put_data_proto.
The treatment of out bound messages by NPI breaks down into the following cases.
The packets that NPI forwards to the protocol module are subject to protocol level flow control. This means that it may take some time to "packetize" a long out bound message since it may be necessary to await protocol level acknowledgements from the remote peer protocol process.
In general, messages with the N_MORE_DATA_FLAG set are subject to delay in the NPI module pending further data to concatenate to fill a packet. It is unwise for an application to set the N_MORE_DATA_FLAG unless it intends to supply more data in a timely manner.
Gcom's NPI driver will allow the use of the N_RC_FLAG in an N_DATA_REQ message whether or not the connection was established using the receipt confirmation option. If the RC option was not specified then the acknowledgement via N_DATACK_IND will have local significance only and will occur when the remote protocol peer (X.25 or Bisync) acknowledges the data packet. The data packet itself will not carry the D-bit when it is transmitted. Note that without the RC option, some X.25 networks implement end-to-end acknowledgements anyway, and others use local DTE/DCE acknowledgements only.
If the connection is set up with the receipt confirmation option set then the X.25 data packet will have the D-bit set and the N_DATACK_IND should therefore have end-to-end significance.
In order to establish a connection with the receipt confirmation option set, the application program issues an outgoing connection using one of the variations of the API routine npi_connect, it must first assign the value REC_CONF_OPT (defined in <gcom/npi.h>) to the global variable npi_connect_flags (defined in <gcom/npiapi.h>).
The same global variable must be set when listening for incoming connections to enable this feature if it is requested by the incoming connection. If the npi_connect_flags variable is set and an incoming connection does not request receipt confirmation then the feature will not be enabled for the connection.
The N_MORE_DATA_FLAG and the N_RC_FLAG map directly into the M-bit and D-bit of X.25. X.25 rules state that packets with the M-bit set must either be full packets or also have the D-bit set. This is why NPI saves up M-bit packets for consolidation.
In SNA one uses the SNA API rather than the NPI API to interface one's application. Considerations of "more data" at the NPI API level are not germane to an SNA application. The SNA API has its own methods and rules for segmenting data.
In Bisync the N_RC_FLAG has meaning only between the application and the NPI driver as described above. The N_MORE_DATA_FLAG will cause the Bisync block to be terminated with an ETB rather than an ETX.