1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
|
NetCosm
=======
NetCosm is currently under development. Things /WILL/ break, and
features might drift out of existence without prior warning!
## Installation
### Prerequisites:
* libgcrypt
* libev
* linux >= 3.4 (need "packet mode" pipes)
* glibc >= 2.9
### Compiling
make
This gives you the executable in `build/unix.bin`.
## Todo List
* World persistence (partial)
* Inventory
* Verbs
* Game scripting
* NPCs
## Internal Design
A child process is spawned for every client that connects. There are
two pipes created for every child: a pipe for the child to write to,
and a pipe for the master to write to.
Both of these pipes are created in "packet mode" (see pipe(2)), and
therefore require at least linux 3.4 and glibc 2.9.
### Child-Master Requests
Many operations, such as listing clients, require the help of the
master process. To request an operation, the child writes it's request
data to it's pipe to the parent. The size of the request MUST be less
than PIPE_BUF, which is 4096 on Linux. The format of the request is as
follows:
| Child PID | Request Code | Data (if any) |
The master polls child pipes for data, and processes any requests it
finds. The master then writes it's data to the pipes of any children
involved in the request.
Child processes that serve connected clients poll for input from the
master process while waiting for client input. The format of these
requests is as follows:
| Request Code | Data (if any) |
Child requests (that is, requests a child sends to the master) are
very reliable. However, requests from the master process to its child
processes are not so reliable. The child process may not be polling
for data, and so would not receive the request.
## Design Goals
Handle 100 simultaneous users sending 100 requests/second with 50ms
latency.
## Known Bugs
* Telnet server implementation is not fully conforming
* Initial account login time is bogus
## Versioning Scheme
Versions are numbered using the MAJOR.MINOR.BUGFIX scheme.
Current stable is 0.3.0.
Major versions mark major milestones (see below), minor versions mark
incremental milestones and compatibility of data files, and bugfix
versions mark major bugfixes that don't warrant a new major or minor
number.
### Roadmap
#### 0.4.0
* Object support
* User inventory support
#### 0.5.0
* Verb support
* World hooks/scripting
#### 0.6.0
* Dynamic world editing
|