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 <http://www.spinellis.gr/sw/unix/netpipe/>. 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 - http://www.spinellis.gr _______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
