[MUD-Dev] Event handling (was: request for comments)

JC Lawrence claw at under.Eng.Sun.COM
Fri Jan 9 19:53:00 CET 1998


On Thu, 8 Jan 1998 23:15:05 PST8PDT 
Vadim Tkachenko<vadimt at 4cs.com> wrote:

> Well, in my model there are no limit on the number of threads,
> usually the number will consist of:
...
> - One thread per incoming connection 

Get say a few hundred or thousand simultaneous players (or bot's), and
this alone will drag almost any current OS model to the floor, Linux
encluded.  FWLIW I use an asynchronous thread pool (again) to handle
network IO.  

> - N
> threads for db connections (implemented as a resource pool with
> minSpare/maxSpare) 

I use (I think) a base set of 5 threads for the DB.  Essentially they
are service bnased threads, each thread supplying a basic service
within teh DB, or to outside callers.  Typically each thread controls
an in-DB data structure which is private to that thread.  After that
everything is just simple message passing between threads (I don't do
much call processing in the server, even in the internal language
implementation its all message based).

> Well, a while ago I've been told to implement a Web crawler for a
> site, and the first thought was - just to go to the root URL, read
> and parse it and as links appear, spawn other threads using the same
> algorithm.

> Obviously, you can parse the HTTP stream much faster than server
> produces it, and, well, www.best.com (a guinea pig for that task)
> started to fail when, say, something like 50th request thread was
> started. Funny, but on my side (Linux, JDK 1.02) nothing bad
> happened.

Some HTTP servers have built-in throttles for the number of
simultaneous connections they will accept from a given IP address.

--
J C Lawrence                               Internet: claw at null.net
                                           Internet: coder at ibm.net
----------(*)                        Internet: jc.lawrence at sun.com
...Honourary Member of Clan McFud -- Teamer's Avenging Monolith...



More information about the mud-dev-archive mailing list