What is rendezvous in interprocess communication?
I found this:
In message passing, it is the condition in which, both, the sender and receiver are blocked until the message is delivered.
I still can't understand why it is called rendezvous.
Can somebody hep but in details please.
Related
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?
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.
(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.
Direct vs Indirect communication
and
Synchronous vs Asynchronous Communication?
In direct communication, it gives the name of the process you are communicating with such as send(destination-process, message) and receive (source-process, message). A link has exactly one pair of communicating processes. Between each pair there exists exactly one link, which may be unidirectional, but is usually bidirectional.
Indirect communication has a unique ID, processes can communicate only if they share a mailbox, also known as ports. During communication a link is established only if processes share a common mailbox. The link may be associated with many processes, and each pair of processes may share several communication links that can be either bi or unidirectional
Synchronous is considered blocking. A blocking receive has the receiver block until a message is available and a blocking send has the sender block until the message is received. For a blocking send/receive, that is called a rendezvous.
Asynchronous is also called non-blocking. For an asynchronous/non-blocking send has the sender send a message and continue. For a non-blocking receive, it has the receiver receive a valid message or it becomes null.
Suppose I have a UDP socket and send a msg to the server. Now how to figure out if the msg has been received by the server?
Coded acknowledgment from server is a trivial option, is there any other way to find out? I guess no..
You can never be sure that a message arrives, even with TCP not. That is a general limitation of communication networks (also applies to snail mail, for example). You can start with the Bizantine Generals Problem if you want to know more.
The thing you can do, is to increase the likelihood of detecting a message loss. Usually that is done be sending an acknowledgement to the sender. But that may get lost too, so for 100% reliability, you would need to send an acknowledgement for the acknowledgement. And then an acknowledgement for the acknowledgement's acknowledgement. And so on.
My advice: Use TCP, if reliability is your main concern. It has been around for some time, and probably won't have some of the flaws a custom solution would have. If you don't need the reliability of TCP, but need low latencies or something else UDP is good at, use UDP. In that case better make sure that it is not a problem if some packets get lost.
IS there a way I can in user-space get notification about a packet being dropped at Layer-2 in 802.11.
According to my understanding what happens is, when a packet is sent out on the medium, there are Layer-2 ACKs which are received if it is delivered correctly (if not,it does the retransmission and ultimately drops the packet if not delivered after several retries..)
I want to be able to access this notification (in user-space)and change the behavior of packet transmission.
I want to be able to send the packet to another host from the FIB rather than dropping the packet.
I have read about libpcap libraries and netfilter hooks which allows me to capture packet and inject them back on the networking stack..
But I'm not able to find hooks (if any, for the wireless stack) to help me capture the packet notification in Layer-2.
Please correct me if I'm not understanding something correctly. Also, any heads-up or links to read would be great.
No, you cannot, at least not using the standardised sockets interfaces. 802.11 is a link layer, and the sockets API is strictly link-layer agnostic: unless it's going to work on all link layers, it's not in sockets. There are good reasons for that: the kind of cross-layer interaction that you envision has been tried many times, and it's always turned out more trouble than it's worth.
You didn't give us any details about the application — but the best solution is most probably to change your application-layer protocol to send explicit acknowledgments, and send your data over the fallback route when you fail to receive an ACK.
If I have a receive primitive where I simply receive a message from a specified sender and I have a receive-all primitive where I receive from any sender, how can this be extended for real-time applications?
This is a question in some course notes I have that I never noticed before :). Any ideas?
An asynchronous receive is a non-blocking receive.
My idea is that we can somehow poll the sender every now and again to check that no messages are getting lost??... I'm not sure. Any ideas welcomed :).
Solution is to use timeouts: Messages can be lost in asynchronous communication so if we are left waiting on a message for too long then we should request to have it resent; a timeout can be used to achieve this.