Uzenet
Posted: Thu Dec 11, 2014 6:54 am
Let's make this happen! This thread to continue the conversation and have a separate place to talk about Uzebox networking hardware as a whole system. This is apart from individual low level device details for a specific adapter(CC3000,WIZnet,ESP8266,etc) that might accomplish the same protocol in a very different manner. Basically the way the Uzebox will accomplish it's part hardware wise, but mixed in with add-on device details since you can't totally separate the two. A quick recap of some important items:
Reading some forum posts, I think Uzenet or UzeNet seems to be the clear favorite for the official name. Any suggestions for another name or is that de facto standard by now? While we are at it, I quite like the "Uzebus" term mentioned in the other thread to indicate the actual way the Uzebox is linked and communicates with the add-on device.
There are 2 basic options for anything like this:
Client->Server
Client->Client(peer to peer or anything else you can call it)
Client->Server I don't see a need for more than one connection and that might have an advantage in dealing with only one other device over the internet. With more connections, you will be getting many more separate packets at random times since you are at the mercy of latency to/from multiple separate paths. We might struggle just to keep 1 connection working while juggling communication with the Uzebox. I am pretty newbie at all this hardware interfacing stuff, so I don't have much of an idea without just experimenting to be honest.
Client->Client I could see using up to 3 connections because it would be nice to play 4 player games. If you keep it to 2 players 1 connection would work perfect, but come on...Harty brings it to an expo and explains that he is playing zombienator over the internet with 3 members of the forums, man !
I think some very important things to discuss are client->client vs. client->server and also LockStep vs Asynchronous/Extrapolated. I will leave the UDP(!)vs TCP discussion for later as it's getting late.
I don't know which will work out better. C->S I think will be easier to handle for our add-on devices, but the disadvantage is, as example: I have access to multiple fast fiber locations(where this traffic and would go unnoticed by me ) So if I have a server running here in the northern US I'm loving it at 8ms latency at home, I am playing with Alec he is close and enjoying a latency of <100ms, Harty jumps in from Germany hitting 180ms maybe grumbling a bit but hey it's fun, and CunningFellow wants to play from Austraillia with 300ms+. I can be sure that Cunning will not enjoy the experience as much as me. If we have a server in Europe everyone will have more even pings of course.
C->C the device will need to send and receive more packets since we are connected to perhaps 3 other add-on devices. The actual internet bandwidth required is so small either way that it doesn't matter for modern Fiber/Cable/DSL connections, but I don't know how hard it will be to sort all that out on the device. It would have the advantage that we would all have approximately the same latency and Cunnings latency would be much better. It at least eliminates the round trip delay, that is I send data to a server from Japan but I can't assume I can advance the game tick until the server sends data across that same path and let's me know he got it and what everyone else sent this tick. Now whenever Cunning gets everyone's pad states he just moves ahead without having to wait for a middle man and everyone moves ahead while packets are still "on the wire" for the next tick or two(since time from input to actually running the tick would always be behind no matter what we did). Kind of pulling that out of thin air because there are basically infinite ways you could do any of that.
I always figured C->C would be better, but centrally located C->S might be much simpler and same performance
uze6666 wrote: .....This field is moving so fast, that it would be unwise to directly implement support for any module. As you noted, some interfacing MCU will be required for that to implement a standard protocol.
.....The dongle thing is great since it's universal, but using the SPI on the EXT port on my PCBs would seem simpler and more efficient and can be neatly hidden in the enclosure.....
.....best is probably to implement that protocol in the kernel to support both the Player2 SNES port and the EXT header.....
.....bit-bang SPI approach to simplify code.....
.....Since there's only seem to be serial based module out tthere (no SPI ) we would need a fronting MCU which exposes a standard protocol as you mentioned.....
Reading some forum posts, I think Uzenet or UzeNet seems to be the clear favorite for the official name. Any suggestions for another name or is that de facto standard by now? While we are at it, I quite like the "Uzebus" term mentioned in the other thread to indicate the actual way the Uzebox is linked and communicates with the add-on device.
I think the answer to that entirely depends on the much larger question what type of networking system is going to work best for a small number of players distributed pretty far apart.uze6666 wrote:Btw, do you see need for more than one socket client and one socket listener at any given time?
There are 2 basic options for anything like this:
Client->Server
Client->Client(peer to peer or anything else you can call it)
Client->Server I don't see a need for more than one connection and that might have an advantage in dealing with only one other device over the internet. With more connections, you will be getting many more separate packets at random times since you are at the mercy of latency to/from multiple separate paths. We might struggle just to keep 1 connection working while juggling communication with the Uzebox. I am pretty newbie at all this hardware interfacing stuff, so I don't have much of an idea without just experimenting to be honest.
Client->Client I could see using up to 3 connections because it would be nice to play 4 player games. If you keep it to 2 players 1 connection would work perfect, but come on...Harty brings it to an expo and explains that he is playing zombienator over the internet with 3 members of the forums, man !
I think some very important things to discuss are client->client vs. client->server and also LockStep vs Asynchronous/Extrapolated. I will leave the UDP(!)vs TCP discussion for later as it's getting late.
I don't know which will work out better. C->S I think will be easier to handle for our add-on devices, but the disadvantage is, as example: I have access to multiple fast fiber locations(where this traffic and would go unnoticed by me ) So if I have a server running here in the northern US I'm loving it at 8ms latency at home, I am playing with Alec he is close and enjoying a latency of <100ms, Harty jumps in from Germany hitting 180ms maybe grumbling a bit but hey it's fun, and CunningFellow wants to play from Austraillia with 300ms+. I can be sure that Cunning will not enjoy the experience as much as me. If we have a server in Europe everyone will have more even pings of course.
C->C the device will need to send and receive more packets since we are connected to perhaps 3 other add-on devices. The actual internet bandwidth required is so small either way that it doesn't matter for modern Fiber/Cable/DSL connections, but I don't know how hard it will be to sort all that out on the device. It would have the advantage that we would all have approximately the same latency and Cunnings latency would be much better. It at least eliminates the round trip delay, that is I send data to a server from Japan but I can't assume I can advance the game tick until the server sends data across that same path and let's me know he got it and what everyone else sent this tick. Now whenever Cunning gets everyone's pad states he just moves ahead without having to wait for a middle man and everyone moves ahead while packets are still "on the wire" for the next tick or two(since time from input to actually running the tick would always be behind no matter what we did). Kind of pulling that out of thin air because there are basically infinite ways you could do any of that.
I always figured C->C would be better, but centrally located C->S might be much simpler and same performance