3

I need to update multiple processes with several different pieces of data, at varying rates, but as fast as 10 Hz. I don't want the receiving processes to have to actively get this data, but rather have it pushed to them, so that they only have to do anything about the new data when there actually is any (no polling).

I'm only sending probably a few bytes of data to each process. The data being transmitted will not likely need to be stored permanently, at least not before being received and processed by the recipients. Also, no data is updated less frequently than once every few seconds, so receiver crashes are not a concern (once a crashed receiver recovers, it can just wait for the next update).

I've looked at unix domain sockets and UDP and a little bit at pipes and shared memory, but it seems that they don't quite fit what I'm trying to do:

  • Domain sockets require the sender to send a separate message to each recipient (i.e., no broadcasting/multicasting)
  • Shared memory has the disadvantage of having the clients check that data has been updated (unless there's a mechanism I'm not familiar with that can notify them)
  • UDP doesn't guarantee that the messages will arrive (maybe not likely a problem for communication on the same computer?), and I have some concern about the overhead from the network stack (which domain sockets doesn't have)

The concern about TCP (and other protocols that support inter-device communication) is that there is functionality that's not needed for interprocess communication on a single device, and that that could create unnecessary overhead.

Any suggestions and direction to references and resources are appreciated.

hBrent
  • 1,696
  • 1
  • 17
  • 38
  • I am likely missing something and I am a bit puzzled at the "too broad" label. hBrent covered fundamental interprocess communication, Maxim suggested persistent unstructured and structured shared storage, and I touched on one example of a messaging queue library. It seems to me we've covered a goodly portion of the general answer space for hBrent's question. Or perhaps you have a concern people will start pumping out too many detailed examples from these general areas? Or is your too-broad concern coming from something else? – David Pointer Jun 27 '14 at 19:50
  • I edited my question after it was put on hold. If it doesn't meet the requirements for being removed from being on hold, please provide some feedback (as specific as possible) about how I may get it to the point of acceptability. Thanks. – hBrent Jun 30 '14 at 17:11
  • What I see you asking is "how can I communicate small amounts of data between Unix processes?" You've examined the usual suspects in Unix IPC and stated their deficiencies from your point of view. I wonder if perhaps the wording of "Any suggestions and direction to references and resources are appreciated." puts people off. Even though the topic area is not broad, that last question might be considered too-broad. What do you think about being very specific in your final question? (I am just guessing, btw, I was hoping the high-rep people would respond.) – David Pointer Jun 30 '14 at 18:59
  • @DavidPointer, I think you may be right. I'll see if I can't be more specific with that final question. I should also look at the rules in the help center, so I get a better idea of what's expected. I also don't know if the question is getting reviewed every time I edit it or if something else triggers reconsideration. – hBrent Jul 01 '14 at 15:01

2 Answers2

3

Have you looked at zeroMQ? It is a lightweight messaging library that supports various push/pull access patterns over several transport mechanisms.

David Pointer
  • 905
  • 2
  • 18
  • 31
  • Awesome. Didn't know about ØMQ. Upvoted. – Joshua Huber Jun 26 '14 at 16:35
  • @JoshuaHuber Excellent! Apache Storm uses it under the hood, so it's well tested and supported. – David Pointer Jun 26 '14 at 16:38
  • 4
    Downvoter, could I get an informative explanation please? I'd like to continue to learn how to make my answers more useful. – David Pointer Jun 26 '14 at 16:41
  • I'd also like to know the reason for the downvote(s), as this seems like a viable solution. – hBrent Jun 26 '14 at 17:38
  • 2
    Was reading the manual for zeroMQ and really liked this view of its authors (quoting): "Take a typical open source project like Hadoop Zookeeper and read the C API code ... 4,200 lines of mystery and in there is an undocumented, client/server network communication protocol ... Zookeeper should be using a generic messaging layer and an explicitly documented wire level protocol. It is incredibly wasteful for teams to be building this particular wheel over and over." – Joshua Huber Jun 26 '14 at 23:04
2

One option is to write flat files or SQLite database on the same box.

And have another control file with a process shared mutex, condition variable and record count mapped into memory of the publisher and subscribers. This is the notification mechanism.

This way you would have full history of records in the file or the database which makes it easy to replay records, debug and recover subscribers from crashes.

The publisher would:

  1. Map the control file into memory.
  2. Add new records to the file or the database.
  3. Lock the mutex.
  4. Update the record count.
  5. notify_all on the condition variable.
  6. Unlock the mutex.

The subscribers would:

  1. Map the control file into memory.
  2. Lock the mutex.
  3. Wait on the condition variable till there are new records (each subscriber maintains its own count of already processed records).
  4. Unlock the mutex.
  5. Process the new records from the file or the database.
Maxim Egorushkin
  • 131,725
  • 17
  • 180
  • 271
  • Thanks for the very detailed solution. I think it may be more complicated than is needed. I should have made it clear that the data in question is status information of which no permanent record is likely required (I'll edit the question). – hBrent Jun 26 '14 at 16:55