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