Service Selection

Rendezvous daemon (rvd) processes communicate using UDP services. The service parameter instructs the Rendezvous daemon to use this service whenever it does network communications on behalf of this transport.

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

Interaction between Service and Network Parameters

Within each Rendezvous daemon, all the transports that use a specific service must also use the same network parameter. That is, if the service parameters resolve to the same UDP port, then the network parameter 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 to that rvd 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; the transport creation call produces the status code 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.

• Point-to-point messages on the transport’s service travel on the appropriate network (as determined by the operating system) irrespective of the transport’s network parameter.
• Inbound broadcast messages on the transport’s service can arrive from any network, irrespective of the transport’s network parameter.

Specifying the UDP Service

Programs can specify the service in one of several ways, listed in order of preference in Specify UDP Service.

Specify UDP Service

Port number

When a program specifies a UDP port number, it must be a string representing a decimal integer. For example:

   "7890"

Service name

When a program specifies a service name, the transport creation function searches the network database using getservbyname(), which searches a network database such as NIS, DNS or a flat file such as /etc/services (in some versions of UNIX).

Default

(Non-Secure Daemons)

If a program does not specify a service, or it specifies 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 a hard default of port 7500.

We strongly recommend that administrators 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:

   rendezvous 7500/udp

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.

Default

(Secure Daemons)

Secure daemons use internal defaults, which must be set explicitly by the administrator; see Default Network and Service.

Direct Communication

To enable direct communication, specify two parts separated by a colon:

• UDP service for regular communication
• UDP service for direct communication

You may specify both parts either as a service name or a port number.

Direct communication is not available when connecting to a remote daemon.

For a general overview, see Direct Communication on page 91 in TIBCO Rendezvous Concepts.

The rvd daemon interprets this service as a UDP service.