Description
This article is from the netrek
Frequently Offered Clever Suggestions list, by Tom Holub
doosh@best.com with numerous contributions by others.
13. Combine all of the server processes into one.
Problem: My workstation can't handle all the context switches.
Proposal: Merge all the ntserv processes into one, and maybe even
combine them with daemonII, so instead of the Server Union we'd have
the Unified Process.
Why Not: A few people have tried this. There are advantages and
disadvantages to doing this, not the least of which is that it
requires a complete rewrite of the server, a partial to full rewrite
of the client, and will work best as a strictly UDP implementation
(which requires a whole new protocol).
Among the disadvantages are the possible loss of the shared memory
segment (which kills the traditional tool interface), the need to
bring the server down whenever changes are made, the inability to
simply restart failed components (ex: restartable daemon), changes in
CPU load possibly resulting in lower UNIX process priorities (and thus
worse real-time performance), changes in the way the kernel sees
Netrek (e.g. waiting for I/O), poorer performance on MP machines, the
larger executable will be more likely to be swapped out under BSD,
loss of memory firewalls between components, possibility of security
breaches in a UDP-only setup, etc, etc.
There are a number of advantages, but this file is meant to discourage
you, not entice you. A reading of the process scheduling chapter in
_The Design and Implementation of 4.3BSD UNIX_ should be required for
anyone contemplating this. It turns out to not be a big deal, anyway;
all modern machines can handle a full netrek server.
Here's a note from somebody who once tried it:
Article 11256 of rec.games.netrek: From: jrichard@cs.cs (John
'MacGyver' Richardson) Date: 30 Dec 92 05:31:11 GMT
[...] Ok, not to beat a dead dog, but I've been working on this for a
while now. It was pretty easy to come up with multiplexed I/O for
logging in. HOWEVER, the big problems are:
o scheduling becomes a disaster! However, I'm trying reading
one packet from whoever's ready and going on to the next slot.
Updates taken care of by the daemon now get taken care of by a
signal handler.
o reading and writing becomes a disaster! If you use TCP you have
to deal with partial reads and writes of packets because you have to
use nonblocking I/O. If you want to write code, you have to have
states for everything in the universe (so to speak). The solution?
Use UDP only. But that requires a TCP like protocol to get those
packets that absolutely have to get there (like a login name). Feel
like re-inventing the wheel? I sure feel like I am now. :)
[...]
This guy clearly didn't know about select(), but there are issues with
that, as well.
Continue to:
Share and Enjoy
Bookmark this story so others can enjoy it:
Tags
game, netrek
