4

I am currently working on a rather large single-threaded, event-based, application designed around epoll under Linux and comparable technologies under other platforms. Currently, whenever we wish two instances to communicate, they typically do it through sockets, whether they are running on the same machine or not. For performance reason, I'm envisioning the use of some form of IPC to speed-up same machine communication. Now, I need to decide of which IPC mechanism to use.

The following factors are important to me:

  • event-driven, without complete redesign -- if the IPC mechanism doesn't fit well with epoll, that's months of work lost for me
  • fast -- if this mechanism is not faster than sockets, it's not worth the time implementing it
  • flexible and (re)configurable during execution -- I believe that this rules out MPI & al
  • no multi-threading required.

I'm willing to use different mechanisms for different platforms, as long as they all use the same paradigm. I'm also willing to get as deep as needed into C / C++ / Obj-C for platform-specific bindings.

Any suggestion?

Thanks.

Yoric
  • 3,348
  • 3
  • 19
  • 26
  • 1
    By the way, sockets have much better performance when they are open on the same machine: http://stackoverflow.com/questions/1644851/sockets-on-same-machine-for-windows-and-linux/1650906#1650906 –  Dec 06 '10 at 10:38
  • Well, in my experience, IP sockets don't. – Yoric Jan 24 '11 at 13:44

3 Answers3

3

Unix sockets. Named pipes. FIFOs.

These all offer the same basic functionality - same machine cross-process communications. The implementations offer slightly different behaviours though.

They all use file descriptors, so you can literally just plug them in where your socket used to be.

AlastairG
  • 4,119
  • 5
  • 26
  • 41
  • IIRC, FIFOs are implemented on top of pipes, and pipes have a reputation for not being too fast (I haven't checked that in years, so I might not be up-to-date on the topic). – Yoric Dec 06 '10 at 11:14
  • 1
    *nixes have traditionally spent quite some time optimizing their pipe implementation. They're not slow, but among the fastest IPC mechanism there is. – nos Dec 06 '10 at 12:26
2

indeed, as skwllsp mentioned, the AF_INET sockets are optimized for data transmission on local host and the speed and complexity is comparable (almost the same?) with fifos,pipes,unix sockets ( a lot of skbuff processing is skipped if the destination is the same host). my 2 cents is to use sockets. this way not only that you keep the same interface for your IPC mechanism but you successfully reuse your code for both remote and local scenarios.

user237419
  • 8,829
  • 4
  • 31
  • 38
0

Try out Unix SysV IPC. It supports:-

  • Message queues
  • Semaphore
  • Shared memory

which might help you.

This link might help more: http://www.ibm.com/developerworks/aix/library/au-ipc/index.html

Omid
  • 160
  • 2
  • 9
  • Is SysV IPC really compatible with the epoll approach? I was under the impression that this wasn't the case. – Yoric Dec 09 '10 at 21:35
  • I couldn't find any reason for incompatibility, but to be honest still I'm not sure! Well the thing is SysV IPC is just another type and as long as you manage to use socket (although I don't know which socket did you use, I guess TCP though) then it shouldn't be an issue. – Omid Dec 11 '10 at 03:03
  • Let me rephrase: epoll is very much fd-oriented. SysV IPC uses a completely event system, doesn't it? So I'd essentially have to poll from two sources instead of one? – Yoric Dec 14 '10 at 13:46