3.3.3.1 Receiving a Remote Disconnect

If the remote end initiates a Disconnect, then a Disconnect Indication (N_DI) message (or possibly an N_Abort message, see "6.4.1 N_Abort--Abort Indication") is received at the NLI. The application need not acknowledge this message since, after sending a Disconnect, the X.25 driver silently discards all messages received except for connect and accept messages. These are the only meaningful X.25 messages on the stream after disconnection.

The receiver of a Disconnect Indication should ensure that enough room is available in the getmsg call to receive all parameters and, when present, up to 128 bytes of Clear User Data. Handling such a Disconnect event would normally be part of the general processing of incoming messages.

The following example could be combined with the code from the data transfer example in the previous section.

struct xdiscf *dis_msg;
 if (hdrptr->xl_type == XL_CTL) {
 	switch (hdrptr->xl_command) {
 /* Other events/indications dealt with 
   * here - e.g. Reset Indication (N_RI)
   */
 		case N_DI: 
 			dis_msg = (struct xdiscf *) hdrptr;
 			printf("Remote disconnect, cause = %x, diagnostic = %x \n",
 			dis_msg->cause, dis_msg->diag);
 /* Any other processing needed here - 
   * e.g. change connection state
   */
 			return;
 		case N_Abort:
 			printf("***Connection Aborted \n");  /* etc.  */
 			return;
 		default:
 			break;
 		}
 	} 

It is guaranteed that no X.25 interface messages are sent to the application once a disconnect message has been passed up to it, wherever the message came from.

Although at this stage the stream is idle, it is in an open state and remains so until some user action. This could be to close the stream, or to initiate a new Listen or Connect request on it.