| |||||||||||||
Fast interprocess communication revisitedFast interprocess communication revisitedPosted Nov 10, 2011 4:58 UTC (Thu) by dlang (✭ supporter ✭, #313)Parent article: Fast interprocess communication revisited
> All of the high-level APIs for IPC make a distinction between requests and replies, connecting them in some way to form a single transaction. Most of the in-kernel support for messaging doesn't preserve this distinction with any real clarity. Messages are just messages and it is up to user space to determine how they are interpreted.
if you have not already looked at the zero MQ guile (0MQ http://zguide.zeromq.org/page:all ), you should probably do so. There is a very interesting situation that shows up about halfway through where you take a standard 'request-response' sequence and flip it around so that the server process that's going to provide the service sends the 'request' and the 'response' is from the client asking the server process to do something.
think carefully about what terminology you use, when the technology gets twisted in interesting ways, the words you pick may end up causing confusion.
the 0MQ guide has a lot of discussions about different ways to use IPC messages, while still leaving the contents of the messages (outside the routing) as having meaning only to the application.
(Log in to post comments)
Fast interprocess communication revisited Posted Nov 18, 2011 6:00 UTC (Fri) by sustrik (guest, #62161) [Link]
Ah. I see 0MQ is mentioned here. I am the person who designed it -- if you are interested in this kind of thing see my comment below about the kernel-space implementation of 0MQ-like system.
|
|||||||||||||