有没有办法判断RV收件箱是否有有效的活动端点？
我有一个客户端创建RV收件箱的系统。然后将这些组件传递给系统中的其他组件，这些组件可以使用收件箱向客户端发送消息。
我想在我的系统中使用Monitor进程来了解客户端是否已经死亡。监视器将具有客户端收件箱。
我可以实现一个心跳机制，但我想知道RV中是否有一个机制可以告诉我收件箱是否仍然有效 - 即，它上面发送的消息是否会被路由到活动客户端。
我想RV本身必须知道这一点 - 因为它会知道它是否可以向收件箱发送消息。有没有办法让我的代码能够访问这些信息，或者测试收件箱在给定时间是否有效？
答案 0 :(得分：1)
收件箱使用直接连接。来自documentation：
传输对象可以创建收件箱名称， 指定一个独特的目的地 到那个运输对象及其过程。 Rendezvous软件 使用点对点 使用收件箱主题名称传递邮件的技术。
而且，直接通信实际上只是UDP
直接通信使用UDP通道上的RPTP。
所以你有两个问题 - 首先是将收件箱映射到ip地址和UDP端口，还有两个问题，告诉你这是不是你想要的。
我一直无法找到解决第一个问题的方法 - 那些收件箱是不透明的，但可能有些聪明的人可能会想出来。
对于第二个问题，似乎从一般情况来解决问题并不是那么容易 - 从sister site
UDP端口只有两种状态：是否收听。这通常转换为“通过进程打开套接字”或“没有任何套接字打开”。后一种情况应该易于检测，因为系统应该使用代码= 3（端口不可达）的ICMP Destination Unreachable数据包进行响应。不幸的是，许多防火墙可能会削减这些数据包，所以如果你没有得到任何回报，你不确定该端口是否处于这种状态。而且我们不要忘记ICMP会话少，也不会重传：端口无法访问的数据包很可能在网络的某个地方丢失。
我猜，最简单的方法是使用心跳机制。在过去，我们有一个围绕RV的图书馆，可以发布所有客户和订阅的任何主题（包括收件箱），用于各种管理流程。
答案 1 :(得分：1)
（并没有真正回答我自己的问题 - 这是来自同事。）
当我在去年我们不得不写的RV桥上工作时，我遇到了这个问题，因为它正在代理和重写收件箱。事实证明，RV为某些操作（阻塞的）创建了“一次性”收件箱，并且没有发送任何消息（无论如何在该多播上），说收件箱已经消失。收件箱的工作方式似乎是：
换句话说，它是接收守护进程，它必须丢弃在已关闭的收件箱中发送的消息，并且没有与常规订阅结束的“LISTEN.STOP”消息等效。