[MUD-Dev] Sockets

[Jon A. Lambert]

On 4 May 99,, Greg Munt wrote:
> If the sockets are blocking, doesn't this mean that you have to have one
> thread per socket?
>

Yes, but many other configurations are possible.  One could assign 
incoming socket connections to a fixed or dynamically sized thread pool.
Such a pool could service threads either as blocking or non-blocking.
J.C Lawrence and others have mentioned these strategies in the past.
The ACE C++ class library has a nice design based on these strategies.   

TychoMUD is a one thread->one connection implementation with a variable
configuration-set choke point.  Like most FTP or HTTP servers, when that
chokepoint is reached, the server will not accept incoming connections
and will inform the client of that fact.

The maximum or optimum number of threads is highly hardware and OS 
dependent.  I don't think anyone can categorically state that one thread 
per connection is a bad thing unless they have a specific number of 
connections and platform in mind.

> More muds aren't using option 4, probably because either (a) if it ain't
> broke, don't fix it, or (b) they are unduly influenced by stockmud design.
 
I don't know.  I suppose it is due to the maturity of threads on some 
platforms which has had a direct impact on the amount of programmer  
acceptance and experience with them.  Also, older server designs often 
have a highly-polluted global namespace and will not lend themselves 
easily to a multi-threaded reengineering.  I think the performance boost 
from threading has been understated or misunderstood on single-processor 
machines probably due to early thread implementations.  Similar to the 
the old "LISP is interpreted and slow" myth. 
  
One of the keys to successfully deploying threading strategies is to have 
a very modular and loosely coupled design.  Suprisingly (or maybe not), 
threading lends itself better to the old-style functional decomposition 
design approach than to a high-level object-oriented design approach.  
Philosophical or religious purity in either technique is not a good 
thing. ;) Establishing a generic interface layer that allows 
communications from any multi-threaded module to another multi-threaded 
module can greatly simplify threaded programming.    


--
--*     Jon A. Lambert - TychoMUD       Email:jlsysinc at .ix.netcom.com      *--
--*     Mud Server Developer's Page <http://pw1.netcom.com/~jlsysinc>      *--
--* I am the Dragon of Grindly Grund, but my lunches aren't very much fun, *--
--* For I like my damsels medium rare, And they always come out well done. *--


_______________________________________________
MUD-Dev maillist  -  MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev