winapi - C# Sockets vs Pipes -

currently working on multi-process desktop application on windows. application shrink wrapped application deployed on client machines across world. while can have broad specifications machines - e.g. windows xp sp3 .net 4.0 cf, wont have control on them , cant specific on configuration - e.g. cannot specify machine must have cuda 1.4 capable graphic processor etc.

some of these processes managed (.net 4.0) , others unmanaged (c++ win32). processes need share data. options have evaluated date

• tcp sockets
• named pipes

pipes seem perform little better, our needs - performance both acceptable. , sockets give flexibility of crossing machine (and operating systems - support non-microsoft oses eventually) boundaries in future hence our preference going sockets.

however - major concern - if use tcp sockets - run issues firewalls? has else deployed desktop applications / programs use tcp ipc , experienced issues? if - kind?

i know open ended question , glad rephrase. know kind of potential problems run into.

edit: throw little more light - transporting few pods, ints, floats , strings. have built layer of abstraction offers 2 paradigms - request/response , subscription . transport layer has been abstracted away , have 2 implementations - pipe based , tcp based.

performance of pipes better on fast lan tcp better on slower networks or wans. see msdn points below.

tpc more more configurable. concerning firewalls, allow open/close communication ports. if that's not option or concern, 1 other option http (rest/json, web service, xml rpc, etc...) not sure if http overhead acceptable. make sure try real world datasets (passing trivial data in test makes overhead seem unreasonable - often, minor compared real world data set).

some other info msdn:

in fast local area network (lan) environment, transmission control protocol/internet protocol (tcp/ip) sockets , named pipes clients comparable in terms of performance. however, performance difference between tcp/ip sockets , named pipes clients becomes apparent slower networks, such across wide area networks (wans) or dial-up networks. because of different ways interprocess communication (ipc) mechanisms communicate between peers.

for named pipes, network communications typically more interactive. peer not send data until peer asks using read command. network read typically involves series of peek named pipes messages before begins read data. these can costly in slow network , cause excessive network traffic, in turn affects other network clients.

it important clarify if talking local pipes or network pipes. if server application running locally on computer running instance of microsoft® sql server™ 2000, local named pipes protocol option. local named pipes runs in kernel mode , extremely fast.

for tcp/ip sockets, data transmissions more streamlined , have less overhead. data transmissions can take advantage of tcp/ip sockets performance enhancement mechanisms such windowing, delayed acknowledgements, , on, can beneficial in slow network. depending on type of applications, such performance differences can significant.

tcp/ip sockets support backlog queue, can provide limited smoothing effect compared named pipes may lead pipe busy errors when attempting connect sql server.

> in general, sockets preferred in slow lan, wan, or dial-up network, whereas named pipes can better choice when network speed not issue, offers more functionality, ease of use, , configuration options.

for more information tcp/ip, see microsoft windows nt® documentation.