The question of 'which server model should I use' is a very complicated one, and I doubt you will find a consistent answer from different people for 'which way is best?'

For the most basic overview:

1. One process per connection: Medium capacity. Simple to implement and maintain. On UNIX platforms, data can be shared between clients in a restricted manner using shared memory segments. Another alternative would be a database backend. Active connection limit restricted by maximum number of process that can be executed on system at one time. If one process dies due to an implementation error, other process remains active and unaffected.
2. One thread per connection: Medium->Large capacity. Data is easily shared between clients. Active connection limited restricted by maximum number of threads that can be executed on system at one time. If Perl ITHREADS are used, special consideration should be taken to understand the cost of creating a thread (Perl data structure copying, etc.). Cost can be minimized by utilizing a thread pool, instead of creating a new thread for each connection.
3. One process, switched connections:Medium->Large capacity if implemented correctly. Correct implementation is difficult as each connection must be managed by a state machine-like device, event handlers need to be broken into small pieces, and some events need to be prioritized. Data is easily shared between clients. Implementation errors have the greatest chance of affecting all active connections when compared to any of the other models.
4. Multiple processes, connection loop:This is the model used by the Apache web server. The principle is that multiple processes actually wait on accept(), and the first one to succeed, gets the connection, and handles the connection completed. An outer processes ensures that sufficient processes are waiting on the listening socket. This model is very resistant to most implementation errors, and is very efficient. Where other models require multiple system calls to handle a connection (accept()/fork(), accept()/pthread_create(), select()/accept()), this model requires only one system call: accept(). Client data must be accessed as per the 'One process per connection' model.

In terms of portability, all models should function to different degrees. My personal attachment is the 'One process, switched connections' model, however, due to its complexity, I would not recommend it to those personally unfamiliar with the issues involved. If you have not ever used non-blocking I/O, I recommend that the 'One process, switched connections' model not be considered.

This description is far from complete, but it should provide you with rough expectations. Notice that I did not label any of these solutions 'Large capacity'. Any implementation that truly needs 'Large capacity' should not be written in Perl. By 'Large capacity', I mean 10000+ connections per minute sustained.

WIN32 NOTE: Take into account that fork() is implemented using Perl ITHREADS under WIN32. Therefore, although all multiple process models should function under WIN32, it is probably better to consider implementing the solutions using Perl threads to avoid the 'emulation' layer.