-$Id: README,v 1.1 2006/12/31 08:32:40 mmondor Exp $

-

-If this all works fine, it might be the basis of a multiplayer

-networking game.  However, this is primarily a test to learn kqueue

-and observe its efficiency, as well as to experiment using TCP for

-such massive multiplayer games on today's networks and internet.

-

-Many games that used TCP for LAN use a while back had to develop

-UDP based protocols to be efficient enough for dialup users or

-other internet users.  We will determine if this is still necessary

-on today's average internet latencies.

-

-We probably still want to prioritize some packets over others.

-For instance, we might drop outgoing position update packets which

-cannot be sent immediately instead of queueing them, allowing less

-frequent updates to slow connections while not needing to provide

-multiple independent game heart rates.

-

-We do not expect to have to port the server part of the game, wich

-is intended to run on BSD systems supporting the kqueue(2) system

-only.  We could have used an event library, however we wanted to

-avoid including non-BSD licensed components.  Although there is a

-BSD licensed libevent as part of NetBSD, using kqueue directly

-allows a few fancy optimization tricks which would require a new

-portable events library to be designed to allow to achieve the full

-advantages of kqueue using an abstracted library.

-

-The client code, however, will be portable and should be able to

-run on Win32 without needing the cygwin runtime libraries.  The

-SDL dependency is reasonable, and can be provided separately, so

-mingw will be used to create those executables.  The client will

-however primarily be developped on NetBSD.  Like SDL, OpenGL

-libraries shouldn't be a problem either.

-

-To avoid using cygwin, and because Win32 winsock does not conform

-to BSD sockets API standards, we expect to have to write a simple

-portable networking layer for use in the client.

-

-

-TODO

-

-- At this point to advance further a client needs to be written.

-- We probably don't need to align packets, we only need to make sure

-  that their size is 32-bit aligned, and that their 16-bit fields are

-  16-bit aligned, their 32-bit ones 32-bit aligned.  Packet type field

-  can be 8-bit.  If we allowed arbitrary offsets when buffering packets,

-  we would need to copy each packet to an aligned buffer as we process them.

-  Evaluate which is more advantageous.