Re: [GNE] GNE NAT traversal and bandwidth performance

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

Bradley Arsenault wrote:
> is hardly noticeable. Its good that you brought this up, I wouldn't
> have thought of it otherwise. 5 Frames is a fifth of a second. I have
> only a small amount of experience in game networking and I'm not sure
> if this is a reasonable latency to expect of a player.

Well you can measure the latency between players to determine the amount 
of command delay you need to introduce. I think pretty much all games 
can benefit from command delay. I switching my thinking of one point of 
"ok, key pressed so do the action now and tell the server" as the 
client's philosophy to "OK, key's pressed let's tell the server and try 
to predict what the SERVER will see/do". The second philosophy 
necessarily means command delay.

In lockstep games you announce the command for frame x (where x is in 
the future). When frame x comes around, if there are packets from all 
players, process that frame, else wait. Of course, the local player is 
its own that sends the message to itself (in the future). The key is to 
determine the minimum frame lead needed so that "waits" do not occur to 
pause/slow the game. You can determine this dynamically. For now, 200 ms 
is acceptable as long as all players are broadband, otherwise I would 
set it to 500ms. For an RTS game a 500ms delay between order issue and 
unit starting the order is actually not that long, unless the RTS is 
extremely action/reflex based (which goes against the S in RTS).

> Its critical that I would be able to implement NAT forwarding somehow.
> From what I've read so far, UDP hole punching involves a change of
> destination IP without forming a new connection. I'm not sure how easy
> that is to do in your code.

I'm not completely sure, but I haven't implemented this in GNE.

> to be allot more difficult that UDP. It may be necessary that if GNE
> where used that TCP like features where implemented manually on top of
> UDP.

This has been the intent since the beginning, but I wanted to do 
research on the API areas of the library, so I put in something that 
"works" under a layer so that I could replace it with pure datagram 
protocols in the future.

The 2nd generation network protocol design that I was starting was going 
to implement this, since this feature alone will hold back GNE from 
serious use.

> Could this be done in GNE anyhow? I'm not sure exactly how these
> systems work, so I can't be quite sure whether special net routines
> are required for them.

Actually, it probably makes best sense to implement this as a library on 
top of GNE. This is separate enough from GNE it can be a separate code 
base. If it works well, it can be merged in, if it could work for most 
games. Otherwise it might be best to leave it as an "officially 
sponsored" add-on/library to use with GNE.

> I quite like the design of the GNE system. It has good documentation,
> and a well constructed API, especially compared to the many C API's
> that I see as my alternatives.

Thanks, this was my focus at the time.

> If GNE isn't being developed, it could become a co-project with Glob2
> (as in advertised on our website and stuff). This would bring it some
> attention from other developers, as well as becoming an integral part
> of Glob. All of the stuff I would have done on Glob2 networking could
> be worked into GNE instead.

This could be discussed. It might make sense to allow some development 
as a branch of GNE then merge those changes into trunk as appropriate. 
But I haven't had enough time to even generate a release of the code in 
the trunk now -- and basically the only thing I have left is packaging 
on that. So I do advise that if you do use GNE, please use the latest 
SVN version as it has a lot of bugfixes that the last release does not.

Jason