Кроссплатформенный клиент-сервер

Можно. Но всё уже сказали, по-сути. Немного ifdef'ов -- инициализация приложения в *nix и win будет различаться. А во всём остальном вендовский winsock очень похож на unix'овый интерфейс сокетов. Даже select по-моему есть. Помимо этого можно стартовать параллельные потоки и делить соединения между ними. Можно стартовать также и процессы, но ради каждого соединения создавать процесс имеет смысл лишь в *nix, и то, если будет не слишком много соединений накапливаться одновременно.
В *nix, помимо этого есть неблокирующие сокеты + сигналы -- не знаю, насколько это приложимо к виндовс. Плюс есть posix'овый наборчик функций aio_*.

Зря боишься. Где-то я читал статью от разрабов апача, в которой они описывают каким образом апач обрабатывает входящие соединения. Со ссылками на файлы .c, и имена функций. С цитатами кода. Изучение той статьи может и займёт много времени, но время на изучение будет зависеть лишь от твоих знаний. Но чем меньше у тебя знаний, тем полезнее будет времяпровождение.

На самом деле выбрать правильный подход за тебя невозможно, ибо задача неизвестна. Может у тебя будет один новый клиент в час появлятся, но сессия будет длиться часов пять -- тогда fork вполне пойдёт. Ну если конечно ни тебя, ни заказчиков не смущает то, что под вендой придётся таскать за собой кучку библиотек cygwin. А может у тебя десять коннектов в секунду, и среднестатистическая сессия длиной десять секунд -- а это совсем другой вариант.

 

Для сети я бы посоветовал не Qt, a ACE

 

Max
максимально кроссплатформенно клиент-сервер на базе CORBA
mico.org
смотри самплесы в нём
прога пишется один раз и работает на любой системе где есть С++ т.е. практически
везде

 

r90

Еще как есть

Аналогично. Только через одно место обработка - шлются сообщения оконной функции. Соответственно, нужно окно.

Можно просто создавать потоки (нити) внутри процесса. Тогда нет зависимости от частоты и длительности сессий. Под Win это CreateThread(), под *nix - _thread().

 

event'ы еше есть.

а не либа pthread для этого юзается? я всегда юзал pthread_*.

 

n0name

Ну это но и есть, либо я не понял. WM_SERVER_ACCEPT, FD_ACCEPT и т.п.

Не буду утверждать, ибо нет под рукой *nix'овского компилятора. Но все-таки мне помнится именно _thread(). Но да и не суть важно. Главное, что вся разница в коде легко решается серией #ifdef.
Правда, вроде есть неприятные различия в работе select и setsockopt.

 

маскимальную производительность конечной системы можно получить только через условную компиляцию
каждая ОС предоставляет (в большинстве случаев) _свой_ эффективный набор API для решения тех или иных задач
не факт, что тот же POSIX для сети в Windows реализован так же эффективно, как в Linux или *BSD
поэтому надо четко разделить логику и средства реализации логики
логика кроссплатформенна по определению
а для каждой поддерживаемой ОС нужно выбрать наиболее эффективные средства реализации (к примеру для Linux вместо select() можно использовать epoll_create()/epoll_ctl()/epoll_wait())
и "обернуть" их макросами/функциями/...

самый лучший вариант - это использование готовой библиотеки типа QT

 

WSAEventSelect/WSAAsyncSelect - event'ы / оконные мессаги.

 

Апач-то вертится под win, и я не слышал что ему на венде какие-то существенные пенальти в плане производительности положены. А если речь идёт о очень быстрой обработке соединений, когда вся работа упирается во ввод/вывод (апач-то ещё всякие скрипты гоняет...) то, насколько я понимаю laio -- это наиболее безумный вариант. Но там, мне кажется, будут огромные проблемы обеспечить кроссплатформенность.

 

n0name
А, все, туплю. Да это и не по теме ТС.

r90

Да ничего ему не положено.

В этих случаях отказываются от использования Apache. Я лично до такой нагрузки на сервера не доходил, но один знакомы есть, чем-то ему Apache не приглянулся.