Network pipes

Diomidis Spinellis dds at
Sat Jul 26 14:40:18 PDT 2003

Diomidis Spinellis wrote:
> I think I can package the proposed sh changes as a separate command,
> following Luigi's suggestion.  The syntax will not include a pipe symbol
> and layout, but the performance benefits will still be there.  It will
> also be a lot more portable and also usable within any shell.

The source code and the documentation for the netpipe standalone command
are now available for download under a BSD license at

Netpipe connects over a TCP/IP socket a remote command specified to a
local input generation command and/or a local output processing command.
The input and output of the remote command are appropriately redirected
so that the remote command's input will come from the local input
generation command and the remote command's output will be sent to the
local output processing command. The remote command is executed on the
machine accessed through the login command. The netpipe executable
should be available through the execution path in the remote machine.
The braces used for delimiting the commands and their arguments should
be space-separated and can be nested. This feature allows you to setup
complex and efficient topologies of distributed communicating processes. 

Although the initial netpipe communication setup is performed through
client-server intermediaries such as ssh(1) or rsh(1), the communication
channel that netpipe establishes is a direct socket connection between
the local and the remote commands. Without the use of netpipe, when
piping remote data through ssh(1) or rsh(1), each data block is read at
the local end by the respective client, is sent to the remote daemon and
written out again to the remote process. The use of netpipe removes the
inefficiency of the multiple data copies and context switches and can in
some cases provide dramatic throughput improvements. On the other hand,
the confidentiality and integrity of the data passing through netpipe's
data channel is not protected; netpipe should therefore be used only
within a confined LAN environment. (The authentication process uses the
protocol of the underlying login program and is no more or less
vulnerable than using the program in isolation; ssh(1) remains secure,
rsh(1) continues to be insecure.) 

Diomidis -

More information about the freebsd-hackers mailing list