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 and a half weeks full-time. Project size: about 2500 lines of code.
3. Related project
   
   We got the work of past ESSI students (Pascal Robinet) who worked on a project named "Klnet" that is similar to ours, but we had not been able to gather any very interesting information or code. In fact, the project was not documented at all and it was written in a very specific (apparently lisp-like) language name 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 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 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 a 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 represented it in 3D by ranslating it into VRML instructions in a file.
   Our program starts a BFS (Breadth First Search) traversal of the graph and displays LANs and routers 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 performant 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 work, we unfortunately had to face some network modification in the topology. It's quite difficult to make your program see the network as you think it is whereas it has just changed the eve.
   The biggest problem went from the fact that the system administration had just bought a new machine called a PowerHub which integrates the ATM technology. It's why several routers have disappeared unexpectally...
   It is a very powerful router that supports hundreds of LANs and hosts but it is quite "discret", we mean it is very hard to detect ! It has not facilitate our task !

2. The access permissions
   Several LANs and routers of the network are not accessible from the poor students that we are ;-). It's especially the case for the teacher's network for example.
   So as it wasn't possible for us to get their routing table, 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 of its implementation of the Thread.
   In order to code "cleanly", our threads yield the CPU when they are waiting for a shell script to finish, unfortunately it wasn't possible for our timeout threads to wake up them if the script was to long to execute (the code of the interrupt() method of threads was empty!!!).
   So we updated our program to the 1.1 release where this bug is fixed. We said this bug, because we off course encountered others... (like waitFor() that never returns even if the script is finished and join() that also doesn't return all the time. cf V.1)

4. Identifying routers
   As we said in the III.2 chapter, we have spent a long time to discover how to identify real routers without cheating by hardcoding them.
   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)
   • the use of routing tables
   • the study of packets paths between hosts (with the "traceroute" command)

V. Conclusion

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

   BUILDING VRML FILE...
   done.

   if the process doesn't 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 have a lot od ideas but haven't got the time to carry them out.
   
   • Getting information on hosts
     We wanted to allow the user to get inormation on a host, printer or bridge simply by a clicking on it with its browser.
     We deeply studied this extension but thought it would require more time that the one that was remaining...
     In fact, a TouchSensor node should be added and it should be designed so as to output a event each time a host is clicked. Then a route should route this event to a special node that would execute a Java program.
     The problem is that we can't really name objects in a VRML world, so the only information we could give to the Java program would be the mouse click 3D position. Then it would be its own task to traverse the graph and found the host that has been clicked.
     One big problem here is that the VRNet program is dead once you visualize the 3D network, and the host database died 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 create a static VRML file, but we heard from friends of the Vision section that it was possible to dynamically create objects using a Java program in a VRML world.
     It's another very interesting way we haven't got the time to explore. It would moreover allow also to implement the previous extension.

   • Following packets moving in the network
     We also thought it would be interesting to display a 3D packet on the network that would leave a host to reach another one, and follow his trajectory driven by routing tables in the VRML world.
3. Experience acquired
   This project was very interesting, and although a lot of problems have arisen, it was a very exciting experience for the following reasons :
   • We have been able to work in 3D graphics
     In fact, working in the network section of the school, we don't have the opportunity to work with graphics and this project allowed us to delve into this very interesting area.
     We have moreover discovered the VRML 2.0 language which is becoming a growing standard very interesting for the WWW. By the way, we would like to thank here Peter Sander to have 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, even if we are studying in the network section of the school we haven't got so much knowledge of the UNIX network administration. This project, and especially the problem we had with identifying the routers forced us to gather information in the UNIX man, books and the comp.unix.admin newsgroup.
     Here again, we would like to thank Jean-Louis Faraut, our system administrator at ESSI for its help.

Please contact us by e-mail for any question or comments.
Liu Kiat and Cyril Bouteille, Students at the Ecole Superieure en Sciences Informatiques
" Potius mori quam foedari "