Figure 30.1 Three X clients using one display.
In this chapter we describe additional TCP/IP applications that many implementations support. Some are simple and easy to cover completely (Finger and Whois), while another is complex (the X Window System). We provide only a brief overview of this complex application, focusing on its use of the TCP/IP protocols.
Additionally we provide an overview of some Internet
resource discovery tools. These are tools to help us navigate
our way around the Internet, searching for items whose location
and exact name we don't know.
30.2 Finger Protocol
The Finger protocol returns information on one or more users on a specified host. It's commonly used to see if someone is currently logged on, or to figure out someone's login name, to send them mail. RFC 1288 [Zimmerman 1991] specifies the protocol.
Many sites do not run a Finger server for two reasons. First, a programming error in an earlier version of the server was one of the entry points used by the infamous Internet worm of 1988. (RFC 1135 [Reynolds 1989] and [Curry 1992] describe the worm in more detail.) Second, the Finger protocol can reveal detailed information on users (login names, phone numbers, when they last logged in, etc.) that many administrators consider private. Section 3 of RFC 1288 details the security aspects of this service.
From a protocol perspective, the Finger server has a well-known port of 79. The client does an active open to this port and sends a one-line query The server processes the query, sends back the output, and closes the connection. The query and response are NVT ASCII, similar to what we saw with FTP and SMTP.
While most Unix users access the Finger server using the finger(l) client, we'll start by using the Telnet client to connect directly to the server and see the one-line commands issued by the client. If the client query is an empty line (which in NVT ASCII is transmitted as a CR followed by an LF), it is a request for information on all online users.
| sun % telnet slip finger | ||||||
| Trying 140.252.13.65 ... | first three lines are output by Telnet client | |||||
| Connected to slip. | ||||||
| Escape character is '^]' . | ||||||
| here we type RETURN as the Finger client command | ||||||
| Login | Name | Tty | Idle | Login Time | Office | Office Phone |
| rstevens | Richard Stevens | *co | 45 | Jul 31 09:13 | ||
| rstevens | Richard Stevens | *c2 | 45 | Aug 5 09:41 | ||
| Connection closed by foreign host. | output by Telnet client | |||||
The blank output fields for the office and office phone are taken from optional fields in the user's password file entry (which aren't present in this example).
The server must be the end that does the active close, since a variable amount of information is returned by the server, and the reception of the end-of-file by the client is how the client knows when the output is complete.
When the client request consists of a usemame, the server responds with information only about that user. Here's another example, with the Telnet client output removed:
| sun % telnet vangogh.cs.berkeley.edu finger | |
| rstevens | this is the client request we type |
| Login: rstevens | Name: Richard Stevens |
| Directory: /a/guest/rstevens | Shell: /bin/csh |
| Last login Thu Aug 5 09:55 (PDT) on ttyq2 from sun.tuc.noao.edu | |
| Mail forwarded to: rstevens@noao.edu | |
| No Plan. | |
When a system has the Finger service completely disabled, the client's active open will receive an RST from the server, since no process has a passive open on port 79:
sun % finger @svr4
[svr4.tuc.noao.edu] connect: Connection
refused
Some sites provide a server on port 79, but it just outputs information to the client, and doesn't honor any client requests:
| sun % finger @att.com | |
| [att.com] | this line output by Finger client; remainder from server |
| ---------------------------------------------------------------------------------- | |
| There are no user accounts on the AT&T Internet gateway, To send email to an AT&T employee, send email to their name separated by periods at att.com. If the employee has an email address registered in the employee database, they will receive email - otherwise, you'll receive a non-delivery notice. For example: John.Q.Public@att.com | |
| sun % finger clinton@whitehouse.gov | |
| [whitehouse.gov] | |
| Finger service for arbitrary addresses on whitehouse.gov is not supported. If you wish to send electronic mail, valid addresses are "PRESIDENT@WHITEHOUSE.GOV", and "VICE-PRESIDENT@WHITEHOUSE.GOV" | |
Another possibility is for an organization to implement a firewall gateway: a router between the organization and the Internet that filters out (i.e., discards) certain IP datagrams. ([Cheswick and Bellovin 1994] discuss firewall gateways in detail.) The firewall gateway can be configured to discard incoming datagrams that are TCP segments for port 79. In this case the Finger client times out after about 75 seconds.
There are additional options for the Finger server, and for the Unix finger client. Refer to RFC 1288 and the finger(l) manual page for the details.
RFC 1288 states that vending machines with TCP/IP
connections that provide a Finger server should reply to a client
request consisting of a blank line with a list of all items currently
available. They should reply to a client request consisting of
a name with a count or list of available items for that product.
30.3 Whois Protocol
The Whois protocol is another information service. Although any site can provide a Whois server, the one at the InterNIC, rs.internic.net, is most commonly used. This server maintains information about all registered DNS domains and many system administrators responsible for systems connected to the Internet. (Another server is provided at nic.ddn.mil, but contains information only about the MILNET.) Unfortunately the information can be out of data or incomplete. RFC 954 [Harrenstien, Stahl, and Feinler 1985] documents the Whois service.
From a protocol perspective, the Whois server has a well-known TCP port of 43. It accepts connection requests from clients, and the client sends a one-line query to the server. The server responds with whatever information is available and then closes the connection. The requests and replies are transmitted using NVT ASCII. This is almost identical to the Finger server, although the requests and replies contain different information.
The common Unix client is the whois(1) program, although we can use Telnet and type in the commands ourself. The starting place is to send a request consisting of just a question mark, which returns more detailed information on the supported client requests.
When the NIC moved to the InterNIC in 1993, the site
for the Whois server moved from nic.ddn.mil
to rs.internic.net. Many vendors
still ship versions of the whois
client with the name nic.ddn.mil
built in. You may need to specify the command-line argument -h
rs.internic.net to contact the correct server.
Alternately, we can Telnet to rs.internic.net
and login as whois.
We'll use the Whois server to track down the author. (We've removed the extraneous Telnet client output.) Our first request is for all names that match "stevens."
| sun % telnet rs.internic.net whois | |
| stevens | this is the client command we type |
| information on 25 other "stevens" that we omit | |
| Stevens, W. Richard (WRS28) stevens@kohala.com +1 602 297 9416 | |
| The InterNIC Registration Services Host ONLY contains Internet Information (Networks, ASN's, Domains, and POC's). Please use the whois server at nic.ddn.mil for MILNET Information. | |
The three uppercase letters followed by a number in parentheses after the name, (WRS28), are the person's NIC handle. The next query contains an exclamation point and a NIC handle, to fetch more information about this person.
| sun % telnet rs.internic.net whois | |
| !wrs28 | client request that we type |
| Stevens, W. Richard (WRS28) | stevens@kohala.com |
| Kohala Software 1202 E. Paseo del Zorro
Tucson, AZ 85718 +1 602 297 9416 | |
| Record last updated on 11-Jan-91. | |
Lots of additional information about Internet variables can also be queried. For example, the request net 140.252 returns information about the class B address 140.252.
Using the VRFY command of SMTP, along with the Finger protocol and the Whois protocol to locate users on the Internet is similar to using the white pages of a telephone book to find someone's phone number. At the present time ad hoc tools such as these are all that's widely available, but research is under way to improve this type of service.
[Schwartz and Tsirigotis 1991] contains additional information on various white pages services being tried on the Internet. The particular tool, called Netfind, can be accessed by using Telnet to either bruno.cs.colorado.edu or ds.internic.net and logging in as netfind.
RFC 1309 [Weider, Reynolds, and Heker 1992] provides
an overview of the OSI directory service, called X.500, and compares
and contrasts it with current Internet techniques (Finger and
Whois).
30.4 Archie, WAIS, Gopher, Veronica, and WWW
The tools that we described in the previous two sections-Finger, Whois, and a white pages service-are for locating information on people. Other tools exist to locate files and documents, and this section gives an overview of these tools. We only provide an overview, because examining the details of each tool is beyond the scope of this book. Methods are given for accessing these tools across the Internet, and you are encouraged to do so, to find which tool can help you. Additional tools are continually being developed. [Obraczka, Danzig, and Li 1993] provide an overview of resource discovery services on the Internet.
Many of the resources used in this text were obtained using anonymous FTP. The problem is finding which FTP site has the program we want. Sometimes we don't even know the exact filename, but we know some keywords that probably appear in the filename.
Archie provides a directory of thousands of FTP servers across the Internet. We can access this directory by logging into an Archie server and searching for files whose name contains a specified regular expression. The output is a list of servers with matching filenames. We then use anonymous FTP to that site to fetch the file.
There are many Archie servers across the world. One starting point is to use Telnet to ds.internic.net, login as archie, and execute the command servers. This provides a list of all the Archie servers, and their location.
Archie helps us locate filenames that contain keywords, but sometimes we're looking for a file or database that contains a keyword. That is, we want to search for a file that contains a keyword, not a filename containing a keyword.
WAIS knows about hundreds of databases that contain information on both computer-related topics and other general topics. To use WAIS we select the databases to search and specify the keywords. To try WAIS Telnet to quake.think.com and login as wais.
Gopher is a menu-driven front end to other Internet resource services, such as Archie, WAIS, and anonymous FTP Gopher is one of the easiest to use, since its user interface is the same, regardless of which resource service it's using.
To use Gopher, Telnet into is.internic.net and login as gopher.
Just as Archie is an index of anonymous FTP servers. Veronica is an index of titles of Gopher items. A Veronica search typically searches hundreds of Gopher servers.
To access Veronica we must go through a Gopher client. Select the Gopher menu item "Beyond InterNIC: Virtual Treasures of the Internet" and then select Veronica from the next menu.
World Wide Web lets us browse a large, worldwide
set of services and documents using a tool called hypertext.
As information is displayed, certain keywords are highlighted,
and we can select more information on those keywords. To access
WWW, Telnet to info.cern.ch.
30.5 X Window System
The X Window System, or just X, is a client-server application that lets multiple clients (applications) use the bit-mapped display managed by a server. "The server is the software that manages a display, keyboard, and mouse. The client is an application program that runs on either the same host as the server or on a different host. In the latter case the common form of communication between the client and server is TCP, although other protocols such as DECNET can be used. In some instances the server is a dedicated piece of hardware (an X terminal) that communicates with clients on other hosts. In another instance, a stand-alone workstation, the client and server are on the same host and communicate using interprocess communication on that host, without any network involvement at all. Between these two extremes is a workstation that supports clients on the same host and clients on other hosts.
X requires a reliable, bidirectional stream protocol, such as TCP. (X was not designed for an unreliable protocol such as UDP.) The communication between the client and server consists of 8-bit bytes exchanged across this connection. [Nye 1992] gives the format of the more than 150 messages exchanged between the client and server across their TCP connection.
On a Unix system, when the X client and X server are on the same host, the Unix domain protocols are normally used instead of TCP, because there is less protocol processing than if TCP were used. The Unix domain protocols are a form of interprocess communication that can be used between clients and servers on the same host. Recall in Figure 2.4 that when TCP is used for communication between two processes on the same host, the loopback of this data takes place below the IP layer, implying that all the TCP and IP processing takes place.
Figure 30.1 shows one possible scenario with three clients using one display. One client is on the same host as the server, using the Unix domain protocols. The other two clients are on different hosts, using TCP. One client is normally a window manager that has authority for the layout of windows on the display. The window manager allows us to move windows around the screen, or change their size, for example.
On first glance the terms client and server appear backward. With applications such as Telnet and FTP we think of the client as the interactive user at the keyboard and display. But with X, the keyboard and display belong to the server. Think of the server as the end providing the service. The service provided by X is access to a window, keyboard, and mouse. With Telnet the service is logging in to the remote host. With FTP the service is the filesystem on the server.
The X server is normally started when the X terminal or workstation is bootstrapped. The server creates a TCP end point and does a passive open on port 6000 + n, where n is the display number (normally 0). Most Unix servers also create a Unix domain socket with the name /tmp/.X11-unix/Xn, where n is again the display number.
When a client is started on another host, it creates a TCP end point and performs an active open to port 6000 + n on the server. Each client gets its own TCP connection to the server. It is the server's responsibility to multiplex all the clients. From this point on the client sends requests to the server across the TCP connection (e.g., create a window), the server sends back replies, and the server also sends events to the client (mouse button pushed, keyboard key pressed, window exposed, window resized, etc.).
Figure 30.2 is a redo of Figure 30.1, emphasizing that the clients communicate with the X server process, which in turn manages the windows on the display. Not shown here is that the X server also manages the keyboard and mouse.
This design, where a single server handles multiple clients, differs from the normal TCP concurrent server design that we described in Section 18.11. The FTP and Telnet servers, for example, spawn a new process each time a new TCP connection request arrives, so each client communicates with a different server process. With X, however, all clients, running on the same host or on a different host, communicate with a single server.
Lots of data can be exchanged across the TCP connection between an X client and its server. The amount depends on the specific application design. For example, if we run the Xclock client, which displays the current time and date on the client in a window on the server, specifying an update of once a second, an X message is sent across the TCP connection from the client to the server once a second. If we run the X terminal emulator, Xterm, each keystroke we type becomes a 32-byte X message (72 bytes with the standard IP and TCP headers), with a larger X message in the reverse direction with the character echo. [Droms and Dyksen 1990] measure the TCP traffic between various X clients and one particular server.
A handy program for examining what's exchanged between an X client and its server is Xscope. It's provided with most X window implementations. It sits between a client and server, passing everything in both directions, and also deciphering all the client requests and server replies. Figure 30.3 shows the setup.
We first start the xscope process on the same host as the server, but xscope listens for TCP connection requests on port 6001, not 6000. We then start a client on another host and specify display number 1, not 0, so the client connects to xscope, not directly to the server. When the connection request from the client arrives, xscope creates a TCP connection to the real server at port 6000, and copies everything between the client and server, and produces a readable description of the requests and replies.
We'll start xscope on our host sun and then run the xclock client on the host svr4.
svr4 % DISPLAY=sun:l xclock -digital -update 5
This displays the time and date in the digital format
Thu Sep 9 10:32:55 1993
in a window on the host sun. We specify an update time of once every 5 seconds.
We specify the -q option for xscope to produce minimal output. Various levels of verbosity are available, to see all the fields in each message. The following output shows the first three requests and replies.
| sun % xscope -q | |
| 0.00: Client -> 12 bytes | |
| 0.02: | 152 bytes <-- X11 Server |
| 0.03: Client -> 48 bytes | |
| ............REQUEST: CreateGC | |
| ............REQUEST: GetProperty | |
| 0.20: | 396 bytes <-- X11 Server |
| ..............REPLY: GetProperty | |
| 0.30: Client -> 8 bytes | |
| 0.38: Client -> 20 bytes | |
| ............REQUEST: InternAtom | |
| 0.43: | 32 bytes <-- XII Server |
| ..............REPLY: InternAtom |
The first client message at time 0.00 and the server's response at time 0.02 are the standard connection setup between the client and server. The client identifies its byte ordering and the version of the server that it expects. The server responds with various information about itself.
The next message at time 0.03 contains two client requests. The first request creates a graphics context in the server in which the client will draw. The second gets a property from the server (the RESOURCEJVIANAGER property). Properties provide for communication between clients, often between an application and the window manager. The server's 396-byte reply at time 0.20 contains this property.
The next two messages from the client at times 0.30 and 0.38 form a single request to return an atom. (Each property has a unique integer ID called an atom.) The server replies at time 0.43 with the atom.
It is impossible to delve farther into this example without providing lots of details about the X window system, which isn't the purpose of this section. In this example a total of 12 segments comprising 1668 bytes is sent by the client and a total of 10 segments comprising 1120 bytes is sent by the server, before the window is displayed. The elapsed time was 3.17 seconds. From this point the client sent a small request every 5 seconds, averaging 44 bytes, with an update to the window. This continued until the client was terminated.
The encoding used by the X protocol is optimized for LANs, where the time spent encoding and decoding the data is more important than minimizing the amount of data transmitted. While this is OK for an Ethernet, it becomes a problem for slow serial lines, such as SLIP and PPP links (Sections 2.4 and 2.6).
Work is progressing to define a standard called Low
Bandwidth X (LBX) that uses the following techniques to reduce
the amount of network traffic: caching, sending differences from
previous packets, and compression. Specifications should appear
early in 1994 with a sample implementation in the X window system
Release 6.
30.6 Summary
The first two applications that we covered. Finger and Whois, are for obtaining information on users. Finger clients query a server, often to find someone's login name (for sending them mail) or to see if someone is currently logged in. The Whois client normally contacts the server run by the InterNIC, looking for information on a person, institution, domain, or network number.
The other Internet resource discovery services that we briefly described, Archie, WAIS, Gopher, Veronica, and WWW, help us locate files and documents across the Internet. Other resource discovery tools are currently being developed.
This chapter finished with a brief look at the X Window System, another heavy user of TCP/IP. We saw that the X server manages multiple windows on a display, and handles the communication between a client and its window. Each client has its own TCP connection to the server and a single server manages all the clients for a given display. With the Xscope program we saw how it's possible to place another program between a client and server to output information about the messages exchanged between the two.
30.1 Use Whois to find the owner of the class A network ID 88.
30.2 Use Whois to find the DNS servers for the whitehouse.gov domain. Does the reply match the answer given by the DNS?
30.3 In Figure 30.3, do you think the xscope process must be run on the same host as the X server?