|--infd w/subproc||--outfd w/subproc|
|--outfd w/subproc||--infd w/subproc|
l$ encapsulate --infd 0 --duplex 5 r$ encapsulate --outfd 1 --DUPLEX 5
l$ encapsulate --infd 0 --duplex 5 r$ encapsulate --outfd 1 --duplex 5
--duplex must have a corresponding --DUPLEX on the remote end.
l$ encapsulate --infd 0 --duplex 5 r$ encapsulate --DUPLEX 5 --outfd 1
--infd must have a corresponding --outfd on the remote end. Its out of order and the channels will be allocated incorrectly leading to protocol errors.
If you understand the source code for encapsulate, you can violate these guidelines, but it is unnecessary, error-prone, and ill-advised; besides, you dont really understand the source code. Dont do it.
The SCP has an implicit polarity. One end is the server and the other end is the client. You can specify which end is which using --client and --server. If you do not specify one, then encapsulate will compare the addresses of both ends of the socket (specified with --fd) and use a deterministic algorithm to pick one to be the server and one to be the client. If the remote address of the socket does not correspond to the remote encapsulate (e.g. the packets are being forwarded through a plugged gateway, the addresses are being masqueraded, or are otherwise percieved inconsistently by the two ends) then this algorithm has a good chance of "failing" and assigning both to be server or both to be client.
The only time you should ever let encapsulate choose between client and server is in interactive situations. It is very likely that a software system built around encapsulate will be reused in a situation where the automatic polarity assignment fails.
Heres a simple file transfer daemon:
server$ faucet 3001 --once --fd3 \ sh -c while ~/src/netpipes4.0/encapsulate --fd 3 -so5i4 \ sh -c "fname=cat 0<&4; echo \$fname; cat < \$fname 1>&5"; \ do true; done client$ hose server 3001 --retry 10 --delay 1 --fd3 \ sh -c while read fname; do \ ~/src/netpipes4.0/encapsulate --fd 3 -si4o5 \ sh -c "echo $fname 1>&5; exec 5>&-; cat 0<&4" \ || break; done
Just type the name of the file you want to retrieve into the hose and press return. It will be dumped to stdout. Repeat until enlightened or bored.
Did you specify --client and --server properly? One side should be server, the other side should be client. If you specify them both as server or both as client, you have made a mistake. Do not rely on the automatic polarity detection. While it is theoretically a very good algorithm, it is fooled very easily.
Do all of your channel assignments (--infd et al) match up? If you get these wrong, encapsulate will freak out and drip spooge all over your shoes.
For deadlock avoidance, make sure you are closing channels when you dont need them anymore. Use the >&- redirection operator in sh or bash. Make sure you close it in all of the background processes as well.
Unable to read stdin from a process that has been backgrounded with & ? Bash closes file descriptor 0 for any subprocess that is backgrounded (e.g. (command&) ). You can get around this by copying 0 onto another descriptor, and then copying it back within the backgrounded process.
( ( cat 0<&3 ) & ) 3<&0
The Session Control Protocol document on SunSite was a draft. There is a more recent one that doesnt specify header compression (which I dont use anyway). It may eventually become an RFC. Then again, encapsulate may be the only program which ever implements SCP.
encapsulate is not hard to deadlock. Until I add unbounded buffering inside encapsulate, avoid constructing deadlock-vulnerable systems.
The encapsulate included with netpipes 4.0 totally failed to handle the case where no subprocess was specified. No error message would be issued, and the program would do absolutely nothing. The 4.1 version should work.
encapsulate has no other known bugs. Im sure there are unknown ones because this software is not yet mature; in fact, its totally wet behind the ears. Break it and send me the pieces.
Well, the command-line argument style is inconsistent with faucet & hose. Ill be updating faucet & hose.
The Linux kernel from the beginning of time up through version 2.0.29 has a problem with sockets being shut down "too fast". This results in loss of data at the end of a stream and an "Error: connection reset by peer" during reads. 2.0.30 supposedly fixes this. This state machine flaw is very likely present in many other OSes, because the strange conditions that exercise it are almost nonexistent in normal applications, but happen all the time in some applications of the NetPipes package. encapsulate can be used to work around this bug in some cases because encapsulate does not perform a shutdown on the network socket ever (it doesnt even do a "close").
Hi Mom! Hi Dad!
Copyright (C) 1997-98 Robert Forsman
This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version.
This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.
You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
Purple Frog Software
|-->||ENCAPSULATE (1)||June 19, 1997|