01-20-2016, 12:43 AM
(This post was last modified: 07-27-2016, 03:12 AM by slugdude.
Edit Reason: Added map
)
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]](http://i.imgur.com/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]](http://i.imgur.com/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/1...sp=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.
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.
***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:
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/1...sp=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.
![[Image: SKYsapx.png]](http://i.imgur.com/SKYsapx.png)
![[Image: 7TsPKdl.jpg]](http://i.imgur.com/7TsPKdl.jpg)
![[Image: F5apzZt.jpg]](http://i.imgur.com/F5apzZt.jpg)
![[Image: oUy8tQS.jpg]](http://i.imgur.com/oUy8tQS.jpg)
![[Image: x0BmUDt.jpg]](http://i.imgur.com/x0BmUDt.jpg)
