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. |