1

Is there a way to tell if an RV inbox has a valid, active endpoint?

I have a system where clients create RV Inboxes. These are then passed to other components in the system which can use the Inbox to send messages to the client.

I would like a Monitor process in my system to know if a client has died. The Monitor will have the client Inbox.

I can implement a heartbeating mechanism, but I wonder if there is a mechanism within RV which can tell me whether the Inbox is still valid - ie, whether messages sent on it will be routed to an active client.

I guess that RV itself must know this - as it will know whether it can send a message to the Inbox or not. Is there a way for my code to be able to access this information, or to make a test about whether an Inbox is valid at a given time?

Richard Shepherd
  • 1,300
  • 17
  • 20

2 Answers2

1

Inboxes use direct connections. From the documentation:

Transport objects can create inbox names, designating a destination that is unique to that transport object and its process. Rendezvous software uses point-to-point techniques to deliver messages with inbox subject names.

And, direct communication is really just UDP

Direct communication uses RPTP over a UDP channel.

So you have two problems - first, mapping the inbox to the ip address and UDP port, and two, telling if it's what you want.

I haven't been able to find any way to solve the first one - those inboxes are opaque, though presumably someone clever could figure it out.

For the second one, it seems like it's not so easy a problem to solve in general - from our sister site

UDP ports only have two states: listening or not. That usually translates to "having a socket open on it by a process" or "not having any socket open". The latter case should be easy to detect since the system should respond with an ICMP Destination Unreachable packet with code=3 (Port unreachable). Unfortunately many firewalls could cut those packets so if you don't get anything back you don't know for sure if the port is in this state or not. And let's not forget that ICMP is session less too and doesn't do retransmissions: the Port Unreachable packet could very well be lost somewhere on the net.

I would guess, the easiest way to do this is with a heartbeating mechanism. In the past, we had a library around RV that would publish all of the clients and any subjects subscribed to (including inboxes) out for various management processes.

dsolimano
  • 8,870
  • 3
  • 48
  • 63
1

(Not really answering my own question - this is from a work colleague.)

I came across this when I was working on an RV bridge that we had to write last year, as it was proxying and rewriting inboxes. It turns out RV creates “throwaway” inboxes for certain operations (the blocking ones), and no message is sent (on that multicast, anyway) to say that the inbox is gone. The way inboxes work seems to be that:

  • The inbox encodes the IP address of the host, a unique process ID for the client on that host/transport, and an incrementing counter
  • The sender just sends a unicast packet to the right IP and port (service)
  • The daemon (if it has clients on that service) checks if it has any active subscriptions on that subject (just like for multicast), and passes it on to the client

In other words, it’s the receiving daemon which has to discard messages sent on closed inboxes, and there is no equivalent to the “LISTEN.STOP” messages that accompany regular subscription ends.

Richard Shepherd
  • 1,300
  • 17
  • 20