conn-tools
Software
www.skarnet.org
The ioconnect program
ioconnect establishes a connection from stdin to a
given open-for-writing file descriptor, and from an open-for-reading
file descriptor to stdout. It maintains both connections separately,
correctly transmitting EOFs when it gets them.
Interface
ioconnect timeout fdr fdw
- fdr and fdw must be valid open file
descriptors. They must not be inferior to 3.
- ioconnect copies stdin to fdw and fdr to stdout. It exits 0
when both its inputs close, or 111 on a hard error.
- If timeout seconds elapse without data being available on
either reading end, ioconnect exits 99, or 111 if there is
still unflushed data in its buffers. A 0 value for timeout means
infinite.
- If one of ioconnect's end is a socket, ioconnect
must be the only process to communicate with the socket.
It uses the shutdown() system call to reliably transmit EOF
through the socket, which badly interferes if other processes access the
socket at the same time.
History
In all pre-0.18 versions:
ioconnect transformed itself into two mutually-controlling
timeoutcat processes: one reading from
stdin and writing to fdw, the other reading from fdr
and writing to stdout.
With 0.18, I managed to get the file descriptor handling right at
last, so ioconnect is a single process by now.
Examples of use
- ioconnect 0 6 7 is the simplest possible
UCSPI client. It may be
used to emulate
ucspi-proxy's
behaviour.
- The main goal of ioconnect is insulation of the
braindead socket API,
which prevents processes from properly closing connections when they
need to. Processes could fork a ioconnect child to take care
of their socket connections for them; then they could reliably close()
the reading and writing end of the socket separately, without
having to jump through hoops with shutdown() themselves.
Of course, the Right Thing would be to change the socket() and
accept() calls so that they return and use two fds
instead of one.