RVD (Rendezvous daemon) vs RVRD (Rendezvous Routing Daemon)
RVRD (Rendezvous Routing Daemon) are simply process owned by middleware or network teams which listens to multicast traffic locally and transmit it to another RVRD counterpart (another host) using TCP. This remote host than re multicast this traffic to their own network. So essentially it used to bridge two different regional networks e.g. London and Newyork etc.
RVRD is multicast in one end and unicast on another end so it receives messages from multiple RVD (Rendezvous Daemon) and sends via TCP to another RVRD which distributes messages on different RVD (Rendezvous Daemon) on there own network e.g. say on NY network.
Control of RVRD (Rendezvous Routing Daemon) resides on middleware/network team and they decide which topics/subject is allowed for RVRD (Rendezvous Routing Daemon) traffic. So if you send a message on a topic that is not configured on RVRD and the subscriber for that service is on another physical network it will not receive those messages until that topic is enabled on RVRD (Rendezvous Routing Daemon) front.
RVRD (Rendezvous Routing Daemon) are simply process owned by middleware or network teams which listens to multicast traffic locally and transmit it to another RVRD counterpart (another host) using TCP. This remote host than re multicast this traffic to their own network. So essentially it used to bridge two different regional networks e.g. London and Newyork etc.
RVRD is multicast in one end and unicast on another end so it receives messages from multiple RVD (Rendezvous Daemon) and sends via TCP to another RVRD which distributes messages on different RVD (Rendezvous Daemon) on there own network e.g. say on NY network.
Control of RVRD (Rendezvous Routing Daemon) resides on middleware/network team and they decide which topics/subject is allowed for RVRD (Rendezvous Routing Daemon) traffic. So if you send a message on a topic that is not configured on RVRD and the subscriber for that service is on another physical network it will not receive those messages until that topic is enabled on RVRD (Rendezvous Routing Daemon) front.
On the other hand RVD (Rendezvous Daemon) is a background process runs on every host which wants to send or receive message from tibco multicast network. Your process depends upon this for reliable and efficient network communication. all messages goes via rvd before it enters or leaves host on a multicast network and RVD (Rendezvous Daemon) is responsible for creating packets or assembling packets to and from the network.
On points
-- RVD transmit outbound message from your program to network.
-- RVD delivers inbound message from network to your process.
-- RVD takes care of Operating system specifics and encapsulates those leaving your process independent of such low level details.
-- RVD daemon can be start automatically if its not running already ,may exit after some specified period of inactivity. if you like this tutorial please share it .
2 comments :
This was what asked to me in an interview
"difference between Tibco RVD and Tibco RVD" :)
wonderful explanation.
Apart from delivering inbound messages from network to application, Tibco Rendezvous Daemon (rvd) also provides subject based addressing, which gives location independence. This is the native tibrv component which implements TRDP protocol for faster message delivery. So your application connects to Rendezvous Daemon using TCP and RVD connects to network using TRDP, which is Tibco's own protocol over UDP. Tibco RVD daemon also provides Reliability by using sequencing, re-transmission and buffering. Your Java or C++ application usually communicate with RVD by using Rendezvous API provided by Tibco. Usually a Rendezvous daemon runs on same host as the Java application, but using remote daemon for sending message is possible. Though it's better to use local rvd daemon than remote rvd daemon, apart from network firewall issues, it's also slower, because your application uses TCP to connect to remote daemon, instead of UDP. Suppose you want to send messages from Asia to Europe using Tibco RV, it will be much faster by using local daemon rather than connecting to a remote daemon situating on that region.
Post a Comment