Protocol Professor: A Program for On-line Teaching about Internet Application Protocols

Arthur Goldberg
Adel Hanna

Presented at Educom '96, Project Information Exchange, Technology Track, Philadelphia Oct. 9, 1996

10 Oct. 1996

Information Systems Department
Stern School of Business
and
Computer Science Department
Courant Institute of Mathematical Sciences
New York University
44 West Fourth St., Room 9-75
New York, NY 10012-1126
artg@cs.nyu.edu
hann7034@cs.nyu.edu

Abstract

University Computer Science students should learn about Internet client/server protocols such as HTTP, NNTP, SMTP, Gopher, etc. Many classrooms now contain Internet connected computers with projection displays. We describe Protocol Professor (PP), a program we use in the classroom to teach students about protocols. PP enables an instructor to rapidly and easily hand simulate many protocols, thereby concretely illustrating their operation. PP clearly displays the messages exchanged between client and server. The instructor generates client messages by clicking on buttons and filling in fields. Several years of classroom experience have demonstrated that PP helps students understand Internet application protocols. PP runs on platforms that support TCL/TK, including Windows and Unix. Download PP from http://goldberg.cs.nyu.edu:8888/protocol_professor/ppv10. Download this paper from http://goldberg.cs.nyu.edu:8888/protocol_professor/paper.html.

Introduction

University computer science students should learn about the operation of Internet client/server application protocols such as HTTP, NNTP, SMTP, Gopher, Archie, ftp, Telnet, etc. These protocols (and associated document standards) underlie most Internet application layer communications.

Many classrooms in affluent schools contain a network-connected podium computer with a projection display that the students can see. (We refer to these as podium computers below.) Teachers use podium computers to teach computing by demonstrating software. Unfortunately, such demonstrations often fail to teach fundamental ideas to students because the software is not designed for classroom teaching. The demonstrations fail for several reasons:

We believe that software designed especially for classroom teaching can dramatically enhance the effectiveness of instructors using podium computers. The design must consider both software engineering and perceptual psychology. We've dubbed such software Classware. This paper describes our initial attempt to build Classware.

Existing approaches to demonstrating protocols on-line

Telnet demonstrations

An instructor can use a podium computer to illustrate Internet protocols in class by telneting to a server and typing commands into the telnet prompt. For example, to illustrate Simple Mail transfer Protocol (SMTP), an instructor might type the commands in the following script:

goldberg{artg}149: Telnet cs.nyu.edu 25
Trying 128.122.153.70 ...
Connected to cs.nyu.edu.
Escape character is '^]'.
220 cs.NYU.EDU Sendmail 4.1/1.34 ready at Fri, 11 Aug 95 15:33:50 EDT
rcpt to:  hann7034@sparky.cs.nyu.edu
250 hann7034@sparky.cs.nyu.edu... Recipient ok
mail from: artg
mail from: artg
250 artg... Sender ok
data
data
354 Enter mail, end with "." on a line by itself
hi adel

I'm writing our paper now, and generating an example
figure.
.
250 Mail accepted
quit
quit
221 cs.NYU.EDU delivering mail
Connection closed by foreign host.

Unfortunately, displaying this text in a classroom can bore and confuse students. The demo can bore students because it is visually monotonous and typing each command slows down the instructor. The demo can confuse students because the text does not distinguish client messages from server messages.

GUI client demonstrations

Alternatively, an instructor could use a GUI client such as a Web browser or an email UA to demonstrate HTTP or SMTP. However, those programs deliberately hide the protocol's details, and therefore teach nothing.

Protocol Professor

We solve these problems with Protocol Professor, a program a teacher can use to hand simulate Internet protocols. PP clearly displays the messages communicated between PP and an Internet server. An instructor can operate PP with minimal typing.

Protocol Simulation

A screen shot of PP during an SMTP demo is shown in Figure 1. PP's interface shows three windows:


Figure 1. PP screen showing SMTP demo

A client protocol message menu for SMTP appears on the left side of Figure 1. (To focus on a protocol's key features, we usually include just the commonly used messages.) To demonstrate a protocol the instructor sends a message by clicking on a protocol message menu button. This opens a dialog box, as shown in Figure 2. Fields in the dialog box identify fields in the message. Required fields are outlined in red, optional fields in green. When the instructor hits the Send button PP sends the message to the connected server.

PP now displays the outgoing message and the server's response in the message trace window. The message trace shows the ACSII text of all messages exchanged between the client, PP, and the server. Client messages are distinguished from server messages by different typefaces and colors. The middle of long server replies are elided so multiple client request - server response interactions can remain on the screen simultaneously.

The instructor sends messages from PP to the server and discusses the results shown in the trace window. Messages from the server to PP appear in black letters on a white background; messages from PP to the server appear in white letters on a dark red background. Arbitrary input, such as the content of an email, is entered in the data window. The instructor explains the messages as they're traced.

For example, Figure 1 illustrates the complete transfer of an SMTP email message. After the TCP/IP connection is established the server responds with a "220 ... ready at" message. The client, PP, says HELO and the server responds. PP sends a MAIL message indicating the email address of the email's sender. Next PP sends a RCPT message indicating the email address of the email's recipient. To transfer the email, PP sends an SMTP DATA message. The email's body (followed by a period on a line by itself) is entered in the data window and transmitted by hitting Send. The SMTP server now transfers the email.

An instructor can also illustrate protocol failures and error recovery by using with PP to transmit incorrect or incomplete messages.


Figure 2. Dialog Produced by Hitting the RCPT Button

Protocol and Server Selection

When PP starts a menu (Figure 3) lists the set of protocols it can simulate. The instructor picks a protocol and PP connects to a server. The instructor can choose the server's machine name and port number. Thus, PP can demonstrate communications with any Internet machine accessible to the podium computer.


Figure 3. Protocol Choice Menu

Multiple protocol support

PP supports multiple protocols. When PP starts it reads a configuration file (Figure 4) which describes protocols. The configuration file is written in an HTML style syntax. Each description consists of a header line and a list of messages. The header describes the following:

Each message line contains the message's name, its optional and required arguments, and a help description. Driving PP from a configuration file makes it easy to add new protocols. Given the rate at which new protocols proliferate on the Internet, we architected PP so one could easily add new protocols to the set PP can simulate.


# Protocols available to the program SMTP NNTP HTTP POP3 FTP FINGER GOPHER TIME # # SMTP specification # <PROTOCOL> NAME=SMTP TYPE=stream UNDERLINEPROTOCOL=tcp CONNECTIONTYPE=multi MESSAGEEND="^.$" COMPLETENAME="Simple Mail Transfer Protocol" <RFCS> NUMBER=821 URL=ftp://nic.merit.edu/documents/rfc/rfc0821.txt </RFCS> <COMMAND> NAME=HELO <ARGUMENTS> OPT=this-host </ARGUMENTS> </COMMAND> <COMMAND> NAME=MAIL <ARGUMENTS> CONST="FROM :" REQ=reverse-path </ARGUMENTS> </COMMAND> <COMMAND> NAME=RCPT <ARGUMENTS> CONST="TO: " REQ=forward-path </ARGUMENTS> </COMMAND> <COMMAND> NAME=DATA <ARGUMENTS> ARBITRARYDATA </ARGUMENTS> </COMMAND> <COMMAND> NAME=VRFY <ARGUMENTS> REQ=user-name </ARGUMENTS> </COMMAND> <COMMAND> NAME=EXPN <ARGUMENTS> REQ=mail-list </ARGUMENTS> </COMMAND> <COMMAND> NAME=QUIT </COMMAND> <COMMAND> NAME=HELP <ARGUMENTS> OPT=command </ARGUMENTS> </COMMAND> <COMMAND> NAME=RSET </COMMAND> </PROTOCOL>

Figure 4. The SMTP Section of a the Protocol Configuration File

Conclusions

We describe Protocol Professor, a tool for in-class, on-line, about Internet application protocols. It helps us teach university students about text-based protocols. We believe PP should be followed by other tools for enhancing in-class, on-line, instruction.

PP implementation and availability

PP was conceived by Arthur Goldberg, designed Arthur Goldberg and Adel Hanna and by implemented in TCL/TK by Adel Hanna. PP ver 1.0 uses TL7.4, TK 4.0 and TCL-DP 3.3 beta 1.

PP 1.0 has been tested on SunOS 4.1.3 and Solaris. It should run on any platform that supports TCL/TK, including Windows and Unix. PP can be obtained from htpp://goldberg.cs.nyu.edu:8888/protocol_professor/ppv10. If you use it, please tell us about your experience.

Experience

PP has helped us teach graduate students, undergraduates and interested passers-by about Internet protocols for several years. Students are impressed by the concrete realization of Internet application messages that they observe when we use PP. It helps them separate out the functionality of application servers and clients. I recall one student saying, "So the browser has to display all that HTML nicely typeset?". Students are surprised to see that the messages sent by many Internet applications are so simple. It impresses them when I send an Internet email by simply issuing the sequence of 4 SMTP messages illustrated above. Often I build on their PP experience and ask them to consider extending a protocol with new messages to provide additional functionality.

PP extensions

PP could be extended in several ways.

  • The configuration file format could be extended to support binary protocols such as DNS and NFS. Their data would need to be converted to strings or numbers before displayed in the log.
  • The message trace could include timing and performance data, or another window could display a space time diagram.
  • Languages other than English should be supported.
  • References

    Goldberg, Arthur and Adel Hanna, Classware: Design Principles for Classroom Demonstration Software, Educom '96, Project Information Exchange, Technology Track, Philadelphia Oct. 9, 1996.