>Digging into Tibco Rendezvous network details – II

>

Daemon Parameter –
The daemon parameter instructs the transport creation function about how and where to find the Rendezvous daemon and establish communication. Each Rendezvous transport establishes a communication conduit with theRendezvous daemon, as the following steps describe:
  1. The daemon process opens a (TCP) client socket, and waits for a client to request a connection.The -listen option of the Rendezvous daemon (rvd) specifies the socketwhere the Rendezvous daemon should listen for new client programconnections.
  2. The program calls the transport creation function, which contacts the daemon at the client socket specified in its daemon parameter. The daemon parameter of the transport creation function must correspond tothe -listen option of daemon process; that is, they must specify the same communication type and socket number.If no daemon process is listening on the specified client socket, then thetransport creation call automatically starts a new daemon process (which listens on the specified client socket), and then attempts to connect to it.
  3. The daemon process opens a conduit for private communication with the newtransport object in the program. All future communication uses that conduit.The request socket is now free for additional requests from other clienttransports.
  • Specifying a Local Daemon – For local daemons, specify the transport creation function‘s daemon parameter andthe -listen option to the daemon process as a (TCP) socket number; for example:”6555″.To use the default client socket, supply NULL as the daemon argument to thetransport creation function, and omit the -listen option to the daemon process.
  • Remote Daemon – In most cases, programs connect to a local daemon, running on the same host asthe program. Certain situations require a remote daemon, for example: The program runs on a laptop computer that is not directly connected to thenetwork. Instead, the laptop connects to a workstation on the network, andthe daemon runs on that workstation. Another example could be that the program connects to a network at a remote site.

For remote daemons, specify two parts (introducing the remote host name as thefirst part): Remote host name: Port number. For example:”purple_host:6555″

Network Parameter –

Every network transport object communicates with other transport objects over anetwork. 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
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

  1. Part one identifies the network, which you can specify in several ways: – Host name, Host IP address, Network name, Network IP number, Interface name, Default TRDP daemons use the network interface which corresponds to the hostname of the system as determined by the C function gethostname(). PGM daemons use the default PGM multicast interface, 224.0.1.78.
  2. 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.
  3. 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.
Advertisements
This entry was posted in Middleware, RV, Tibco. Bookmark the permalink.

One Response to >Digging into Tibco Rendezvous network details – II

  1. Pingback: network, multicast and send address in TransportNetwork; via Digging into Tibco Rendezvous network details – II « The Wiert Corner – irregular stream of stuff

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s