[MUD-Dev] Libs for 3D Client/Servers
sean at ffwd.cx
Wed Jul 11 09:04:32 New Zealand Standard Time 2001
From: "Jon Lambert" <tychomud at ix.netcom.com>
> Sean Kelly wrote:
>> I agree. MS' apparently intentional differences from the BSD
>> definition are quite bothersome, and Unix and Windows have gone
>> in completely different directions as far as efficiently handling
>> high-volume socket operations. Personally, I really like Windows
>> IOCP model, and was kicking around how to implement a similar
>> model in Unix. It wouldn't be incredibly difficult, but I doubt
>> you would get the same performance out of it as Windows would
>> provide with the same model.
> There is quite the mental block in insisting on compliance with a
> posix interface to the *nix sockets stack
My only interest here was portability. And as you say, support can
come from either party.
> despite it's sub optimal design and compromises that lead to
> performance problems. Both of which have been commented on by Cox
> and Gooch. Schmidt's patterns papers and their references to the
> workings of BSD's stack are also illuminating.
This is interesting. I have asked around about how to implement
high-performance sockets in unix because the solutions seemed a bit
clunky at times. I'll read up on what Cox and Gooch have said.
> I've posted on the topic here but responses were much more
> interested in the exploring the term "windows" and what it meant
> to them than in understanding and implementing a form of "iocp"
> (or the stack as a RT device) in *nix. It's a rather perplexing
> attitude for those who chest beat that they have access to their
> OS's kernel source and can modify it any time they like. Still I
> think it would probably be an interesting and popular freshmeat
> type project.
After a bit of searching, it looks like the problem has been at
least partially addressed. SGI hsa implemented an asynch i/o model
and I ran across a thread on fa.linux.kernel which discusses the
topic in some detail. But this quote (from Chuck Lever) is telling:
"i think that one area where people neglect to see the
architectural significance of completion ports is that they
simplify an application's design not only by providing queued I/O,
but also by creating a clean way of dispatching work efficiently
to multiple threads. this is what select() has done in the past,
but select() isn't workable any more"
> Anyways when the topic of network "scaling" comes up here, what
> that really means is "scaling up to the limits of the posix
In my search I did run across a number of complaints about the
limitations of the posix interface. And I'd always complained about
MS API's... I'll do a bit more research and perhaps I've have more
to contribute later.
> or talking about more sexy topics like server distribution. I'm
> not going to revisit the area since I've already said much of what
> I was going to say anyways as a FWIW in past posts before being
> sidetracked into arguing old windows myths and legends. Besides I
> really don't have any personal or practical commercial interest in
> "scaling" a mud server up to thousands of users, let alone on
But this is a big issue for MMORPGs. Personally, I think it's a
topic worth discussing, provided it doesn't turn into advocacy.
MUD-Dev mailing list
MUD-Dev at kanga.nu
More information about the MUD-Dev