04-11-2015, 11:04 PM
So I'm taking a break from Minecraft until my exams are over, but intOREnet development will continue in my head and my notepad in my spare moments.
Two final notes, due to the large amount of switches required, it is highly unlikely that there will be enough loaded at one given time for the network to be viable. There is a bug with hoppers on 1.8 that will allow me to load an area. Unfortunately, this cannot be switched on and off easily as demand changes. The most control is the ability to shut down and turn on large segments of the network, from my plot, within spawn chunks. When I return and when I have built these switches, I will use this to ensure reliability of intOREnet, so long as staff are OK with it.
The other note is that due to interest in protocol designing, here are the 'set in stone' specifications of how the switches will handle data.
1 000000 00 1 000000 00 1 0000 1 00000000000000000000000000000000
All the 1's are lead bits. Some of them are in the middle because of how the switches and hubs interpret the packets.
The first 6 0's is the destination hub's address. This is assigned to you when the hub is connected to intOREnet and cannot be changed.
The next 2 is which physical port on the hub the destination device is connected to. This could change if you change what port it is connected to (There will be 4 ports, 00, 01, 10 and 11, allowing 4 devices per hub. If people have a plot next to each other and only intend to have one or two devices the I recommend that they share a hub, since only 63 hubs [Maybe one more, maybe one less] can be connected to intOREnet). These two sections make up the destination address.
The next 6 and two is as above, except this is the source address and port.
The next 4 is the packet number. Since, because of routing, packets may arrive in a different order, and data may expand over two or more packets, packets must be numbered so that the receiving hubs can put them in the correct order before sending the devices the data. At the start of a single continuous stream of data, the packet number will be 0000. The next packet will have packet number 0001. Then 0010, then 0011, etc. When you are finished, the last packet MUST have absolutely NO data in it. This is so that the hubs know that this is the end of the data and there are no more packets to be received. When you send the next set of data again, start from 0000 again. Once a hub has received all packet numbers between 0000 and whatever number is no data, it will send the data to the device.
The next 32 (4 bytes) is the data. You can put ANYTHING in here, as the switches will not modify it's contents. It is up to you to decide how your devices should interpret the data. However, once your data has ended, you NEED to send a packet with no data.
Once the packets have finished being sent, switched, transferred, and stitched together, the hub will proceed to send this information to the correct device in the following way:
1 000000 00 1 00000000000000000000000000000000
It strips out all the unnecessary sections for the end device.
The 1's, as before, are leads.
The 6 then 2 are the source address.
The 32 is the data.
All packets received by the end devices will be in the correct order already. A packet with no data in it will be sent last to the device.
Sending data will take the exact same format as above, except instead of source address, it's destination address, and between the source address and the data is a lead bit and the 4 bit packet number. Your hub will add the rest automatically. (the source address). A packet addressed to 111111 XX will be treated like a local address (like 192.168.X.X) and can be used to communicate locally to devices on your LAN. The XX is which port the device is connected to.
So you can come up with any way, format etc. of sending different types of data so long as it conforms as above. Feel free to ask questions but I cannot guarantee I will answer it.
I will return some time after the 15th of June.
-Slug
Two final notes, due to the large amount of switches required, it is highly unlikely that there will be enough loaded at one given time for the network to be viable. There is a bug with hoppers on 1.8 that will allow me to load an area. Unfortunately, this cannot be switched on and off easily as demand changes. The most control is the ability to shut down and turn on large segments of the network, from my plot, within spawn chunks. When I return and when I have built these switches, I will use this to ensure reliability of intOREnet, so long as staff are OK with it.
The other note is that due to interest in protocol designing, here are the 'set in stone' specifications of how the switches will handle data.
1 000000 00 1 000000 00 1 0000 1 00000000000000000000000000000000
All the 1's are lead bits. Some of them are in the middle because of how the switches and hubs interpret the packets.
The first 6 0's is the destination hub's address. This is assigned to you when the hub is connected to intOREnet and cannot be changed.
The next 2 is which physical port on the hub the destination device is connected to. This could change if you change what port it is connected to (There will be 4 ports, 00, 01, 10 and 11, allowing 4 devices per hub. If people have a plot next to each other and only intend to have one or two devices the I recommend that they share a hub, since only 63 hubs [Maybe one more, maybe one less] can be connected to intOREnet). These two sections make up the destination address.
The next 6 and two is as above, except this is the source address and port.
The next 4 is the packet number. Since, because of routing, packets may arrive in a different order, and data may expand over two or more packets, packets must be numbered so that the receiving hubs can put them in the correct order before sending the devices the data. At the start of a single continuous stream of data, the packet number will be 0000. The next packet will have packet number 0001. Then 0010, then 0011, etc. When you are finished, the last packet MUST have absolutely NO data in it. This is so that the hubs know that this is the end of the data and there are no more packets to be received. When you send the next set of data again, start from 0000 again. Once a hub has received all packet numbers between 0000 and whatever number is no data, it will send the data to the device.
The next 32 (4 bytes) is the data. You can put ANYTHING in here, as the switches will not modify it's contents. It is up to you to decide how your devices should interpret the data. However, once your data has ended, you NEED to send a packet with no data.
Once the packets have finished being sent, switched, transferred, and stitched together, the hub will proceed to send this information to the correct device in the following way:
1 000000 00 1 00000000000000000000000000000000
It strips out all the unnecessary sections for the end device.
The 1's, as before, are leads.
The 6 then 2 are the source address.
The 32 is the data.
All packets received by the end devices will be in the correct order already. A packet with no data in it will be sent last to the device.
Sending data will take the exact same format as above, except instead of source address, it's destination address, and between the source address and the data is a lead bit and the 4 bit packet number. Your hub will add the rest automatically. (the source address). A packet addressed to 111111 XX will be treated like a local address (like 192.168.X.X) and can be used to communicate locally to devices on your LAN. The XX is which port the device is connected to.
So you can come up with any way, format etc. of sending different types of data so long as it conforms as above. Feel free to ask questions but I cannot guarantee I will answer it.
I will return some time after the 15th of June.
-Slug