Skip to content

Latest commit

 

History

History
80 lines (60 loc) · 3.27 KB

limitations.rst

File metadata and controls

80 lines (60 loc) · 3.27 KB
Raw

Limitations

Datagram sockets can only process writes as individual packets with a maximum packet size. Therefore, if the program being run attempts to write(2) 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 PIPE_BUF and 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 data?

It is not possible to open /dev/stdout or /dev/stderr because they are sockets. No program would need to do this but like the use of /dev/stdin it may be desirable in scripts to work around limitations in file descriptor handling (however this is unlikely for an interactive program).

For more details read the :doc:`architecture <architecture>` document.

BSD Operating Systems

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 which avoids problems some of the time but messages are likely to be lost from programs that write large amounts of data very quickly or do so inefficiently (1 byte at a time).

On some versions of some operating systems the communication will be too unreliable for any kind of use and may or may not report errors.

GNU Hurd

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.

Cygwin

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 dtee after the child process has exited (until waitpid(2) is processed).
  • Read output from child processes if the program being run forks into the background (causing dtee to exit).
  • Read output from child processes if dtee is killed.