I have a large C#/WPF application. This application needs to collect data from other, "sub", applications that will be running on a Windows service - same network, different PC. Is sockets the best way to handle communications between the two (as opposed to remoting or something else)?
+5
A:
WCF is the recommended approach for cross process communication in v3.5 and newer. Sockets and Named Pipes could/would work, but you'll find much better support via WCF.
JeffN825
2010-09-14 00:01:54
upboated for the support comment.
DaveE
2010-09-14 00:09:27
+2
A:
I would say that it ultimately depends on your performance requirements. Look at WCF as a layer of abstraction way above sockets. The price you pay for layering is performance, but I would be surprised if WCF did not offer sufficient performance for you.
Christopher Hunt
2010-09-14 00:24:47
Wcf failed miserably for us when shipping large amounts of strings between processes/machines and documentation for the myriad of configuration options is pretty poor. Memory seems to be particularly badly managed when thrashing Wcf connections. We ended up writing our own Rpc implementation to keep memory and Cpu to more reasonable levels, but that's a pretty tough job.
spender
2010-09-14 00:40:56
I must say that I'm surprised, but then, that's a reasonably familiar feeling to me. :-)
Christopher Hunt
2010-09-14 00:45:20
A:
Sockets is the fastest thing you can get, so if you need to make it as fast as you can you should use sockets. They're more complicated then WCF but in return you get full control on the lowest level.
Also be prepared that the actual bottleneck will be in Serialization/Deserialization of objects passed between client and server (of course if they're complicated).
Kirill Muzykov
2010-09-16 18:10:14