routing-sims | Misc scripts to simulate different routing schemes

routing-sims is a Python library. routing-sims has no bugs, it has no vulnerabilities, it has a Strong Copyleft License and it has low support. However routing-sims build file is not available. You can download it from GitHub.

The packet forwarding procedure is slightly modified from the TZ scheme, to reduce stretch a little further. A separate hashtable lookup is used to check if destinations are a peer ("neighbor" in the usual terminology from graph theory), in the local cluster, or a landmark. Forwarding uses the following priorities:. Checking peers is a deviation from the usual TZ forwarding procedure. My rationale is that each node needs to store some state per peer anyway (for the distance-vector routing portion of the scheme). This is just exploiting extra information that is present at each node, but not actually in the routing table, to slightly improve routing performance. In particular, you presumably need to store at least a port number per peer, and a hashtable is a natural structure to use for those lookups anyway. Landmark selection is significantly different, to remove the full view requirement. An iterative scheme is used to calculate an approximation of each node's coreness. Each node is assigned a weight, equal to degree minus coreness ("dmc" in the scheme's name). A target weight W is selected, equal to the maximum weight for which at least W nodes have weight >= W. The nodes with weight >= W are kept as landmarks. This landmark selection process is done independently at each node, using only information in the local routing table. Nodes propagate information about the selected landmarks to their peers, and the network converges on one set of landmarks to use. It is possible to extend the scheme for name-independent routing, but this has not been implemented in the simulation. It is assumed that the network would include some mechanism to allow header lookups based on flat IDs (e.g. kademlia dht, key = cryptographically generated address, value = header w/ timestamp and cryptographic signature). It is also assumed that a node which is equidistant from multiple landmarks will keep a header for each landmark, and send all of them in dht lookup responses. The sender may then select the header which uses the nearest landmark, which helps to further reduce the stretch of the routing scheme (as per the scheme from Strowes's thesis, this optimization is included in the simulation). Senders should keep the header cached and check for updates periodically. Use of a dht would generally introduce an additional logarithmic term to the memory requirement for each node. For the pathfinding itself, the simulation uses a distance vector routing protocol with a soft-state approach. Each node periodically sends a sequence-numbered message to its direct peers (neighbors). If no message is received for a significant amount of time, then the node times out and the information is removed from the routing table. This was the simplest thing I could think of to implement for the simulation; something better should be used for a real implementation.