I agree with Lex's argument. I'd certainly try his approach
for starters. A secondary advantage is that it is much easier to debug
and analyze a server with a single thread than one that has two or more
threads per client request. You may ultimately need to fork a thread to
handle each request, but I'd add that code only after you've gotten the
server logic working well in the single-threaded version. (I've just been
through this server debugging process myself, and it worked nicely.)

Dean's also right that there are limits on the number of open sockets. In
Unix and Linux, there is a hard OS limit. On other platforms, there may be a limit
based on the amount of available application heap, since each socket requires some
buffer space that gets allocated out of the C heap. (The old 2.5 Mac VM, for example,
allowed no more than 44 sockets. The 3.1 VM apparently doesn't have this limit.)

It's easy to find out what the limit is--just try to create, say, 1000 sockets:

    Socket initializeNetwork.
    (1 to: 1000) collect: [:i | Socket createIfFail: [nil]].

Inspect the result and see how many actual sockets you got in the
resulting array.

Of course, a more realistic test would be to actually establish connections on
the sockets, since certain resources might only be allocated when the connection
is established.

Good luck with your project.

	-- John



At 5:56 PM -0400 8/13/01, Dean_Swan at Mitel.COM wrote:
>From:  Dean Swan at MITEL on 08/13/2001 05:56 PM
>
>Lex,
>
>     Although all your arguments make sense here, I'd like to mention one
>concern.  Most *nices have a kernel limitation on the maximum number of
>descriptors per process.  I don't know if this is also true for Linux, which is
>what the original poster was targeting, but in any case, it could have a bearing
>on the maximum number of simultaneously open sockets (and files) that a given
>instance of Squeak can have.  I remember a project I was working on long ago
>where we had to instantiate another server process for every 50 client
>connections that we anticipated because of this kernel limitation (it was on an
>SCO system, btw).
>
>                                              -Dean Swan