Question

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.

Answer 1

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:

In a fast local area network (LAN) environment, Transmission Control
Protocol/Internet Protocol (TCP/IP) Sockets and Named Pipes clients
are comparable in terms of performance. However, the performance
difference between the TCP/IP Sockets and Named Pipes clients becomes
apparent with slower networks, such as across wide area networks
(WANs) or dial-up networks. This is because of the different ways the
interprocess communication (IPC) mechanisms communicate between peers.

For named pipes, network communications are typically more
interactive. A peer does not send data until another peer asks for it
using a read command. A network read typically involves a series of
peek named pipes messages before it begins to read the data. These can
be very costly in a slow network and cause excessive network traffic,
which in turn affects other network clients.

It is also important to clarify if you are talking about local pipes
or network pipes. If the server application is running locally on the
computer running an instance of Microsoft® SQL Server™ 2000, the local
Named Pipes protocol is an option. Local named pipes runs in kernel
mode and is extremely fast.

For TCP/IP Sockets, data transmissions are more streamlined and have
less overhead. Data transmissions can also take advantage of TCP/IP
Sockets performance enhancement mechanisms such as windowing, delayed
acknowledgements, and so on, which can be very beneficial in a slow
network. Depending on the type of applications, such performance
differences can be significant.

TCP/IP Sockets also support a backlog queue, which can provide a
limited smoothing effect compared to named pipes that may lead to pipe
busy errors when you are attempting to connect to SQL Server.

> In general, sockets are preferred in a slow LAN, WAN, or dial-up
network, whereas named pipes can be a better choice when network speed
is not the issue, as it offers more functionality, ease of use, and
configuration options.

For more information about TCP/IP, see the Microsoft Windows NT®
documentation.