Named Pipes ? XML-RPC ? Standard Input-Output ? Web Services ?
I would not use unsafe stuff like Shared Memory and similar
+3
A:
Named pipes would be the fastest method, but it only works for communication between processes on the same computer. Named pipes communication doesn't go all the way down the network stack (because it only works for communication on the same computer) so it will always be faster.
I left out Shared Memory since you specifically mentioned that you don't want to go that route. Shared Memory would be even faster than named pipes tho.
So it depends if you only need to communicate between processes on the same computer or different computers. Any XML-based communication protocol (eg. Web Services) will usually be slower due to the massive overhead in XML.
Jaco Pretorius
2010-01-05 06:32:41
Named pipes *can be* and *are* used for communication with remote processes. It's *anonymous pipes* that can only be used for local processes.
Aaronaught
2010-03-23 17:34:04
Are you sure of that? In .NET remoting I've always been of the opinion that it can only be used between local processes...
Jaco Pretorius
2010-03-24 08:36:14
Yes, named pipes were meant to be used for client/server communications, much like sockets, but unlike sockets some client operating systems can't be "servers".
Dave Van den Eynde
2010-03-25 13:42:40
+1
A:
i don't think there's a quick answer to this. if i was you, i would buy/borrow a copy of Advanced Programming in the Unix Environment (APUE) by Stevens and Rago and read Chapter 15 and 16 on IPC. It's a brilliant book if you really want to understand how *nix (a lot of it applies to any POSIX system) works down to the kernel level.
If you must have a quick answer, i would say the following (without putting a huge amount of thought into it), in descending order of efficiency:
Local Machine IPC
- Shared Memory/Memory Mapped files
- Named Pipe/FIFO (only between related processed - i.e. fork)
- Unix Domain Socket
At both levels, you are going to have to think about how the data you transfer is encoded/decoded and trade off between memory usage and CPU utilization.
At the Network level, you will have to consider what layers of protcols you are going to run on top of. Most commonly, at the bottom of the application layer you will be choosing between TCP/IP or UDP. TCP has a lot more overhead as it is does error correction, checksumming and lots of other stuff. if you need in order delivery of messages you need to use TCP as opposed to UDP.
On top of these are other protocols like HTTP, SOAP (on top of HTTP or another protocol like FTP/SMTP etc.). A binary protocol is going to be more efficient as long as you are network bound rather than CPU bound. If using SOAP on the MS.Net platform, then binary encoding of the messages is going to be quicker across the network but may be more CPU intensive.
I could go on. it's not a simple question. Learning where the latencies are and how buffering is handled are key to being able to make decisions on the trade offs you are always forced to with IPC. I'd recommend the APUE book above if you really want to know what is going on under the hood...
billywhizz
2010-03-23 17:25:04
yes, but he also said mono and there is nothing stopping you using any of these methods in C# or any other language really. C# is a language. not an OS. A bit unfair marking my answer down i think...
billywhizz
2010-03-23 17:30:07
A:
Windows Messaging is one of the fastest ways for IPC, after-all Windows is built on them.
It's possible to use WM_COPYDATA with IPInvoke calls to exchange data between 2 form based .Net applications, and I've got an open source library for doing exactly that. I've bench marked around 1771 msg/sec on a fairly hot laptop.
TheCodeKing
2010-03-25 13:34:37