How to use named pipes over network?

Question

I'm trying to create a connection over network via named pipes. I'm doing it as it says in msdn. I create pipes server side with function.

CreateNamedPipe(
                     "\\\\.\\pipe\\myNamedPipe",
                     DUPLEX | FILE_FLAG_OVERLAPPED,
                     0,
                     255,
                     BUFFER_SIZE,
                     BUFFER_SIZE,
                     0,
                     IntPtr.Zero);

and trying to connect via CreateFile() function

CreateFile(
                  "\\\\10.0.0.29\\pipe\\myNamedPipe",
                  GENERIC_READ | GENERIC_WRITE,
                  0,
                  IntPtr.Zero,
                  OPEN_EXISTING,
                  FILE_FLAG_OVERLAPPED,
                  IntPtr.Zero);

10.0.0.29 is server machines ip. If I'm trying to run client side program on server machine with pipe name "\\.\pipe\myNamedPipe" or "\\10.0.0.29\pipe\myNamedPipe" (10.0.0.29 is servers ip) or "\\localhost\pipe\myNamedPipe" it works fine.

So how to use named pipes over network?

What error are you getting when you try to run the client remotely? Your problem is almost certainly that the remote client cannot satisfy security requirements: this may be the default access control on the pipe itself, or something in the network stack (e.g. firewall). — Chris Dickson, May 25 '11 at 08:18
@Chris: Error code is 4, which means **The system cannot open the file.** — Samvel Hovsepyan, May 25 '11 at 10:39
@Chris: With network I think everything ok (firewall turned off), how can I see pipes default access control? — Samvel Hovsepyan, May 25 '11 at 10:45

score 3 · Answer 1 · answered May 25 '11 at 06:46

3

Starting with version 3.5, named pipes are supported natively in the .NET Framework, you don't have to use tedious interop p/invoke code. See this introduction article here: .NET 3.5 Adds Named Pipes Support for a sample.

Using this constructor overload, NamedPipeClientStream Constructor (String, String), you can pass a server name argument.

answered May 25 '11 at 06:46

Simon Mourier

132,049
21
248
298

True, sort of - though "supported natively" is a bit misleading since the .NET System.IO.Pipes classes are just managed wrappers which use native Win32 APIs in a similar way to what the OP is doing. But is this an answer to his question? – Chris Dickson May 25 '11 at 08:22
@Chris - Well. I'm not the one who marked this as an answer :-) Since its much simpler and takes care of p/invoke issues, I definitely thinks it's an answer to the question "how to use named pipes over network". Concerning the "natively" term, it's arguable. There's a difference in "supported" (almost everything is supported in .NET with p/invoke) and "it's there available in the API". How would you say that? – Simon Mourier May 25 '11 at 08:35
OK, I don't really disagree with you... it was just that the question and other comments seemed to indicate that the problem was that execution locally worked but execution remotely failed, and it's not clear that the cause of that has been resolved... @Samvel Hovepyan: have you got it working remotely now? – Chris Dickson May 25 '11 at 09:22
@Samvel - ok, so it's probably an infrastructure problem. Check firewalls as Chris said. Note: windows error 4 is ERROR_TOO_MANY_OPEN_FILES. – Simon Mourier May 25 '11 at 12:35

score 2 · Answer 2 · edited Jul 11 '17 at 07:02

2

Pipe Server must have a name you need to specify a name for the server and not IP address.

See this tutorial.

However named pipes are convenient for local connections, because on the Network you get the overhead of TCP encapsulating making using named pipes inconvenient.

Using named pipes for local connection improve speed but over the network doesn't have much sense ... Use Socket ...

edited Jul 11 '17 at 07:02

konzo

1,973
22
32

answered May 25 '11 at 06:23

aleroot

71,077
30
176
213

Thanks for the answer, but in tutorial both and server side and client side work on the same computer. I try demo program for the network but it does not work. – Samvel Hovsepyan May 25 '11 at 06:56
Firewall configuration on server? – Vnuk May 25 '11 at 06:58

score 2 · Answer 3 · answered Mar 27 '12 at 22:08

I think the question is answered above, but keep in mind there is a big problem using named pipes that are opened to a remote machine. When you call the windows API function WaitNamedPipe with a timeout greater than 0, the calling thread will use a whole CPU until the named pipe either connects or times out. With a timeout of 0, it doesn't have enough time to make a remote connection, so you are basically forced to use all of a CPU each time you try to connect, and all you can do is time out, and try again later.

I encountered this problem and found I wasn't alone: http://social.msdn.microsoft.com/Forums/sv-SE/netfxnetcom/thread/7bbf5a0b-3c22-4836-b271-999e514c321b

Until Microsoft provides a more performance friendly way of connecting to remote named pipes, I'm going to stop using them entirely, and I suggest you do the same. If for any reason you're unable to connect almost immediately, you end up with a livelock.

How if you are using io completion ports properly is a named pipe using 100% cpu? It should be no different than a non-blocking tcp connection. — Jonathan Henson, Sep 12 '18 at 03:36
@JonathanHenson It's a bug - according to a comment [here](https://stackoverflow.com/a/9959061/1086351) it may be fixed in Windows 10. — fcrick, Sep 19 '18 at 16:32

How to use named pipes over network?

3 Answers3

Linked