+- Forums - Open Redstone Engineers (https://forum.openredstone.org)
+-- Forum: ORE General (https://forum.openredstone.org/forum-39.html)
+--- Forum: Projects & Inventions (https://forum.openredstone.org/forum-19.html)
+---- Forum: In Progress (https://forum.openredstone.org/forum-20.html)
+---- Thread: intOREnet (/thread-5661.html)
RE: intOREnet - slugdude - 11-05-2015
(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.
RE: intOREnet - Halflife390 - 11-05-2015
When will construction start! Iv been waiting for ages now. I know I haven't been on the server much lately due to other projects but I will return properly to work on this and other things.
RE: intOREnet - slugdude - 11-05-2015
(11-05-2015, 10:56 PM)Halflife390 Wrote: When will construction start! Iv been waiting for ages now. I know I haven't been on the server much lately due to other projects but I will return properly to work on this and other things.
That, I cannot answer. It'll take as long as it takes.
RE: intOREnet - anatevka - 11-06-2015
Wow. As only a moderately experienced redstonist, this is mindblowing. I'm still only in the student world, but I would love to be connected when I advance. Hopefully I'd be able to learn a lot from it
RE: intOREnet - slugdude - 11-06-2015
(11-06-2015, 08:34 AM)anatevka Wrote: Wow. As only a moderately experienced redstonist, this is mindblowing. I'm still only in the student world, but I would love to be connected when I advance. Hopefully I'd be able to learn a lot from it
In terms of the build server, the hardware isn't very impressive, other builders have built way more complex things.
RE: intOREnet - Magic :^) - 11-06-2015
slug what about having a packet buffer at each switch? That's what I was thinking about doing with a small scale network i'm kind of working on.
basically the way i -might- be doing it, is each switch can hold a packet and store it there while it waits for the next switch to be idle.
it might be a little slower, but redstone is slow af anyways
edit: ah but in my case all this hub/switch stuff would just be 1 routing 'node'
RE: intOREnet - slugdude - 11-08-2015
(11-06-2015, 12:54 PM)MagicalGentleman Wrote: slug what about having a packet buffer at each switch? That's what I was thinking about doing with a small scale network i'm kind of working on.
basically the way i -might- be doing it, is each switch can hold a packet and store it there while it waits for the next switch to be idle.
it might be a little slower, but redstone is slow af anyways
edit: ah but in my case all this hub/switch stuff would just be 1 routing 'node'
I considered that, but my switches are slow af. And buffers can overflow, and I don't want that.