Datagram sockets can only process writes as individual packets with a maximum
packet size. Therefore, if the program being run attempts to
more than this size in one call the write will fail and that part of the output
will be lost.
This is not usually a problem because the default socket buffer size is usually
much higher than the size programs typically write with. For safety, the socket
buffer size will be increased to at least
BUFSIZ if the
default is smaller than these values.
Writes to the socket (on Linux or GNU Hurd) will block until there is capacity
available in the socket buffer. If the process uses
sendfile(2) then (on
Linux) the writes occur in
PIPE_BUF sized chunks so it works as normal, but
why are you using an interactive program that outputs such large quantities of
For more details read the architecture document.
Writes to the socket do not block when the receive buffer of the peer socket is full. The default socket receive buffer is quite small so it will be raised to 512KB (for the send buffer, 256KB). This avoids problems most of the time.
Messages are likely to be lost from programs that write large amounts of data (more than 128..256KB) very quickly or do so inefficiently (1 byte at a time).
Like FreeBSD/OpenBSD/Darwin but the socket buffer can only be raised to 128KB so messages are very likely to be lost if data is written quickly. Unlike the other BSDs, this will result in an error on the receive call so it will not go unreported.
Does not currently have support for returning addresses of Unix sockets, so none of the output works. It may be possible to implement custom pipe-like objects with three file descriptors in user space.
Writes larger than the page size (4KB) are truncated and there’s no way to increase the size of the socket buffer.
Performs as well as Linux but the maximum amount of data that can be streamed quickly is limited by the size of the socket buffer (which will will be raised to 2MB).
There are security issues because the underlying implementation of Unix sockets
is a UDP socket on localhost. This presents an opportunity for another process
to bind the same port after
dtee or the command being run exits, which will
allow it to:
- Write additional input for
dteeafter the child process has exited (until
- Read output from child processes if the program being run forks into the
- Read output from child processes if