278 posts
Posted 31 January 2013 - 05:03 PM
Hello all. I am posting this here in case I get distracted and never actually release this.
This "project" was a result of my failure to implement a working routing protocol for ComputerCraft of my own, and subsequent interest in computer networking. I then suddenly had the idea to split the routing function and the "framework" of the router into seperate files, allowing users to swap out routing functions as necessary. Several days later, I finished this.
This router is designed to work in the background, but can run in the foreground (primarily to assist in debugging). The router is mainly designed to work with link-state routing protocols, but MAY be able to use distance-vector protocols. In addition, this is designed to run with minimal setup; all you need to run it (on a new computer, at least) is the program itself and the routing algorithm you'll use. (for those that are wondering, there's a new parameter that activates the "loadaside" module (I'm just making up words here, bear with me) that loads the CRF alongside the default shell / startup files.
The router's changes to the API have been designed to mask the difference between "normal" rednet messages and routed packets; however, due to this "masking", using GPS with routing may not be a good idea; the modified rednet.receive reports an inaccurate distance for routed packets. In addition, the router can also generate fake rednet_message events that return the same parameters as rednet.receive.
However, if you opt to use the rednet_message events instead of rednet.receive(), please keep in mind that you will have to filter out the messages used by the routers themselves.
Keep in mind that using this router results in a loss of security; messages are sent and received in the clear. If you need to be secure, use encryption at the application level. In other words, you need to encrypt all of your outgoing messages before sending them; we do not do this for you.
In addition, any significantly interested malicious user can read any traffic that passes though an attacker-controlled node. In other words, it's no different from the real-world internet.
As I said before, there are 2 parts to this setup:
A quick rundown of what each component does:
Most of the API calls should be self-explanatory (all functions take no arguments unless specified):
rednet.allNodes - Returns a table with every visible node on the network.
rednet.localNodes - Returns a table with the nodes that this router is directly connected to (i.e within normal rednet range.)
rednet.forceNodeAdvert - Forces a node advertisement, showing other nodes that this node is online and ready to receive data.
rednet.forceNodePruning - Forces a reference-count node pruning, which looks for nodes with no neighbors and removes them from the node list.
rednet.forceLocalNodeUpdate - Forces a local node ping, which finds new neighbors.
rednet.forceTimeEventTick - Forces all of the above to occur.
rednet.getParameter - Gets a user parameter (passed on startup or set via the API; see below)
rednet.setParameter(parameter, state) - Sets a user parameter (handy for enabling/disabling verbose-debugging mode)
rednet.packetTotals - Returns the number of packets that have been sent from the current router, have been routed through the current router, and have been addressed to the current router.
rednet.distanceToID(id) - Returns the node-to-node distance to the passed ID. This distance may be slightly larger than the "straight-line" distance returned from local rednet usage.
This "project" was a result of my failure to implement a working routing protocol for ComputerCraft of my own, and subsequent interest in computer networking. I then suddenly had the idea to split the routing function and the "framework" of the router into seperate files, allowing users to swap out routing functions as necessary. Several days later, I finished this.
This router is designed to work in the background, but can run in the foreground (primarily to assist in debugging). The router is mainly designed to work with link-state routing protocols, but MAY be able to use distance-vector protocols. In addition, this is designed to run with minimal setup; all you need to run it (on a new computer, at least) is the program itself and the routing algorithm you'll use. (for those that are wondering, there's a new parameter that activates the "loadaside" module (I'm just making up words here, bear with me) that loads the CRF alongside the default shell / startup files.
The router's changes to the API have been designed to mask the difference between "normal" rednet messages and routed packets; however, due to this "masking", using GPS with routing may not be a good idea; the modified rednet.receive reports an inaccurate distance for routed packets. In addition, the router can also generate fake rednet_message events that return the same parameters as rednet.receive.
However, if you opt to use the rednet_message events instead of rednet.receive(), please keep in mind that you will have to filter out the messages used by the routers themselves.
Keep in mind that using this router results in a loss of security; messages are sent and received in the clear. If you need to be secure, use encryption at the application level. In other words, you need to encrypt all of your outgoing messages before sending them; we do not do this for you.
In addition, any significantly interested malicious user can read any traffic that passes though an attacker-controlled node. In other words, it's no different from the real-world internet.
As I said before, there are 2 parts to this setup:
- The router itself. (Code: 62t0X4be)
- The routing function. (Code: 0v7CrUUg)
A quick rundown of what each component does:
- The router: This is the application itself; obviously you need it.
- The routing function: This is used by the router to find a route to send packets down. The link points to an implementation of a Breadth-First Search.
- A way to start the router: This isn't explicitly required, but if you want to run your router in the background, this is a must. The link points to my Simple Server Starter. (node: which may be horribly broken)
Most of the API calls should be self-explanatory (all functions take no arguments unless specified):
rednet.allNodes - Returns a table with every visible node on the network.
rednet.localNodes - Returns a table with the nodes that this router is directly connected to (i.e within normal rednet range.)
rednet.forceNodeAdvert - Forces a node advertisement, showing other nodes that this node is online and ready to receive data.
rednet.forceNodePruning - Forces a reference-count node pruning, which looks for nodes with no neighbors and removes them from the node list.
rednet.forceLocalNodeUpdate - Forces a local node ping, which finds new neighbors.
rednet.forceTimeEventTick - Forces all of the above to occur.
rednet.getParameter - Gets a user parameter (passed on startup or set via the API; see below)
rednet.setParameter(parameter, state) - Sets a user parameter (handy for enabling/disabling verbose-debugging mode)
rednet.packetTotals - Returns the number of packets that have been sent from the current router, have been routed through the current router, and have been addressed to the current router.
rednet.distanceToID(id) - Returns the node-to-node distance to the passed ID. This distance may be slightly larger than the "straight-line" distance returned from local rednet usage.
