Specifications

Page 16 Remote Procedure Call Programming Guide
4. Other RPC Features
This section discusses some other aspects of RPC that are occasionally useful.
4.1. Select on the Server Side
Suppose a process is processing RPC requests while performing some other activity. If the other activity
involves periodically updating a data structure, the process can set an alarm signal before calling svc_run()
But if the other activity involves waiting on a a file descriptor, the svc_run() call won’t work. The code for
svc_run() is as follows:
void
svc_run()
{
fd_set readfds;
int dtbsz = getdtablesize();
for (;;) {
readfds = svc_fds;
switch (select(dtbsz, &readfds, NULL,NULL,NULL)) {
case -1:
if (errno == EINTR)
continue;
perror("select");
return;
case 0:
break;
default:
svc_getreqset(&readfds);
}
}
}
You can bypass svc_run() and call svc_getreqset() yourself. All you need to know are the file descriptors of
the socket(s) associated with the programs you are waiting on. Thus you can have your own select() that
waits on both the RPC socket, and your own descriptors. Note that svc_fds() is a bit mask of all the file
descriptors that RPC is using for services. It can change everytime that any RPC library routine is called,
because descriptors are constantly being opened and closed, for example for TCP connections.
4.2. Broadcast RPC
The portmapper is a daemon that converts RPC program numbers into DARPA protocol port numbers; see
the portmap man page. You can’t do broadcast RPC without the portmapper. Here are the main differences
between broadcast RPC and normal RPC calls:
1. Normal RPC expects one answer, whereas broadcast RPC expects many answers (one or more
answer from each responding machine).
2. Broadcast RPC can only be supported by packet-oriented (connectionless) transport protocols like
UPD/IP.
3. The implementation of broadcast RPC treats all unsuccessful responses as garbage by filtering them
out. Thus, if there is a version mismatch between the broadcaster and a remote service, the user of
broadcast RPC never knows.
4. All broadcast messages are sent to the portmap port. Thus, only services that register themselves
with their portmapper are accessible via the broadcast RPC mechanism.
5. Broadcast requests are limited in size to the MTU (Maximum Transfer Unit) of the local network.
For Ethernet, the MTU is 1500 bytes.