 |
» |
|
|
|
Features | |
The following features of direct access to level 3 (X.25)
with NetIPC are described in this section: Supports switched virtual circuits
(SVCs) and permanent virtual circuits (PVCs). Provides access to the call user data (CUD) field
in call packets. Provides access to X.25 addresses in call packets. Creation of a catch-all socket which can be used
to accept data packets with no CUD or unrecognized CUD. Provides ability to send up to 128 bytes of call
user data using the fast select facility. Provides ability to append, generate and examine
the facility field in call packets. Provides access to X.25 protocol features. Allows direct specification of the target X.25 address
or PVC number.
Limitations | |
Limitations using direct access to level 3 (X.25) are: Intranet use only (level 4 provides
internet and intranet connections) One virtual connection socket accesses one X.25
virtual circuit for data transfers over X.25. Multiplexing of connections
over a virtual circuit is not supported. IPCNAME, IPCNAMERASE and IPCLOOKUP are not supported.
Switched Virtual Circuits (SVCs) | |
Switched virtual circuits are defined as a logical association
that only exists as long as the connection does. Both processes
create their own local call sockets using IPCCREATE that can be associated with protocol relative
addresses. To establish a connection with a specific server process,
a request process must include a server protocol relative address
in the IPCDEST intrinsic. Alternatively, an opt parameter in IPCCREATE can be used to create a catch-all socket where
any incoming request for a connection can be accepted (whether or
not the server protocol relative address exists). A catch-all socket
receives incoming call requests that do not match any other given
protocol relative address. One catch-all socket can be defined for
each X.25 network. As an example, two programs communicating over an SVC can
be designated as the requester and server. Both programs need to
be running in order for communication to occur. Figure 1-10 “SVC Requestor Processing Example” shows the order of NetIPC calls used for a requestor
program and the X.25 packets generated as a result of the calls. Figure 1-11 “SVC Server Processing Example” describes the order of NetIPC calls used for
a server program. Figure 1-10 “SVC Requestor Processing Example” shows the order of NetIPC calls
used for a requestor program and the X.25 packets generated as a
result of the calls. The calls outlined in Figure 1-10 “SVC Requestor Processing Example” perform
the following functions: Create a call socket with IPCCREATE. The call socket descriptor (calldesc) is returned. Create a destination descriptor socket (destdesc) with IPCDEST. You must specify a remote protocol relative address
(protoaddr) to be associated with the destination descriptor. Establish the virtual circuit socket with
IPCCONNECT, supplying the calldesc and destdesc created by the previous two calls. Receive a response to the connection request with
IPCRECV, setting the data length parameter (dlen) equal to zero. Send a message over the connection with
IPCSEND. Receive a message over the connection with
IPCRECV. Shutdown the connection with IPCSHUTDOWN. Cause and diagnostic values and/or clear user
data can be entered that will be included in an X.25 clear packet
sent as a result of this call.
Figure 1-10 SVC Requestor Processing Example Figure 1-11 “SVC Server Processing Example” shows the order of NetIPC calls
used for a server program and the X.25 packets generated as a result
of the calls. The calls outlined in Figure 1-11 “SVC Server Processing Example” perform
the following functions: Create a call socket with IPCCREATE. The call socket descriptor (calldesc) is returned. The socket could be created as a catch-all and/or
bound to a particular protocol relative address. Call IPCRECVCN and wait for an incoming call request packet.
IPCRECVCN will return a VC descriptor (vcdesc) when it is established that the incoming protocol
relative address defined in (1) matches the incoming protocol relative
address, or a catch-all socket was created in (1). As IPCRECVCN completes and returns a vcdesc, X.25 sends the requestor process a call accepted packet. Receive a message over the connection with
IPCRECV. Send a message over the connection with
IPCSEND. Since the server (IPCRECV) in this example waits to receive a message, you
may decide to set a timer to handle the inactivity. (Optional step.) Shutdown the connection with
IPCSHUTDOWN after data has not been received for a period
of time. (For example, after a timeout has occurred.) Note that
the X.25 protocol implicitly handles the incoming clear request
by sending a clear confirmation packet.
Figure 1-11 SVC Server Processing Example Permanent Virtual Circuits (PVCs) | |
Permanent virtual circuits are defined as two DTEs with a
logical association permanently held by the network. Since the connection
is permanent, both processes must initiate the connection using
the IPCCREATE intrinsic. Both processes must specify the destination
of a connection request with the IPCDEST intrinsic which requires a node name corresponding
to a configured PVC number. The possible ordering of intrinsic calls to communicate over
a PVC could be as follows: Create a call socket with IPCCREATE. The call socket descriptor (calldesc) is returned. Create a destination descriptor socket (destdesc) with IPCDEST. Establish the virtual circuit socket with
IPCCONNECT, supplying the calldesc and destdesc created by the previous two calls. Send a reset packet (to the DCE) by setting the
reset request in IPCCONTROL. Send an interrupt packet to the remote process by
setting the interrupt request in IPCCONTROL. Send data over the connection with IPCSEND. Receive data over the connection with IPCRECV. Send a reset packet by setting the reset request
in IPCCONTROL when all data has been sent/received. Shutdown the connection with IPCSHUTDOWN. Note that a PVC is a permanent connection, and
the shutdown process releases the resources associated with the
connection.
Note that these steps do not show how to synchronize data
transfer between the two programs, and do not include error checking,
or the intrinsic calls required for adding options and special user
capabilities. Access to the Call User Data (CUD) Field | |
The NetIPC intrinsics IPCCONNECT, IPCRECVCN, IPCCONTROL, IPCRECV (on connection establishment), and IPCSHUTDOWN (with fast select) provide access to the call
user data (CUD) field in call packets as follows: Specifying a protocol relative
address in the CUD. This field may be present in X.25 call request and
incoming call packets which you can access with IPCCONNECT and IPCRECVCN. The call user data field can only be accessed
over an SVC. The maximum length of the call user data (CUD) field
is normally 16 bytes. The CUD can be up to 128 bytes if the fast
select facility is available. For NS X.25, the first four bytes
of the CUD are reserved for protocol relative addressing. Figure 1-12 “NS X.25 Call User Data Field (four
bytes)” shows the contents of the first four bytes
of the HP 3000 X.25 CUD. The first two bytes, as shown
in Figure 1-12 “NS X.25 Call User Data Field (four
bytes)”, indicate that the source of the
call request packet is an HP 3000 node using direct access
to level 3. Optionally, the last two bytes contain the protocol
relative address that the call request expects to find (if any). To access the entire CUD (16 bytes without fast select or
128 bytes with fast select), the opt parameter protocol flags bit 17 can be set in IPCCONNECT. This option is useful for communication with non-HP
nodes. See the discussion of the Fast Select Facility for examples
using NetIPC intrinsics to send and/or receive call user data using
fast select.
Figure 1-12 NS X.25 Call User Data Field (four
bytes) Connecting to a catch-all
socket. Using IPCCREATE, you can identify a socket as a catch-all socket.
All incoming calls with a protocol relative address specified in
the CUD that does not match any given protocol relative address
are routed to the catch-all socket. Only one catch-all socket may
be defined for each X.25 network on each node. For an incoming call with a protocol relative address specified, NetIPC
checks if the address matches one created. If it matches, the call
is accepted. If it does not match, NetIPC checks for the existence of
a catch-all socket. If no catch-all socket has been created, the
call is rejected and a clear packet is sent by X.25. If a catch-all
socket has been created, the call is accepted. If no protocol address is specified in the incoming call,
NetIPC checks for the existence of a catch-all socket. If no catch-all
socket has been defined, the call is rejected. If there is a catch-all
socket, the call is accepted. Defer connection requests. Using IPCRECVCN with the deferred flag set allows you to examine the
call user data, facilities, and calling node address before accepting
or rejecting the connection. The IPCCONTROL intrinsic provides you with the capability to
accept or reject a connection request that is in the deferred state.
Fast Select Facility | |
The fast select facility, a datagram service, is available
over an X.25 network. Fast select is configured as a parameter in
the X.25 User Facility Set Parameters screen during NMMGR configuration
of X.25 on the HP 3000. (See the X.25 XL System
Access Configuration Guide for more information.) When
you use the fast select facility, up to 128 bytes of call user data
may be sent in a X.25 call packet using NetIPC intrinsics. Fast select has two options: No restriction on response:
allows the receiver of the connection request the choice of either
accepting or rejecting the connection. Restriction on response:
the receiver must always reject the connection.
The receiver of the connection can use IPCRECVCN to examine the call user data, facilities or calling
node's address before deciding to accept or reject the
connection. If the connection is accepted, up to 128 bytes of call user
data may be placed in the call confirmation packet using IPCRECVCN. Once accepted, the virtual circuit is open and
can be used as a virtual circuit that does not have fast select.
The side that closes the connection can send 128 bytes
of clear user data in the clear packet using the IPCSHUTDOWN call. Figure 1-13 “Fast Select No Restriction” is an example
of the sequence of calls used with fast select, no restriction. Figure 1-13 Fast Select No Restriction If the connection is rejected, up to 128 bytes of clear user
data may be put in the clear packet using IPCSHUTDOWN. Figure 1-14 “Fast Select Restricted” is an example using
fast select with restriction. Figure 1-14 Fast Select Restricted Facility Field | |
The X.25 facility field is built from the facility set configured
with NMMGR. With direct access to X.25 level 3, the facility field
can be appended with facilities specified in the opt parameter of the IPCCONNECT intrinsic. The values for the facilities used
must follow the X.25 recommendation. For example, a user wants to use a facility set with packet
size and window size negotiation and wants to append the CCITT-specified
DTE facilities to that facility set. In NMMGR, the user has verified
the facility set contains packet size and window size negotiation.
The facility field generated from the facility set would contain
the following (in octal): Facility length : %6
Packet size neg code field : %102
Packet size in : %10
Packet size out : %10
Window size net code field : %103
Window size in : %7
Window size out : %7 |
To add the DTE facilities, the user must specify all the bytes
required by the X.25 recommendation in the IPCCONNECT request. In this example, to add the DTE facilities
(calling address extension, called address extension and QOS end-to-end
delay) the following values must be entered in the option field
buffer (shown in octal): CCITT-specified DTE fac marker : %17
Calling add extension code : %313
Calling add extension length : %3
Calling add extension : %5
: %5
Called add extension code : %312
Called add extension length : %3
Called add extension : %6
: %6
QOS minimum throughput : %12
QOS throughput in/out : %314 |
NetIPC appends this to the facility-set generated field, and
updates the "facility length". In this example,
the facility length would be %21. When a connection is received, the user can examine the entire
facility field (see IPCRECV). Access to X.25 Protocol Features | |
The NetIPC intrinsics provide access to the following X.25
protocol features: Send and receive interrupt
and reset packets. You can request the X.25 protocol to send an interrupt
or reset packet with IPCCONTROL. When used in this way, the IPCCONTROL intrinsic will not return until the appropriate
confirmation packet is received by X.25. Set no activity timeout. You can set a no activity timeout value with the IPCCONTROL intrinsic. This option clears the connection after
the specified time if no data packets are exchanged on the virtual
circuit. Qualifying X.25 data packets. The Q bit in the general format identifier field in
an X.25 data packet can be set using the IPCSEND intrinsic. The status of the Q bit in
incoming data packets is returned in the IPCRECV intrinsic. The Q bit status can be used
to indicate whether the data is a user message (Q bit=0) or a device
control message (Q bit=1) from or to a remote PAD. Set end-to-end acknowledgment. The D bit in the general format identifier field in
an X.25 data packet can be set using the IPCSEND intrinsic. The status of the D bit in incoming
data packets is returned in the IPCRECV intrinsic. Setting the D bit locally specifies end-to-end acknowledgment
of data packets. IPCSEND does not complete until it receives acknowledgment
that the entire message has been received. For HP 3000
to HP 3000 communication, IPCRECV initiates the acknowledgment when the remote HP
3000 process has received the entire message. Set cause and diagnostic codes. Using IPCSHUTDOWN, you can enter a reason code that will be included
in X.25 clear packets as cause and diagnostic values. This option
is only used with SVCs. Reasons for events or errors are returned
by IPCCONTROL. See Appendix B “Cause and Diagnostic Codes” for a list of
diagnostic codes used with X.25 protocol access. Note that when
the DTE sends the clear packet, the cause code is always set to
zero.
|
