This chapter contains the following sections:
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).
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.
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.
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.
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.