Jump to content




Somewhat-Common Routing Framework (aka Yet Another Attempt at Recreating the Internet)

networking wireless utility

13 replies to this topic

#1 KillaVanilla

  • Members
  • 303 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: Each link above points to a program that can be used for the specified task.
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)
Quick developer notes:
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.

#2 NeverCast

  • Members
  • 400 posts
  • LocationChristchurch, New Zealand

Posted 01 February 2013 - 09:07 AM

This looks very promising!
I shall investigate immediately!

Nice work KillaVanilla! Nice API with it too.

#3 Jojo.bacon

  • Members
  • 20 posts

Posted 01 February 2013 - 11:01 AM

So basically it routes packets while maintaining support for programs that use regular rednet connections? Cool!

#4 KillaVanilla

  • Members
  • 303 posts

Posted 01 February 2013 - 11:23 AM

View PostJojo.bacon, on 01 February 2013 - 11:01 AM, said:

So basically it routes packets while maintaining support for programs that use regular rednet connections? Cool!
Yep. As long as said programs that use normal rednet connections don't need to know the distance between nodes (so probably no GPS over routers). (Some) Support for this will (probably) be added shortly.

EDIT: Holy shit, GPS over routers is definitely possible, as long as each node knew where it was...aaand now it seems kinda stupid.
EDIT2: brb, implementing GPSoCRF...


EDIT3: Okay, what the hell. As it turns out, my testing setup was messed up. As it turns out, I had no idea that the world I was using was at what could be considered "high altitude".

#5 Jojo.bacon

  • Members
  • 20 posts

Posted 01 February 2013 - 11:40 AM

View PostKillaVanilla, on 01 February 2013 - 11:23 AM, said:

View PostJojo.bacon, on 01 February 2013 - 11:01 AM, said:

So basically it routes packets while maintaining support for programs that use regular rednet connections? Cool!
Yep. As long as said programs that use normal rednet connections don't need to know the distance between nodes (so probably no GPS over routers). (Some) Support for this will (probably) be added shortly.

EDIT: Holy shit, GPS over routers is definitely possible, as long as each node knew where it was...aaand now it seems kinda stupid.
EDIT2: brb, implementing GPSoCRF...

It works with distance?
Mind blown.

#6 nutcase84

  • Members
  • 711 posts
  • LocationIn My Lonely Little Computer Corner

Posted 01 February 2013 - 11:59 AM

player = player.detect()
this == "awesome"
if this == "awesome" then
give(KillaVanilla, diamonds, 999999)
else
kill(player)
end


#7 Jojo.bacon

  • Members
  • 20 posts

Posted 01 February 2013 - 12:31 PM

Are you sure it could not be possible? You could add the distances possibly? Edison found hundred of ways NOT to make the lightbulb.

#8 KillaVanilla

  • Members
  • 303 posts

Posted 01 February 2013 - 12:32 PM

View PostJojo.bacon, on 01 February 2013 - 11:40 AM, said:

View PostKillaVanilla, on 01 February 2013 - 11:23 AM, said:

View PostJojo.bacon, on 01 February 2013 - 11:01 AM, said:

So basically it routes packets while maintaining support for programs that use regular rednet connections? Cool!
Yep. As long as said programs that use normal rednet connections don't need to know the distance between nodes (so probably no GPS over routers). (Some) Support for this will (probably) be added shortly.

EDIT: Holy shit, GPS over routers is definitely possible, as long as each node knew where it was...aaand now it seems kinda stupid.
EDIT2: brb, implementing GPSoCRF...

It works with distance?
Mind blown.

Well, kinda. Due to the way routing works, the distances returned are node-to-node distances, so their accuracy is horrible - Node-to-node distance is always greater than straight-line distance. by GPSoCRF, I mean that any node connected to two others could determine its position and automatically become a "locator" node as well. Similar to normal GPS hosts, but automatic. The concept is somewhat similar to how geolocation works in real life. However, if you have any ideas on how to determine straight-line distances from these less accurate node-to-node distances, that would be nice. In any case, I'm trying to get rednet.receive to return something sensible for the distance return value. It may not be accurate, but it's something, right?

Also, how did you post your reply before my reply to your question? (That sure sounds confusing...)

EDIT: Also, emergency "whoops I didn't realize that this was broken" update up.

#9 Beastly

  • Members
  • 6 posts

Posted 01 February 2013 - 01:32 PM

I got one word for this, well acctually three, I HATE YOU :) jk
I've been trying to do this via the vector system (not the built in, yet an entire vector system) for months...

#10 KillaVanilla

  • Members
  • 303 posts

Posted 01 February 2013 - 01:41 PM

View PostBeastly, on 01 February 2013 - 01:32 PM, said:

I got one word for this, well acctually three, I HATE YOU :) jk
I've been trying to do this via the vector system (not the built in, yet an entire vector system) for months...

Routing? If so, then by all means, go for it! Doing it myself was one of the main reasons I made this. I've been trying to make this for 4-6 months or so, and just now managed to complete it.

#11 Jojo.bacon

  • Members
  • 20 posts

Posted 01 February 2013 - 04:35 PM

Even if It screws up GPS it is worth it. Time to make my own ISP on my FTB server! I built a radio tower going to sky level to reach the whole town, making more to reach my far away friends with rednet. The reason this is so good is the fake rednet events, because it basically has backwards-compatibility with all the programs I use.

#12 KillaVanilla

  • Members
  • 303 posts

Posted 03 February 2013 - 03:41 AM

View PostJojo.bacon, on 01 February 2013 - 04:35 PM, said:

Even if It screws up GPS it is worth it. Time to make my own ISP on my FTB server! I built a radio tower going to sky level to reach the whole town, making more to reach my far away friends with rednet. The reason this is so good is the fake rednet events, because it basically has backwards-compatibility with all the programs I use.
If you're using the latest version, then GPS should already work, although it'll be VERY inaccurate. I'll go run some tests to see how inaccurate it is.
My bad, forgot that I didn't implement broadcasting.

#13 KillaVanilla

  • Members
  • 303 posts

Posted 03 February 2013 - 03:58 AM

Uh, crap. I just realized that I was using the wrong event type for the "fake rednet messages" parameter, fixing now

EDIT: Okay, events fixed and broadcast support added. I have no idea if it even is a good idea to allow broadcasting. Then again, if someone really wanted broadcasting, they could simply use rednet.allNodes() and rednet.localNodes(), so it doesn't seem like much of a big deal.

EDIT2: Currently working on V3.

#14 vcordie

  • Members
  • 6 posts

Posted 12 February 2013 - 03:24 AM

If I'm reading this right, like I think I am, this router allows you to send a standard rednet message using any computer, using the standard already implemented rednet, over a relay of nodes that will pick the shortest path/best path/whatever, to a target computer.

If im on computer B and I want to send a message to Computer A which is 150000 blocks away, so long as I have the nodes set up (within rednet range) between A and B, I can send that message?





1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users