Copyright © Cloud Software Group, Inc. All Rights Reserved

Network Parameter

Every network transport object communicates with other transport objects over a network. On computers with only one network interface, the Rendezvous daemon communicates on that network without further instruction from the program.

On computers with more than one network interface, the network parameter instructs the Rendezvous daemon to use a particular network for all communications involving this transport. To communicate over more than one network, a program must create a separate transport object for each network.

The network parameter also specifies multicast addressing details (for a brief introduction, see Multicast Addressing).

To connect to a remote daemon, the network parameter must refer to the network from the perspective of the remote computer that hosts the daemon process.

Constructing the Network Parameter

The network parameter consists of up to three parts, separated by semicolons—network, multicast groups, send address—as in these examples:

lan0	network only
lan0;225.1.1.1	one multicast group
lan0;225.1.1.1,225.1.1.5;225.1.1.6	two multicast groups, send address
lan0;;225.1.1.6	no multicast group, send address

Part One—Network

Part one identifies the network, which you can specify in several ways:

(Sheet 1 of 2)

Host name	When a program specifies a host name, the transport creation call uses an operating system call that searches a network database to obtain the IP address. The maximum length of a host name string is 256 characters.
Host IP address	When a program specifies an IP address, it must be a string representing a multi-part address. For example:    "101.120.115.111"
Network name (where supported)	When an application specifies a network name, the transport creation function calls getnetbyname(), which searches a network database such as Network Information Services (NIS) or a flat file (such as networks) in the system directory.
Network IP number	If a program specifies a host IP address or a network IP number it must be in dotted-decimal notation. For example, 101.55.31.
Interface name (where supported)	When an application specifies an interface name, the transport creation function searches the interface table for the specified interface name. For example, lan0. The interface name must be one that is known to ifconfig or netstat.
Default	If a program does not specify a network, the transport creation function uses the default network interface. Daemons use the network interface that corresponds to the host name of the system as determined by the C function gethostname().

 

The use of the UDP broadcast protocol has generally been superseded by IP multicast protocol. To use broadcast protocols without multicast addressing, specify only part one of the network parameter, and omit the remaining parts.

Part Two—Multicast Groups

Part two is a list of zero or more multicast groups to join, specified as IP addresses, separated by commas. Each address in part two must denote a valid multicast address. Joining a multicast group enables listeners on the resulting transport to receive data sent to that multicast group.

For a brief introduction to multicasting, see Multicast Addressing.

Part Three—Send Address

Part three is a single send address. When a program sends multicast data on the resulting transport, it is sent to this address. (Point‑to‑point data is not affected.) If present, this item must be an IP address—not a host name or network name. The send address need not be among the list of multicast groups joined in part two.

If you join one or more multicast groups in part two, but do not specify a send address in part three, the send address defaults to the first multicast group listed in part two.

Multicast Addressing

Multicast addressing is a focused broadcast capability implemented at the hardware and operating system level. In the same way that the Rendezvous daemon filters out unwanted messages based on service groups, multicast hardware and operating system features filter out unwanted messages based on multicast addresses.

When no broadcast messages are present on the service, multicast filtering (implemented in network interface hardware) can be more efficient than service group filtering (implemented in software). However, transports that specify multicast addressing still receive broadcast messages, so combining broadcast and multicast traffic on the same service can defeat the efficiency gain of multicast addressing.

Rendezvous software supports multicast addressing only when the operating system supports it. If the operating system does not support it, and you specify a multicast address in the network argument, then transport creation calls produce an error status (TIBRV_NETWORK_NOT_FOUND).

Copyright © Cloud Software Group, Inc. All Rights Reserved