The Real Experiment eXecution approach to Networking courseware

General concepts

• The Networking Courseware

• An example: REX teaches TCP/IP and some high-level protocols (FTP, DNS, ARP)

• The REX Interface

• The Courseware Preview

A networking courseware deals with instruments that are mostly software applications (such as Telnet or FTP clients and WWW browsers); it is worth noting that the nature of the instruments is substantially the same as the REX interface, since both of them are software applications. The REX interface is no more forced to directly connect with an external instrument, but it can limit itself to sniff the network traffic produced by the student's activity. In this way the REX interface becomes independent from the instrument: for instance, a Virtual Teacher that knows the FTP protocol is able to deal with any kind of FTP client/server application. This feature enlarges the range of applicability with comparable complexity and development costs.

Figure 3- The REX Model applied to the Networking Protocols Domain

We conclude with an example drawn from the REX Networking Courseware: we will describe a sketch of a lesson in which REX teaches TCP/IP, FTP, DNS and ARP protocols to the student. In Figure 4 a detailed picture of the REX architecture for the Networking Courseware is given; the small Java cup designates components written in Java language. 

At a first sight, REX components can be classified into five layers: 

1. Network Layer. This is actually the "real world". 
2. Sampling Layer. Modules in this layer monitor interactions between the real world and the student, making them available to the other components. 
3. Analysis Layer. Modules in this layer provide low-level support for components in the higher levels. 
4. Heuristic Layer. This layer actually holds the Virtual Teacher "knowledge". 
5. Interface Layer. This layer is composed by the Virtual Teacher interface and by various tools available for the student to analyse the experimental results. 

Figure 4 - REX Architecture for the Networking Protocols CBT

The main components of the system are: 

• The Sniffer. This program captures the traffic between the student client station and the network. There are many sniffers available, some of them are integral part of operating systems (e.g. the snoop utility on Solaris). The Sniffer is usually written in native language, because of its strict performance requirements. A sniffer usually introduces security concerns, but in the REX architecture it is located on the server host where it is not directly accessible by anyone. 
• The Traffic Data Server. This component is an intermediate interface between the Sniffer and the other REX components. It is written in Java language (with native method extensions), so it can communicate with other Java modules by means of the RMI API. The Traffic Data Server acts as a security shield against possible Sniffer misuse by malicious intruders. 
• The Protocol Interpreter. This module provides low-level support for interpreting networking protocols. 
• The Virtual Teacher. This module holds the Virtual Teacher's "knowledge".
• Various Analysis Tools. They provide support to the student to inspect network packets.

Thanks to the Java language dynamic nature, the REX interface can be easily enhanced without making changes to existing parts of the software. For instance, to support the SMTP protocol it is enough to add the proper plug-in modules in the Protocol Analyser and in the Virtual Teacher. 

Now we will briefly describe a sketch of a possible session with this networking courseware. We will refer host names to the sample network depicted in Figure 5: 

• rex-client the host where the student works; 
• rex-server the host where there is the WWW server and the Sampling Layer components; 
• dns-server a host with Domain Name Server capabilities; 
• ftp-server an external host acting as an FTP server. 

Figure 5 - Computers used in the example.

After the student has fired up the TCP/IP lesson, (s)he is presented with a window running an FTP client (Figure 6). In the Virtual Teacher window REX displays a suggestion to open an FTP connection by issuing the command open ftp-server; then the FTP client establishes its connection with the FTP server, as usual. A pair of DNS and ARP query/response transactions are generated on the network, as well as some FTP traffic. All packets are captured by the Sniffer and interpreted by the Protocol Interpreter. This material is used by the Virtual Teacher as XX to explain both the DNS and the ARP protocols.

In the TCP Window all the generated packets appear in iconic form. The student can freely inspect them analysing all their fields, for instance learning how different level packets are encapsulated according to the OSI definitions. 

When the first step is over, the Virtual Teacher invites the student to enter the login and the password. Now a sufficient amount of TCP traffic has been generated. The Virtual Teacher analyses the packets and displays a graphic showing how sequential TCP packets are linked together by means of the sequence and acknowledgement numbers, as well as other concepts such as fragmentation and the push function. 

It is important to stress the student's freedom when playing with the real thing. While it is true that the Virtual Teacher often provides hints to proceed, the student is really free to do what (s)he wants (of course staying in the FTP environment). 

Unlike canned drills, that look always the same, this sketch of lesson could be replayed many times and it might exhibit some slight differences, giving the "feel" of the real world. For instance: 

• the ARP request can be missing, if the requested datum is cached locally; 

• the route to another FTP server might be broken, in which case the Virtual Teacher could suggest the use of the traceroute command to find where the problems are; 

• different FTP client and servers might generate slightly different traffics. 

Here is a snapshot of what you will see when the courseware starts:

REX provides some tools to analyse network packets:

1. A map which represents the hosts involved in the experiment and the active TCP sockets, whose main status variables are shown. The map displays what happens in the network when each IP packet is transmitted (for instance the way each packet affects the status of sockets). A green arrow points the source and the destination of the selected packet.

2. A control panel which displays a brief description of the packet being analysed. Four buttons allow the student to move through all the packets of the transaction.

3. An hypertext with more detailed information about the selected packet.

REX collects the network packets as they are generated and prepares their graphical representation in the network map. At the beginning, the first packet is selected and displayed. When you have completed the analysis of the current packet, you can move forward in the packet sequence by pressing the NEXT button, until you reach the latest generated packet. If you would like to step back, you can use the PREV button to have REX displaying again the previous stages of the experiment. The FIRST and the LATEST buttons are shortcuts for the first and the latest packet in the experiment.

You can experiment both the real version of the courseware and the demo.

In the real world, the experiment is performed in the following way: the student fires up REX, launches a FTP client program (such as ftp.exe in Windows 95/NT or similar commands in the UNIX world) then issues some FTP commands.

The demo describes a sketch of the lesson where the protocols involved in a FTP transaction are explained; it is based upon a data file which was previously recorded using the complete version of the courseware. In this way REX can be operated locally without any network connection and avoiding the installation of all the modules included in the courseware.

If you want download and install the real Ftp Courseware click here.

If you want try the demo of the Ftp Courseware click here.