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.)
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.