Magicnet, a small network

[Magic :^)]

So, I'm getting close to the completion of my main router/node thing, so i'll go ahead and describe how it works.

First of all, there's a 6 bit IP address and 2-bit port number in a header byte in the form of aa.bb.cc:dd

11 isn't used. I'm keeping things in groups of 3 for easier routing. Maybe i'll use 11 to broadcast to multiple locations, but for now it's undefined.

so, in a maxed out network, there would be 3*3*3 (27) unique addresses, with 3 ports for a client to use at each address. The intention is that a plot can have a unique IP address (or share it with a neighbouring one) with 3 device ports to share.

The nodes are going to be hardcoded with their location information, which is about 8 or so torches/repeaters placed on a decoder. Fairly straightforward to configure. This location information allows the nodes to pass data along the shortest path possible. Since data will always take the same path from A to B, you also don't have to worry about receiving packets out of order.

Each node has an internal buffer which holds a packet as it waits for the next node to be free, if it is busy. This is done by a simple handshake protocol, where the node send a REQ pulse to the destination, and will only start sending the data after it receives an ACK signal in return. Since each node is buffered, an example 16 node network at max congestion would be able to handle 16 packets simultaneously.

The data is routed by the nodes by looking at direct neighbours (mini decoder rom sorts that out):
If the data is already at the right node, it gets passed down a child node.
If the data is in the same group of 3 nodes, but not this one, the data is passed left or right to the correct one.
If the data needs to go somewhere outside this nodes scope, it promotes up to a parent node.

A packet can be variable length, anywhere between 2 and 10 bytes in multiples of 2. Metadata about the packet length is not required, as the node can tell when transmission is finished once the periodic 8 tick initiate line stops. (this is a line which is already required for 8 tick/byte serial transmission)

The transfer cable (1 way) consists of 2 serial transmission lines, 1 initiate line, 1 REQ line and 1 ACK line.

Packet layout:

Code:

Each [] is 8 bits
Serial Line A: [IP address + port num][D0][D2][D4][D6]
Serial Line B: [Return IP if required][D1][D3][D5][D7]

A maximum sized 10 Byte packet would take 40 ticks to serialize in this system.

[Tommyand]

for aa to cc, 00 isn't used. I'm keeping things in groups of 3 for easier routing. Maybe i'll use 00 to broadcast to multiple locations, but for now it's undefined.

WHYYYyyyyyy... would you make 0 undefined? Unless... you have addresses with zero be special loop-back addresses? Why have 27 when you could have... uh... more! (64?)

[Magic :^)]

It's for routing convenience more than anything else. grouping together 3 nodes is MUCH simpler than grouping together 4. groups of 3 are also more efficient for finding the shortest paths through the network.

also i changed the unused bit pair to be 11 instead of 00. For now, a packet with a 11 in any of the address fields will just be ignored. The first router that the packet hits will just send a ping back as if it was handled correctly, but nothing will have been sent further than that router.

[Magic :^)]

Bumping for update: changed the protocol up, i'll probably make a new thread about it.

I'm able to send small packets on a local network now :O

[Magic :^)]

I was asked to explain the system to someone wanting to use it, and my explanation went quite in detail so I'll post it here too:

the network hardware is pretty much finished yeah, but due to the issue of redstone in unloaded chunks, a large scale network isn't feasible at the moment.

so, at the moment there isn't a network to connect to xD

you could use a router for your own local network though, that is totally possible. If you go to my plot (/p visit MagicalGentleman) there's two routers sunk halfway into my plot floor. You could copy one of those to use for yourself, one router can serve 3 unique IPs and is designed to promote up to a parent router if there isn't a match.

There's a hatch at the top of each router which has signs explaining how that particular router is programmed. Each router is unique so it's kind of like MAC addresses (? lol)

If you look at the two on my plot, one will have more bits programmed than the other. You'll want to take that one as that's the one programmed for unique IPs, the second one with more XX terms on the signs is for communicating with different routers.

If you fly down the hatch directly below the signs you'll see torches and repeaters on 4 decoders corresponding to what is written on those signs. That's basically the routing table for that particular router, to do what the signs say.

To actually USE the router, your sender must follow the following rules:

Send a 2 tick request (REQ) pulse on a request line, and wait for a returning 2 tick acknowledge (ACK) pulse from the router. When you get that response, the router is now waiting for you to send a packet.

To send the packet you MUST use 1 tick per bit serial. For every pair of bytes you send on the two data lines, you need to pulse the initiate line on the same tick as the first bit. (ask around for dylanrussel's serial designs. I use his protocols) The data packets can be any multiple of 2 bytes from 2 to 10 bytes. It follows this organisation:

Code:

Each [] is 8 bits
Serial Line A: [IP address][D0][D2][D4][D6]
Serial Line B: [optional info][D1][D3][D5][D7]

The IP address must not contain a pair of ones.
e.g. 01 10 00 01 is fine, but 01 10 11 01 is not fine!
each pair of bits is actually representing a ternary/trinary number. Threes are just easier to work with when trying to connect groups of routers together in the long run. If the router detects a 11, It will automatically delete the packet you send it.

Do whatever you want with the optional info byte. It's just bonus space as the main info for the router is just the IP.

The key for the different data lines are on the router where the main inputs are.
The black box with the lever behind it is for hard resetting the router. That fixes any worldedit bugs you might have from moving it, or if the router is waiting for a response that will never come.
(will be explained in a sec)

To receive data from the router, you will first get a REQ from it, just like how you sent a REQ to send to it. You need to respond to that REQ as quick as you can with an ACK so you don't lock up the router! It will wait for your response forever if you don't talk back to it! (I haven't implemented a timeout D: )

After you respond the router will immediately start sending the packet to you in the same form as you would send stuff yourself. (again, dylanrussel's serial designs, there should be a receiver or two lying around)

One important thing to keep in mind is that I haven't tested packets larger than 2 bytes yet! The router should send and receive packets up to 10 bytes fine, but it might not be able to handle more than one request in quick succession. I fear it might send both packets to the first IP D:

[jxu]

I will be very surprised if someone actually sets up a functioning network on this server
It's been tried like a dozen times

[Magic :^)]

functioning network inter-plot won't work until chunk loading stuff is solved. I have no interest in researching that myself.

A local network within your plot however? perfectly possible.

[§§§§]

Yeah. I may try a simple two plot network with my neighbor.

[LordDecapo]

I will be very surprised if someone actually sets up a functioning network on this server
It's been tried like a dozen times

This iis one.. well u just need to connect some nodes to it and such. But it's mostly done already

[Magic :^)]

If i get around to making a V2 of this router, I'll define the [optional byte] to be the sender's IP.

With this information, It would be reasonable to make a more robust router design, one with a timeout xD

if the router waits too long to send a packet, I could then have it timeout and return a 'could not send' packet back to the original sender. The router would generate its own 'return' IP which would have a 11 pair that corresponds to the tree level where the timeout happened. This also means that error reports won't bounce back and forth between non-clients as two successive timeouts would result in sending to a 11 address which will be deleted :O

Armed with the debug info, one could more easily find broken routers and fix large networks with not much hassle!

If i made this, the protocol would be backwards compatible with the current design too which is nice.

EDIT:
Oh you could also opt out of error reports by setting your return IP to include a 11 pair. That might be handy for some people.

[ddthj]

functioning network inter-plot won't work until chunk loading stuff is solved. I have no interest in researching that myself.

A local network within your plot however? perfectly possible.

Lol been there, done that

[PI-Pyru-Pyru]

So, I'm getting close to the completion of my main router/node thing, so i'll go ahead and describe how it works.

First of all, there's a 6 bit IP address and 2-bit port number in a header byte in the form of aa.bb.cc:dd

11 isn't used. I'm keeping things in groups of 3 for easier routing. Maybe i'll use 11 to broadcast to multiple locations, but for now it's undefined.

so, in a maxed out network, there would be 3*3*3 (27) unique addresses, with 3 ports for a client to use at each address. The intention is that a plot can have a unique IP address (or share it with a neighbouring one) with 3 device ports to share.

The nodes are going to be hardcoded with their location information, which is about 8 or so torches/repeaters placed on a decoder. Fairly straightforward to configure. This location information allows the nodes to pass data along the shortest path possible. Since data will always take the same path from A to B, you also don't have to worry about receiving packets out of order.

Each node has an internal buffer which holds a packet as it waits for the next node to be free, if it is busy. This is done by a simple handshake protocol, where the node send a REQ pulse to the destination, and will only start sending the data after it receives an ACK signal in return. Since each node is buffered, an example 16 node network at max congestion would be able to handle 16 packets simultaneously.

The data is routed by the nodes by looking at direct neighbours (mini decoder rom sorts that out):
If the data is already at the right node, it gets passed down a child node.
If the data is in the same group of 3 nodes, but not this one, the data is passed left or right to the correct one.
If the data needs to go somewhere outside this nodes scope, it promotes up to a parent node.

A packet can be variable length, anywhere between 2 and 10 bytes in multiples of 2. Metadata about the packet length is not required, as the node can tell when transmission is finished once the periodic 8 tick initiate line stops. (this is a line which is already required for 8 tick/byte serial transmission)

The transfer cable (1 way) consists of 2 serial transmission lines, 1 initiate line, 1 REQ line and 1 ACK line.

Packet layout:

Code:

Each [] is 8 bits
Serial Line A: [IP address + port num][D0][D2][D4][D6]
Serial Line B: [Return IP if required][D1][D3][D5][D7]

A maximum sized 10 Byte packet would take 40 ticks to serialize in this system.

This is exactly the kind of knowledge I'm looking for! MagicalGentleman, you are the best! I'm going to visit your plot quit often! ;D

[Chibill]

Please don't bump 2 month old threads when you are not saying something productive.

[Reewass_Squared]

Where do I sign up? This looks somewhat promising.

[josh03222]

Please don't bump 2 month old threads when you are not saying something productive.

Where do I sign up? This looks somewhat promising.

[MW3_587786]

Please don't bump 2 month old threads when you are not saying something productive.

Whelp now it's a recent thread. I'll ask again, where do I sign up?

[LordDecapo]

U dont. This isn't being set up server wide. Magic, others and I see that it's clearly pointless to do such a thing. It only adds lag and unneeded latency. If you want to use maginet, take the parts, assemble one on your plot and connect some stuff to it. Or ask magic if he will put something u make on his little test network.

[josh03222]

I thot threads get locked if they git bumped...