The VRNet Project

I. Preface

1. Goal
   The goal of this project was to make a software that would be able to explore by itself a domain network, build a graph of its topology and represent it in 3 dimensions. We also planned that some animations would be integrated in the 3D world if the time permitted.

2. Duration
   The development process took us two weeks and a half full-time.
   Project size: about 2500 lines of code.

3. Related project
   Last year, a similar project, known as Klnet, was undertaken by two past ESSI students (Pascal Robinet) but we were not able to gather any interesting information or code from it. In fact, the project was not documented at all and it was written in a very specific (apparently lisp-like) language named Klone developed by INRIA which we do not know. We therefore had to start from scratch.

4. The network environment under test
   Our application was developed and tested on the ESSI network and some problems like reachability of the teachers' network (cf. V.1) had to be dealt with. Nevertheless, we think that the same application can work out fine on other class-B domain networks, without too much modification.

5. Implementation Tools
   The program is mainly written in Java with the JDK 1.1, but sometimes some shell scripts have been used to gather network information.
   The application generates a ".wrl" file which obeys the VRML 2.0 standard, thereby allowing very portable 3D "moving worlds" to be created.
   We used the Liquid Reality VRML browser and the CosmoPlayer Plug-in for Netscape (on SGIs) to visualize VRML 2.0 files.

II. Using VRNet

1. System requirements
   This program is supposed to be portable on all the UNIX systems that supports a JVM 1.1 (Java Virtual Machine) (i.e. Solaris, IRIX, AIX , HP-UX, etc.).
   A VRML 2.0 compliant browser is also needed to visualize the generated 3D network.

2. Installing the application
   
   • Download the gzipped tar archive : VRNet.tgz.
   • Unpack it using the command :

     gzip -d VRNet.tgz | tar xvf -

   • Add the path of the VRNet directory to your CLASSPATH environment variable.
     In zsh :

     CLASSPATH=your_path_to_VRNet/VRNet:$CLASSPATH

3. Running the program
   
   • Run the main Java class in the VRNet directory using the Java interpreter:
     

     java VRNet

   A trace of the application execution is displayed on the screen informing the user of the current task under way. Error messages due to hosts connection failure or connection timeouts may appear but the program does not stop. Instead it attempts to connect to other hosts until it succeeds or until all the hosts have been tested.

4. Viewing the generated VRML file
   If no error has occurred and the program is completely finished, the user will find a file called "net.wrl" in the VRNet/worlds directory. He then just has to open it under the VRML 2.0 compliant browser to navigate through it.
   The VRML file generated on the ESSI network gives the following 3D network:

The ESSI network in VRML 2.0
Sorry for the poor quality of this grab, it has been taken using an SGI with a 8-bit only graphic card.

III. Implementation overview

The ESSI network comprises various different entities, namely hosts (SunSparc, PCs, Silicon Graphics terminals), bridges (Xyplex and Cisco routers, powerhubs) and printers. All these entities are organised in subnetworks.

The implementation of this application involves 3 distinct phases :

• gathering network information,
• discovering the routers to understand the topology and build a graph of the network,
• and modeling the whole network in VRML.
1. Gathering network information
   • Detecting the printers
     The program first executes the

     lpstat -s

     command to gather the alias of all the printers available in the domain network.

   • Reading from the Yellow Pages
     The Yellow Pages, now named as the NIS (Network Information Service) and available via the system command ypcat, enable us to build a database of all the hosts and LANs (Local Area Network) in the ESSI network. The following commands :

     ypcat hosts
     ypcat ethers

     allow respectively to :
     • obtain a list of all hosts names, their IP address and their aliases,
     • and to get the ethernet address of the hosts

   • Building a host database
     A specific Java class named "LanDB" parses the yellow pages to build its own database, where all hosts are grouped by their LAN IP address using the domain subnetwork mask (255.255.255.0 for ESSI).

2. Understanding the topology and building a graph of the network
   • Detecting bridge interfaces
     To model a network, bridges have to be identified. Unfortunately, hosts and bridges are mixed up in the the hosts database built with the Yellow pages. So how do we identify routers ?
     Routers have several interfaces (that are registered in the Yellow Pages), one for each LAN to which they are connected. There is no way to find out that two different interfaces belong to the same router !
     It is therefore necessary to use another information: the routing tables of the domain hosts.
     The routing table of a host can be viewed using the command :

     netstat -r

     Here is a simple one :

     Routing tables
     Destination          Gateway              Flags    Refcnt Use        Interface
     localhost.essi.fr    localhost.essi.fr    UH       1      26         lo0
     default              xyrouter4.essi.fr    UG       18     26633      le0
     157.169.4.0          volte.essi.fr        U        5      5529       le0

     The second line indicates that the default route of all the packets leaving this LAN from this host is via the "xyrouter4", and the G flag informs us that it is a Gateway (i.e. a bridge).

     So, assuming that each host of the same LAN has the same routing table, our program picks up a host at random per LAN and tries to get its routing table.
     Once all the routing tables have been collected the program attempts to identify the different interfaces of the physical routers. The algorithm that achieves this task is not trivial at all! (c.f.IV.4)

   • Building the graph
     We thought for a long time about the question: how to build the graph of a network topology ? At ESSI the topology is simply a tree, but we wanted to make a very general program and so decided to use a graph representation.
     Several representations are possible. We decided to use :
     • as nodes: the bridges and LANs,
     • as arcs : the interface of a bridge that connects it to a LAN.
     This representation implies that two bridges or two LANs are never directly connected.
     In fact, it is not interesting to include the hosts in the graph, only the backbone is important. Hosts are simply connected to a LAN according to a star topology...

3. Modeling the whole network in VRML
   Having created the graph in memory, the program next represents it in 3D by translating it into VRML instructions in a file.
   Our program starts a BFS (Breadth First Search) traversal of the graph and displays LANs and routers nodes as they are discovered. In order to avoid the overlapping of these nodes, the program builds up a list of the occupied regions in space and aims the connections to new nodes in the free parts of the space. In fact, for each new connection, the program successively tests the following directions : (x+, x-, y+, y-, z+, z-), until it finds an unoccupied area in the space. However, if it reaches the end of the list without finding an empty space, it is then forced to give up. This can happen if the degree of a node exceeds 6 (the 3-Dimensions in the 2 directions) or if the graph is very dense and there is not enough space.

   Complex objects that use a IndexFaceSet, such as routers and hosts, have been designed under Autodesk 3D Studio 5.0 and have been converted to a VRML 1.0 file which is itself subsequently converted to a VRML 2.0 file using an SGI converter. These files are then called by the Inline VRML instruction in the main VRML file. We have tried to make objects as simple as possible by using a minimum of vertices, but since the number of hosts at ESSI is quite important, the VRML scene is always very slow to navigate through on low-graphic performance computers.
   Here again, it took us a long time to design all these objects and assign the right Transform VRML node to each object (It was not easy to anticipate the rotations in 3D!)

IV. Problems encountered

1. The "moving ESSI"
   During our project, we unfortunately had to face some modification in the network topology. It is quite difficult to make your program see the network as you think it is when it has just changed recently.
   The biggest problem came from the fact that the system administration department had just bought a new machine called a PowerHub which integrates the ATM technology. It is the reason why several routers have suddenly disappeared unexpectedly!
   The PowerHub is a very powerful router that supports hundreds of LANs and hosts but it is very hard to detect using the traditional system commands! It has therefore not facilitated our task!

2. The access rights
   Several LANs and routers of the ESSI network are not accessible from the poor students that we are ;-). It is especially the case for the teacher's network for example.
   So, as it was not possible for us to get their routing tables, we had to imagine and hardcode them in our program in order to simulate their access.

3. The JDK bugs
   We began the project using the 1.0.2 release of the JDK but faced a bug in its implementation of the Thread class.
   In order to code properly, our threads yield the CPU when they are waiting for a shell script to finish. Unfortunately it was impossible for our timeout threads to wake up the waiting thread if the script was too long to execute (the source code of the interrupt() method of Thread was empty!!!).
   So we updated our program to the 1.1 release where this bug has been fixed. We said this bug, because we, of course, encountered others... (like waitFor() that never returns even if the script is finished and join() that also does not return all the time. cf V.1)

4. Identifying routers
   As we said in the chapter III.2, we have spent a long time finding out how to identify real routers without cheating by hardcoding them into the program.
   We had to deeply study the problem and have tested several solutions :
   • gathering information in the SNMP (Simple Network Management Protocol) MIB (Management Information Base),
   • using of routing tables,
   • studying packets paths between hosts (with the traceroute command).

V. Conclusion

1. Known Bugs
   The main methods should wait for the death of the explorer thread using the join() method. Unfortunately, sometimes it does not work because of a JDK bug... Type Ctrl-C to kill the process when it is written :

   BUILDING VRML FILE...
   done.

   if the process does not finish by itself.

2. Possible extensions
   The VRNet software has been designed to fully support the following extensions. The VRML 2.0 standard has been especially chosen to allow a dynamic behavior of the 3D network. Unfortunately we had a lot of ideas which we had not had the time to implement.
   
   • Getting hosts information
     We wanted to allow the user to get information on a host, printer or bridge simply by a clicking on it in the browser.
     We studied this extension in depth, but thought that it would require more time that the one that was remaining.
     In fact, a TouchSensor node can be added and it can be designed so as to output an event each time a host is clicked. Then a route can be designed to send this event to a special node that will execute a Java program.
     The problem is that we cannot really name objects in a VRML world, so the only information we could give to the Java program would be the 3D position of the mouse click. Afterwards, it would be responsible for traversing the graph and finding the host that was clicked.
     This gives rise to a second problem : the VRNet program is terminated when you visualize the 3D network, and the host database dies with it. It would be interesting to keep all these information in the VRML world by implementing the next extension...

   • Integrating the Java program in the VRML world
     For the moment, a standalone Java program creates a static VRML file, but we heard from friends of the Vision section that it was possible to create objects dynamically using a Java program in a VRML world.
     It is another very interesting approach which we have not had the time to explore. Moreover, it will have enabled the previous extension to be implemented.

   • Following packets moving in the network
     We also thought it would be interesting to display a 3D packet that would leave a host to reach another one on the network, and follow its trajectory as driven by routing tables in the VRML 3D world.

3. Experience acquired
   This project has been very interesting, and although a lot of problems have been encountered, it has been a very exciting and enriching experience for the following reasons :
   • We have been able to work in 3D graphics
     In fact, being in the network section of the school, we do not have much opportunity to work with graphics and this project has allowed us to delve into this very interesting area.
     In addition, we have discovered the VRML 2.0 language which is becoming a growing and attractive standard for the WWW. By the way, we would like to express our thanks to Peter Sander for having introduced us to this language as well as Pascal Eymery and Yann Fuselier, two friends students in the Vision section of ESSI for their help.
   • We have been able to strengthen our knowledge in networks
     To be frank, although being students in the network section of the school, we have not got much knowledge of UNIX network administration. This project, and especially the problem of router identification, urged us to gather information from the UNIX manual, books and the comp.unix.admin newsgroup.
     We wish to extend our appreciation to Jean-Louis Farault, our system administrator at ESSI for his invaluable help.