Deepthroat писал(а):... Появляется соединение, создается поток для соединения, а основной поток вновь переходит к ожиданию....
В принципе, это классическая схема работы TCP-шного сервера. Она годится и для unix-подобных операционок и для осей семейства windows.
Однако при таком подходе есть большой подводный камень. В случае серъёзной нагрузки на сервер, количество потоков может быть слишком большим. Сам лично под win2k сталкивался с ситуацией, когда при очередном подключении подвисал вызов TThread.Create. Трассировка кода показала, что висла API функция CreateThread. Плюс ко всему, возможна ситуация, когда необходимо синхронизировать клиентские потоки между собой. Например, когда они используют какие то общие массивы данных. При этом велика вероятность получения ситуации типа deadlock.
Поэтому, при работе в win32 среде, я предпочитаю организовывать сервер с помощью асинхронных сокетов, работающих через оконные сообщения. В этом случае, поток, получающий данные от клиентов и организующий подключения всегда один и нет необходимости следить за потоками и организовывать синхронизацию между ними.
Хотя, конечно, этот механизм не является кроссплатформенным. Что при работе с FPC может быть критичным.