[MUD-Dev] Re: TECH: Distributed Muds
bruce at puremagic.com
Fri Apr 27 01:25:06 New Zealand Standard Time 2001
J C Lawrence wrote:
> On Thu, 26 Apr 2001 21:18:11 -0700
> Caliban Tiresias Darklock <caliban at darklock.com> wrote:
>> On Thu, 26 Apr 2001 20:31:37 -0700, J C Lawrence <claw at 2wire.com>
>>> I've never liked the base concept of a select() looping process
>>> that tried to do real work between select() calls. It can work to
>>> be sure, but it has always smelled of playing with fire.
>> I've always seen it as sort of an "every other MUD does this, it
>> must be a good idea" solution. I think most people who start
>> writing a MUD server concern themselves first and foremost with
>> making a good *MUD* instead of with making a good DB core, a good
>> object model, and a good communications link.
> I'd always thought that it was because that's been the basic model
> discussed in Stevens and Comer, and its also the simplest to
> incrementally develop and extend.
> Path of least resistance and all that rot.
Going even beyond that, networking doesn't seem to be something that
most people immediately understand. An example of this would be to
see how many of the servers out there correctly use non-blocking I/O.
Cold didn't for years until I fixed it soon after I started doing Cold
server hacking a couple of years ago. Various other codebases that
people are building that I've come into contact with weren't doing
non-blocking I/O either. Most of the time, they felt that because
they were using select(), they didn't have to worry!
Maybe the lack of any good and well documented examples within a MUD
server is something that hurts here?
(I'll have to ask Jon Leonard about this ... it doesn't look like
devmud is using non-blocking I/O and apart from this, its code is nice
and simple, although still select()-based.)
Or perhaps, instead, this is a result of different people building mud
servers for differing reasons. Some very broad generalizations
I work on them to achieve a set of technical goals and to produce
something that others can take and build a good game with. I have
no direct interest in the game really when I'm doing server
hacking. Others seem to just build them en-route to trying to
realize their visions, rather than starting with something and
building on top of it.
Others are just writing them to learn. Of these groups, probably
only the first (where I think I am) would care about efficient or
scalable I/O strategies or implementation techniques.
MUD-Dev mailing list
MUD-Dev at kanga.nu
More information about the MUD-Dev