[Next]  [Previous] [Contents]

----------------------------------------------------------------------------

3. Understanding the problem

Understanding a problem is the first half of the path to solving it.

3.1 Giving names to things

If you want this hack to work for you, you'll have to get an idea of how it
works, so that in case anything breaks, you know where to look for.

The first step toward understanding the problem is to give a name to
relevant concepts.

So we'll herein call "local" the machine that initiates the connection, as
well as programs and files on that machine; conversely, we'll call "remote"
what's on the other side of the connection.

3.2 The problem

The goal is to connect the input and output of a local IP emulator to the
output and input respectively of a remote IP emulator.

Only the communication channels with which IP emulators interact are either
direct devices (in the usual case of pppd), or the "current tty". The
previous case obviously does not happen with telnet sessions. The latter is
tricky, because when you launch the local emulator from the command line,
the "current tty" is linked to the command-line user, not to a remote
session; also, should we open a new session (local or remote) on a new
terminal, we must synchronize the launching and connection of IP emulators
on both sides, least one session's garbage output is going to be executed as
commands on the other session, which would recursively produce more garbage.

3.3 Additional difficulty

To get the best ease of use, the local IP emulator has to provide IP to
kernel networking, hence be pppd. However, pppd is dumb enough to only
accept having data through /dev or thru the current tty; it must be a tty,
not a pair of pipe (which would be the obvious design). This is fine for the
remote pppd if any, as it can use the telnet session's tty; but for the
local pppd, it sucks, as it can't launch the telnet session to connect to;
hence, there must some kind of wrapper around it.

Telnet behaves almost correctly with a pair of pipe, except that it will
still insist on doing ioctl's to the current tty, with which it will
interfere; using telnet without a tty also causes race conditions, so that
the whole connection will fail on "slow" computers (fwprc 0.1 worked
perfectly on a P/MMX 233, one time out of 6 on a 6x86-P200+, and never on a
486dx2/66).

[Note: if I find the sucker (probably a MULTICS guy, though there must have
been UNIX people stupid enough to copy the idea) who invented the principle
of "tty" devices by which you read and write from a "same" pseudo-file,
instead of having clean pairs of pipes, I strangle him!]

----------------------------------------------------------------------------
[Next]  [Previous] [Contents]