Of course,
named pipes can be accessible through a network, according to Microsoft documentation:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa365590%28v=vs.85%29.aspx[
^].
If you failed to achieve that kind of communication, I cannot say why, because my access to your hard drive is somewhat limited. :-)
However, the real question is this: is it practical to use this communication possibility or not? I don't think it is practical, unless you already have some legacy code which is heavily based on named pipes and you need to extend the existing well-working functionality from local to network communication.
The problem is that the pipes are accessed remotely indirectly, through an additional system network service which somehow relays the pipe to the network stream. I don't think this is good for performance. (However, I much admit I never compared.)
There is one much more important problem with named pipes: if you implement network functionality, it would not be good enough to make your system
heterogeneous, working with hosts using different software platforms. Please see below.
For new development, I think it's much better to develop communication based on
sockets and Internet protocols, or some class libraries based on sockets:
http://en.wikipedia.org/wiki/Network_socket[
^],
http://msdn.microsoft.com/en-us/library/windows/desktop/ms740673%28v=vs.85%29.aspx[
^],
http://technet.microsoft.com/en-us/library/cc958787.aspx[
^].
In contrast to Windows named pipes, socket communications can be done multiplatform, which is very important even if you work only on Windows. Who knows what requirements can you face in near future?
—SA