gnelib-users — Discuss/Ask questions about GNE with other GNE users.

Re: [GNE] A problem with GNE

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

The client has to be on the network with an ip as normal, of course, but in GNE, when you bind you should never need to set a local ip for client, nor typically a port, either. How are you trying to connect?

Also if you are not using the subversion version of GNE, you should, it is far more stable.
Jason

liukehua880123 <liu...@16...> wrote:

I want to write  a program with GNE, but i meet a problem now  .When I connect the server   must I  set ip for the client ? Can you give me some suggestion that how  can i connect the server in the Local area network without seting the ip for the client ? 

Thank you ...........

[GNE] A problem with GNE

[liukehua880123 <liu...@16...>]

I want to write  a program with GNE, but i meet a problem now  .When I connect the server   must I  set ip for the client ? Can you give me some suggestion that how  can i connect the server in the Local area network without seting the ip for the client ?
Thank you ...........

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

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

[GNE] GNE NAT traversal and bandwidth performance

[Bradley A. <gen...@gm...>]

Hello. I'm the new maintainer of the www.globulation2.org project, and
I'm giving serious consideration to using GNE for our networking
engine. There has been allot of talk on our development mailing list
about remaking the network code that already exist because allot of it
is adhoc, c-style, and not particularly maintainable, and we have
allot of troubles with it as well.

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.

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.

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.

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?

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

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.

-- 
Really. I'm not lieing. Bradley Arsenault.

[GNE]GNE Updates

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

Well I've not made a post to this list in 2 years.  So I figure that I give 
an update.  I've made some GNE updates at my site:

2005-Sep-16 -- GNE Updates
I've added the CVS changelog to the current progress section and also added 
an article about a potential design issue with GNE about how truly 
effective a multithreaded network engine can be in a game? It's an open 
problem and I encourage discussion about it in the fourms, especially if 
you have designed something around this.


Also, if you are not aware, there are some important bugs fixed in the CVS, 
for example a compile bug that occurs only in MSVC.NET 2003.  If you have 
that compiler, you will want to use the CVS version.

Jason

[GNE]Size of libgne.a (mingw32)

[MidoriKid <mid...@ya...>]

826k (!) doubles the size of my executable.  Is there
a way to reduce the size of it?  A dynamic library
would be my requested feature.  :)

MidoriKid

__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree

[GNE]Re: Compilation complication

[Aaron D. <aa...@fi...>]

FYI, I got it to compile just fine using OLD_CPP on my linux box.  Now I'm
trying to get HawkNL to compile on my FreeBSD box =)  I always love a
challenge.  I'll give any feedback on the API itself once I get some time
to fiddle.  I'm sure excited!

Cheers!

-- 
Aaron Dalton
aa...@fi...
http://aaron.finch.st

[GNE]Re: Compilation complication

[Aaron D. <aa...@fi...>]

Makes perfect sense.  The docs I saw said that 2.96 was what was 
supported so I didn't use OLD_CPP.  I'll try that first thing tomorrow.  
Good luck with school!  I too am finishing up a degree and it's lots of 
work.  I'm sure excited to get started with gnelib!

Cheers!
Aaron Dalton
aa...@fi...
http://aaron.finch.st

Re: [GNE]Compilation complication

[Gillius <gi...@ma...>]

Originally the GCC 2.96 code was the default, but since GCC 3 is no longer 
backwards compatabile with GCC 2.9x, and almost everyone has upgraded now, 
the proper version that compiles with GCC 3 and MSVC6 and later is used.

You need to enable the old C++ compatibility mode of the GNE library in 
order to fix these problems.  On the g++ command line the -DOLD_CPP=1 
parameter needs to be given.  In the makefile system you should be able to 
do it with make:

make OLD_CPP=1

Originally OLD_CPP mode was default but OLD_CPP won't compile with GCC 3 
now so the new version is default.

This is the last version of GNE that will be officially supporting GCC 
versions prior to GCC 3 (through my support).  It is too much trouble for 
me as one person working on the last year of his degree to support 11 
compilers so I have dropped quite a few, the biggest one for GNE 0.70 was 
drop for MSVC6 support, because of a bug I could not workaround for MSVC6 
without seriously compromising the API.  The next release will deprecate 
support for MingW 1.0 and 2.0 (leaving 3.0 as supported) and GCC versions 
prior to 3 under Linux, but it may still compile.

If you or anyone else is interested in maintaining any and all ports -- 
basically all you need to do is make sure the CVS version is compiling and 
working on your machine, please let me know, so I won't have to drop GCC 
2.9x support.

Jason

On 24 Sep 2003 at 12:25, Aaron Dalton wrote:

> I am using gcc version 2.96 20000731 (Mandrake Linux 8.1 2.96-0.62mdk).  I
> have successfully installed min_boost and HawkNL and am now trying to make
> gnelib.  Everything compiles just fine (with some very minor
> adjustments) until I get to Console.cpp.  I am not an expert C++-man so
> I'm not quite sure how to fix this problem.  Any help would be greatly
> appreciated.  Below is the error I'm getting.  It appears to not
> like the type "int_type".  Thanks so much for your time.
> 
> -- 
> Aaron Dalton
> aa...@fi...
> http://aaron.finch.st
> 
> [root@chariss gnelib-0.70]# make
> g++ -c -o src/Console.o -MMD -Wall -Iinclude -I/usr/include -O3 -s
> -I/usr/local -I/usr/local/include -D_XOPEN_SOURCE=500 src/Console.cpp
> In file included from /usr/include/iostream.h:31,
>                  from /usr/include/stream.h:33,
>                  from /usr/include/ostream.h:25,
>                  from src/Console.cpp:21:
> /usr/include/streambuf.h: In method `ios::~ios ()':
> /usr/include/streambuf.h:485: warning: deleting `void *' is undefined
> 
> In file included from include/gnelib/Console.h:24,
>                  from src/Console.cpp:28:
> include/gnelib/ConsoleStreambuf.h: At top level:
> include/gnelib/ConsoleStreambuf.h:47: syntax error before `('
> include/gnelib/ConsoleStreambuf.h:77: syntax error before `('
> include/gnelib/ConsoleStreambuf.h:78: parse error before `*'
> make: *** [src/Console.o] Error 1
> [root@chariss gnelib-0.70]#
> 
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Gnelib-users mailing list
> Gne...@li...
> https://lists.sourceforge.net/lists/listinfo/gnelib-users

[GNE]Compilation complication

[Aaron D. <aa...@fi...>]

I am using gcc version 2.96 20000731 (Mandrake Linux 8.1 2.96-0.62mdk).  I
have successfully installed min_boost and HawkNL and am now trying to make
gnelib.  Everything compiles just fine (with some very minor
adjustments) until I get to Console.cpp.  I am not an expert C++-man so
I'm not quite sure how to fix this problem.  Any help would be greatly
appreciated.  Below is the error I'm getting.  It appears to not
like the type "int_type".  Thanks so much for your time.

-- 
Aaron Dalton
aa...@fi...
http://aaron.finch.st

[root@chariss gnelib-0.70]# make
g++ -c -o src/Console.o -MMD -Wall -Iinclude -I/usr/include -O3 -s
-I/usr/local -I/usr/local/include -D_XOPEN_SOURCE=500 src/Console.cpp
In file included from /usr/include/iostream.h:31,
                 from /usr/include/stream.h:33,
                 from /usr/include/ostream.h:25,
                 from src/Console.cpp:21:
/usr/include/streambuf.h: In method `ios::~ios ()':
/usr/include/streambuf.h:485: warning: deleting `void *' is undefined

In file included from include/gnelib/Console.h:24,
                 from src/Console.cpp:28:
include/gnelib/ConsoleStreambuf.h: At top level:
include/gnelib/ConsoleStreambuf.h:47: syntax error before `('
include/gnelib/ConsoleStreambuf.h:77: syntax error before `('
include/gnelib/ConsoleStreambuf.h:78: parse error before `*'
make: *** [src/Console.o] Error 1
[root@chariss gnelib-0.70]#

[GNE]Latest Changes

[Gillius <gi...@ma...>]

I was hoping to get the next GNE release out the door the first few days of 
this week, but in addition to the blackout, I'm having to do overtime work.

I did finish the very last code change I wanted to make.  Nothing more 
should change in the code unless I discover any "showstopper" errors.  the 
only thing I expect to work on is on the install scripts, docs, and 
readmes.

In that department, some may be interested to hear that someone has 
expressed interest in trying to compile GNE on a Mac OS X machine.  If I 
hear more details, GNE may have a Mac OS X port for this next release!  
Theorietically, if Mac OS X looks like a "generic UNIX machine" then GNE 
should compile on it.  I've already run GNE on Solaris and Linux on both 
little and big-endian machines.  I built GNE to be aware of different 
processor architectures so it should theoritically work on Mac without a 
hitch if it supports ncurses and POSIX threads (which I believe it does).

Yes Elias, I know I have no addressed your issues mentioned earlier.  That 
is because I need to relook at the installation method of the library now 
that it requires Boost.

The latest code change I made was to retire the unsafe RawPacket class and 
replace it with the Buffer class.  Java fans will take note that it has the 
same semantics as a java.nio.Buffer for many of its methods.  The Buffer 
class is "safe" in that it will throw exceptions if the buffer overflows or 
underflows.  RawPacket provided some asserts but not all conditions could 
be checked, and asserts are only run in debug mode.  Buffer's checks are as 
stringent as possible and are always performed.  Hopefully this will make 
it very difficult to remote exploit a GNE application through a fault of 
GNE.

Therefore, the internal parsing API has changed so that readPacket and 
writePacket are not only allowed but are now encouraged to throw exceptions 
(compatable with type GNE::Error&).  The GNE code now gracefully handles 
these exceptions.

Jason

Latest changes:
  Added ErrorCode User for user-inherited Error objects.
  Throwing exceptions during readPacket and writePacket is now allowed.
  RawPacket class was retired and replaced by the new safer class Buffer.
    RawPacket's name was confusing, and did not have strong protection against
    overflow and underflow.

[GNE]GNE Release Candidate

[Gillius <gi...@ma...>]

I've checked in what I hope is the last of all major changes to GNE in the 
last 13 months.  I decided that I wanted to refactor the API, and I figured 
that if I was going to break backwards compatiblity I should do it all in 
one go.

I'm getting anxious to make a release but I am working very hard to make 
sure not to put out a product with any major holes or bugs.

Before I decided to do the refactor I was very well on my way to finishing 
the high-level API.  For the next release the high-level API will not be by 
any means finished.  I didn't want to remove any code, so for the next 
release anything marked as "high-level GNE" is strictly experimental - It's 
still very much in progress and its API may drastically change, espically 
since I coded it before the mid-level API refactor.

You will find all of the major concepts for GNE are still intact.  The 
hugest change I've made is a move to smart pointers for the listeners and 
threads and other major GNE objects.  The implementation I use adds no 
overhead to accessing the objects and the overhead for deletion and 
creation is very small (but it wouldn't matter anyways since you aren't 
saying new ClientConnection() in the middle of a tight render loop!).

This should remove those embarassing delete conn; delete this; type 
constructs and greatly simplify the use of the code by having to worry 
about memory management.

The following document is incomplete but shows some of the major API 
changes:
http://www.rit.edu/~jpw9607/gne/apichanges.htm

The release candidate code can be found in the current CVS repository -- 
please note due to problems with SF's CVS servers the delay is about 24 
hours before the general public sees the code, and my latest changes were 
made Sunday night, and more may come.

The only piece of work I am considering now is improving the RawPacket 
class to do buffer overflow and buffer underflow checking by throwing 
exceptions, and fix up a little bit about how it manages memory.

Here is the current change log that covers all the changes that were not 
part of the huge API refactor:

GNE 0.55 to current
  Fixed a extremely unlikely condition where a SyncConnection may be waiting
    forever to get its next packet.
  Major reworking of the connecting code, and added a state to Connection to
    help keep track of things.  These changes fixed some bugs including at
    least one deadlock, and increased robustness when GNE is shutdown while
    a Connection is connecting (so it can fail and quit early).
  Complete reexamination and major overhaul of event generation to listeners,
    and the synchronization that occured as a result.  Hopefully this will
    get rid of the deadlocks and hopefully most if not all of the remaining
    bugs dealing with connections.
  Fixed 2 memory leaks in Connection.
  Fixed overflow bugs in Time.
  The debug log isn't shutdown when an explicit GNE::shutdownGNE call is
    made.  This resolves some hard-to-avoid crashes when using the gnedbg
    macros.  Instead logging runs in its own atexit after GNE's.
  Added the PacketStream::writePacket method taking a SmartPtr.
  LockObject nad LockObjectEx added.  These work on SynchronizedObjects like
    gout.
  onTimeout events were being generated even when the timeout value was set to
    0.
  Like Connections and Timers, ServerConnectionListeners can live after
    being "lost".  The method ServerConnectionListener::closeAllListeners was
    added.
  Thread::requestAllShutdown, Timer::stopAll, Connection::disconnectAll
    methods added.
  optional clearOnExit param to Console::initConsole
  Thread::waitForAllThreads didn't work right at all.  How did I miss that?!
  Major API changes, see http://www.rit.edu/~jpw9607/gne/apichanges.htm
    There were a LOT of changes not listed here.  That document covers most of
    what is not listed here.
  Added Console::mclearConsole method.
  Added ObjectBroker, ObjectBrokerClient, ObjectBrokerServer.
  Added ChannelProvider and ChannelPacket to add in channel functionality into
    GNE.
  Added clock synchronization capability into the PingPacket class.
  Added copy constructor and operator= to Time class.
  Modified exisiting packet classes and examples to use RawPacket::getSizeOf.
  Added RawPacket::getSizeOf functions.  You should now use these rather than
    the sizeof operator when determining the serialized size of the packet.
  Added RawPacket operators to read and write GNE::Time objects.
  Added operators *, /, *=, /= for integers in the Time class.
  Added Time::getTotalmSec, to return total milliseconds time.
  Added a debugging system for mutexes which is active when compiling GNE in
    debugging mode.  It detects the following cases:
    * If you try to release a mutex you have not acquired, or if you try to
      release a mutex that the current thread does not own.
    * If you try to destroy a mutex that is still locked.
    The mutex now keeps track of a recursive count, and who owns it, which can
      be viewed easily when debugging by most debuggers.
  Added the ConsoleBuffer and TextConsole classes, a word-wrapping window
    that supports scrolling, and an arbitrary rendering device.
  Changed header include scheme to get rid of any extra header files I could,
    most notably my main goal was to get rid of forcing the user to have
    windows.h included indirectly through gnelib.h.

[GNE]Network Library Design

[Gillius <gi...@ma...>]

I've got up most of the high-level network design up on the GNE site now, 
for all interested parties to see (and comment on).

http://www.rit.edu/~jpw9607/

I'll be working on adding a bit more to it (mostly creating the 
ChannelProvider section), and proofing what's there, because I've changed 
my mind on quite a few things in the middle of designing the features of 
the API, so there may be some inconsistancies.

This weekend I will be working on the library and code quite a bit, so 
hopefully by the end of this weekend I aim to be completed with the design 
and get the headers and DOxygen documentation finalized, and stubbed C++ 
code enough to generate documentation to put up.  I've already done quite a 
bit of headers/docs and a little bit of code, but once I got all of the 
headers done I got confused and saw some holes in the API so I decided to 
relook at it and create some formal design stuff and the charts, and 
hopefully I can use most of what's there.  Luckily I didn't write any code -
- just goes to emphasize to definitely write all of your stubs, headers, 
and documentation before you do any code to make sure the API is sound.

Jason

[GNE]GNE High Level Server Design

[Gillius <gi...@ma...>]

I've been working on the High Level Design.

I've ran out of time to work on this tonight since I'm already very very 
late for bed, but I got soo close.  I hope to finish it tomorrow or Thurs, 
but this is close enough I'm putting it up privately for some comments from 
you guys before I put it up on the public site.

Basically (for those knowing the GNE mid-level API) all of the stuff you 
see in the chart executes in the mid-level API's onNewConn event.  The high-
level API wraps over the mid-level events and provides the high-level 
functionality and new events there.

The chart shows the server side, but I think at least generally what the 
client does is very implicit based on what the server is doing and getting 
from the client.

http://www.rit.edu/~jpw9607/gne/design/HighLvlServerDesign.htm

This second URL is my first try at the chart, but it was meant more for the 
user, whereas the first chart I linked to was meant for me, since it 
includes mode GNE stuff.  You can see some of the original stuff I designed 
and how it has changed.

http://www.rit.edu/~jpw9607/gne/figs/GNEHighConnection.png

I also have lots of other things designed, like channels and whatnot.  I 
hope to write up stuff about that soon.

Jason

[GNE]High Level GNE API

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

I'm currently designing the high-level GNE API, but I'm running into 
some tough choices, because I want to offer enough flexibility so that 
any time of game can be made in the way the author desires, but I want 
to make programming the commonalities between games as simple as 
possible, but unfortunately these two ideas are often at odds.

If I move a piece of functionality into GNE, then I am making some sort 
of assumption about the target application.  This makes programming the 
games simpler, but reduces flexibility.  Where I can I've tried to make 
some features optional, and others extendable by inheritance.

What I am stuck on right now is how to handle players in the Server 
class.  There are some choices I can follow.  Keep in mind, this entire 
high-level API is built upon the mid-level one, and therefore is 
optional, so what I did in the mid-level is keep it so that it's 
suitable for 99.999% of games, but for the high-level I want it suitable 
for the most common set of games.

The ultimate amount of flexibility comes from a system where the game 
author manages all player lists.  GNE provides a couple of utility 
functions, and a way of obtaining unique player IDs from a function it 
can then use to assign to a player.  I'm not really fond of that choice 
because handling players and player lists is pretty common to all games.

My second choice is to let GNE manage simple player objects including 
IDs, and let the game author attribute a packet type to be tied to the 
objects.  GNE will create the new players and get their player data 
packet.  This simple method will allow a good level of functionality but 
without having to worry about designing the GNE API to allow the user to 
derive their own classes.  If more than a single packet is needed to 
describe a player, the author will have to handle that functionality on 
their own.  It is intended that the player data packet contain things 
like ping time, score, etc, and the players' avatars are handled 
separately.  The disadvantage of this system is that if other 
information is needed then the author has to make a list of players 
external to GNE but mirroring the GNE list to contain the additional 
data.  Also it prevents the author from using the same class to describe 
the player from a network perspective and the player from the game's 
perspective.

I'm trying to think of a way the author can create their own classes 
that GNE will use, similar to what is done on the mid-level API with the 
Packet and ConnectionListener classes.  The big problem with this is 
trying to come up with a way to effectively allow the author to create 
their own class to extend GNE's.  Also in the current high-level design 
I am considering right now, the data about the player resides in a 
different place from where the player gets his events.  I'm trying to 
see how to resolve that issue, though.  One thing I am thinking is to 
have a custom pointer in GNE's player class to the author's specific 
player class, so that they are stored in the list together and managed 
at the same time with the same API.  The disadvantage to allowing the 
author to extend the GNE class is that the author's classes become more 
dependant on the underlying design of the GNE, and additionally the API 
will be more complicated as a result, because unlike the mid-level API 
where the author's code runs to make their listeners, the connection 
process is handled mainly in GNE code, which makes designing generic 
code more difficult.  The advantages is that there is additional 
flexibility offered through this system.

In the latter 2 systems I'm still trying to decide how to handle the 
user data.  It may be possible that when a client joins, the server does 
not like its data (ie the client has a non-unique name).  How do I 
handle this situtation generically in GNE?  I could have the client 
present its data, and then the server can either refuse the client's 
connection, or present a revised copy of the data, and finish the connect...

Any insights you can give would be helpful.  Mostly what I'm looking for 
is the kinds of games you think are common, and what are the most usual 
ways of dealing with players, and the most usual attributes.  Knowing 
that may help me decide what choices to make, and what 
limitations(assumptions) are acceptable to apply for the sake of greatly 
simplifying game author code.

Jason

[GNE]GNE Tutorial 2

[Gillius <gi...@ma...>]

I've written a draft of the 2nd GNE tutorial.  It's currently up on my 
site.  It's called "Network Game Programming Techniques using 
PacketFeeder," and it can be found at:

http://www.rit.edu/~jpw9607/gne/tutorials/tut2.htm

It didn't turn out as well as I originally thought for, nor did it cover 
all of the points I originally intended, and it covered points that I 
originally did not intent to cover ;).  Let me know what you think about it 
and if it's of any use.

Jason

[GNE]onFailure()

[Elias P. <el...@us...>]

Hi,
just wanted to say, I managed to compile GNE with gcc-3 shortly after
you left yesterday. Apparently my gcc-2.95 is not UNIX-98 compliant,
whatever that means - and so it doesn't have that one pthread function.

Something else, I started with my example now, and have a short question
about onFailure(). I was trying to understand the exping example: If I
open a server and a client, i can shut down the client, and then
reconnect, no problem.
But if I kill the client (with the kill command), the server receives an
onFailure(), then also shuts down. What I want is, the server should
receive the onFailure() if it likes to do so, but continue listening and
not shut down - for obvious reasons. I couldn't figure out how to do it,
mainly because I don't see where in the code the server shuts down. What
exactly happens after it receives the onFailure()? There's no exit() or
anything, and knowing only C, I'm lost :) (It's not really a big problem
for now. My example program works, but I have to make the clients
disconnect before shutting down, else the server shuts down itself when
the first client is shut down.)

--
Elias Pschernig

[GNE]GNELIB learning curve

[Tero L. <ter...@au...>]

Hello,

I'm a quite fresh user of GNE and still learning its logic. I want to say=
 that=20
GNE is awfully hard to learn.. reference manual is good for some purposes=
,
for example if you want to check what kind of parameters particular funct=
ion=20
wants but not for learning. Examples are over-complicated and I don't fan=
cy=20
putting code to header(.H) files. Examples should be only about 100 lines=
 or=20
less and in one file so you can keep a text editor open while you rip stu=
ff.=20
:-)
The only place I could find how to send unreliable packets is exhello.cpp=
=2E No=20
sign of it in manual.

There should be a proper tutorial, helping users to learn this great libr=
ary=20
step-by-step. Remember, easier lib =3D=3D more popular lib (almost).=20

Best regards,
  Tero Laitinen

[GNE][Fwd: GNE 0.55 Release]

[Elias P. <el...@us...>]

-----Forwarded Message-----

> From: Gillius <jp...@cs...>
> To: Elias Pschernig <el...@us...>
> Subject: GNE 0.55 Release
> Date: 20 Jul 2002 01:23:53 -0400
> 
> I've tried MANY times in the last two days to send this out.  No matter
> what I've tried I'm unable to send mail to gnelib-users and gnelib-devel
> anymore.  Do you think you can forward this to the list?
> 
> In fact it took me several trys just to get this through to your email.  
> Seems SF doesn't like my domain name anymore and thinks it's an invalid or 
> spoofed name or something I dunno...
> 
> After some more months of work, GNE 0.55 has been released.
> 
> GNE, or the Game Networking Engine, is a cross-platform, multithreaded,
> C++ networking library with an API specifically addressing the needs of
> game networking, which I designed as a networking library to use with my
> games using the Allegro library.  GNE uses the HawkNL library by Phil
> Frisbie to provide cross-platform compatability.
> 
> There are two parts of GNE, the first being the mid-level classes that
> handle parsed (endian independent) packet data, error checked, and
> bandwidth throttled communication between two peers using an event-driven
> scheme.
> 
> The second part is the high-level classes than will now be worked on and
> will handle things like unique player ID's, player-to-player text
> communications, and develop a framework for a game server. It will also
> have a list server which is a server list players can connect to find
> games to play in.
> 
> This release is particularly of great importance to GNE.  The mid-level
> API has been completed!  (The high-level is in design stage now).
> 
> Because GNE is now finally considered (by me) to be ready for using in
> games, I've spent a huge amount of time improving its usability, thus GNE
> 0.55 is mostly a cleanup of GNE 0.49. The build process has now been
> greatly cleaned up and simplified -- GNE now only requires 1 rather than 2
> external libraries, and the library it does need (HawkNL) comes with it
> precompiled as a special version (MSVC6, MSVC.NET, mingw only) to not need
> pthreads-win32 when in Windows.
> 
> The installation process for MSVC6, MSVC.NET, and mingw now include 
> automatical installers which walk you through the installation or 
> reinstallation process step-by-step, detecting your settings, and allowing
> you to customize your install. If it discovers any errors, it attempts to
> fix them, or if it is unable, to offer advice.
> 
> The documentation has also been improved through the creation of a large
> tutorial, and additions to the GNE FAQ and code reference documentation.
> 
> On the technical side of things, there have been bug fixes, and the packet
> writing scheme has been rewritten to greatly enhance performance, control,
> and latency of the outgoing data (the PacketFeeder class).
> 
> The GNE website:
> http://www.rit.edu/~jpw9607/
> 
> Jason Winnebeck
> 
> 
> 

[GNE]GNE 0.55 Tutorials

[Gillius <gi...@ma...>]

GNE developers/users and EGSTank developers:

This is addressed to both lists, even though you don't know each other ;).  
I thought I'd hit 2 birds with one stone.

Hmm I just spent the last three and a half solid hours finishing up this 
tutorial.  Lots of people have been complaining that GNE is too hard to use 
so I wrote up this tutorial.

http://www.rit.edu/~jpw9607/gne/tutorials/

Note that this is for the next version of GNE which isn't released as we 
are still working out compile bugs in mingw for Windows, and with HawkNL in 
Linux (fixed, but waiting for release of HawkNL 1.6b5 or final).  Almost 
all of it is still directly applicable to GNE 0.45 though anyways.

I've really late now and my eyes hurt, so it's not proofed, and I may have 
made some lame mistakes towards the end ;).

GNE developers - please provide feedback.  Also EGS developers who might 
work on networking code will want to read this.

I hope to have a very clean GNE 0.55 release which will mark the completion 
of the mid-level API.  With this new tutorial and the interactive 
installers for MSVC6, MSVC.NET, and mingw I hope the library will move into 
it's actual "useful" phase rather than it's current phase of "lots of kick 
ass code that no one but Gillius can figure out."

Jason

Re: [GNE]Help!

[Gillius <gi...@ma...>]

Sorry for the very long response time.  I just got my new computer back up, 
though.

Have you read the beginners guide yet?

There is a ServerConnectionListener class which listens on a port for 
ClientConnections to connect.  Then when this happens a ServerConnection is 
created, and the first time you see it is in your onNewConn handler.

OurConnectionListener is derived from ServerConnectionListener, so it is 
just a class representing the socket listen() is called on, and when 
something comes in, it accept()s and the newly spawned socket becomes the 
ServerConnection which is subclasses in the examples as OurServer.

exhello and exsynchello are examples that show the minimum code to set up a 
fully-functional framework and initiate a connection.  There is a bit of 
overhead, but once you get that framework in, it should be very easy to 
expand onto that.

Gillius

On 20 Mar 2002 at 20:39, Varlock wrote:

>     Hello.
> 
>     I just signed up over here from your suggestion on the [AGP] list. I
> don't really want to bother getting the new pthreads working with it or
> anything like that - it seems to work just fine as it is with the older
> version, but I would really love some help understanding how GNE works.
> Mainly, these points.
>     I understand the concept of a packet, and I really like your packet
> structure. I've already made a new packet type and I think I've got that
> under control. Unfortunately, I don't really get the rest of it. I've looked
> through some of the example programs and I don't know what the difference
> between a ConnectionListener and a Server and/or Client are. Why do the
> examples define an OurConnectionListener, and what does it do?
>     Grr. I'm having trouble coming up with specific examples here for some
> reason. If you assume all I really understand are the packets, is there
> something I could read which would help me get what I need to do to write a
> simple application? I'm mostly getting confused by the example programs. For
> example, let's start of with how do I
> 
> a.) create a server (ie. the classes required)
> b.) create a client
> 
>     Thanks. I'm sure I'll have a lot more questions as I get to understand
> this stuff. I believe I have a good grasp of the concepts of networking, you
> probably don't have to go into a lot of theory. I just need to understand
> how your code relates to that theory so I can get on to the good stuff.
> Thanks again.
> 
> - Trevor
> 
> 
> _______________________________________________
> Gnelib-users mailing list
> Gne...@li...
> https://lists.sourceforge.net/lists/listinfo/gnelib-users

[GNE]Help!

[Varlock <va...@ca...>]

    Hello.

    I just signed up over here from your suggestion on the [AGP] list. I
don't really want to bother getting the new pthreads working with it or
anything like that - it seems to work just fine as it is with the older
version, but I would really love some help understanding how GNE works.
Mainly, these points.
    I understand the concept of a packet, and I really like your packet
structure. I've already made a new packet type and I think I've got that
under control. Unfortunately, I don't really get the rest of it. I've looked
through some of the example programs and I don't know what the difference
between a ConnectionListener and a Server and/or Client are. Why do the
examples define an OurConnectionListener, and what does it do?
    Grr. I'm having trouble coming up with specific examples here for some
reason. If you assume all I really understand are the packets, is there
something I could read which would help me get what I need to do to write a
simple application? I'm mostly getting confused by the example programs. For
example, let's start of with how do I

a.) create a server (ie. the classes required)
b.) create a client

    Thanks. I'm sure I'll have a lot more questions as I get to understand
this stuff. I believe I have a good grasp of the concepts of networking, you
probably don't have to go into a lot of theory. I just need to understand
how your code relates to that theory so I can get on to the good stuff.
Thanks again.

- Trevor

[GNE]GNE CVS

[Gillius <gi...@ma...>]

GNE is nearing version 0.5.  If you are keeping up to date via CVS (if you 
are, I'm sorry I haven't been doing a great job keeping a consistant 
quality of code at all times and also changing the API on you a lot with 
small things).

If you are using the CVS GNE, I ask that you please update and test what is 
going on right now.  Make sure that you can run all of the examples 
properly.  I've been seeing 3 errors but I've not been able to reproduce 
them locally on my two test machines, and they are very bad errors.

The exnetperf example has been updated to allow the reporting and changing 
of rates (changing of rates in client-side only, simply for ease of 
programming -- the server CAN change the rates but it would require a much 
more complicated UI).

I have very little left to do for GNE 0.5 and the completion of the mid-
level classes!  Once 0.5 comes out you should be able to use all of the 
classes and functionality you've seen promoted thus far.  After 0.5 the 
game engine classes, which are all optional, will be added into GNE.

My only question about adding significant functionality into GNE is whether 
or not I want to include a sample game into GNE 0.5.  Writing a sample game 
will help be a proof-of-concept, and it will test my API as well as become 
a much deeper test of GNE.  I want so that when 0.5 comes out that 
hopefully the API for the current classes will be _FROZEN_ so people can 
actually start to use it, and this code would become beta quality at 0.5, 
with the game server code being pre-alpha.

I am still deciding if I want to release a GNE 0.49 for widespread public 
beta testing before putting out 0.50, and adding a sample game would have a 
very large impact on this decision.

This is the big moment here people.  Say what you want to say now or 
potentially forever hold your peace until GNE 2.

Gillius

[GNE]GNE Update

[Gillius <gi...@ma...>]

Work continues on the CVS version of GNE.  The exciting 0.5 release 
containing the completed mid-level API I believe is just a couple of weeks 
away!  At this time GNE will be "complete" from the basic aspect of data 
communications between peers.  After this is completed, the game engine, 
high-level classes will be started.  (Your testing, help, and ANY 
suggestions will all be VERY appreciated in this process!)

Anyways, I've been doing quite a bit of work moving towards this goal.
As you already know, the GNE protocol spec was released quite some time 
ago, and I am working on implementing that spec.

So far, I have implemented the handshake part of the spec, and tonight I 
have just finished the ExitPacket functionality for a graceful disconnect 
and this is now in the CVS.  It is ironic how it was easier for me to code 
GNE to work properly when the connection FAILED -- it was actually harder 
to get the proper behavior for an ideal disconnect ;).  Well sorta.  Turned 
out I found a way to solve it very easily but I had to think about it for 
awhile ;).

Development would have gone faster but I have spent quite a bit of time 
doing some more serious testing of GNE in preparation of 0.5 and the rest 
of the protocol implementation.  I have been running stress tests and such 
to make sure that GNE is operating top-notch, and in this process I have 
found plenty of bugs, and luckily I have discovered and corrected some VERY 
obscure bugs that I would only have (likely) found in the raw pre-protocol 
implementation code, so I've been making a point to test hard throughout 
this whole process.

Just tonight I decided to go wild, and I started 6 exhello clients on my 
machine hammering as hard as they could on a server process on my machine.  
I had them in a loop to connect as fast as possible 100 times over.  To my 
delight, thanks to the blocking nature of GNE (and the much improved 
Windows XP kernel), I didn't see any noticeable performance degredation at 
all.

Although, because threading issues are very sensitive to processor speeds 
and operating systems, I encourage anyone willing to keep up to date with 
the latest CVS when possible and make sure that the examples are always 
running properly for them, and to report any errors on the gnelib-users 
list or to me personally.  I espically want to hear bug reports about how 
you feel that API might be weak, hard to understand, or that the 
documentation is deficient, because it will be pointless for me to make a 
library that no one can use.

For those of you curious, here is the complete, boring list of changes thus 
far since 0.45:
GNE 0.45 to current
  Graceful disconnects are now detected and handled through the onExit 
event.
  ExitPackets are now sent when a connection closes, as per the GNE 
protocol
    specification.
  Created and implemented the ExitPacket class.
  Fixed an event syncronization bug in SyncConnection that caused an assert
    to fail in onDisconnect.
  Now if a listener for a Connection is NULL the event thread is halted
    until a listener is set.  Before, it was an error to have a NULL 
listener
    but now you can set a NULL listener to temporarily hold events.
  Fixed an acquire/release bug in exsynchello's usage of gout.
  Fixed thread-related bug in ServerConnection dtor.
  Implemented PacketStream::waitToSendAll and added timeout option.
  Fixed a bug in ConnectionEventGenerator where it can try to start an 
event
    on a listener that was just unregistered, and this would cause an 
access
    violation as unregistration invalidates the iterator.
  Fixed a bug where a deadlock was likely to occur when a write failed.
  exrawtest updated to test endianness of the RawPacket.
  Due to a new feature in HawkNL, GNE now sends all data in little endian
    format which is consistant with the GNE protocol spec.
  Added Time::toString and the ability to output it to an ostream.
  New example exping to show and test PingPacket.
  Added ID attribute to every GNE Packet class.
  A new class PingPacket to handle pinging.
  Removed the timestamp value from the Packet class.  That should have been
    removed long ago.  Another packet will eventually be created that
    supports timestamps.
  A mutex was no longer needed in Connection and was causing deadlocks, so 
it
    was removed.  The mutex was left over from the old event system before 
it
    was rewritten.
  Handshaking as specified in the GNE protocol specs is now implemented.
  When an unreliable connection does not exist, packets marked as being 
sent
    over the unreliable packet stream are sent over the reliable stream
    instead.
  Added adjustCount function in the Counter class.
  RawPacket class updated to use the GNE protocol data types.  Nulls are 
now
    allowed in the middle of strings.  Max string size is 255 bytes.
  RawPacket example updated to better test new GNE protocol requirements.
  More work on exnetperf to handle more clients and better format the data.
  Added the LockMutex class as a convenience.  It locks a mutex on creation
    and unlocks it on deletion which is useful for use in functions with 
many
    exit points, or functions that throw exceptions.
  Fixed a bug with an assert being outside of a guarded section and 
actually
    causing errors it was supposed to fix.

Gillius