Automatic Program Startup for Incoming X.25 Calls

An application written to handle an incoming call may be started on the command line and "listen" for a call (X25listen), sleeping until it arrives. Alternatively, x25daemon may execute your application at the time the new call request arrives at your system.

How Applications are Invoked by the x25daemon

An application that uses the API to interact with a remote device using a switched virtual circuit must have a device name (/dev directory entry) to use before it can do anything. The easiest way to do this is for x25daemon to provide the name when it invokes the program, as in the following example.

ANY:PASS:YES:/etc/padd -d $dev -v $index

The $dev field is replaced by the packet layer device. In this example, padd is started with the arguments: -d /dev/x25pkt -v NN where NN is the call index. The call index is unique for every incoming call and existing virtual circuit, and is used by the X.25 drivers to identify incoming calls that are later accepted by applications such as padd.

x25daemon will also replace the $netid field with the network identifier as defined in /etc/packetnets that corresponds to the physical link on which the incoming call arrived.

When a program uses the PASS disposition, it has the option of using _X25getcallinfo to obtain the information associated with the incoming call packet before accepting it. The following is an example.

     ct = X25open(netid);
     _X25getcallinfo(X25_fd(ct), call index, &cps);

A PASS disposition program may also pass the incoming call on to another process, or clear it (with X25clear), rather than accepting it. If a program chooses to pass the call on elsewhere, it must be disposed of before the internal timer runs out, since Netcom II will clear calls that appear to be hung by the application (not cleared or accepted).

Revision 1.1 (January 2002)