Forums - Open Redstone Engineers
intOREnet v1.1 - Printable Version

+- 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 v1.1 (/thread-9174.html)

Pages: 1 2 3

intOREnet v1.1 - slugdude - 01-20-2016

So I kinda did a capo - redesigning a project before it's built. But trust me, it was worth it.

Firstly I will cover changes to the protocol. The unnecessary packet number has been dropped and the leftover bits have been replaced by extra address space. These extra bits will be used for LANs - supporting much larger LANs. There were two bits left over which sit after the source address and have been labelled 'Unused Flags". Future versions of intOREnet will use these flags to set them apart from the older versions, so for now just make sure you keep them 00. Although no matter what they are it makes no difference to the routers right now, it will in the future. Version 1 will NOT be implemented. I plan to implement this version because it's epic. Below is an image showing the current protocol with leftmost being the first sent and rightmost the last.

[Image: kqJKrC8.png]

***CROPPING ERROR, THE DATA SHOULD HAVE 1 MORE BIT, MAKING IT 56.***

As can be seen from the diagram, the LAN portion of the address is now 3-bit instead of 2. It now supports eight LAN devices (hopefully excluding LAN switches) instead of the old, puny four. The whole prefix thing will be explained below but it is not required reading for using intOREnet.

If you plan on simply using intOREnet then you need not read further. If you are interested on what routing will go on behind the scenes, read on.

I've decided to break the intOREnet up into 'areas' which will have their own prefix. If you're thinking the word 'tree' stop thinking it. The routers in an area will be interconnected in any allowing arrangement - no specific hierarchy or structure. The routers will also be connected cross-area as many times as wanted. Each area has one designated router which will act as a routing destination for packets from other areas. Structurally it is the same except a small minor difference, and there mus only ever be one per area. Each router only knows how to route to other routers in it's own area, and the aforementioned designated router from other areas. The reason I have done this is it drastically cuts down the amount of memory each router needs, reducing it's size probably in half, if not more. If a packet arrives at a router, it first checks it's destination prefix. If the prefix matches the prefix for the area it is in, it routes as normal. If the prefix does not match, it routes toward the designated router of the other area which it does match.

But here's the weird part: It may not actually reach the 'designated' router. To explain this, I will use a shittily drawn diagram:

[Image: 2WA8s69.png]

The yellow blobs are ordinary routers. The blue blobs are the designated routers (there's probably a technical term for this so if anyone knows it please correct me). The orange blobs are LANs. The green lines are 2 wires (one each way) for serial communication. The black lines show the divides between the areas. (Yes, I know there are a ridiculous amount of routers, it won't be like this in Minecraft, I'm just shit at planning drawings).

Let's say we send a packet from LAN A to some address in LAN F. The packet travels North to router B. Since B and F are not in the same area, B cannot rout directly to F, so it looks at the prefix, and routes towards X, the designated router in F's area. It travels West to C, which does exactly the same thing as B. It travels West to D.

D and F are in the same area - D knows how to get to F. So instead of routing it West to X, it routes North to E - a faster route. It then travels straight South to F, it's destination.

------

So that's what happens with routing. A number of people have asked what happens when a router receives multiple packets at once. In this situation, the router only processes the first one it receives (favouring North, then East, then South, then West if at exactly the same time - probably!). The others, while the router is busy, are directed right in blind hope. The reason for this is that redstone is SLOW and BIG. Two alternate solutions would theoretically work, but would be impractical: 1. The router has a table of valid alternate routes. The problem with this one is size - this router has to fit underneath a plot floor and the extra memory would make it pretty damn big and hard to manage. 2. The router asks nearby routers if they have a valid route. This is where speed crops up, as in many areas, it could be in the 10s of second for transfer time between routers - potentially in the minutes (though I doubt it). Double it, because the result needs to be returned. This could actually work and I may investigate to see if it turns out to be more practical than I anticipated, but it's not a major issue as I highly doubt this will happen very often.

------

This thread: If you have a question about intOREnet, or a proposal, please, post it here. If you have a question about any of these: Chunk loading, whether you want or can be connected, date I will finish, my Mother or other female relatives, a joke, or something not related to intOREnet, I'd appreciate if you didn't post that here. The last intOREnet thread for the old version got tons and tons of pages, I want to kinda keep this tidy. Thanks.

Map of intOREnet connectability: https://docs.google.com/spreadsheets/d/10LVhXGYJ5rgfqjgyeJRmLAwKTy2QwjaCFSBoDRxUUAw/edit?usp=sharing
If anyone has a *problem* with the status of their plot on that map ^ please let me know either by forum PM or ingame.

RE: intOREnet v1.1 - Apuly - 01-20-2016

So... your switches route...
Doesn't that mean your witches are routers?
And I'm assuming that your routers are routers as well.
So your LAN only consists of routers?
sounds like a stupid lan to me.

Also, I don't fucking remember allowing you to put wires under my plot.
If I find any at any point in time, expect intorenet to receive quite a bit of gibberish.

RE: intOREnet v1.1 - Halflife390 - 01-20-2016

Noice, do we have a date as to when construction will start yet?

RE: intOREnet v1.1 - slugdude - 01-20-2016

(01-20-2016, 01:57 PM)Apuly Wrote: So... your switches route...
Doesn't that mean your witches are routers?
And I'm assuming that your routers are routers as well.
So your LAN only consists of routers?
sounds like a stupid lan to me.

Also, I don't fucking remember allowing you to put wires under my plot.
If I find any at any point in time, expect intorenet to receive quite a bit of gibberish.

Ehm, maybe... you see they don't really route - all they know is what THEY have to do with the packet. One switch would not know the 'next step' after it sends it - only what that specific switch has to deal with. I guess this means it's not a router. The thing that calculates which routes are best is intOREnet itself - when a new LAN is connected, it broadcasts it's desired address. If it's taken, nothing happens. If it is not, the switch that receives it writes the source direction in the corresponding location in memory for that specific address. It then resends the 'assignment packet' in every direction. A switch only writes the direction from which it came from first, and if alternate, slower routes reach it, it discards it and does nothing.

The LANs will probably be built using a system similar to Magic's switches, in a tree structure, but of course you can directly plug your device into the thingy that sends stuff to the intOREnet switches (some kind of small LAN switch with a teeny amount of memory for local addresses) for optimal low latency.

Also you must've said I could use at some point, or I wouldn't have made it like that. But if you're no longer OK with this then I can remove you from it.

Actually now I remember, I asked if I could run a wire along the very edge of your plot so I could reach NT, in the hopes jall and embi would agree too. They both said no so I guess I won't be needing your plot anyway, I've changed it to red now, is that OK?

RE: intOREnet v1.1 - slugdude - 01-20-2016

(01-20-2016, 12:43 AM)slugdude Wrote: This thread: If you have a question about intOREnet, or a proposal, please, post it here. If you have a question about any of these: Chunk loading, whether you want or can be connected, date I will finish, my Mother or other female relatives, a joke, or something not related to intOREnet, I'd appreciate if you didn't post that here.

(01-20-2016, 05:40 PM)Halflife390 Wrote: Noice, do we have a date as to when construction will start yet?

This counts as asking for a date.

RE: intOREnet v1.1 - Halflife390 - 01-20-2016

(01-20-2016, 07:56 PM)slugdude Wrote:
(01-20-2016, 12:43 AM)slugdude Wrote: This thread: If you have a question about intOREnet, or a proposal, please, post it here. If you have a question about any of these: Chunk loading, whether you want or can be connected, date I will finish, my Mother or other female relatives, a joke, or something not related to intOREnet, I'd appreciate if you didn't post that here.

(01-20-2016, 05:40 PM)Halflife390 Wrote: Noice, do we have a date as to when construction will start yet?

This counts as asking for a date.

Yes, yes it does, I kinda speed read that part.

RE: intOREnet v1.1 - LordDecapo - 01-21-2016

slug i have a thing that will let you take in a packet from all 4 sides at any time, and have up to 8 scheduled in the order they came in NESW based on the time, so it only prioritizes the side if multiple come in at the same time

its 100% scale-able btw, just stack more on it... and if ur using 2 tick serial for ur stuff, then BEAUTIFUL! it can schedule and do its calculations in 2 ticks less time then the amount u normally have to delay the initiate by.

RE: intOREnet v1.1 - slugdude - 01-22-2016

(01-21-2016, 12:27 AM)LordDecapo Wrote: slug i have a thing that will let you take in a packet from all 4 sides at any time, and have up to 8 scheduled in the order they came in NESW based on the time, so it only prioritizes the side if multiple come in at the same time

its 100% scale-able btw, just stack more on it... and if ur using 2 tick serial for ur stuff, then BEAUTIFUL! it can schedule and do its calculations in 2 ticks less time then the amount u normally have to delay the initiate by.

1 tick serial - sorry!

RE: intOREnet v1.1 - Chibill - 01-22-2016

if all the messages are a fixed length can't you buffer them in a repeater loop??

RE: intOREnet v1.1 - slugdude - 02-20-2016

(01-22-2016, 11:42 PM)Chibill Wrote: if all the messages are a fixed length can't you buffer them in a repeater loop??

Yeah.

But what if a further packet arrives? The repeater loop is still in use so it can't be used.