| 1 |
root |
1.1 |
This directory contains the socket related code. |
| 2 |
|
|
|
| 3 |
|
|
When to differentiate socket related code and code that should belong |
| 4 |
|
|
in either the server or common directory is a bit of a grey area. A |
| 5 |
|
|
good test is that if the codes primary purpose is to send data to the |
| 6 |
|
|
client or receive/parse client commands, it should be here. |
| 7 |
|
|
|
| 8 |
|
|
Certainly the low level communication commands need to be here (setting |
| 9 |
|
|
up the socket, and the primitive reads/writes which more format the data |
| 10 |
|
|
but don't originate it). The functions that encapsulate the item |
| 11 |
|
|
details to send to the client are also located in this directory, as |
| 12 |
|
|
are some of the protocol commands the client sends to us. |
| 13 |
|
|
|
| 14 |
|
|
The higher level commands (ie, north, maps, cast, ...) are not included |
| 15 |
|
|
here. Some of them probably should be, since they do little more than |
| 16 |
|
|
just output data (who, maps for example.) The problem with this approach |
| 17 |
|
|
is the main dispatch routine is still in the server directory, as it should |
| 18 |
|
|
be (commands to move the player primary function is to do just that - move |
| 19 |
|
|
the player. updating the players view is the result of that move). So |
| 20 |
|
|
it probably makes sense to keep all those commands clustered there. |
| 21 |
|
|
|
| 22 |
|
|
The commands where moved out because I wanted a cleaner seperation of |
| 23 |
|
|
the client/server protocol area and the actual server functions - this |
| 24 |
|
|
makes it easier to find code that your are looking for and reduces |
| 25 |
|
|
the number of files in the server directory. Down the road, I see |
| 26 |
|
|
this as more of an issue as the common directory will likely get incorporated |
| 27 |
|
|
into the server directory and that then get broken out into a few |
| 28 |
|
|
more specific subdirectories (objects, map, maybe a few more). |
| 29 |
|
|
|
| 30 |
|
|
Description of the files: |
| 31 |
|
|
|
| 32 |
|
|
info.c: Contains the drawinfo and magic map commands. Was |
| 33 |
|
|
called sockio.c |
| 34 |
|
|
|
| 35 |
|
|
init.c: Handles basic initialization of data needed for the client |
| 36 |
|
|
server, initialization of data structure for new clients, and the freeing |
| 37 |
|
|
of data when done. This also contains the declarations for the global |
| 38 |
|
|
variables that are used. |
| 39 |
|
|
|
| 40 |
|
|
item.c: Commands dealing with objects. This includes both |
| 41 |
|
|
server updates to the clients, and request from the client to perform |
| 42 |
|
|
an action on some item. Some requests from the client may get passed |
| 43 |
|
|
back to functions in the server directory - more commands from the |
| 44 |
|
|
server probably need to get moved. |
| 45 |
|
|
|
| 46 |
|
|
loop.c: Main socket event loop. This includes the select calls and |
| 47 |
|
|
the main dispatch loop for data read from the sockets. |
| 48 |
|
|
|
| 49 |
|
|
lowlevel.c: Low level socket commands. The actual calls to read and |
| 50 |
|
|
write data to the socket. This file also includes the glue to format |
| 51 |
|
|
packets per the protocol definition, decompress the packets, and the |
| 52 |
|
|
utility functions to add/remove stuff from the SockLists. This |
| 53 |
|
|
only really deals with moving the data back and forth at a low |
| 54 |
|
|
level (intergers/bytes), not at the object level. It also contains |
| 55 |
|
|
the statistics recording functions. |
| 56 |
|
|
|
| 57 |
|
|
request.c: Handles requests to/from the client. This is the |
| 58 |
|
|
low level protocol commands, not the higher level game commands. |
| 59 |
|
|
This includes sending the players attributes and map to the client. |
| 60 |
|
|
|
| 61 |
|
|
sounds.c: Calls for sending sound information to the client. |
