> On Fri, 3 Jan 1997, Richard B. Johnson wrote:
>
> > Do you really think that a single task can handle 100 sockets open to
> > 100 clients in an efficient manner?
> >
> > Now, I don't KNOW what the number is. But I do KNOW that the number is
> > not "N"! Having some kind of enforced limit causes one to design code
> > rather than just winging it.
>
> Some servers, like muds and SQL servers, have no options but to handle all
> the clients from one process. These servers could benifit from threads,
> but they can't spawn of childs becouse of the communication between the
> processes would be far to complicated and massive.
>
> All the big muds I know handles several hundreds of clients from one task,
> so the answer to your question is yes.
The answer to the question cannot be "yes". Just because "that's the way
it's presently done", does not qualify as "efficient", correct, or anything
else.
A properly designed server does not need to communicate between anything
except the Client that it serves and the "database" that it accesses on
behalf of the Client. Record locking maintains "database" integity. The
quoted database means "any shared resource".
Now, it is not efficient to kick-off a separate child to handle each
connection. It is also not efficient to have a single task handle everything.
There is some design necessary to figure out what goes in between.
Cheers,
Dick Johnson
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Richard B. Johnson
Project Engineer
Analogic Corporation
Voice : (508) 977-3000 ext. 3754
Fax : (508) 532-6097
Modem : (508) 977-6870
Ftp : ftp@boneserver.analogic.com
Email : rjohnson@analogic.com, johnson@analogic.com
Penguin : Linux version 2.1.20 on an i586 machine (66.15 BogoMips).
Warning : It's hard to remain at the trailing edge of technology.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-