2

In IPC code if i get a handle from a named pipe by using the Win32 API by calling CreateFile everything works. If i do the same thing using the NamedPipeClientStream it does not want to connect.

Working Version

[DllImport("kernel32.dll")]
internal static extern SafePipeHandle CreateFile(
          string lpFileName,
          uint dwDesiredAccess,
          uint dwShareMode,
          IntPtr securityAttributes,
          uint dwCreationDisposition,
          uint dwFlagsAndAttributes,
          IntPtr hTemplateFile);        

public openPipe()
{

     SafePipeHandle localDeviceHandle;
     // Second Paameter is READ/WRITE Access, Fifth Parameter Open Existing 
     // This was done for brevity of the example.
     localDeviceHandle = FileApi.CreateFile("\\\\.\\SeaMAC0", 
                                            (uint)3, 
                                            0, 
                                            IntPtr.Zero, 
                                            (uint)3, 
                                            (uint)FileApi.FileAttribute.Normal, 
                                            IntPtr.Zero);
}

Non Working

public openPipe()
{

  SeaLevelNamedPipe = new NamedPipeClientStream("SeaMAC0");

  /*or SeaLevelNamedPipe = new NamedPipeClientStream(".","SeaMAC0");*/

   SeaLevelNamedPipe.Connect(); //It will hang here for ever   
}

The code here is far from complete and done for brevity. Shouldn't they function the same?

I do not have access to the server pipe code as this was developed by a third party.

ΩmegaMan
  • 29,542
  • 12
  • 100
  • 122
56K
  • 37
  • 1
  • 6

1 Answers1

1

You are not using a valid named pipe name for the lpFileName argument in your first "this works" example. This: "\\\\.\\SeaMAC0" is not a valid named pipe name.

Refer to the documentation on Pipe Names:

Use the following form when specifying the name of a pipe in the CreateFile, WaitNamedPipe, or CallNamedPipe function:

\\ServerName\pipe\PipeName

where ServerName is either the name of a remote computer or a period, to specify the local computer. The pipe name string specified by PipeName can include any character other than a backslash, including numbers and special characters. The entire pipe name string can be up to 256 characters long. Pipe names are not case-sensitive.

The pipe server cannot create a pipe on another computer, so CreateNamedPipe must use a period for the server name, as shown in the following example.

\\.\pipe\PipeName

Thus, in your second "does not work" example, the constructed pipe name that the .NET NamedPipeClientStream, will use to connect to the server pipe is:

\\.\pipe\SeaMAC0

Which is subsequently used in a call to the WaitNamedPipe Win32 method to try to connect to the named pipe server, in a connection loop, with an infinite time-out when Connect is called. Given the fact that no pipe server with the given name exists, it will end up exactly as you described: waiting, forever alone.

Note that for your used file name ("\\\\.\\SeaMAC0"):

Win32 Device Namespaces

The "\\.\" prefix will access the Win32 device namespace instead of the Win32 file namespace.

...

If you're working with Windows API functions, you should use the "\\.\" prefix to access devices only and not files.

So e.g. \\.\COM1 will open a handle to the COM1 device, and \\.\DISPLAY1 represents the default display device. If SeaMAC0 is not an actual device name on your system, your "Working Version" likely returned a handle that was invalid. If such a device did exist, it returned a handle to the device, not to a named pipe instance.

Alex
  • 13,024
  • 33
  • 62
  • Actually it is a device http://www.sealevel.com/store/serial/synchronous-serial/pci-express/5103es-pci-express-1-port-rs232-synchronous-serial-interface-uses-z85230.html its a Synchronous serial card.But thank you for the link it will give me a chance to read up more on this. – 56K May 22 '15 at 01:00
  • @56K It would seem that information was quite relevant to your question. You may want to edit it and add the information. Also that means this answer still explains why you were seeing the behavior you observed. I will update the answer to incorporate your new information. – Alex May 22 '15 at 18:48