Currently I am working on a multi-process desktop application on Windows. This application will be a shrink wrapped application which will be deployed on client machines across the world. While we can have broad specifications for the machines – e.g. Windows XP SP3 with .Net 4.0 CF, we wont have control over them and we cant be too specific on their configuration – e.g. we cannot specify the machine must have a cuda 1.4 capable graphic processor etc.
Some of these processes are managed (.Net 4.0) and others are unmanaged (C++ Win32). The processes need to share data. The options I have evaluated to date are
- Tcp sockets
- Named Pipes
Pipes seem to perform a little better, but for our needs – performance from both are acceptable. And sockets give us the flexibility of crossing machine (and operating systems – we would like to support non-Microsoft OSes eventually) boundaries in the future hence our preference for going with sockets.
However – my major concern is this – If we use Tcp sockets – are we likely to run into issues with firewalls? Has anyone else deployed desktop applications / programs that use TCP for IPC and experienced issues? If so – what kind?
I know this is a fairly open ended question and I will be glad to rephrase. But I would really like to know what kind of potential problems we are likely to run into.
edit: To throw a little more light – we are only transporting a few PODs, ints, floats and strings. We have built a layer of abstraction that offers 2 paradigms – a request/response and subscription . The transport layer has been abstracted away and currently we have two implementations – pipe based and TCP based.
Best Answer
Performance of pipes is often better on a fast LAN but TCP is often better on slower networks or WANs. See msdn points below.
TPC is also more configurable. Concerning firewalls, they allow you to open/close communication ports. If that's not an option or a concern, an alternative would be http (REST/json, web service, xml rpc, etc...) but you have to consider if the http overhead is acceptable. Make sure you try it with real world datasets (passing trivial data in a test makes the overhead seem unreasonable, which would be very reasonable with a real world data set).
Some other info from msdn: