Chapter 3. Listens
Prev |  | Next

## Chapter 3. Listens

This chapter contains the following sections:

- “Listening for Incoming Calls”

- “Call User Data Matching”

- “Address Matching”

- “Priority”

The major features of listening are the following:

- Any number of processes can listen simultaneously, subject to resource constraints imposed by the system administrator. Moreover, any number of these processes can listen at the same (set of) called addresses. Note that there are no means of listening for a particular calling address.

- An application can elect to listen and handle one or more Connect Indications at a time. The most likely use of this feature is when the application wants to make use of the next facility.

- An incoming connection may be accepted on a stream other than the one that received the Connect Indication (the listening stream).

## Listening for Incoming Calls

When an application wishes to listen for incoming calls, it must specify the (called) address(es) and Call User Data (CUD) field values for which it is prepared to accept calls. The data that does this is passed as part of a Listen Request.

The control part of the message is accompanied by a data part containing the addresses to be registered for incoming calls. The data portion is treated as a byte stream of CUD and addresses conforming to the following definition:

    unsigned char  l_cumode;
    unsigned char  l_culength;
    unsigned char  l_cubytes [l_culength];
    unsigned char  l_mode;
    unsigned char  l_type;
    unsigned char  l_length;
    unsigned char  l_add[(l_length+1)>>1];

It is important to note that, depending on both the value of the “mode” bytes and the lengths, not all fields need to be present. Refer to the individual field descriptions below for more details.

## Call User Data Matching

The fields l_cumode, l_culength, and l_cubytes are used to match the CUD field of the incoming call, if any, against that specified in the Listen Request.

l_cumode |  | This field defines the type of matching. Three cases are possible: X25_DONTCARE The listener ignores the CUD—l_culength and l_cubytes are omitted. X25_IDENTITY The listener match is made only if all bytes of the CUD field are the same as the supplied l_cubytes. X25_STARTSWITH The listener match is made only if the leading bytes of the CUD field are the same as the supplied l_cubytes. The last two are intended to distinguish X.29, for example, from other higher level protocols.
l_culength |  | This is the length of the CUD in octets for an X25_IDENTITY or X25_STARTSWITH CUD field match. If l_culength is zero, the l_cubytes are omitted. Currently, the range for l_culength is zero to 16 inclusive. The application still has to check the full CUD field.
l_cubytes |  | This is the string of bytes sought in the CUD field when l_cumode is X25_IDENTITY or X25_STARTSWITH.

## Address Matching

The fields l_mode, l_type, l_length and l_add are used to match the address field(s) of the incoming call against that specified in the Listen Request.

l_mode |  | This field defines the type of matching to be done. Three cases are possible: X25_DONTCARE The listener ignores the address—l_type, l_length, and l_add are omitted. X25_IDENTITY The listener match is made only if all semi-octets of the address are the same as the supplied l_add. X25_STARTSWITH The listener match is made only if the leading semi-octets of the address are the same as the supplied l_add.
l_type |  | This is the type of the address entry, and it can have two values: X25_DTE or X25_NSAP. It denotes the important addressing quantity. For X.25(84) and X.25(88), for example, NSAPs (or extended addresses) are the important addresses, while for X.25(80), where there is no NSAP, the DTE is the important quantity. Various applications can be distinguished by X.25 DTE subaddress where necessary. On many X.25(84) and X.25(88) networks, it is possible to listen on either X25_DTE or X25_NSAP addresses. This is not possible when running X.25(84) or X.25(88) over LLC-2 (Logical Link Control-Class II) on the LAN. In this case, the DTE address field is NULL and the X25_NSAP field is used.
l_length |  | This is the length of the address l_add in semi-octets—the common format for X.25 DTE addresses and NSAPs. If l_length is zero, then l_add is omitted. The maximum values for l_length are 15 for X25_DTE and 40 for X25_NSAP.
l_add |  | This contains the address. l_add is omitted when l_length is zero.

## Priority

The Listen Request queue is ordered in terms of the amount of listen data supplied. The more a Listen Request asks for, the higher its place in the queue. Connect Indications are sent to the listener whose listening criteria are best matched.

Privileged users can ask for a Listen Request to be placed at the front of the queue, regardless of the amount of listen data supplied. To do this, the Listen Request should be sent as a M_PCPROTO message. This is achieved by setting the RS_HIPRI flag in `putmsg`. Such requests are searched in the order in which they arrive.

The system administrator controls whether or not listening for incoming calls is a privileged operation. If listening is privileged, incoming calls will be sent only on listen streams opened by a user with superuser privilege. This prevents other users accepting calls that may contain private information, passwords, and so on.

In systems where privileged and non-privileged listens are allowed:

- Privileged listens have priority.

- A matching but busy privileged listen prevents a search of any non-privileged listens.

Prev | Table of Contents | Next
Chapter 2. Data Structures |  | Chapter 4. NLI Message Primitives