[MUD-Dev] Multithreaded sockets

[Bruce Mitchener]

Sean Kelly wrote:

> This isn't a very efficient use of resources.  Problem is, the
> best way to overcome this is really platform-dependent.  In
> Windows, it's IOCP.  I believe that Linux also has a similar
> kernel-level signaling architecture now, too.  Barring that,
> there's always select and nonblocking sockets.

The usual site for reading up on large-scale/high-performance
networking under Linux/FreeBSD/etc is Dan Kegel's C10k site:

   http://www.kegel.com/c10k.html

Another solution may be to just use an existing framework that
provides abstractions of various networking/threading models
implemented on Windows and the Unices:

   http://www.cs.wustl.edu/~schmidt/ACE.html

But really, it would be nice for people to stop worrying about some
of these issues and just actually write a mud instead of spending
their next year dinking around with how to handle the 1000 users
online at once that they'll never see without actually spending time
on their game play, content, etc.  It would be nice to see more
actual running MUDs come out of the MUD-Dev crowd one day after all.

Just get something that works and doesn't suck too much.  Use a
single thread for networking, use select() or poll(), and move along
and worry about networking again later when you have 800 or 1000
people logging in at once.  Plain old boring select() will work just
fine with 500 users.

Finally ...

szii at sziisoft.com wrote:

> How big are you planning to go?  If you're under, say, 500 users
> with medium load you're probably be okay, but you'll notice it.
> If you're aiming for 1k+, or 500+ fairly intense users you may
> reconsider it. (Assuming P3-500s)

On Linux at least, you'll notice it before that. 500 threads would
consume a fair chunk of virtual memory as well as cause the OS
scheduler some degree of unhappiness.

> If you're really hardcore, look into hyperthreading, or running on
> a cluster using virtual machines.

Why?  For the size of a userbase that Draymoor is likely to see for
a while, there's absolutely no need for this, either at a technical
level or a budgetary level.  And neither of those are likely to
yield better price/performance over simpler solutions.

  - Bruce

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