ИМХО, Так же, как и Виста на втором третьем пне, я думаю.


А что в потоки выносится? Обработка подключений? Обработка запросов клиентов?

я бы порекомендовал для начала почитать отличия apache1 от apache2 - как они сделаны ( кроссплатнформенный он)
почитать про клиент Ultima Online, он в исходах доступен и кучу народа держит по отзывам
потом посмотреть как это к QT привязать

PS: я не большой тут спец, может че не так написал

Судя по всему этот "connection port" - аналог классического select-а?
2 Detonator дай хоть ссылку на документацию. Чтоб можно было точно понять что это.

Извиняюсь, ошибся в названии, на самом деле называется "I/O completion ports"
http://www.gamedev.ru/community/mmorpg/articles/?id=6

Но есть ли аналог под Linux/MacOSX я до сих пор не нашел.

Простой select не масштабируем, т.к. очень медленный когда работаешь с сотнями сокетов. Я с этим еще давно столкнулся.
Вот тут к примеру хорошо описана эта проблема, но статья старая, я не знаю найдено сейчас кросплатформенное решение или нет.
http://www.atnf.csiro.au/people/rgooch/linux/docs/io-events.html

Делить сокеты на группы по 16-32 штук в каждой и каждую в группу обрабатывать в своем потоке - такой способ реализации я предполагаю на крайний случай если не найдется найти ничего лучшего, взаимодействие между самими такими потоками сильно усложнит программу, к тому же незнаю как в линуксе, а под виндовс каждый новый поток отнимает около 1Мб памяти, да и при большом количестве потоков только на переключение и синхронизацию меджду ними тратится ну очень много времени, программа ведет себя уже не очень предсказуемо.

Смотрел. А еще о aio_read() читал такое: "This model looks appealing, until we look under the hood of some aio_*() implementations. The Linux glibc implementation is a case in point: there is no kernel support. Instead, the C library (glibc 2.1) launches a thread per FD for which there are outstanding AIO requests (up to the maximum number of configured threads)."
Ну и кому нужна такая реализация с тысячей потоков в фоне?