Open topic with navigation

TIBCO Rendezvous® 8.8.0

# 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.

## Service Groups

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.

## Interaction between Service and Network Parameters

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:

| • | 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 Service

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

| • | Service name

| • | Port number

| • | Default

By Number

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

By Name

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).

Defaults

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:

       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.

The `rvd` daemon interprets this service as a UDP service.

## Specifying Direct Communication

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:

        "7706:7707"
        "rendezvous:5238"
        ":"
        ":0"

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

| • | The second part specifies the UDP service that the Rendezvous transport object uses for direct communication. This part remains within the program; the transport object never passes it to rvd, which interprets this part as a UDP service for eligible point-to-point communication (RPTP).

Defaults

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.

Restriction

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.

| • | The two parts of any service parameter must specify two different port numbers.

| • | 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.

## See Also

Direct Communication

Did you find this helpful?

Yes No
Great!
Thanks for taking the time to give us some feedback.
Sorry about that

Why wasn't this helpful? (check all that apply)

Could not find what I was looking for
Instructions confusing or unclear
Instructions did not work

Want to tell us more?

Please select at least one option or provide details about the issue!!

Error occurred while submitting feedback.

Error2 occurred while submitting feedback.

TIBCO Rendezvous®

Copyright © 1997-2025. Cloud Software Group, Inc. All Rights Reserved.