|
The Space Tyrant Source Code |
|
|
The Space Tyrant source code is written in C and compiles with every recent GCC compiler I've tried on both Linux and Mac OS X. It should be pretty easy to port the code to other Unices as well. The Source Code: st.c (Linux and Mac) Just download the source file, save it as st.c, and then compile it as follows:sh st.c The compile script is embedded at the top of the source file so the above command is all you have to do to build your own binary.
This source file is preconfigured to produce a 100,000 sector universe. That is easy enough to modify -- but you'll have to edit the source file. To do so, find the #define statements that set GAMESIZE and DBLOCK. Comment out the pair that sets GAMESIZE to 100000 and DBLOCK to 100 and uncomment another pair. Then, compile it again for a smaller or a larger game universe.
Unless you are a C programmer, that is proabably all you'll want to do to it at first. I'd recommend you run it with the default settings for a game or two so you appreciate just how big a game you would like.
Once you have a binary, type the following command in the directory with the binary to initialize the system and start the first game:./st 9999 Note that the '9999' number refers to the network port the game will listen on for connections.
Type `telnet localhost 9999` to connect -- the first player to register in a newly initialized game becomes the administrator of the system -- so make sure you are the first to log in!
A few features of the code:
ST is 100% C code (the embedded shell script, mentioned above, is technically a C comment ;). It is a single source file that is:- a Unix daemon
- an example of POSIX thread programming
- a network server using TCP sockets
- a memory based daemon with an asynchronous dirty block disk backup thread
The ST code also includes:- an easily understandable recursive sort
- a function pointer array
- ring buffer message queues
- random number generator macros
- detached thread spawning and reaping routines
- signal processing routines (interrupt handlers)
- a shortest-path algorithm
The code is less than 4500 C source statements in length. Including comments and C statements that span multiple lines, the source file is under 9500 lines long.
Space Tyrant is released under the terms of the GPL Version 2. |
|
| mail this link | permapage | -Ray, March 6, 2007 (Updated: March 12, 2007)
Linux System Administration: NFS Tutorials and Articles |
|
The Space Tyrant Programming Model |
|
|
I considered several programming models for the Space Tyrant server design. The Last Resort (TLR), a predecessor to Space Tyrant (ST), is based on a process-per-user forking model using inetd or xinetd to handle the listening and spawning of new processes. While the forking model is inherently distributable to multiple processors, it introduces inefficiencies such as extra memory usage and it also makes coordinating user activities slow and difficult.
Second, I considered a non-blocking, single threaded, single process model. In this approach, one process handles everything in a single thread. It would use non-blocking IO, where IO functions return immediately if they encounter a would-be delay to their read or write operation. Obviously, the code logic has to keep track of pending IO operations and the user sessions dependent upon them. The thttpd web server is an example of a non-blocking, single process server. It's extremely fast and efficient although it only makes use of a single CPU core. However, this model is quite complicated to code, and might make it easier to introduce timing bugs.
Third, I considered a pure multithreaded, single process model with a thread for each player. While appealing in many ways, this model would require the same kind of coordination between threads that the process-per-user, forking model requires between processes. Such interprocess communication would be slightly simpler than the forking model in that the various threads inherently use the same memory, but the coordination issues otherwise remain the same.
Last, I considered a hybrid threaded model. This model would include IO threads for each user, a disk backup thread, a network listener thread, and a single master thread to implement all game logic and data manipulation. While that central thread might become a bottleneck on multicore systems, it does offload the IO processing, listening, and backup to any additional processors, and, best of all, it requires minimal coordination overhead.
The IO threads would write their requests to queues serviced by the game logic thread, which would send a response to each IO thread as that thread's requests are completed.
The listener thread's job would be to listen for new network connections and to spawn IO threads for each new player connection. The backup thread would periodically scan the game data and write any modified data blocks to disk.
This model combines the game logic simplicity of the non-blocking single process model with the coding simplicity of the threaded model, while separating the IO -- and its associated delays -- from the main logic.
The tradeoffs seemed quite acceptable so this last model was the approach used for the ST project.
The code is written in C to compile with GCC and runs under both Linux and Mac OS X. |
|
| | mail this link | permapage | -Ray, March 6, 2007 (Updated: March 30, 2007) |
(Contact: r00t at this domain)
© 2008-2012, Ray Yeargin
| |
|
