I/O socket and thread concept in servants?

[Moak]

Hi,
I wonder which socket I/O concept do modern gnutella servants follow, how many threads they use for handling connected clients and handling downloads?

Okay let's seprate GUI from operative Gnutella code first and focus on the real Gnutella network core only (Berkeley sockets, Winsock is also based on the familiar Berkeley BSD "socket" interface). A gnutella servant will open a listening socket (socket/bind/listen)... and then? Theory: A typical Gnutella servant will handle a few gnutella connections (one to 4-5, many for superpeers) and a bunch of file up/downloads, which typically take some minutes. Also a Gnutella servant should handle many small new socket connections in a short time (for giving busy states or handling chat requests). So far theory, coming to implementation:

1. multithreaded server
Should the network thread remain blocking until a new client connection comes in and create/fork a new thread for every connection? That would result in one listening thread + one thread for every gnutella connection, for every upload and download. Disadvantage: A lot of context switches and overhead for thread/process creation.

2. multithreaded/sequential server
Same as above but mixed: All short requests (telling we are busy, chat requests) are handled sequential (we build on TCP/IP stack's backlog buffering). Which means new client request might be pending but handled very fast without any thread overhead. Threads are only created for actions that have a permanent expectation (handling free connects and upload/download slots).

3. select()-based server
Should the newtork thread block until something interesting happens on any of a group of sockets and handle every client connection step by step? Disadvantages: a lot of socket selects() necesarry, but AFAIK strong in handling a high number of connections. I guess (?) this is also what happens in Winsocks Asynchronous mode.

4. prethreaded/forked or whatever
Something that apache webserver does. Client threads/processes are created in a pool, remaining idle. The main listening thread just creates the client socket and gives it to the allready existing client threads, which handle them fast without extra thread overhead. Disadvantages: Maybe oversized, Gnutella clients to not have to handle thousands of small requests in a short time.

Ideas, feedback, anyone with Gnutella client experience?
Thx, Moak