(09-04-2015, 01:57 AM)Back_and_Black1 Wrote: He probably will use LPM (longest prefix match algorithm) it's whats used irl.
LPM is only used when the subnets have a varying prefix length. In intOREnet, all the subnet's prefixes will be 6 bits long. This makes the hardware sooooo much easier. Also I have made a few alterations to the protocol to support larger subnets and I will post it when done.
As for the actual hardware itself, little bits of progress have been made recently and I *AM* still working on this.
(09-03-2015, 10:12 PM)TSO Wrote: SO... let's say I want to send something to LD from my nonexistant plot. To make it simple, I'll say that LD is a straight line to the west of me. I'll say the hub under me is hub 0, the one to my north is hub 1, the one to my west is hub 2. Okay, in order to get from me to LD, let's say it has to go through a minimum of 5 hubs. How does hub 0 know that the next hub it needs to get to is hub 2? Does it have a large table saying which of the other 62 connections are on which of the 4 output ports it has? If hub 2 is busy, and my hub decides to reroute through the north hub (hub 1), how does it know that by sending hub 1 my data, it will end up at LD's plot. When the data gets to hub 1, if hub 1 says that the best way to get to LD's plot is through hub 0, what prevents it from being routed back to hub 0?
1. Hub 0 has a table telling it what direction to send packets depending on the subnet they address, so essentially yes
2. Due to the limitations of redstone, no re-routing can be done; because by the time hub 0 hears about hub 2 being busy, it won't be busy anymore because redstone is slow af. That said, some in-switch re-routing maaayyy be possible. The majority of packets received by the switches will probably be in straight lines, so if it receives another packet whilst still dealing with one, it could just send it straight on in blind hope. If it can't go that way, it will just be sent back, in which time the first switch would be free again. This may offer a slight advantage over just buffering the packets since if straight on is correct, then it would be faster.
That is a possibility but I haven't decided yet.