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
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
|
NetCosm
=======
NetCosm is currently under development. Things WILL break, and
features might drift out of existence without prior warning!
## Installation
### Prerequisites:
* openssl (for password hashing)
* libev
### Compiling
make
This gives you the executable in `build/unix.bin`.
### Running
If you want to listen on a privileged port (below 1024), you will
either have to run the executable as root (not recommended), or set
the CAP_NET_BIND_SERVICE capability on Linux:
sudo make setcap
If running as root, you will need an unprivileged user called 'nobody'
on your system in order for things to work.
## Todo List
* Game scripting
* NPCs
## Internal Design
### Child-Master Requests
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)) if
available, and as UNIX domain socket pairs if not, which is slightly
wasteful, as they are full-duplex but only used in a half-duplex
manner.
Many operations, such as listing clients, require the help of the
master process. To request an operation, the child writes its request
data to its 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
* Every subsequent connection allocates slightly more memory than the
last
## Versioning Scheme
Versions are numbered using the MAJOR.MINOR.BUGFIX scheme.
The latest version is 0.5.1.
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.
### Changelog
#### 0.4.0 (skipped)
* Object support
* User inventory support
#### 0.5.0
* Verb support
* World hooks/scripting
##### 0.5.1
* Work on dunnet clone
* API enhancements
* Many bugfixes
### Roadmap
#### 0.6.0
* NPC users
#### 0.7.0
* Dynamic world editing
#### 1.0.0
* Procedural generation
|
