CODEWITHSUNDEEP
c#.netpipenamed-pipes
fingerprint211b
fingerprint211b

Reputation: 1186

Having problems with .NET named pipes and ambiguous exceptions

I've written a client that connects to a server via a named pipe, and it works fine with my server. However, when I try to connect to a remote server, it fails when I call Connect(), and throws "Request not supported exception", and I have no idea what that means (tried looking on msdn, didn't help).

This is the relevant piece of code. I am sure the server and the path exist, because another client (whose source I can't see, but I know it uses nxpipe) can connect to it. 

NamedPipeClientStream stream = new NamedPipeClientStream(serverName, pipeName, PipeDirection.InOut);
stream.Connect(timeout);

Does anyone have any ideas what that means?

Thanks.

EDIT (SOLVED) : You will NOT BELIEVE what the problem was. First, the guy that ordered the app forgot to ran the server app and open the pipe, so we spent hours trying to figure out what's going on, assuming the pipe is opened on the remote machine. After he remembered that he forgot to run the server app (a few days later), we still had problems. At that point I already wrote a client using .NET pipes and the native pipes using CreateFile. Turns out the guy also forgot to tell us the whole name of the pipe (weird that we got "request not supported" for invalid pipe name, though). Luckily we had an app they used earlier, which had part of that pipe name hardcoded (and part of it you still had to specify) so we used process explorer to figure out the full name of the pipe and finally connected. Now it works :|

Upvotes: 1

Views: 2725

Answers (2)

Chris Dickson
Chris Dickson

Reputation: 12135

I think this must be a Win32 IO exception (ERROR_NOT_SUPPORTED - error code 50). If so it will be coming from the RPC/SMB protocol by which named pipe communications are remoted from one machine to another. It means that one side is trying to invoke a protocol operation which is not supported by the other side.

In your context I imagine this means that the security context from which you are trying to initiate the named pipe communication is not compatible with what is supported by the other side (or conceivably even some firewall in between which has rules at the protocol level).

If both sides were Windows machines I would start by checking using NET USE whether the security context on the initiating side can establish a connection to the IPC$ share on the other side. I afraid I have no knowledge of the Libra mainframe or what difference this might make.

Upvotes: 1

Mark Avenius
Mark Avenius

Reputation: 13947

Named pipes only exist within the current machine. You need to use something like TCP to cross the machine boundary.

EDIT:

Correction, according to this, it is possible across a network. I must have been mistaken, and perhaps the default behavior is that access to NT AUTHORITY\NETWORK is denied.

Upvotes: 1

Related Questions