Tibco RV: Message Lifetime + No Copy for Branches

Question

1, How long is the message in the listener queue? Until the dispatcher reads the message from the queue in the scenario "1 publisher 1 consumer"?

Listener listener = new Listener(Queue.Default, transport, subject, new object()); listener.MessageReceived += OnMessageReceived; Dispatcher dispatcher = new Dispatcher(listener.Queue); 

2, Tibco RV is typically used in a large distribution system with relatively loose requirements for reliable delivery of, say, market data published in 20 applications in the enterprise. I heard that Tibco RV implements a “no copy” branching solution - how is this possible? I assume that we need to at least go through all registered listeners for this queue and notify each of them, during which the message is copied 20 times. Please enlighten me.

3, Combine questions 1 and 2, it makes no sense for the message to live in the listener queue until ALL registered listeners parse the message. What happens if 1 out of 20 applications shuts down? This will disrupt the rv demonstration process due to ever-increasing messages. Does Tibco RV have a lifetime limit (ttl) for each message? How to check and set new values?

Google doesn't have much information, so please help.

Thanks.

Answer 1

Big questions.

• Keep in mind that if you do not use the RV protocol, then the disk will not remain constant. Sent messages will remain in the memory of the sending Rendezvous daemon until they are delivered to all users.

  However, you need to understand that RV is an optimistic protocol, not TCP, which is a pessimistic protocol. Each packet sent using TCP must be acknowledged. This round-trip protocol slows down. Rendezvous, on the other hand, uses a protocol that sits on top of UDP, which has no session and does not require any configuration. Therefore, when the Rendezvous daemon sends a message, it is assumed that it was successfully delivered if a retransmission request is not received . Thus, in order to fully answer your first question, the default behavior for the Rendezvous daemon is to save the messages that it sent to memory for 60 seconds after sending the message. This allows it to fulfill retransmission requests.

• The fan is turned off using broadcast or multicast protocols over UDP. Using broadcast is not recommended, and multicast is recommended. Using multicast groups uses significantly less network resources. At the network interface level, only those hosts that join the multicast group will receive packets related to Rendezvous traffic. Similarly, on a network switch, the multicast level is much less resource intensive.

  The bottom line is that the sending Rendezvous daemon sends a message only once, and the network sends a copy of the connected packets to each host on the subnet, if broadcasting is used, or hosts that have an interest, if multicast b.

• At pub-sub, consumers usually receive messages that are sent while they are alive and consuming . Thus, with pure Rendezvous, if the consumer was to go down, the subscription would be canceled for that consumer. If we think about your example of market data, this is exactly the behavior that we want. IBM trades thousands of times per second, so if I miss a price quote, it doesn't really matter. I will get the next one. In addition, I do not want stagnant prices.

  However, sometimes consumers want to send messages while they are not working. This can be achieved using certified messages and setting up regular correspondents. For more information, see the Rendezvous Concepts Guide . Finally, the 60-second behavior that I mentioned in step # 1 can be changed using the "reliability" parameter when starting the Rendezvous daemon. There are some cases where this might make sense (although the default is best for most common cases). For more information, see the Rendezvous Administrator's Guide .