3. How TERM works

Before experimenting with TERM it is strongly advised to first read this complete chapter and the INSTALLATION file provided with the package. Also take a look at the manual pages linecheck, (term)test and TERM. This will help you to work easier and faster.

3.1 Nomenclature

I assume you are dialling a system through some sort of terminal server. I use the terms local and remote to refer to the home and network connected systems respectively (unless I use them to mean something else :-).

TERM provides the local machine, which has no network connection, but is connected, via a serial line, to a remote machine which is in turn connected to a network with network services. Let us look at how a machine with a 'traditional' network connection provides these services. First the user invokes a program, like ftp or telnet, that requests a network service. What these programs do is make a system call requesting network services. The operating system then obtains these services via its network interface (e.g. it sends and receives packets over the ethernet). SLIP and PPP do exactly this, by converting your modem line into a network interface, which is in principle no different from an ethernet. The downside of this is that these protocols make the modem-connected machine part of the network, just like any other machine. This implies all the administrative burdens associated with being a network node (more actually, since the modem link must also be administered).

In the absence of a network connection like SLIP or PPP, what does one typically do? Well, you dial your network connected machine, read your mail, your news etc; if you need a file, you first transfer it to the remote machine and then download it to your local machine using kermit or some other communication program. This is a bit of a pain, especially since you can only really do one thing at a time that uses your modem link. The idea behind TERM is basically to automate and multiplex this process. TERM is invoked on both the local and remote machines, and the two processes communicate with one another over the modem line. When you need a network service, you make a request to the local TERM daemon, which forwards the request to the TERM daemon on the remote, network-connected, machine. The result is then returned over the modem line.

To be more concrete, say you want to retrieve a file by ftp. First you need a version of ftp that can speak to TERM. You invoke this termftp as you do a regular ftp, say termftp nethost.gov, but this special version makes its network request to the local TERM daemon instead of the kernel. The local TERM forwards this request, over the modem line, to the remote TERM, which opens an ftp connection to nethost.gov, and transmits the data back over the modem link. TERM is smart enough to have many different things going on at once; so you can have several different network sessions using the same modem link, e.g. you can be logged into another distant host via termtelnet while the termftp transfer is going on.

If this is too abstract (or unclear) do not worry; the important piece of information to get out of this section is that there are two copies of TERM running, one on each end of the modem link.