Re: [GNE] GNE NAT traversal and bandwidth performance

[Jason W. <gi...@gi...>]

Bradley Arsenault wrote:
> In Globulation 2, it is essential that every packet arrive intact and
> in order. Every machine must remain 100% synced for every frame. So,
> every frame (it runs at 25 fps constantly), sends a small packet
> indicating what order the user has given for that frame. An order
> would be like constructing a building at (x,y) or increasing the
> number of units assigned to a task.

You are separating the graphical framerate from the logic framerate?

> If an order is not recieved for a frame, the engine can not move
> ahead, because the clients will be instantly desyncronized elsewise.
> The game is not suited for a constant-update system used in many
> FPS's. Instead, it runs the game logic on every client, and just
> transmits user input over the network.

OK, so you are using a lockstep networking model. This is similar to what has 
been used in games like Starcraft. What bothers me about your description is 
how you say "for a frame," implying that there is no lead time on orders. If 
the algorithm really is "get order, send packet, wait for packets from other 
players, advance frame" you are going to have problems because packets don't 
move that fast. The approach to solve that is to send orders executed to 
schedule them to execute in the future. If I understand the Starcraft method 
properly, the schedule-ahead time is constant, depending on the setting of the 
"latency" level (low, mid, high). If a packet is delayed more than the 
schedule-ahead time the "waiting for players" appears. Of course, the model 
can be improved by doing the schedule-ahead more dynamically and I assume RTS 
games today use such a model.

> Before I finalize my decision to use GNE for our game, I have a few questions:
> 
> 1) Can GNE do NAT traversal techniques like UDP hole punching? This is
> very important for a game like this. Can GNE do other techniques as
> well? Perhaps the high level API could have functionality that
> systematically covers all of the possible UDP NAT traversal techniques
> when trying to establish a connection.

This will be one of the eventual goals of GNE, but in the current version the 
focus was on the API. At the time the attempt was to make a modern API when 
exceptions, RAII, smart pointers, templates, etc were not in common use, 
although in the last few years GNE is probably not as ground breaking in this 
area.

But under the hood GNE still uses the first generation protocol that I 
developed to be as easy as possible, so that I could freeze the API and then 
improve the networking layer later. As a result, TCP is used for reliable 
messages and UDP is used for unreliable. GNE also does not do anything to try 
to bypass NAT -- it assumes that the server is not behind a NAT, or has the 
appropriate port forwarding set up. The client can be behind a NAT, of course.

I looked into P2P methods to break NAT but it requires a matchmaking server 
and I believe an entirely UDP-based protocol. Development on the 2nd 
generation of protocol for GNE was started but never finished.

> 2) What is the bandwidth overhead of GNE? As I already explained,
> Glob2 requires TCP like stability with all of its packets. What is the
> overhead in network bandwidth for using GNE in such a manner?

GNE uses TCP for reliable packets. There's a 2 byte overhead per combined 
packet as a packet marker. GNE will combine small game messages (what you see 
as Packet in the code) into larger packets transparently to save on IP header 
overhead. The entire GNE protocol is detailed completely in the specification:

http://www.gillius.org/gne/gneproto.htm

You can determine the exact amounts of overhead from the specification. The 
spec is 100% correct from what I remember and should be complete enough to 
implement a clone of GNE at the network level without referring to any GNE code.

> 3) Can GNE do things like automatically searching a LAN for people who
> are hosting games? Is this planned for future releases?

No. Game searching and game matchmaking service code was planned as a 
"post-1.0" goal for GNE.

> Other than those 3 issues, I quite like the current design of GNE. And
> event driven and multi-threaded interface is exactly what I was
> planning if I couldn't find a pre-existing engine. And the use of
> libraries like Boost for smart pointers is equally within my domain,
> as I use Boost frequently in my own coding.

Yes I was trying to focus on API more than implementation as my own personal 
goal in this, but development has basically stopped for the last couple years, 
unfortunately.

Jason