+- Forums - Open Redstone Engineers (https://forum.openredstone.org)
+-- Forum: ORE General (https://forum.openredstone.org/forum-39.html)
+--- Forum: Build Discussion (https://forum.openredstone.org/forum-50.html)
+--- Thread: intOREnet standards thread (/thread-11499.html)
intOREnet standards thread - qwerasd205 - 12-27-2016
This thread is for the purpose of suggesting and establishing standards involved with intOREnet.
RE: intOREnet standards thread - qwerasd205 - 12-27-2016
This is my idea for a proto request standard packet exchange.
--
Total success:
A: Ping!
B: Pong!
B: Ping!
A: Pong!
A: This is a protocol request
B: Affirmative
A: For protocol X
B: Yeah, I use version Y
A: Okay I'm starting transmission now.
--
B online but does not use protocol X:
A: Ping!
B: Pong!
B: Ping!
A: Pong!
A: This is a protocol request
B: Affirmative
A: For protocol X
B: Oh, I don't have protocol X support (all 1s in the data.)
A: Okay, carrying on.
--
B is not online:
A: Ping!
B: ...
--
B is online but A isn't reachable:
A: Ping!
B: Pong!
B: Ping!
A: ...
(After a few failed pings from B):
B: Not getting a pong, terminating connection.
--
Keep in mind with all of these after a timeout if no ack is received a new packet is sent, after a few failed packets (no response) a termination is sent.
RE: intOREnet standards thread - qwerasd205 - 12-27-2016
Idea for ping standard:
A 5 bit prefix indicated ping or pong, so essentially a ping's data area would look like this:
[10000][26 bits of arbitrary data]
and a pong would look like this:
[01111][26 bits cloned from the ping data]
So yeah that's pretty much it lol.
RE: intOREnet standards thread - Apuly - 12-27-2016
Or we make it simpler:
Total success:
A: This is a protocol request for protocol X
B: Affirmative
B online but does not use protocol X:
A: This is a protocol request for protocol X
B: Denied: protocol not supported
B is not online:
A: This is a protocol request for protocol X
B: ...
B is online but A isn't reachable:
A: This is a protocol request for protocol X
B: Denied: not reachable
When designing these protocols, you must keep in mind that there's very limited bandwidth and extremely high delay.
The amount of overhead that your protocol has is so ridiculously high, sending a single packet would take a couple of minutes.
It's important to get rid of as much overhead as possible, and I think that my implementation has as little as would be practicable.
RE: intOREnet standards thread - qwerasd205 - 12-28-2016
(12-27-2016, 11:17 PM)Apuly Wrote: Or we make it simpler:You don't seem to understand that all that "overhead" is necessary.
Total success:
A: This is a protocol request for protocol X
B: Affirmative
B online but does not use protocol X:
A: This is a protocol request for protocol X
B: Denied: protocol not supported
B is not online:
A: This is a protocol request for protocol X
B: ...
B is online but A isn't reachable:
A: This is a protocol request for protocol X
B: Denied: not reachable
When designing these protocols, you must keep in mind that there's very limited bandwidth and extremely high delay.
The amount of overhead that your protocol has is so ridiculously high, sending a single packet would take a couple of minutes.
It's important to get rid of as much overhead as possible, and I think that my implementation has as little as would be practicable.
The pings at the start are to check that both hosts are alive and reachable by the other host. Acks are needed to avoid major failure by packet loss. "denied not reachable" doesn't make sense because it has to ping to see if it can reach A in the first place.
I put a lot of thought in to it.
Also, assuming, say, 12 routers between the two hosts (which would be a lot), it takes 5 seconds to process a packet in a router meaning 1 minute to send the packet from A to B. Then, to establish a connection with my photo between A and B using protocol X with Y version, it will take 9 minutes, assuming no dropped packets, but if a packet is dropped the connection doesn't need to start form square one and it will only add a little over 1 minute to the time it takes to establish a connection.
RE: intOREnet standards thread - Apuly - 12-28-2016
all fine and dandy that you use the pings to see if there's a connection, but you can cut those out completely, and have the request function as ping request as well.
and to be frank I really don't see the use in sending multiple ping packets before opening a connection. if a host can't be reached, it won't receive ping packets in the first place.
RE: intOREnet standards thread - qwerasd205 - 12-28-2016
(12-28-2016, 09:48 AM)Apuly Wrote: all fine and dandy that you use the pings to see if there's a connection, but you can cut those out completely, and have the request function as ping request as well.
and to be frank I really don't see the use in sending multiple ping packets before opening a connection. if a host can't be reached, it won't receive ping packets in the first place.
You seem to be expecting 100% reliability and no packet drops. A makes sure it can connect to B and B makes sure it can connect to A, then the connection continues. Also, you seem to have conglomerated your protocol request and the packet naming the type of protocol, this dramatically reduces your potential request and protocol type data space and so, looking in to the future is a poor idea.
RE: intOREnet standards thread - lollershihi - 12-28-2016
(12-28-2016, 05:55 PM)qwerasd205 Wrote:(12-28-2016, 09:48 AM)Apuly Wrote: all fine and dandy that you use the pings to see if there's a connection, but you can cut those out completely, and have the request function as ping request as well.
and to be frank I really don't see the use in sending multiple ping packets before opening a connection. if a host can't be reached, it won't receive ping packets in the first place.
You seem to be expecting 100% reliability and no packet drops. A makes sure it can connect to B and B makes sure it can connect to A, then the connection continues. Also, you seem to have conglomerated your protocol request and the packet naming the type of protocol, this dramatically reduces your potential request and protocol type data space and so, looking in to the future is a poor idea.
Failure on A-side
A: This is a protocol request for protocol X
packet dropped....
A: This is a protocol request...
If this doesn't answer after X tries, B is not online or not reachable.
Failure on B-side
A: This is a protocol request for protocol X
B: Affirmative
packet dropped between B and A...
Now B doesn't know whether A has recieved and answered, but his packet was lost, or the packet of B was lost. The protocol will have to decide who tries to send first. But the same problem exist after pings have happened.
Your ping's are not smaller than the protocol request, or any other data packet.
RE: intOREnet standards thread - Apuly - 12-28-2016
I assume that no packets will be lost because we work with redstone, not electronics.
If chunks aren't loaded, or for whatever reason a connetion can't be made, it doesn't matter whether the connection was stable in the beginning.
Hack, with your overhead, it can happen that packets that could be send in time can't be send any more, just because of the amount of overhead.
Checking if packets are dropped IRL (using TCP) is on a packet by packet basis, not by setting up a connection and then never checking if the packets dropped again.
With regards to the amount of supported protocols, an intOREnet data segment is 30 bits long.
Assuming you use a byte to identify the type of packet (which is a shit ton for the amount of types you need), you still have 2^22 = 4194304 amount of different protocols that you can support.
If that's too little for future support, you can go ahead and permanently ban me from the server.
RE: intOREnet standards thread - qwerasd205 - 12-28-2016
(12-28-2016, 11:13 PM)Apuly Wrote: I assume that no packets will be lost because we work with redstone, not electronics.
If chunks aren't loaded, or for whatever reason a connetion can't be made, it doesn't matter whether the connection was stable in the beginning.
Hack, with your overhead, it can happen that packets that could be send in time can't be send any more, just because of the amount of overhead.
Checking if packets are dropped IRL (using TCP) is on a packet by packet basis, not by setting up a connection and then never checking if the packets dropped again.
With regards to the amount of supported protocols, an intOREnet data segment is 30 bits long.
Assuming you use a byte to identify the type of packet (which is a shit ton for the amount of types you need), you still have 2^22 = 4194304 amount of different protocols that you can support.
If that's too little for future support, you can go ahead and permanently ban me from the server.
First of all it's 31 bits. Also, packet collisions can happen causing packet drops. I talked with slug about the infrastructure of iOn.
RE: intOREnet standards thread - lollershihi - 12-29-2016
But pinging won't help against packet drops. only "acknowledge" helps confirm the arrival of a packet
RE: intOREnet standards thread - slugdude - 12-30-2016
Yes a collision will cause a packet drop though this is unlikely. Also it's 32 bits not 31.
There should be an option of whether to acknowledge and check and do loads of pings or not depending on the kind of data you want to send - much like in real life, TCP and UDP.
RE: intOREnet standards thread - Apuly - 12-30-2016
From what qwers protocol is suggesting, once it's validated that a connection works it's no longer possible for packets to collide.
Is this correct? Because to me that doesn't sound very correct.
RE: intOREnet standards thread - lollershihi - 12-30-2016
(12-30-2016, 11:39 AM)Apuly Wrote: From what qwers protocol is suggesting, once it's validated that a connection works it's no longer possible for packets to collide.
Is this correct? Because to me that doesn't sound very correct.
No, that's not true. packets can still collide when someone else sends something while the two others are still "communicating"