10.2. Logins via the network
Two computers in the same network are usually linked via a
single physical cable. When they communicate over the network,
the programs in each computer that take part in the communication
are linked via a virtual connection, a sort
of imaginary cable. As far as the programs at either end of the
virtual connection are concerned, they have a monopoly on their
own cable. However, since the cable is not real, only imaginary,
the operating systems of both computers can have several virtual
connections share the same physical cable. This way, using just
a single cable, several programs can communicate without having
to know of or care about the other communications. It is even
possible to have several computers use the same cable; the virtual
connections exist between two computers, and the other computers
ignore those connections that they don't take part in.
That's a complicated and over-abstracted description of
the reality. It might, however, be good enough to understand
the important reason why network logins are somewhat different
from normal logins. The virtual connections are established
when there are two programs on different computers that wish
to communicate. Since it is in principle possible to login
from any computer in a network to any other computer, there is
a huge number of potential virtual communications. Because of
this, it is not practical to start a getty
for each potential login.
There is a single process inetd (corresponding to
getty) that handles all network logins.
When it notices an incoming network login (i.e., it notices
that it gets a new virtual connection to some other computer),
it starts a new process to handle that single login. The original
process remains and continues to listen for new logins.
To make things a bit more complicated, there is
more than one communication protocol for network logins.
The two most important ones are telnet and
rlogin. In addition to logins, there are many
other virtual connections that may be made (for FTP, Gopher, HTTP,
and other network services). It would be ineffective to have a
separate process listening for a particular type of connection,
so instead there is only one listener that can recognize the type
of the connection and can start the correct type of program to
provide the service. This single listener is called
inetd;
see the Linux Network Administrators' Guide
for more information.
