We currently use winio's named pipe implementation to create http duplex sockets.
We use CloseWrite() to close the server side of the socket.
This works ok if the client is also using winio. But if the client uses a different named pipe implemenation, CloseWrite() does not behave correctly. (in particular, NodeJS/libuv's implementation)
i also understand that this may end up being a libuv bug -- i couldn't find much documentation on the 0-length message approach to CloseWrite() that winio does, or if this is a generally accepted pattern.
We currently use winio's named pipe implementation to create http duplex sockets.
We use CloseWrite() to close the server side of the socket.
This works ok if the client is also using winio. But if the client uses a different named pipe implemenation, CloseWrite() does not behave correctly. (in particular, NodeJS/libuv's implementation)
My (very naive) understanding is the winio uses a 0-length message to signal the end of the socket. https://github.com/microsoft/go-winio/blob/d68e55cd0b80e6e3cac42e945f1cff6ddb257090/pipe.go#L161 which other libraries do not support.
Can you all advise on if there's something we should be doing differently here?
Thank you!
Detailed repro steps:
Here's how this breaks things in application-level code: https://github.com/apocas/dockerode/issues/534
Here's a more detailed repro case:
server side:
client side:
Then run (in separate terminals):
expected behavior: WinIO should close the socket and nodejs should detect the 'end' event.
actual behavior: nodejs hangs indefinitely
Other notes: The workaround is to use Close() on the Go side instead of CloseWrite(). This closes the whole duplex (rather than closing just one side)