12-25-2016, 09:41 PM
(This post was last modified: 01-17-2017, 06:57 PM by slugdude.
Edit Reason: Upd8ed FLiP pic
)
Nope, today is not April 1st.
Introduction
I sincerely apologise for the delay, but I'm lazy and good at procrastinating and partly busy with schoolwork -- but it's here now! I will start placing the routers and wires on the plots to which I already have permission later today. A map can be seen here: https://docs.google.com/spreadsheets/d/1...sp=sharing
(For some stupid reason Google Sheets won't work for me on Chromium. If you have the same problem try Firefox, works for me there)
Please note that this map has not been updated for a while so there are likely more plots that belong to new people that are not on this list. It would be really handy if staff could fix Dynmap as it makes keeping the map up to date way easier. Never mind, it works but it's just not map.openredstone.org anymore.
If anyone has an issue with their plot status on the map, speak to me in-game or alternatively by forum PM, preferably not in this thread.
This post will serve as an introduction to what intOREnet is, how to use it, and if you're interested, how it works, in full. I will be answering questions below but please keep "m9 can I be coonectereded pl0x" to in-game messages, or forum PMs. I will also be editing this post to add to it if things change, such that this becomes like a one-stop place for intOREnet information.
Before I proceed, I must say that I have not built LAN hardware yet. I will some time after January 2017 (got mock exams), and you can still use intOREnet without it, but you will be limited to one device per person (though if you're feeling adventurous, you could make your own LAN hardware and I'd be happy to help. Speak to me if you're interested).
"So - what is intOREnet?"
As the very punny name implies, intOREnet is an ORE internet. It is often abbreviated to iOn.
"But what can I do with it?"
Pretty much anything involving sending messages over large distances, much like the Internet in real life, but slower.
"Why would I want it?"
Because it's fun, and my vision is for it to inspire more redstone innovation. I've already heard people's plans for intOREnet devices, such as an email server, a file server and even multiplayer games over intOREnet (though with that last one, intOREnet will be very slow so it's probably mostly limited to turn based games.)
"Won't it be laggy?"
Maybe. Because PlotSquared (our plot plugin) does not allow pistons to push over plot boarders, I am limited to using hopper chunk loading. Besides, the pistons weren't very good at keeping the fairly large routers loaded for long enough for them to process. Hoppers should be more reliable with the drawback that they would need to keep the chunks loaded permanently. However, I will keep to the promise I made to staff when I started this project, that was that if intOREnet created noticable performance impacts then I would have to remove some or all of it.
But, consider this - the server render distance seems to be about 11, which means that a single person keeps a 22*22 chunk area (because 10 is the distance from the player, not the length of the area so double it) loaded which is 484 chunks. Imagine those chunks arranged in a line, the length of that line in metres would be 484*16 = 7744m. So 7.7km of wire could be loaded with no extra lag than another person coming online. That's a lot. Plus, I hear our new build server is really powerful.
There's only one sure-fire way of finding out if it's an issue though.
"Wait wait wait - what about the lag created by the redstone?"
The routers are designed to do absolutely nothing while idle, so no updates (not even a clock). I am not using instawire, because when it's slower it's easier on the server. In early tests last year I found instawire to be too laggy whereas normal wire had no issue. So nothing will even happen on intOREnet if nobody is sending packets. And I anticipate that packets won't be sent *that* often anyway.
"Will there be intOREnet on the school server?"
Unfortunately not. The plots on school are a mess with many people inactive, who I can't contact. Since I require a plot owner's permission to build on their plot as Nick and the other staff made sure, it would be near impossible to connect.
"Why can't school people just claim a bunch of plots in the corner?"
Because the hopper chunk loading requires a direct connection to spawn chunks. Hence why I made sure I got a plot next to spawn on the new 1.8 world regen.
"How do I get started?"
Well, first your plot needs to be connected. If you want to be connected, first check the map. If your plot is bright green it means you've already asked and intOREnet will be rolled out to you eventually. If it's dark green, then you've asked, but intOREnet can't reach you. You can move your plot to one of the pink plots (if they're still free - map is outdated) if you want to (but let me know so I can update the map).
Once you have intOREnet connection, you must know a few things to start making intOREnet compatible devices, which brings me on to:
Usage guide and guidelines
Before I proceed, there are a few rules about devices on intOREnet and if I find anyone breaking them, I will disconnect you either temporarily or permanently.
First, some terminology that I will use:
Packet: How you send data on a network. Contains at least a destination address, a source address and the data you want to send.
Router: These devices decide which direction each packet should go in order to reach it's destination.
LAN: Local Area Network. It consists of any devices connected to each other locally before the connection to intOREnet.
Dropped packet: A packet that is discarded and not sent.
Protocol: Defines how devices must construct the packet to understand each other
Encapsulated: When you have a protocol within the data section of another protocol.
Collision: When two or more packets reach a router at similar times.
Acknowledgement: A way to make sure your packet was delivered.
Address: A unique number associated to each device. (I know it can mean other things on the real internet but I'm keeping this noob-friendly.
-----------------------------------------------------------------------------------------------------------------------------------
Firstly, you must know that packet delivery is not 100% guaranteed. If a collision occurs with a packet you sent, the packet may be dropped and you will not be notified. If your data needs to be delivered, you will need to have an acknowledgement system in place.
Packets on intOREnet are sent on a single wire, as 1 bit per tick (or 10 bps, bits per second) serial. The first bit is always a 1 (known as a lead bit, to let devices know that a packet is coming.
Lets move on to the protocol every intOREnet device must use, which I call FLiP (Fixed Length intOREnet Packeting):
![[Image: mhaRp43.png]](http://i.imgur.com/mhaRp43.png)
The above image illustrates how a FLiP packet should be constructed. The unused flags are there because in future iterations of intOREnet they will be used to ensure backwards compatibility. Also, the one awkwardly shoved between the two addresses is because initially it was a lead bit because my previous router design required one there too. (it was terrible, don't ask).
The addresses are comprised of three parts. The first two make up the address of the LAN you wish to send to (don't worry about the fact there's two parts as it's not important for using intOREnet. The last three bits say which device on the LAN you want to send to (if someone has a device connected directly to intOREnet and not via a LAN then they will receive any packet addressed to anything on that 'LAN').
The source address should always be the address of the sender. LAN hardware in the future may be able to prevent you messing up the first 7 bits of the source address, but as LANs aren't a thing yet, you will need to make sure this is right. Spoofing this is against the rules.
Finally, the data section can contain anything that you want the recipient to receive. The routers will not read the data and will not alter the packet at all.
It is a packet structured like this *must* be what leaves your device otherwise intOREnet will not understand how to process it and will count as gibberish as far as the rules go. Also, it is a packet like this that will arrive back at your device.
Your connection to intOREnet is just two data wires and hoppers for chunk loading. If you have LAN hardware then you may have up to 7 sets of 2 wires, for up to 7 devices. One wire is for sending data, the other is for receiving.
There are also special addresses. 1111111XXX will send to the XXX device on your LAN (like 192.168.X.X in real life), and 1111111000 can be used as a loopback address (like 127.0.0.1 in real life). As such, no-one will have the LAN address of 1111111.
Sending to addresses starting with 000 is strictly forbidden.
While you can just send raw data to wherever you need it, I don't recommend it. Instead, I suggest you create your own protocol and encapsulate it in a FLiP packet. This will allow others to also use the same protocol and easily differentiate between different protocols. Yay for standardisation. There should be a commonly used protocol that has an identifier to tell it what kind of data it carries and lots of people should use this. I won't be enforcing a system like this but I highly recommend it. This will also make it easy to reject data that you don't have the means to process.
That's pretty much all you need to do to use intOREnet, but I know many of you will be interested to know what happens to your packet after it is sent, and for you, I move on to:
Explanation of how it works
It does not matter if you do not understand this section - it is not required for using intOREnet.
The physical topology for intOREnet is a partially connected mesh, with a LAN (or not, if they still don't exist) on each node.
The way routers on intOREnet route is that they all have 4 connections. One to the North (00), one to the East (01), one to the south (10) and one to the West (11). When it receives a packet, it looks into it's memory (it's routing table) and picks out two bits that match the destination address of the packet. These two bits tell the router which direction it needs to send the data in.
But there's a twist: Having a memory slot for every single address would make the routers an insane size. So instead, intOREnet will be broken down into 7 areas, each with 15 LANs on it (except for area 111, which will have 14 LANs). The area is what is called the prefix in the FLiP illustration above. So, when a router receives a packet, it first checks to see if it it destined for a LAN in the same are as it (which is hardcoded into each router). If it does, it routes as normal. If it does not, it routes the packet 'in the general direction' of the area it is destined for. This drastically reduces the size of the routers and by extension the speed (due to memory latency).
So how does it know where to send it?
When a new node is connected then a special packet addressed to 0000000000, and the source address of the address that is to be used, must be sent out. When a router receives this. it acts very differently from normal. First, it checks to see if the source address's area matches it's hardcoded area. If it does, it takes the direction the packet came from and tries to store it in it's routing table. If there is already an entry for that address, it discards the packet and stops. Is there isn't then it proceeds to send the packet in every direction.
If the area does not match, then it will do the same, except it will store for the 3 bit address of the area instead of the 4 bit address of the LAN. The result is every router on the net now knows the optimal route to get to that address. The upside is that this method does not require complicated routing calculations. The downside is that all network traffic must cease otherwise collisions will interfere (and the odd quirk that two routes to the same must not equal each other in terms of ticks).
When a collision occurs at a router, the first arrived packet will get processed (even if they were only one tick apart). The second packet gets dropped. If they arrive in the same tick, both will be dropped. The collision system in intOREnet is not very good and I will be improving it over time. But for now, it works, and I didn't want to delay the project any more.
Summary
I'm sorry this took so long. Over the next few days (possibly weeks if things pop up but hopefully days) I will start laying down the intOREnet wires and routers.
Happy intOREnetting.
Introduction
I sincerely apologise for the delay, but I'm lazy and good at procrastinating and partly busy with schoolwork -- but it's here now! I will start placing the routers and wires on the plots to which I already have permission later today. A map can be seen here: https://docs.google.com/spreadsheets/d/1...sp=sharing
(For some stupid reason Google Sheets won't work for me on Chromium. If you have the same problem try Firefox, works for me there)
Please note that this map has not been updated for a while so there are likely more plots that belong to new people that are not on this list. It would be really handy if staff could fix Dynmap as it makes keeping the map up to date way easier. Never mind, it works but it's just not map.openredstone.org anymore.
If anyone has an issue with their plot status on the map, speak to me in-game or alternatively by forum PM, preferably not in this thread.
This post will serve as an introduction to what intOREnet is, how to use it, and if you're interested, how it works, in full. I will be answering questions below but please keep "m9 can I be coonectereded pl0x" to in-game messages, or forum PMs. I will also be editing this post to add to it if things change, such that this becomes like a one-stop place for intOREnet information.
Before I proceed, I must say that I have not built LAN hardware yet. I will some time after January 2017 (got mock exams), and you can still use intOREnet without it, but you will be limited to one device per person (though if you're feeling adventurous, you could make your own LAN hardware and I'd be happy to help. Speak to me if you're interested).
"So - what is intOREnet?"
As the very punny name implies, intOREnet is an ORE internet. It is often abbreviated to iOn.
"But what can I do with it?"
Pretty much anything involving sending messages over large distances, much like the Internet in real life, but slower.
"Why would I want it?"
Because it's fun, and my vision is for it to inspire more redstone innovation. I've already heard people's plans for intOREnet devices, such as an email server, a file server and even multiplayer games over intOREnet (though with that last one, intOREnet will be very slow so it's probably mostly limited to turn based games.)
"Won't it be laggy?"
Maybe. Because PlotSquared (our plot plugin) does not allow pistons to push over plot boarders, I am limited to using hopper chunk loading. Besides, the pistons weren't very good at keeping the fairly large routers loaded for long enough for them to process. Hoppers should be more reliable with the drawback that they would need to keep the chunks loaded permanently. However, I will keep to the promise I made to staff when I started this project, that was that if intOREnet created noticable performance impacts then I would have to remove some or all of it.
But, consider this - the server render distance seems to be about 11, which means that a single person keeps a 22*22 chunk area (because 10 is the distance from the player, not the length of the area so double it) loaded which is 484 chunks. Imagine those chunks arranged in a line, the length of that line in metres would be 484*16 = 7744m. So 7.7km of wire could be loaded with no extra lag than another person coming online. That's a lot. Plus, I hear our new build server is really powerful.
There's only one sure-fire way of finding out if it's an issue though.
"Wait wait wait - what about the lag created by the redstone?"
The routers are designed to do absolutely nothing while idle, so no updates (not even a clock). I am not using instawire, because when it's slower it's easier on the server. In early tests last year I found instawire to be too laggy whereas normal wire had no issue. So nothing will even happen on intOREnet if nobody is sending packets. And I anticipate that packets won't be sent *that* often anyway.
"Will there be intOREnet on the school server?"
Unfortunately not. The plots on school are a mess with many people inactive, who I can't contact. Since I require a plot owner's permission to build on their plot as Nick and the other staff made sure, it would be near impossible to connect.
"Why can't school people just claim a bunch of plots in the corner?"
Because the hopper chunk loading requires a direct connection to spawn chunks. Hence why I made sure I got a plot next to spawn on the new 1.8 world regen.
"How do I get started?"
Well, first your plot needs to be connected. If you want to be connected, first check the map. If your plot is bright green it means you've already asked and intOREnet will be rolled out to you eventually. If it's dark green, then you've asked, but intOREnet can't reach you. You can move your plot to one of the pink plots (if they're still free - map is outdated) if you want to (but let me know so I can update the map).
Once you have intOREnet connection, you must know a few things to start making intOREnet compatible devices, which brings me on to:
Usage guide and guidelines
Before I proceed, there are a few rules about devices on intOREnet and if I find anyone breaking them, I will disconnect you either temporarily or permanently.
- Don't send data to someone unless you know they are correctly set up to receive and process it. If, for example, you send printer data to someone's email receiver, then they will just get a bunch of gibberish. I highly recommend, if you make a device, you incorporate some sort of system to check if the data is legit. You could possibly whitelist certain addresses to make sure you only receive data from those addresses.
- Don't send gibberish on intOREnet. This can clutter up the network, make it slower for everyone else, confuse the routers and even cause damage to other people's devices. This will not be tolerated.
- Leave a reasonable gap between packets. While this won't actually break anything it's a good guideline to follow since if you send a packet to a router, then send another packet before it's done processing, the second packet will either be dropped or get cut in half and sent like that, which would count as gibberish. The current-gen routers may take up to 100 ticks to process a packet before it's ready to receive another. If this is too slow for you then tough. At some point in the distant future I will create a better router, but these ones work for now.
- No tampering with intOREnet hardware beyond your LAN (or single device, if LANs still aren't a thing and/or your device is plugged directly into the net) unless I have authorised it. This can seriously mess up the router's routing tables and all of the routers' routing tables across the network may need to be reset which will take a long time.
- Never send packets addressed starting with 000. These are special packets designed for address designation and can mess up the network. The LAN hardware in the future should prevent this but it does not exist yet so... just... don't.
- (If RS technology gets there) Malware is allowed for testing and proof-of-concept only. Malicious attacks on other users will not be tolerated.
- No attempting to spoof your source address.
- No tampering or expanding the chunk-loading hoppers without my permission.
- If I tell everyone to stop sending stuff for a while, stop sending stuff! It's important.
- No DDoSing!
First, some terminology that I will use:
Packet: How you send data on a network. Contains at least a destination address, a source address and the data you want to send.
Router: These devices decide which direction each packet should go in order to reach it's destination.
LAN: Local Area Network. It consists of any devices connected to each other locally before the connection to intOREnet.
Dropped packet: A packet that is discarded and not sent.
Protocol: Defines how devices must construct the packet to understand each other
Encapsulated: When you have a protocol within the data section of another protocol.
Collision: When two or more packets reach a router at similar times.
Acknowledgement: A way to make sure your packet was delivered.
Address: A unique number associated to each device. (I know it can mean other things on the real internet but I'm keeping this noob-friendly.
-----------------------------------------------------------------------------------------------------------------------------------
Firstly, you must know that packet delivery is not 100% guaranteed. If a collision occurs with a packet you sent, the packet may be dropped and you will not be notified. If your data needs to be delivered, you will need to have an acknowledgement system in place.
Packets on intOREnet are sent on a single wire, as 1 bit per tick (or 10 bps, bits per second) serial. The first bit is always a 1 (known as a lead bit, to let devices know that a packet is coming.
Lets move on to the protocol every intOREnet device must use, which I call FLiP (Fixed Length intOREnet Packeting):
The above image illustrates how a FLiP packet should be constructed. The unused flags are there because in future iterations of intOREnet they will be used to ensure backwards compatibility. Also, the one awkwardly shoved between the two addresses is because initially it was a lead bit because my previous router design required one there too. (it was terrible, don't ask).
The addresses are comprised of three parts. The first two make up the address of the LAN you wish to send to (don't worry about the fact there's two parts as it's not important for using intOREnet. The last three bits say which device on the LAN you want to send to (if someone has a device connected directly to intOREnet and not via a LAN then they will receive any packet addressed to anything on that 'LAN').
The source address should always be the address of the sender. LAN hardware in the future may be able to prevent you messing up the first 7 bits of the source address, but as LANs aren't a thing yet, you will need to make sure this is right. Spoofing this is against the rules.
Finally, the data section can contain anything that you want the recipient to receive. The routers will not read the data and will not alter the packet at all.
It is a packet structured like this *must* be what leaves your device otherwise intOREnet will not understand how to process it and will count as gibberish as far as the rules go. Also, it is a packet like this that will arrive back at your device.
Your connection to intOREnet is just two data wires and hoppers for chunk loading. If you have LAN hardware then you may have up to 7 sets of 2 wires, for up to 7 devices. One wire is for sending data, the other is for receiving.
There are also special addresses. 1111111XXX will send to the XXX device on your LAN (like 192.168.X.X in real life), and 1111111000 can be used as a loopback address (like 127.0.0.1 in real life). As such, no-one will have the LAN address of 1111111.
Sending to addresses starting with 000 is strictly forbidden.
While you can just send raw data to wherever you need it, I don't recommend it. Instead, I suggest you create your own protocol and encapsulate it in a FLiP packet. This will allow others to also use the same protocol and easily differentiate between different protocols. Yay for standardisation. There should be a commonly used protocol that has an identifier to tell it what kind of data it carries and lots of people should use this. I won't be enforcing a system like this but I highly recommend it. This will also make it easy to reject data that you don't have the means to process.
That's pretty much all you need to do to use intOREnet, but I know many of you will be interested to know what happens to your packet after it is sent, and for you, I move on to:
Explanation of how it works
It does not matter if you do not understand this section - it is not required for using intOREnet.
The physical topology for intOREnet is a partially connected mesh, with a LAN (or not, if they still don't exist) on each node.
The way routers on intOREnet route is that they all have 4 connections. One to the North (00), one to the East (01), one to the south (10) and one to the West (11). When it receives a packet, it looks into it's memory (it's routing table) and picks out two bits that match the destination address of the packet. These two bits tell the router which direction it needs to send the data in.
But there's a twist: Having a memory slot for every single address would make the routers an insane size. So instead, intOREnet will be broken down into 7 areas, each with 15 LANs on it (except for area 111, which will have 14 LANs). The area is what is called the prefix in the FLiP illustration above. So, when a router receives a packet, it first checks to see if it it destined for a LAN in the same are as it (which is hardcoded into each router). If it does, it routes as normal. If it does not, it routes the packet 'in the general direction' of the area it is destined for. This drastically reduces the size of the routers and by extension the speed (due to memory latency).
So how does it know where to send it?
When a new node is connected then a special packet addressed to 0000000000, and the source address of the address that is to be used, must be sent out. When a router receives this. it acts very differently from normal. First, it checks to see if the source address's area matches it's hardcoded area. If it does, it takes the direction the packet came from and tries to store it in it's routing table. If there is already an entry for that address, it discards the packet and stops. Is there isn't then it proceeds to send the packet in every direction.
If the area does not match, then it will do the same, except it will store for the 3 bit address of the area instead of the 4 bit address of the LAN. The result is every router on the net now knows the optimal route to get to that address. The upside is that this method does not require complicated routing calculations. The downside is that all network traffic must cease otherwise collisions will interfere (and the odd quirk that two routes to the same must not equal each other in terms of ticks).
When a collision occurs at a router, the first arrived packet will get processed (even if they were only one tick apart). The second packet gets dropped. If they arrive in the same tick, both will be dropped. The collision system in intOREnet is not very good and I will be improving it over time. But for now, it works, and I didn't want to delay the project any more.
Summary
I'm sorry this took so long. Over the next few days (possibly weeks if things pop up but hopefully days) I will start laying down the intOREnet wires and routers.
Happy intOREnetting.
![[Image: dMJ1zUf.gif]](https://i.imgur.com/dMJ1zUf.gif)
![[Image: 5UtoACT.png]](http://i.imgur.com/5UtoACT.png)
![[Image: 3XGvKCS.png]](http://i.imgur.com/3XGvKCS.png)
![[Image: qDPDcJn.png]](http://i.imgur.com/qDPDcJn.png)
lol
