Service Parameter

Rendezvous daemon (rvd) processes communicate using UDP services. The service parameter instructs the Rendezvous daemon to use this service whenever it conveys messages on this transport.

As a direct result, services divide the network into logical partitions. Each transport communicates on a single service; a transport can communicate only with other transports on the same service. To communicate on more than one service, a program must create a separate transport object for each service.

A service group is a group of Rendezvous transport objects that communicate using the same UDP service. Rendezvous daemon processes connect transports within a service group on the same network, so they can share messages with one another.

Within each rvd process, all the transports that specify a given service must specify the same network parameter. That is, if the service parameters resolve to the same UDP port, then the network parameters must also be identical. (This restriction extends also to routing daemons.)

For example, suppose that the program foo, on the computer named orange, has a transport that communicates on the service svc1 over the network lan1. It is illegal for any program to subsequently create a transport (connecting to the same daemon process on orange) to communicate on svc1 over any other network—such as lan2. Once rvd binds svc1 to lan1, that service cannot send outbound broadcast messages to any other network. Attempting to illegally rebind a service to a new network fails; transport creation calls produce an error status (TIBRV_INIT_FAILURE).

To work around this limitation, use a separate service for each network.

The limitation is not as severe as it might seem at first, because it only affects outbound broadcast messages:

Rendezvous programs specify services in one of three ways, shown below in order of preference:

When you specify a port number, it must be a string representing a decimal integer (for example, "7890").

When you specify a service name, the transport creation function calls getservbyname(), which searches a network database (such as NIS) or a flat file (such as services in the system directory).

If you specify null, the transport creation function searches for the service name rendezvous.

If getservbyname() does not find rendezvous, the Rendezvous daemon instructs the transport creation function to use default service 7500.

It is good practice for administrators to define rendezvous as a service, especially if port 7500 is already in use.

For example, network administrators might add the following service entry to the network database:

Once this entry is in the network database, programmers can conveniently specify NULL or the empty string as the service argument to create a transport that uses the default Rendezvous service.

The rvd daemon interprets this service as a UDP service.

To enable direct communication, specify a two-part service parameter, separating the parts with a colon. You may specify either part by service name, by port number, or by default. For example:

•

The first part specifies the service that rvd uses for regular communication. rvd interprets this part as a UDP service.

To use the rendezvous service for regular communication (or if rendezvous is not defined, the default regular service, 7500), omit the first part of the parameter.

To use an ephemeral service for direct communication, either omit or specify zero for the second part (but include the separating colon). The operating system assigns an available service number.

To disable direct communication, specify a one-part parameter, omitting the separating colon and the second part.

On each host computer, programs can bind a UDP service only once. Consider these consequences:

•

On host computer foo, no two transport objects (whether in the same process or different processes) can bind the same UDP service for direct communication.

•

If a transport object on host computer foo specifies a UDP service for regular communication, no other transport object on foo can bind that service for direct communication.

•

The opposite is also prohibited. If a transport object on host computer foo binds a UDP service for direct communication, no other transport object on foo can bind that service for regular communication.

•

However, any number of transport objects on host computer foo—in any number of processes—can specify the same UDP service for regular communication. Those transports communicate through rvd, which binds the service only once—in accord with the restriction.