tags:

views:

170

answers:

2

I'm working on what should (hopefully) be a small feature for a .NET software solution that will allow one application to report on the status of multiple instances of another application running on more than one computer on the same network.

I took a look at this MSDN article on named pipes, and set up a simple client/server project that worked great. However, this was only two processes running on the same computer (so for the NamedPipeClientStream constructor, I passed "." as the serverName parameter). Attempting to run this same project on separate machines on the same network caused the client process to fail, reporting that the network path was not found.

This could definitely just be a matter of me passing the wrong string as serverName from within the client process. (I tried the IP address as well as what I believe was the machine's network name, but perhaps I had the format wrong.) In any case, some help on getting client/server IPC working on separate machines on the same network would be much appreciated. (I am also asking this question because I don't even know if using named pipes is the most logical solution in the first place.)

+4  A: 

Named pipes will work, but it's tricky to get it to work if all of the computers are not on the same domain.

Another option, of course, is just to use sockets. It's not much more complicated to use sockets than it is to use Named Pipes.

Finally, if all applications are .NET, then WCF is an option as well. The main benefit here is that you don't have to worry the over-the-wire protocol, it's just a series of methods calls. Though WCF does add some overhead in terms of security and configuration.

Dean Harding
+1 WCF, for .NET, is the way to achieve this.
Will Marcouiller
@codeka: Wow, you mentioning that pipes are tricky across domains was quite eye-opening for me; I was indeed trying to use them from two different domains. I gave it another shot on two computers in the same domain and it worked perfectly. More importantly, your suggestion to look into WCF (all the applications are indeed in .NET) was very helpful. I'm looking into that now.
Dan Tao
A: 

MailSlots is another alternative that might work for you, it allows messages to be broadcast to targeted machine or a local network.

I have an open source implementation wrapped in a C# library that may help. It uses a MailSlot implementation for network propagation, but also falls back to WM_COPYDATA windows messages or IOStreams in order to dispatch messages to all processes on a single machine. This gets around a limitation that only one process can read a MailSlot message.

http://xdmessaging.codeplex.com/

TheCodeKing