next up previous contents
Next: User Interface Up: Testprogram Implementation Previous: Plug-in architecture   Contents

Networking Module

The networking code is implemented as straightforward as possible. An application has to be instructed where it can find one other node by specifying an IP address. After this the node recursively scans the available nodes by requesting the addresses of all neighbours of the already known nodes. This discovery process is implemented in a separate thread that continually runs in the background as long as we are connected. Nodes are selected as direct neighbours indiscriminately until all available slots have been filled with active nodes. The number of slots can be specified as an option by the user.

The first problem with this implementation is that creating direct neighbours from the neighbours of the first node encountered will results in a high degree of locality. In extreme cases this will reduce a network to a large number of distinct islands of subnets. Furthermore, there are far too much edges in the net from any connected node to another, leading to a lot of overhead. The existence of local subnets has been identified by (10).

A few rudimentary safety features have been implemented to reduce the network traffic. First of all, a message received directly from a webclient is given a pseudorandom codestring to identify it across the network. This ensures that a network node will not rebroadcast a message more than once, thus eliminating loops from the network. Second, a time to live (TTL) variable is added that is decremented at every node. The TTL ensures that a message dies out after a certain amount of time. The downside of this is that there exists the change that a query is not being sent across the entire network. Our current implementation uses a TTL of 32, which would allow more than 4 billion nodes to receive the message if each node has only 2 direct neighbours. I therefore expect, although I don't have any proof for this, that the TTL is rarely used to stop a message from being resent.

The nodes basically have one receiving socket, the server, that listens to standard HTTP requests and as much sending sockets, clients, as there are direct neighbours in the active configuration. The clients rebroadcast the original HTTP message together with the added TTL and identifying string if allowed. Using standard HTTP basically creates a webserver. The gNutella network also sends messages using HTTP, but does not actively support webclients. Our testprogram, on the other hand, sends results in XML with XSLt and CSS extensions. XSLt documents contain translation rules. In our case this extra document tells the receiving client how to transform the raw XML data into a user friendly HTML webpage. The other link, a Cascading Style Sheet, adds some extra customization of the webpage. Because we simply send raw data to the user most processing of data is executed at the webclient's local machine. This should increase the maximum network throughput. A secondary advantage of this scheme over the use of hardcoded parsing rules is the flexibility of data output it entails. The sending of XML allows other programs to reinterpret the data and webmasters to present it to their users in a customized way.


next up previous contents
Next: User Interface Up: Testprogram Implementation Previous: Plug-in architecture   Contents
2002-08-28