Pipes between Windows and Linux Apps

Question

If I have a Windows and a Linux machines on the same LAN, can I use (named) pipes to talk between the two?

I am specifically thinking of using System.IO.Pipes namespace in C# or VB.NET on the Windows side.

Answer 1

UNIX Named pipes are NEVER used for intermachine communication. A named pipe is a special inode in the filesystem (that makes it have a name like any other file) One process calls open(2) for reading or writing (normally one process opens it for reading and the other for writting) and other process connect to it via the named FIFO. The named fifos are implemented specially in the kernel, as when the FIFO is empty, a process reading from it will be blocked waiting for it to have data. Also, when a process fills up the FIFO (they have limited capacity, as they use a small amount of blocks from the inode pointers --- only the direct blocks) it's blocked on writting until some reader empties the fifo data.

As one file in the filesystem is only visible in the server hosting it, it has no network visibility, and cannot be used as a network communications mechanism.

For network communication you have the socket(2) (and friends) interface. There exists also what is called Unix domain sockets, which are sockets in the sense of being bidirectional (and you have to connect them, also) but are only for local use, mainly because they don't use the full TCP/IP stack to comunicate one end to the other. They appear like this (with a p in the first mode position) in the ls(1) listings:

luis@asus-luis:/run$ ll hogsuspend 
prw------- 1 root root 0 ago 10 16:54 hogsuspend

and unix sockets do it so:

luis@asus-luis:/run$ ll /dev/gpmctl 
srwxrwxrwx 1 root root 0 ago 10 16:54 /dev/gpmctl

(with an s)

---

@mcu, to be able to use some communication means between machines in a network you need to use network compatible technology. Pipes were first invented in unix environments, and didn't use at all networking capabilities, and that has been true since then, and Microsoft adapted the term to something they use to intercommunicate their machines. Today all the communication infrastructure in Windows uses partly or completely TCP/IP stack. This means that named pipes, when it is the case to use network resources, somehow, should use some kind of process making a gateway to TCP/IP resources. In that case, probably a TCP socket (if you want to maintain reliability) will be used to make the interconnection between machines. I don't know actually the mechanism behind Windows named pipes or how the interoperate with the network. I'll find some information for you and try to extend my explanation to be useful for you. UNIX named pipes appear in the system's filesystem and so, are not visible (and in case they are, using NFS or some other network capable remote filesystem access, don't give transparent acces to the remote resources as if they were a local resource)

The term unix named pipe was coined to represent an interprocess communication object used to provide half-duplex, transparent comunication between two processes. The name was coined from water pipes, that were used to transfer continously water(data) between two points in a serialized, reliable way.

Windows borrowed the concept and implemented some SOCKET like object, but with a NetBios based naming structure. This means that if you use Windows on top of TCP/IP stack (this is NetBios runs using TCP/IP sockets, which can be not the case) you still need some way (this is provided as a NetBios service) to map a pipe name (something in the form \\machine\pipe_name following Netbios naming, into a host ip/address and a port number) through a NetBios call (this can be available if you install on linux/unix some software like Samba) or you implement that service yourself on top of TCP/IP.

Unix pipes exist since the beginnings of unix, and probably named pipes were introduce around year 1975 or 1978 (still two years to wait for MS-DOS to be born, and more to see Microsoft Windows living)

The concept named pipe used in Windows is complete different thing that as it is used in unix (or linux) and so, you should consider using a Linux socket for the thing. But in order to communicate with a Windows named pipe, you need to still know how windows maps named pipes into tcp/ip sockets --- and that only, which is normally the case, that Windows is using its SMB sockets (IMHO better name than pipes, as they represent a point to connect, and not the full connection channel, despite what Microsoft can think)---

Answer 2

Named pipes alone cannot accomplish this over IP. The simplest solution is that you create a named pipe on each machine and use netcat (nc in Linux) to send information between the pipes.

I don't know how that works in Windows, but I can give an example of doing it in Linux (rather, any modern Unix), and there's probably some easy way to do adapt this for Windows:

machinea wants to talk to machineb. A opens named pipe at /tmp/mypipe that some program writes to. B opens named pipe at /tmp/mypipe that some program reads from. B runs nc -l 9000 > /tmp/mypipe to listen for TCP/IP connections on port 9000 and write the output to the named pipe. A runs cat /tmp/mypipe | nc machineb 9000 to read from its named pipe and pipe the read data to netcat to send it to machine B. Of course, the programs running on A and B don't "care" whether the pipe information is going over TCP/IP; netcat handles that, and they just talk to their named pipes, however they're supposed to do that.

You may need to fiddle with the order in which you open the named pipes, open the programs that read/write to/from them, and run the netcat commands. I'm answering this from memory.