>Digging into Tibco Rendezvous network details – I

>

Tibco RV is is one of the most used messaging systems. Athough lot of people use RV but there are some concepts which are known mainly to admins. These are some concepts which are better to be known by developers also for better programming.

Rendezvous Daemon

The Rendezvous daemon is a background process that supports all Rendezvous communications. Distributed processes depend on it for reliable and efficient network communication. All information that travels between processes passes through a Rendezvous daemon as it enters a host computer or exits a sending process. Its functions are as following :-
• Transmits outbound messages from program processes to the network.
• Delivers inbound messages from the network to program processes.
• Filters subject-addressed messages.
• Shields programs from operating system idiosyncrasies, such as low-level sockets.

The Rendezvous daemon process, rvd, starts automatically when needed, runs continuously and may exit after a period of inactivity. We can run the deamon on our local machine or can even connect to another daemon running on some remote machine.

Transport –

Programs use transport objects to send messages and listen for messages. A transport determines three aspects of message delivery:
  1. Delivery scope—the potential range of its messages
  2. Delivery mechanism—the path (including software, hardware and networkaspects) that its messages travel
  3. Delivery protocol—the ways in which programs cooperate and shareinformation concerning message delivery. Various types of transport object combine these aspects to yield different qualities of service—for example, intra-process delivery, network delivery, reliabledelivery, virtual circuit, certified delivery, and distributed queue delivery.
Rendezvous software distinguishes between two broad classes of transports.

• Network transports – A network transport delivers messages across a network, to processes on one ormore hosts. It also can deliver messages to several processes on a single host. All messages pass through a Rendezvous daemon process.The service, network and daemon parameters of a network transport specifyits scope within the network

• Intra Process Transport – An intra-process transport delivers messages between program threads within asingle process.Intra-process messages do not pass through a Rendezvous daemon process;instead, they remain local within the program process. Intra-process messagesare significantly faster than network messages.Each program contains exactly one intra-process transport; the Rendezvousopen call creates it automatically. Its scope is the program process. Any threadcan dispatch intra-process events from an appropriate queue.

Service parameter

The service parameter instructs the Rendezvous daemon to use this servicewhenever it conveys messages on the transport. As a direct result, services divide the network into logical partitions. Eachtransport communicates on a single service; a transport can communicate onlywith other transports on the same service. To communicate on more than oneservice, a program must create a separate transport object for each service. Within each rvd process, all the transports that specify a given service mustspecify the same network parameter. That is, if the service parameters resolve tothe same UDP or PGM 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, hasa transport that communicates on the service svc1 over the network lan1. It isillegal for any program to subsequently create a transport (connecting to the samedaemon process on orange) to communicate on svc1 over any other network—such as lan2. Once rvd binds svc1 to lan1, that service cannot send outboundbroadcast messages to any other network. Attempting to illegally rebind a serviceto a new network fails; transport creation calls produce an error status(TIBRV_INIT_FAILURE).

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

–> Point-to-point messages on the transport’s service travel on the appropriatenetwork (as determined by the operating system) irrespective of thetransport’s network parameter.

–> Inbound broadcast messages on the transport’s service can arrive from anynetwork, irrespective of the transport’s network parameter.

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

  1. Service name – When you specify a service name, the transport creation function callsgetservbyname(), which searches a network database (such as NIS) or a flat file(such as services in the system directory).
  2. Port number – When you specify a port number, it must be a string representing a decimalinteger (for example, “7890”).
  3. Default – If you specify null, the transport creation function searches for the service namerendezvous. If getservbyname() does not find rendezvous, the Rendezvous daemoninstructs the transport creation function to use a hard default:

The TRDP daemon offers the default service 7500.The PGM daemon offers the default service 7550.

Advertisements
This entry was posted in Middleware, RV, Tibco. Bookmark the permalink.

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

  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