intOREnet v1.1 - Printable Version

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)

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.

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

tl;dr: It's not done yet

RE: intOREnet v1.1 - Halflife390 - 02-21-2016

(02-20-2016, 09:57 PM)MW3_587786 Wrote: tl;dr: It's not done yet

I still have faith that this will one day be complete!

RE: intOREnet v1.1 - ddthj - 02-22-2016

A few questions:
Can you keep the packets serialized at all times?
Isn't everything going to be huge because of the packet size?
Is there progress outside of what's been written down on paper?

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

(02-22-2016, 05:13 PM)ddthj Wrote: A few questions:
Can you keep the packets serialized at all times?
Isn't everything going to be huge because of the packet size?
Is there progress outside of what's been written down on paper?

1. Not entirely sure what you mean, but if you mean that I should just operate directly on the packet without stopping it and parallelising it, no, I can't. Because the speed is 10bps, or 1 tick per bit, so comparators and torches don't work properly.

2. No. In terms of the switches, they only touch the Destination address - the rest is not read and passed straight through. In terms of the end devices, it depends on how you use it. You don't have to use *all* of that data, just leave trailing zeros and don't read them. It really depends on the higher-level protocol in use.

3. Nope, because I'm lazy as fuck and schoolwork comes first.

RE: intOREnet v1.1 - Rodentman87 - 02-26-2016

How high off of the lower build limit will the wires be?

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

(02-26-2016, 12:55 AM)Rodentman87 Wrote: How high off of the lower build limit will the wires be?

I don't know exactly how high they must be to connect to the switches, it depends on how they end up built.

That said, the wires themselves, possibly with the exception of the switches, can be at any height. They don't even have to be underground, but they look pretty ugly so I'll put them underground, close as possible to the bottom, unless specific people say otherwise for their plot.

RE: intOREnet v1.1 - slugdude - 06-10-2016

So I FINALLY FINISHED (sort of - I still need to do some redirecty thing) the intOREnet router! Better late than never I guess. Here are some pictures of it:

[Image: SKYsapx.png]

I've tested it and it works! However it does lack a way to either buffer or redirect packets it receives while busy, but that should be fairly trivial to add.

Here are some pictures of me testing it under my plot: (I made it as flat as possible so it fits nicely)

[Image: oUy8tQS.jpg]

IntOREnet is very close!

(Yes, I know this is pretty simple and shouldn't have taken me 1 and a half years but 1. School irl and 2. About a week ago I realized (with the help of Koy) I was approaching it all wrong, facepalmed, and started again.)

RE: intOREnet v1.1 - Halflife390 - 06-11-2016

(06-10-2016, 07:04 PM)slugdude Wrote: So I FINALLY FINISHED the intOREnet switch! Better late than never I guess. Here are some pictures of it:

I've tested it and it works! However it does lack a way to either buffer or redirect packets it receives while busy, but that should be fairly trivial to add.

Here are some pictures of me testing it under my plot: (I made it as flat as possible so it fits nicely)

IntOREnet is very close!

(Yes, I know this is pretty simple and shouldn't have taken me 1 and a half years but 1. School irl and 2. About a week ago I realized (with the help of Koy) I was approaching it all wrong, facepalmed, and started again.)

Yay

RE: intOREnet v1.1 - slugdude - 06-11-2016

(06-11-2016, 12:13 AM)Halflife390 Wrote:
(06-10-2016, 07:04 PM)slugdude Wrote: --snip--

Yay

That's a very long, thought out response.

RE: intOREnet v1.1 - ddthj - 06-12-2016

(06-10-2016, 07:04 PM)slugdude Wrote: So I FINALLY FINISHED the intOREnet switch! Better late than never I guess. Here are some pictures of it:
(Yes, I know this is pretty simple and shouldn't have taken me 1 and a half years but 1. School irl and 2. About a week ago I realized (with the help of Koy) I was approaching it all wrong, facepalmed, and started again.)

Dang that think was only half-done a few days ago.

also Idk if it would help, but a switch that I built has a semi-nice buffer system inside of it, it's on my plot under one of the MCPU's

RE: intOREnet v1.1 - slugdude - 06-13-2016

(06-12-2016, 10:16 PM)ddthj Wrote:
(06-10-2016, 07:04 PM)slugdude Wrote: So I FINALLY FINISHED the intOREnet switch! Better late than never I guess. Here are some pictures of it:
(Yes, I know this is pretty simple and shouldn't have taken me 1 and a half years but 1. School irl and 2. About a week ago I realized (with the help of Koy) I was approaching it all wrong, facepalmed, and started again.)

Dang that think was only half-done a few days ago.

also Idk if it would help, but a switch that I built has a semi-nice buffer system inside of it, it's on my plot under one of the MCPU's

tfw literally a few posts ago I posted pics of my working switch designed specifically for intOREnet.

I already have a sort of locking thing specifically for that length packet wchich I can easily adapt to be a buffer.

RE: intOREnet v1.1 - ddthj - 06-13-2016

(06-13-2016, 01:55 AM)slugdude Wrote:
(06-12-2016, 10:16 PM)ddthj Wrote:
(06-10-2016, 07:04 PM)slugdude Wrote: So I FINALLY FINISHED the intOREnet switch! Better late than never I guess. Here are some pictures of it:
(Yes, I know this is pretty simple and shouldn't have taken me 1 and a half years but 1. School irl and 2. About a week ago I realized (with the help of Koy) I was approaching it all wrong, facepalmed, and started again.)

Dang that think was only half-done a few days ago.

also Idk if it would help, but a switch that I built has a semi-nice buffer system inside of it, it's on my plot under one of the MCPU's

tfw literally a few posts ago I posted pics of my working switch designed specifically for intOREnet.

I already have a sort of locking thing specifically for that length packet wchich I can easily adapt to be a buffer.

Oh, well I thought you said that you needed to look into buffers so that the switch wouldn't drop packets if it was busy?

RE: intOREnet v1.1 - slugdude - 06-15-2016

(06-13-2016, 05:58 PM)ddthj Wrote:
(06-13-2016, 01:55 AM)slugdude Wrote:
(06-12-2016, 10:16 PM)ddthj Wrote:
(06-10-2016, 07:04 PM)slugdude Wrote: So I FINALLY FINISHED the intOREnet switch! Better late than never I guess. Here are some pictures of it:
(Yes, I know this is pretty simple and shouldn't have taken me 1 and a half years but 1. School irl and 2. About a week ago I realized (with the help of Koy) I was approaching it all wrong, facepalmed, and started again.)

Dang that think was only half-done a few days ago.

also Idk if it would help, but a switch that I built has a semi-nice buffer system inside of it, it's on my plot under one of the MCPU's

tfw literally a few posts ago I posted pics of my working switch designed specifically for intOREnet.

I already have a sort of locking thing specifically for that length packet wchich I can easily adapt to be a buffer.

Oh, well I thought you said that you needed to look into buffers so that the switch wouldn't drop packets if it was busy?

Well yeah but it's just a bunch of locked repeaters, quite trivial really.

RE: intOREnet v1.1 - TheRedCrafter344 - 06-21-2016

You have permission to use my plot for IntOREnet! PLEASE DO IT

-xXRed_MinerXx

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

(06-21-2016, 10:09 PM)TheRedCrafter344 Wrote: You have permission to use my plot for IntOREnet! PLEASE DO IT

-xXRed_MinerXx

(01-20-2016, 12:43 AM)slugdude Wrote: 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.

RE: intOREnet v1.1 - josh03222 - 07-26-2016

slug...how will u load the chunks that the wires go through? Wouldn't it be laggy? Also, can I pls be connected? Also, when will you finish...

btw do u have sisters? If so, are they hawt? Also, if both are true, are they single?

IntOREnet will get finished.

i liek cheez

RE: intOREnet v1.1 - LordDecapo - 07-27-2016

Gtfo josh

RE: intOREnet v1.1 - slugdude - 07-28-2016

(07-27-2016, 06:16 PM)LordDecapo Wrote: Gtfo josh

RE: intOREnet v1.1 - josh03222 - 07-29-2016

(07-28-2016, 07:20 AM)slugdude Wrote:
(07-27-2016, 06:16 PM)LordDecapo Wrote: Gtfo josh

RE: intOREnet v1.1 - LambdaPI - 09-26-2016

Ask slug, but i think since protocol support is being removed soon, intOREnet will be dead.