For Berkeley Sockets API users

This section describes improvements that X.25 Streams provide for Berkeley Sockets users. You should carefully read this information in order to fully anticipate the effects that upgrading to X.25 Streams will have on your Berkeley Sockets-based applications.

Improved Call Acceptance

The ioctl(X25_CALL_ACPT_APPROVAL) system call allows applications to screen incoming calls.

Table 2-1 Classic versus Streams

X.25 Classic	X.25 Streams
Call only allowed after the listen() call.	Call allowed before and after a listen() call.

By issuing the ioctl(X25_CALL_ACPT_APPROVAL) before a listen() call you can prevent calls arriving between the issuance of a listen() and the ioctl call from being automatically accepted.

Larger message size for applications

The ioctl(X25_SET_FRAGMENT_SIZE) system call allows you to define the maximum message size that your application can receive.

Table 2-2 Classic versus Streams

X.25 Classic	X.25 Streams
ioctl only allowed after the connect() or ioctl(X25_SEND_CALL_ACEPT) calls	ioctl allowed before or after the connect() or ioctl(X25_SEND_CALL_ACEPT) calls

This allows you to avoid receiving large, unwanted messages that may arrive between the issuance of a connect() (or ioctl(X25_SEND_CALL_ACEPT)) call and the issuance of the ioctl(X25_SET_FRAGMENT_SIZE) call.

Enhanced PVC management

The X.25 Streams product provides enhanced PVC management functions for the ioctl(X25_SETUP_PVC) call. The differences between X.25 Classic and X.25 Streams PVC management capabilities are summarized in the table below.

Table 2-3 Classic versus Streams

X.25 Classic

X.25 Streams

Sends a reset request at connection time (in both blocking and non-blocking modes).

When an application releases a PVC with the close() call no reset request is issued.

Does not send a reset request at connection time.

A reset request is automatically sent when the socket receives a close() call.

Since, in X.25 Streams, the ioctl(X25_SETUP_PVC) call does not use the reset mechanism, HP recommends that you use the ioctl(X25_RESET_VC) call immediately after the ioctl(X25_SETUP_PVC) call to ensure proper end-to-end PVC connection before data is sent.

Facilities management

Changes to the ioctl(X25_RD_FACILITIES) call

Read Facilities

In X.25 Streams, the ioctl(X25_RD_FACILITIES) call cannot be used to get default Facilities data because this information is automatically recovered by the ioctl(X25_WR_FACILITIES) call.

Table 2-4 Classic versus Streams

X.25 Classic	X.25 Streams
ioctl call used before connection to read default facilities data.	No need to use read ioctl call before a connection because default facilities are automatically retrieved by the ioctl(X25_WR_FACILITIES) call.

If your application attempts to implement the ioctl(X25_RD_FACILITIES) call before a connection is established, the system will return the error message:

errno 223 (EOPNOTSUPP)




	NOTE: If you want to specify additional Read Facilities (other than the default), you must append them as an argument to the ioctl(X25_WR_FACILITIES) call.

Window size

In X.25 Streams, when the Window Size facility is included in a call request packet, and the result of the negotiation is 430202 (default value), the call is accepted because this default value is automatically accepted.

You can specify the Window Size value by setting the flow control value in your X.25 configuration file to:

flowcontrol enabled

The default CCITT X.25 Window Size value 430202 represents:

43 — window size negotiation
02 — window size from the called DTE
02 — window size toward the called DTE

Closed User Group

With X.25 Streams, the Closed User Group (CUG) facility is always reported by the ioctl(X25_RD_FACILITIES) call as extended (hexadecimal 0x47), regardless of whether the actual configured default is extended or basic.

Table 2-5 Classic versus Streams

X.25 Classic	X.25 Streams
The CUG type can be extended or basic.	CUG type is always extended.

Transit Delay

With X.25 Streams, the Transit Delay Selection facility is not reported by the ioctl(X25_RD_FACILITIES) call when a call packet containing this facility is received by a called or calling application.

Table 2-6 Classic versus Streams

X.25 Classic	X.25 Streams
Transit Delay Selection reported.	Transit Delay Selection not reported.

End-to-End Transit Delay Selection

The End-to-End Transit Delay Selection facility contains 3 fields:

cumulative
requested
maximum acceptable End-to-End Transit Delay

In X.25 Streams, the ioctl(X25_RD_FACILITIES) system call reports the cumulative and the maximum acceptable End-to-End Transit Delay fields as specified in your default configuration (as in X.25 Classic). The requested field value, however, is always reported as 0xffff.

Table 2-7 Classic versus Streams

X.25 Classic	X.25 Streams
All field values returned with specified default values.	Requested field value always set to 0xffff.

Changes to throughput class negotiation facility

With X.25 Streams, the default throughput class values are not included with call requests when the calling application does not specify this value at connection time with the ioctl(X25_WR_FACILITIES) call.

Table 2-8 Classic versus Streams

X.25 Classic	X.25 Streams
Sends call request with default values for throughput class negotiation.	No throughput class facilities are included with call requests.

This will have no impact on users because the PDN (Public Data Network) automatically adds the default values that were specified at subscription time.

You specify whether throughput class negotiation is allowed or not with the neg_outthruputclass parameter in your X.25 configuration file. To allow throughput class negotiation, set the thruputclass flag to ON.

Out-of-Band event management

With X.25 Streams, the reason value for OOB_VC_CLEAR event signal is always 0 (zero) for both called and calling applications.

Table 2-9 Classic versus Streams

X.25 Classic	X.25 Streams
Reason could have two values: 2 = level 2 down, 0 = other	Reason is always 0 (zero).

Applications manage out-of-band events using a signal handler. When a VC is cleared, the signal handler sends the OOB_VC_CLEAR signal to the application. This signal contains three types of information:

cause — contained in the clear packet
diagnostic code — contained in the clear packet
reason — is always 0 (zero).

Recommendation

If you want to enable your application to determine that level 2 is down, use the ioctl(X25_GET_IFSTATE) system call instead.

Added security for socket binding

With X.25 Streams only one bind() call can be issued per socket. This stops multiple bind() calls from allowing a socket to receive more than one call from the same interface.

With X.25 Classic, two bind() calls can connect to the same socket if:

the first bind() call is set to receive all incoming calls from interface 0 with a PID value of 99,
AND
the second bind() call is set for the same interface but specifies no PID value.
Table 2-10 Classic versus Streams
X.25 Classic
X.25 Streams
Multiple bind() calls from the same interface can succeed in connecting to the same socket.
Only one call per socket per interface allowed.

Once a bind() call "binds" a socket to a particular interface, any additional bind() calls will return the error code: 227(EADDRNOTAVAIL).

Changes in connection management

With X.25 Streams, the connect() call sends outbound packets to the first initialized interface by default.

NOTE: The first initialized interface is the one that is first initialized when the sub-system is restarted after all cards are stopped.

Table 2-11 Classic versus Streams

X.25 Classic	X.25 Streams
Sends the call request packet to the interface that corresponds to x25_0.	Sends the call request packet to the first initialized interface.

New error codes

With X.25 Streams, illegal system calls return the error code:

errno 223 (EOPNOTSUP)

Table 2-12 Classic versus Streams

X.25 Classic	X.25 Streams
Illegal calls return `errno 22 (EINVAL)`.	Illegal calls return `errno 223 (EOPNOTSUP)`.

If the system call is legal but has an invalid argument, X.25 Streams returns the same value as X.25 Classic, i.e. errno 22 (EINVAL).

New restrictions for Network Facilities

In X.25 Streams calling applications can only send 32 bytes of called or calling Network Facilities data.

Network Facilities are specified just after the 0x0000, 0x000f or 0x00ff markers in the following packet types:

call request
call confirmation
clear request
clear confirmation

Table 2-13 Classic versus Streams

X.25 Classic	X.25 Streams
No limit for Network Facilities.	Limit of 32 bytes for Network Facilities.




	NOTE: The CCITT 1988 recommendation for the Network Facilities marker is 109 (less 2 for the marker).

Only CCITT facilities supported

X.25 Streams only supports recommendations specified in the CCITT 1988 and ISO 8208 standards.

The only facility markers allowed are 0x0000, 0x000f and 0x00ff.

Table 2-14 Classic versus Streams

X.25 Classic	X.25 Streams
Non-CCITT facilities supported.	Only CCITT 88 and ISO 8208 standards supported.

The ioctl(X25_WR_FACILITIES) system call will return errno 22 (EINVAL) if any facilities codes other than CCITT 88 and ISO8208 are used by your application.




	NOTE: Refer to the CCITT recommendations for more information on facilities markers.