RFCs and Internet Documentation

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

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.

• 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

Basic Telnet operation:

1. 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.
2. 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.
3. 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

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.

File Transfer

• User's files can be stored on a remote file server, which allows shared access. The files always remain stored on the server's disk, but are accessed as though they are stored locally. The fact of their remote storage is transparent to the user, and the fact that the netork is used is not (necessarily) obvious. This is the way students' home directories are stored on the Bendigo Unix systems.
• Files can be shared by copying them from one system to another, performing any desired operations, and (maybe) copying them back. This is called "file transfer", although the thing that gets transferred is a copy of the file, not the actual file - it still exists on the remote system. The networked nature of file transfer is apparent in the commands which are used. In the Internet this is implemented using FTP: the File Transfer Protocol.

  FTP is documented in RFC 959.

FTP Process Model

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

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

Remote Procedure Call

This material is optional

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.