Implement NamedPipe*Stream on Unix domain sockets #6833

stephentoub · 2016-03-11T18:50:51Z

Today, NamedPipeServer/ClientStream on Unix are implemented on top of FIFOs, aka named pipes. There are some unfortunate limitations to this that are causing problems for typical usage of NamedPipeServer/ClientStream:

FIFOs can be constructed as both read and write (i.e. InOut), but a writer can then immediately read what was written. In other words, whereas one might expect there two be two data channels, one in each direction, there's only one that everyone can read and write from.
FIFOs can be connected to by any number of readers and writers, which has the effect of meaning a reader doesn't unblock when a writer disconnects, because there may be another writer in the future.

To address these significant limitations, this commit moves NamedPipeServer/ClientStream to be built instead on top of Unix domain sockets. Unix domain sockets are an IPC mechanism for local communication using the sockets model, and we have support for it via System.Net.Sockets, thanks to #5051.

Both of the aforementioned problems are addressed by this change. A few other positive outcomes:

The participants on each side of the connection can get the credentials of the other side, so GetImpersonatedUserName is now implemented.
Our Socket implementation has a good async implementation, so we can use it for all of the async operations exposed rather than queueing a work item that then blocks doing the synchronous operation.

There are a few downsides, but they're worth the tradeoff:

FIFOs have the same general blocking behavior as anonymous pipes and as named pipes on Windows: a call to Write doesn't complete until an associated Read comes along. That's not the case with Unix domain sockets, where a Write typically just deposits the data into a buffer. Writes on a socket only block when the buffer is full.
Unix domain sockets are considered to be a bit slower than FIFOs.
Changing the buffer size of a FIFO impacts the whole FIFO, whereas changing the buffer size for a socket impacts just that end of the socket.
There's also a small hack that uses reflection to work around #6807, the lack of an exposed handle property on Socket. Hopefully that'll be fixed soon and then we can remove the hack.

There continue to be several features that we don't support on Unix, e.g. message transmission, max number of servers, etc.

(One oddity here is that this makes the Unix implementation of System.IO.Pipes.dll have a dependency on System.Net.Sockets.dll, but I spoke with @weshaggard and, other than it being odd, we couldn't come up with any strong reason not to. In the layering, Sockets is already considered lower-level.)

cc: @ericeil, @ianhays, @bartonjs, @jaredpar, @AArnott, @CIPop, @ericstj, @dsplaisted, @IlyaBiryukov, @bpschoch
Fixes https://github.com/dotnet/corefx/issues/1849

jaredpar · 2016-03-11T18:52:41Z

CC @agocke, @TyOverby

ericeil · 2016-03-11T19:04:01Z

src/Native/System.Native/pal_networking.cpp

+    struct ucred creds;
+    socklen_t len = sizeof(creds);
+    return getsockopt(fd, SOL_SOCKET, SO_PEERCRED, &creds, &len) == 0 ?
+        GetNameFromUid(creds.uid) :


Using a side-effect of the condition here feels odd to me. I think I'd rather this just be an if/else statement, so the execution order is more apparent.

Really? I rather like this construction 😄 If it really bothers you, I can change it.

I won't insist. :)

agocke · 2016-03-11T19:10:06Z

@stephentoub One thing I thought weird about pipe streams was that Read opportunistically read n bytes, while Write always wrote all the data. Is this still true, i.e. writes are buffered such that any write always succeeds fully? Is it also true for domain sockets that the entirety of the Write is buffered? Or that part of it can be buffered and return to the writer (e.g., in the case where the buffer is full)?

ericeil · 2016-03-11T19:11:59Z

src/System.IO.Pipes/src/Microsoft/Win32/SafeHandles/SafePipeHandle.Unix.cs

+
+            return (long)handle >= 0 ?
+                Interop.Sys.Close(handle) == 0 :
+                true;


How would we end up with a handle that needs to be closed here?

Anonymous pipes.

Ahhh. Might be good to have a comment to that effect.

stephentoub · 2016-03-11T19:13:00Z

writes are buffered such that any write always succeeds fully? Is that also true for domain sockets?

It needs to be based on the contract provided by Stream.Write/WriteAsync.
https://github.com/stephentoub/corefx/blob/namedpipes_on_domainsockets/src/System.IO.Pipes/src/System/IO/Pipes/PipeStream.Unix.cs#L99-L106
https://github.com/stephentoub/corefx/blob/namedpipes_on_domainsockets/src/System.IO.Pipes/src/System/IO/Pipes/PipeStream.Unix.cs#L155-L167

agocke · 2016-03-11T19:14:06Z

@stephentoub I see. Is there a plan to provide an addition to the contract that allows for partial writes?

stephentoub · 2016-03-11T19:15:30Z

Is there a plan to provide an addition to the contract that allows for this behavior?

I'm not clear on what behavior you're hoping for. You want a write method that waits until it can write at least 1 byte and then writes as much as it can and returns an Int32 for how much it wrote? There are no plans for such a thing.

agocke · 2016-03-11T19:16:09Z

@stephentoub Yeah, I edited the comment -- that's what I was asking about. You answered the question though, thanks!

jaredpar · 2016-03-11T19:17:34Z

src/Native/System.Native/pal_networking.cpp

+
+        struct passwd pw;
+        struct passwd* result;
+        if (getpwuid_r(uid, &pw, buffer, bufferLength, &result) == 0)


The result value is never freed. Is that intentional. Could not find a reference to whether this needs to be freed or not in the docs.

It's a bit of a strangely designed function. result is set to &pw on success or to NULL if the entry couldn't be found. Either way, nothing to be freed.

ericeil · 2016-03-11T19:36:15Z

A couple of nits, otherwise LGTM.

stephentoub · 2016-03-14T18:47:51Z

@dotnet-bot test this please

Unix domain sockets can result in ENOENT failures due to the specified file path not existing. There's no corresponding entry in SocketError, so it often ends up showing up as an unknown -1 error. This commit just adds a mapping to the closest entry possible, AddressNotAvailable, making it both a bit easier to diagnose and making it possible to filter based on AddressNotAvailable in consuming code.

A previous change allowed AddressFamily.Unix and non-IPEndPoints to be used in System.Net.Sockets, removing some asserts and changing some if/elses to support it. One case was missed, though, in ConnectAsync, which causes asserts and runtime failures when using Socket.ConnectAsync with Unix domain sockets. This commit just makes the same change to that code path that was made to other similar ones.

Today, NamedPipeServer/ClientStream are implemented on top of FIFOs, aka named pipes. There are some unfortunate limitations to this that are causing problems for typical usage of NamedPipeServer/ClientStream: - FIFOs can be constructed as both read and write (i.e. InOut), but a writer can then immediately read what was written. In other words, whereas one might expect there two be two data channels, one in each direction, there's only one that everyone can read and write from. - FIFOs can be connected to by any number of readers and writers, which has the effect of meaning a reader doesn't unblock when a writer disconnects, because there may be another writer in the future. To address these significant limitations, this commit moves NamedPipeServer/ClientStream to be built instead on top of Unix domain sockets. Unix domain sockets are an IPC mechanism for local communication using the sockets model, and we have support for it via System.Net.Sockets. Both of the aforementioned problems are addressed by this change. A few other positive outcomes: - The participants on each side of the connection can get the credentials of the other side, so GetImpersonatedUserName is now implemented. - Our Socket implementation has a good async implementation, so we can use it for all of the async operations exposed rather than queueing a work item that then blocks doing the synchronous operation. There are a few downsides, but they're worth the tradeoff: - FIFOs have the same general blocking behavior as anonymous pipes and as named pipes on Windows: a call to Write doesn't complete until an associated Read comes along. That's not the case with Unix domain sockets, where a Write typically just deposits the data into a buffer. Writes on a socket only block when the buffer is full. - Unix domain sockets are considered to be a bit slower than FIFOs. - Changing the buffer size of a FIFO impacts the whole FIFO, whereas changing the buffer size for a socket impacts just that end of the socket. There continue to be several features that we don't support, e.g. message transmission, max number of servers, etc.

Also add/update a few tests.

Implement NamedPipe*Stream on Unix domain sockets

tmds · 2016-03-19T10:52:27Z

@stephentoub why is UnixDomainSocketEndPoint no longer public?

stephentoub · 2016-03-19T11:11:53Z

why is UnixDomainSocketEndPoint no longer public?

It was just sample code that was only compiled into a test; it wasn't actually public in a shipping assembly nor in a contract.

tmds · 2016-03-19T12:30:09Z

@stephentoub is the intention to make it public? are there missing bits?

stephentoub · 2016-03-19T12:33:17Z

is the intention to make it public?

Not for an initial release. Maybe at some point in the future. In the meantime, if you need them, you can copy the end point implementation into your project.
https://github.com/dotnet/corefx/blob/master/src/System.Net.Sockets/tests/FunctionalTests/UnixDomainSocketTest.cs#L248-L325

masaeedu · 2018-03-01T07:11:31Z

Is there any intention to expose an equivalent to the \\.\pipe\<pipe name> file from Windows? I'm trying to do cross platform process substitution, but it doesn't seem like there is any file based interface to the pipes on Linux.

…domainsockets Implement NamedPipe*Stream on Unix domain sockets Commit migrated from dotnet/corefx@3ebf2fc

dnfclas added the cla-already-signed label Mar 11, 2016

stephentoub added the 2 - In Progress label Mar 11, 2016

ericeil reviewed Mar 11, 2016
View reviewed changes

jaredpar reviewed Mar 11, 2016
View reviewed changes

stephentoub force-pushed the namedpipes_on_domainsockets branch from 4f5dad8 to dea6316 Compare March 11, 2016 20:21

davidsh added area-System.Net X-Plat labels Mar 11, 2016

stephentoub mentioned this pull request Mar 12, 2016

Remove InterprocessTests project #6840

Merged

stephentoub force-pushed the namedpipes_on_domainsockets branch from dea6316 to 7dea5fa Compare March 12, 2016 12:50

stephentoub mentioned this pull request Mar 12, 2016

Implement SocketPal.Poll on Unix with poll instead of select #6846

Merged

stephentoub added 5 commits March 14, 2016 20:07

Add GitHub issue numbers for several Socket TODOs

8c0e687

Address PR feedback and fix several reliability issues

c39ac9a

Also add/update a few tests.

stephentoub force-pushed the namedpipes_on_domainsockets branch from 7dea5fa to c39ac9a Compare March 15, 2016 00:13

stephentoub added a commit that referenced this pull request Mar 15, 2016

Merge pull request #6833 from stephentoub/namedpipes_on_domainsockets

3ebf2fc

Implement NamedPipe*Stream on Unix domain sockets

stephentoub merged commit 3ebf2fc into dotnet:master Mar 15, 2016

stephentoub deleted the namedpipes_on_domainsockets branch March 15, 2016 02:55

stephentoub removed the 2 - In Progress label Mar 15, 2016

karelz modified the milestone: 1.0.0-rtm Dec 3, 2016

karelz added the os-linux Linux OS (any supported distro) label Mar 8, 2017

CXuesong mentioned this pull request May 2, 2018

Support Unix Domain Socket CXuesong/JsonRpc.Standard#4

Open

swernli mentioned this pull request Jan 31, 2020

Expose UnixDomainSocket dotnet/runtime#18227

Closed

picenka21 pushed a commit to picenka21/runtime that referenced this pull request Feb 18, 2022

Merge pull request dotnet/corefx#6833 from stephentoub/namedpipes_on_…

8b96a6b

…domainsockets Implement NamedPipe*Stream on Unix domain sockets Commit migrated from dotnet/corefx@3ebf2fc

gfoidl mentioned this pull request Aug 16, 2023

Named Pipes on Linux don't use FIFO named pipes, rather they use Unix-domain-sockets dotnet/docs#36710

Closed

Jozkee mentioned this pull request Nov 17, 2023

Fixed setting ReadMode to Message for NamedPipeClientStream on Windows dotnet/runtime#94742

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Implement NamedPipe*Stream on Unix domain sockets #6833

Implement NamedPipe*Stream on Unix domain sockets #6833

stephentoub commented Mar 11, 2016

jaredpar commented Mar 11, 2016

ericeil Mar 11, 2016

stephentoub Mar 11, 2016

ericeil Mar 11, 2016

agocke commented Mar 11, 2016

ericeil Mar 11, 2016

stephentoub Mar 11, 2016

ericeil Mar 11, 2016

stephentoub commented Mar 11, 2016

agocke commented Mar 11, 2016

stephentoub commented Mar 11, 2016

agocke commented Mar 11, 2016

jaredpar Mar 11, 2016

stephentoub Mar 11, 2016

ericeil commented Mar 11, 2016

stephentoub commented Mar 14, 2016

tmds commented Mar 19, 2016

stephentoub commented Mar 19, 2016

tmds commented Mar 19, 2016

stephentoub commented Mar 19, 2016

masaeedu commented Mar 1, 2018

Implement NamedPipe*Stream on Unix domain sockets #6833

Implement NamedPipe*Stream on Unix domain sockets #6833

Conversation

stephentoub commented Mar 11, 2016

jaredpar commented Mar 11, 2016

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

agocke commented Mar 11, 2016

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

stephentoub commented Mar 11, 2016

agocke commented Mar 11, 2016

stephentoub commented Mar 11, 2016

agocke commented Mar 11, 2016

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ericeil commented Mar 11, 2016

stephentoub commented Mar 14, 2016

tmds commented Mar 19, 2016

stephentoub commented Mar 19, 2016

tmds commented Mar 19, 2016

stephentoub commented Mar 19, 2016

masaeedu commented Mar 1, 2018