Приветствую.
Изучаю написание сетевого демона под линукс. Сейчас мой демон имеет структуру:
...
sd = socket();
bind(sd, ... );
if ( listen(sd, 5) == -1)
{ ... }
for (;;) {
ns = accept(sd, ...);
pid=fork();
if (pid == 0) /* child */
{
close(sd);
...
recv();
...
close(ns);
exit(0); /* exit status of child */
}
close(ns); /* parent */
}
Вопрос такой: при этой архитектуре будут ли у демона серьезные ограничения по числу одновременно обрабатываемых запросов? Если да, то что нужно менять в структуре приложения? Поможет ли здесь select()/poll() ?
Спасибо!
>Приветствую.
>
>Изучаю написание сетевого демона под линукс. Сейчас мой демон имеет структуру:
-----
>for (;;) {
>
>ns = accept(sd, ...);
>pid=fork();
----->Вопрос такой: при этой архитектуре будут ли у демона серьезные ограничения по
>числу одновременно обрабатываемых запросов? Если да, то что нужно менять в
>структуре приложения? Поможет ли здесь select()/poll() ?
>
>Спасибо!
на каждое соединение делать fork() - это большие проблемы с производительностью и стабильностью системы, вот упремся в максимальное кол-во процессов и привет, да и затраты на scheduling, context switches, и сам fork еще никто не отменял.почитайте http://kegel.com/c10k.html.
>на каждое соединение делать fork() - это большие проблемы с производительностью и
>стабильностью системы, вот упремся в максимальное кол-во процессов и привет, да
>и затраты на scheduling, context switches, и сам fork еще никто
>не отменял.
>
>почитайте http://kegel.com/c10k.html.
спасибо, почитаю.
С другой стороны, на других форумах меня убеждали что потоки на данный момент плохо реализованы в линуксе и использовать их не рекомендовали. Но я тем не менее все равно буду их пробовать.
И еще - в моем случае обслуживание каждого соединения по идее не должно занимать более 1сек. времени. Так ли уж форки здесь навредят?
>С другой стороны, на других форумах меня убеждали что потоки на данный
>момент плохо реализованы в линуксе и использовать их не рекомендовали.
нормально реализованы, все прекрасно работает, причем довольно быстро, using kernel 2.6 и nptl.>И еще - в моем случае обслуживание каждого соединения по идее не
>должно занимать более 1сек. времени. Так ли уж форки здесь навредят?ну я могу открыть 5000 соединений к этому вашему серверу меньше чем за 1 секунду :)
>>С другой стороны, на других форумах меня убеждали что потоки на данный
>>момент плохо реализованы в линуксе и использовать их не рекомендовали.
>нормально реализованы, все прекрасно работает, причем довольно быстро, using kernel 2.6 и
>nptl.
в моем случае я жестко привязан к ядру 2.4.18>
>>И еще - в моем случае обслуживание каждого соединения по идее не
>>должно занимать более 1сек. времени. Так ли уж форки здесь навредят?
>
>ну я могу открыть 5000 соединений к этому вашему серверу меньше чем
>за 1 секунду :)
но ведь можно и ограничить кол-во соединений, пуская сервер через inetd :)
на каждую ж..у с резьбой найдется х... с винтом конечно :)
но остальных проблем это не решает anyway
>на каждую ж..у с резьбой найдется х... с винтом конечно :)
>но остальных проблем это не решает anyway
а все-таки - как обстоят дела с тредами в 2.4.x?
>>на каждую ж..у с резьбой найдется х... с винтом конечно :)
>>но остальных проблем это не решает anyway
>а все-таки - как обстоят дела с тредами в 2.4.x?
В линуксе потоки от процессов мало чем отличаются. Есть два принципиально разных способа: fork/clone и select. Первый проще реализовать, а второй быстрее работает (только если хорошо подумать).