3.3.3 Dealing with Resets and Interrupts

Resets and Interrupts are dealt with in a similar way, except that there is no data passed with a Reset Request. When a Reset Request or Interrupt is issued, the application must wait for the acknowledgment, as for an expedited request. However, until this is received, the only action that can be taken is to issue a Disconnect Request.

The diagnostic field in a Reset Request or Interrupt contains the reason for issuing the reset. Standard values for this are defined in the include file <netx25/x25_proto.h>, although the application can set any value. See Chapter 9, Error Codes for more details.

When a Reset Indication is received, there are only two valid actions that may be taken:

• send a Reset Confirmation message to acknowledge the reset

• send a Disconnect Request

In either case, pending data is flushed from the queue.

Reset Indications can be dealt with as part of the general processing of incoming messages, as shown in the following disconnect handling example.

#include<netx25/x25_proto.h>
 struct xrstf rst;
 S_X25_HDR *hdrptr;
 rst.xl_type= XL_CTL;
 rst.xl_command= N_RI;
 rst.cause= 0;
 rst.diag= NU_RESYNC;
 ctlblk.len= sizeof (struct rstf);
 ctlblk.buf= (char *) &rst;
 if (putmsg(x25_fd, &ctlblk, 0, 0) < 0) {
 	perror(" putnmsg");
 	exit(1);
 	}
 	for (;;) {
 		if (getmsg(x25_fd, &ctlblk, &datblk, &getflags) < 0) {
 			perror("Getmsg fail");
 			exit(1);
 			}
 		hdrptr = (S_X25_HDR *) ctlbuf;
 		if (hdrptr->xl_type == XL_CTL) {
 			continue;
 			}
 		switch (hdrptr->xl_command) {
 			case N_RC:  /* Reset complete */
 /* Enter data transfer */
 				break;
 			default:
 				break;
 			}  /* end switch */
 		} /* end for */

Control messages, like resets and interrupts, take higher priority than normal data messages, both internally in the PLP driver, and across the network.

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.