[MUD-Dev] Libs for 3D Client/Servers

[Sean Kelly]

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
for linux

  http://oss.sgi.com/projects/kaio/

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
> interface"

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
> *nices.

But this is a big issue for MMORPGs.  Personally, I think it's a
topic worth discussing, provided it doesn't turn into advocacy.

Sean

_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev