RVD (Rendezvous daemon) vs RVRD (Rendezvous Routing Daemon)
RVRD (Rendezvous Routing Daemon) are simply process owned by middleware or network teams which listens multicast traffic locally and transmit it to another RVRD counter part (another host) using TCP. This remote host than re multicast this traffic to there own network. So essentially it used to bridge two different regional network e.g. London and Newyork etc.
RVRD is multicast in one end and unicast on other end so it receives messages from multiple RVD (Rendezvous Daemon) and send 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 message on a topic which is not configured on RVRD and subscriber for that service is on some 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.
RVRD (Rendezvous Routing Daemon) are simply process owned by middleware or network teams which listens multicast traffic locally and transmit it to another RVRD counter part (another host) using TCP. This remote host than re multicast this traffic to there own network. So essentially it used to bridge two different regional network e.g. London and Newyork etc.
RVRD is multicast in one end and unicast on other end so it receives messages from multiple RVD (Rendezvous Daemon) and send 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 message on a topic which is not configured on RVRD and subscriber for that service is on some 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.
