From: Matthew Mondor Date: Mon, 30 Jun 2014 18:48:00 +0000 (+0000) Subject: Removed obsolete README X-Git-Url: http://git.pulsar-zone.net/?a=commitdiff_plain;h=37b6a78521fce29f01620fe05ec214e132d8bd40;p=mmondor.git Removed obsolete README --- diff --git a/mmsoftware/mystic_ships/server/README b/mmsoftware/mystic_ships/server/README deleted file mode 100644 index 43516e0..0000000 --- a/mmsoftware/mystic_ships/server/README +++ /dev/null @@ -1,48 +0,0 @@ -$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.