RFCs and Internet Documentation
In this subject, we concentrate fairly heavily on the protocols and
architectures used in the global Internet.
Every aspect of the Internet is documented in a series of documents
called "RFCs" (Request For Comment). RFCs are the means by which new
technologies are introduced in the Internet: after suitable research
work has been done, the new proposals are published as an RFC. On the
other hand, some RFCs document standard Internet protocols. RFCs are
usually in plain text form.
Once an RFC is published, it is not changed. However, it may be
"obsoleted" by later work. Unfortunately, there is no easy way to
"browse" RFCs to discover which RFC is the latest on a particular
topic, although there are various Indexes which can be useful.
RFCs are available on-line on the Internet, and can be downloaded
using anonymous ftp. In Australia, they are available at several
sites: in particular your lecturer's favourite archives are
at ftp://munnari.oz.au/rfc/ and
http://mirror.aarnet.edu.au/rfc/
You may (later) need to learn how to download RFCs to answer some
of the assignment questions.
Application Protocols
Application protocols define the way in the TCP reliable service can
be used to achieve network-based computing. Because applications can
assume reliability, their protocols can be relatively simple.
Most application protocols use commands (and, in some cases,
responses) in a human-readable form. They normally also use plain
ASCII text where possible. This makes debugging the protocols quite
straightfoward in most cases.
Some application protocols include:
- Telnet
- provides remote login allowing a user to log into a remote
computer as though it was local. We examine Telnet in this lecture.
- SMTP
- provides the basic Internet electronic mail delivery protocol. We
look at electronic mail in the next lecture.
- FTP
- is used to copy files from one system to another.
- HTTP
- is the protocol basis of the World Wide Web, and is quite complex.
Remote Login
Remote login means to "log in" to a computer (or, to use the
historical term, a "host") as though it were local.
- The idea of "remote login", as opposed to "local login" is
significant in the history of computing - originally, a user "logged
in" at a basic display terminal which was directly connected to a
hardware port on a multi-user host computer.
- If the host was connected
to a network, remote login allowed users to log in to other networked
hosts over the network as though their terminal was directly
connected. Either way, the idea of "logging in" is still based on
getting a command line shell on the target system. On our
Unix systems, we nowadays talk about a shell window, which
performs this function.
- Some systems do not (even now) support remote login.
- Different operating systems have (or used to have... ) quite
different procedures for handling local logins, making the problem of
providing a generic remote login facility (potentially) quite
difficult.
Telnet
Telnet is the basic remote login protocol, and is supported on
virtually all time-shared operating systems.
Basic Telnet operation:
- The user invokes the telnet client process, usually by name from
the command line, eg:
telnet ironbark
Once running, the client process then establishes a TCP connection to
the desired telnet server, which is "waiting for connections" at the
well-known port 23 - note that we are again ignoring the question of
how the name "ironbark" gets translated to a network address, see
later.
- In the case of Unix, the telnet server connects the incoming
connection to a variation of the standard "login" process on the
server host. This may work differently on other systems.
- The user's keystrokes are transmitted to the remote server, and
output is displayed on the user's screen. Thus, initially the user can
"log in", and once authenticated has a normal shell (command line
interface) on the remote host.
Telnet Commands and Options
- The telnet protocol defines a "network virtual terminal"
that provides a standard interface to remote systems, regardless of
their particular approach to terminal login. A Telnet implementation
(client or server) maps the semantics of local terminal operation to
the NVT before sending data over the connection. Some aspects of the
NVT include:
- The NVT uses standard US-ASCII, defining the meaning of a subset
of the ASCII control codes.
- It defines a standard "line ending", the two character sequence
<CR><LF>
- It permits certain "out of band" commands to be sent to the remote
host.
- It permits either of the client or the server to negotiate a
variety
of standard and advanced options. These include:
- Allow one side to echo all data which it receives.
- Use 8-bit characters, instead of the default 7-bit.
- Set terminal type for (eg) screen editing.
- Change to linemode or character mode.
Other Aspects of Remote Login
Programs which implement the telnet protocol are widely (and freely)
available, and Telnet is much used.
The BSD version of Unix introduced a remote login utility with
enhanced characteristics called "rlogin." Some of its features are:
- It supports the idea of "trusted" hosts, whereby a remote login
request from a trusted host (providing usernames match) is not
re-authenticated. This can be administered on a per-host basis
(/etc/hosts.equiv) or a per-user basis (~/.rhosts).
- rlogin exports the user's local "login environment" to the remote
host, so that an rlogin session can look almost identical to a local
login.
Finally, the telnet program can be used to connect to other services
than the standard telnet server at port 23. Most telnet
implementations allow the user to specify a port number on the command
line, and will open a TCP connection to that port. This can be very
useful in debugging communications software.
File Transfer
The basic unit of storage in virtually all modern computer systems
is the file. A fundamental requirement in networked systems
is access to files which are stored on remote computers. There
are at least two models which can be used for this:
FTP Process Model
An FTP client process (presumably one desirous of transferring
a file) establishes a control connection to
an FTP server, waiting (listening) at the standard FTP port 21. This
connection carries all FTP commands and responses.
When a file is to be transferred, the client process opens a new
connection to the server at port 20, the FTP data transfer port.
This data connection is used to carry the actual data in the
file. In Unix-like systems, this is usually achieved by "forking"
a "child" process at each end of the connection, thus:

One interesting aspect of FTP is that the control connection is
implemented using a subset of the TELNET protocol, using the TELNET
NVT.
FTP in Operation
An FTP server normally requires clients to authenticate themselves by
providing a valid username and password before allowing them to
perform file transfers. Ordinary users thus find FTP a convenient
way to transfer files between systems.
Many systems provide a special FTP service whereby the username
"anonymous" allows access to a public file area. The Unix ftp
command works as follows for anonymous file fetching:
redgum 27> ftp munnari.oz.au
Connected to munnari.oz.au.
220 munnari.OZ.AU FTP server (Version 5.91 95/11/08 02:44:16)
ready.
Name (munnari.oz.au:pscott): anonymous
331 Guest login ok, send ident as password.
Password: p.scott@latrobe.edu.au
230 Guest login ok, access restrictions apply.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> cd rfc
250 CWD command successful.
ftp> get rfc959.Z
200 PORT command successful.
150 Opening BINARY mode data connection for rfc959.Z (48587 bytes).
226 Transfer complete.
48587 bytes received in 4.5 seconds (10 Kbytes/s)
ftp> close
221 Goodbye.
ftp> quit
File Sharing - NFS
This material is optional
The Network File System (NFS) was developed by Sun
Microsystems, and is
the defacto standard for transparent filesystem sharing in Unix and
some other environments. NFS is embedded in the operating system of a
client, thus:

Remote Procedure Call
This material is optional
NFS is built on two tools: a Remote Procedure Call (RPC)
mechanism and a general purpose eXternal Data Representation
(XDR) definition and library. These tools are also the basis of the
OSF Distributed Computing Environment (DCE) specification.
RPC allows a programmer to write distributed systems while not
being aware of the actual code and protocols which are used to implement
them over the network. A remote procedure call (or function call for
those sad souls who have only programmed in C) has semantics
exactly the same as a local call, making such programming relatively
straightfoward.
The XDR library code transparently performs a mapping between local
data representations and a standard format which actually crosses
the network
in the RPC call and return messages. Possibly the best example of
the need for this is the byte ordering problem which exists between
the Intel/DEC world (little endian) and everyone else
in the universe (big
endian).
The utilities which build an RPC application automatically call XDR
before transferring any data.
This lecture is also available in PostScript format.
The tutorial for this lecture is Tutorial #03.
[Previous Lecture]
[Lecture Index]
[Next Lecture]
Phil Scott