Using Fast Select

The use of fast select in X.25 is described in X.25: The PSN Connection. This section describes how to access this Facility through X.25.

The fast select Facility allows processes to specify up to 128 bytes of call user data in the CALL REQUEST, CALL ACCEPTED, and CLEAR REQUEST packets. Usually, only 16 bytes are permitted in the CALL REQUEST packet and no user data in the CALL ACCEPTED and CLEAR REQUEST packets. This Facility is called "fast" because it allows programmers to specify user data in the same packet which is requesting or acknowledging a connection request. Usually, the CALL REQUEST packet contains all of the information the server side needs to service the request, and it terminates the connection and places all the information that the client needs regarding the results of its request in the CLEAR REQUEST packet. The circuit is never fully set up, but is then quickly torn down, hence the term "fast select".

The ioctl() calls used for fast select are listed below:

X25_WR_USER_DATA (for writing extended call user data).
X25_RD_USER_DATA (for reading extended call user data).
X25_WR_FACILITIES (for writing Facilities).
X25_RD_FACILITIES (for reading Facilities).

A summary of the steps needed to enable fast select on the calling and receiving side of a connection appears in the next two subsections.

Fast Select on the Calling Side

To implement fast select on the calling side, issue the ioctl(X25_WR_FACILITIES) call with the fast select Facilities code defined in CCITT X.25 recommendations. Specify the call user data for the packet with the ioctl(X25_WR_USER_DATA). These calls must be executed before issuing the connect() call.

If the calling side is using protocol IDs for address matching, the protocol ID must be specified in the call user data field before any other call user data is added with the ioctl(X25_WR_USER_DATA) call. These data may be specified in separate ioctl() calls, or combined into one, but the protocol ID must come first. Remember that the protocol ID length is not defined by the CCITT. Programmers of the two processes must agree on the number of bits of the call user data field to use for the protocol ID before connection establishment begins.

When the Facilities and call user data fields have been specified for the fast select call, the calling side issues a connection request with connect() and waits for the response from the remote server.

Fast Select on the Called Side

The called side may respond in three ways:

If not accepting fast select calls, the called side will return a CLEAR REQUEST packet with no data.
If accepting fast select calls, the called side may execute an ioctl(X25_WR_USER_DATA) call to send data back to the calling side, then return a CLEAR REQUEST packet with data by executing a close() call. The called side can also return a call accept (with data) by executing ioctl(x25_SEND_CALL ACCEPT). The called side may return clear-user data or call user data to the calling side only if the called side is controlling call acceptance with ioctl(X25_CALL_ACPT_APPROVAL).
If fast select was indicated in the Facilities field with no restrictions on response, the called side may simply accept the call, and read the call user data with the ioctl(X25_RD_USER_DATA). The connection is then considered an ordinary virtual circuit; that is, fast select is no longer in effect.

The maximum length for the user data field in the CLEAR REQUEST packet is 128 bytes. The server may execute the ioctl(X25_WR_USER_DATA) more than once to write the entire user data field. If more than 128 bytes must be transmitted, the called side (server) of the connection should respond with a CALL ACCEPTED packet and transmit the entire response with normal DATA packets, or the called side must simply clear the connection completely by calling close().

Details regarding fast select are defined in the CCITT X.25 Recommendations, and X.25 configuration information is presented in your X.25/9000 User's Guide.

Fast Select Operation Summary

A server can respond to a fast select call in any of three ways:

The call can be cleared immediately with no data
The call can be cleared with user data specified
A normal SVC can be established with or without user data specified in the call accept packet

Which of these alternatives are available depends on the design of the client and server processes.

This section is written with the assumption that interfaces for both the client and the server are configured to permit fast select, and the network provider allows fast select.

The actions to be taken are shown in the three scenarios below. The initial steps for sending and receiving fast select is the same for all scenarios. These initial steps are shown in Table 6-1 “Steps for Fast Select”. Depending on the design of the application, the server may take any of three actions that are described later.

Initial Steps for Fast Select

The initial steps performed by the client and server when configured to permit fast select are described below and shown in Table 6-1 “Steps for Fast Select” on the following page.

The server creates an AF_CCITT listen socket.
The server binds an x25addrstr structure containing the addressing information.
The server establishes a listen queue.
The server prepares the call to control call acceptance.
The server listens for a CALL REQUEST packet.
The client creates an AF_CCITT socket.
The client specifies the fast select Facility for the CALL REQUEST packet.
The client specifies the call user data for the CALL REQUEST packet.
The client sends the CALL REQUEST packet.
The server's accept() call unblocks when it receives the CALL INDICATION packet.
The server reads and parses the Facilities field.
The server reads and interprets the user data field.

Table 6-1 Steps for Fast Select

Server Events	X.25 Events	Client Events
1. `socket()`	No Event	No Event
2. `bind()`	No Event	No Event
3. `ioctl(X25_CALL_ACPT_APPROVAL)`	No Event	No Event
4. `listen()`	No Event	No Event
5. `accept()` blocks	No Event	No Event
6. No Event	No Event	`socket()`
7. No Event	No Event	`ioctl(X25_WR_FAC ILITIES)`
8. No Event	No Event	`ioctl(X25_WR_USE R_DATA)`
9. No Event	CALL REQUEST packet transmit ted	`connect()` blocks
10. `accept()` unblocks	CALL INDICATION packet received	No Event
11. `ioctl(X25_RD_FACILITIES)`	No Event	No Event
12. `ioctl(X25_RD_USER_DATA)`	No Event	No Event

After the above steps have been done, the server has the information it needs to process the fast select. Three actions are possible. They are discussed individually in the next three subsections.

Clearing a Fast Select Call Immediately

If the server detects that it cannot handle the fast select call for any reason, it can clear the circuit immediately. Steps for this are described below and in Table 6-2 “Clearing a Fast Select Call Immediately”. Steps shown in Table 6-1 “Steps for Fast Select” are assumed to have already occurred.

The server transmits the CLEAR REQUEST packet.
The client receives the CLEAR INDICATION packet and takes appropriate actions.

Table 6-2 Clearing a Fast Select Call Immediately

Server Events	X.25 Events	`Client Events`
1. `close()`	CLEAR REQUEST packet transmitted	No Event
2. No Event	CLEAR INDICATION packed received	`connect()` returns -1 (ECONNREFUSED)

Transmitting a CLEAR Packet with User Data

The server can respond to a fast select call by sending a CLEAR REQUEST packet that contains a user data field. Steps for this are described below and shown in Table 6-3 “Sending Clear User Data for a Fast Select”. Steps shown in Table 6-1 “Steps for Fast Select” are assumed to have already occurred.

The server writes the user data field with information appropriate to respond to the fast select call.
The server transmits the CLEAR REQUEST packet.
The client receives the CLEAR INDICATION packet and takes appropriate actions.

Table 6-3 Sending Clear User Data for a Fast Select

Server Events	X.25 Events	Client Events
1. ioctl(X25_WR_USER_DATA)	No Event	No Event
2. `close()`	CLEAR REQUEST packet transmit ted	No Event
3. No Event	CLEAR INDICATION packed received	`connect()` returns -1`(ECONNREFUSED)`

Establishing an SVC in Response to a Fast Select Call

The server can establish an SVC in response to a fast select call. Steps for this are described below and in Table 6-4 “Fast Select Connection Establishment”. Steps shown in Table 6-1 “Steps for Fast Select” are assumed to have already occurred. The fast select Facility must be set for no restrictions on response for this option to be used.

The server optionally writes the user data field with information appropriate to indicate the reason for its response to the fast select call.
The server transmits the CALL ACCEPTED packet.
The client receives the CALL CONNECTED packet.
Both the server and client have the option to write user data and carry on normal SVC data transmission with DATA packets.
The connection is closed by the client or server (see “Terminating a Connection”).

Table 6-4 Fast Select Connection Establishment

Server Events	X.25 Events	Client Events
1. `ioctl(X25_WR_USER_DATA`)	No Event	No Event
2. `ioctl(X25_SEND_CALL_ACPT)`	CALL ACCEPTED packet transmitted	No Event
3. No Event	CALL INDICATION packet received	`connect()` unblocks (returns 0)
4. `read()` and `write()`	DATA packets transmitted and received	`read()` and `write()`
5. `close()`	CLEAR REQUEST/INDICATION packet transmit ted and received	`close()`