Свежие комментарии

:) для этой задачи я подходящего варианта не нахожу.

Классический префорк как в апаче где один процесс на одного клиента отлично работает с SYSV семафорами - делаем сокет, слушаем, делаем semget с одним семафором в наборе, увеличиваем его на один, расфоркиваемся.. после этого дочерние пытаются уменьшить значение семафора на 1, потом accept, увеличиваем обратно на 1...в итоге только один процесс разблокируется и получает клиента.. все как в книжках.

Вот только как быть если дочерний процесс у меня обслуживает больше одного клиента с использованием мультиплексинга? Вариант с семафором не работает. Если делать захват семафора после селекта - гонки. Если до, то надо с флагом IPC_NOWAIT, иначе живые клиенты всех процессов кроме одного встанут. Но в любом случае получится так, что серверный сокет захватит один процес, а о моменте его освобождения никто не узнает. Нужен механизм что бы их пнуть, при чем так что бы пробудились не все, а только один.

Боюсь что не понятно получается.

К операционной системе применимы те же принципы, что и ко всему остальному коду: если она может быть переписана за разумное время и стоимость переписывания с нуля оказывается меньше, чем стоимость поддержки и развития готовой, то надо переписать.

Поэтому, в соответствии с этим принципом, она обычно чужая - не переписывается за разумное время под наши требования :)

Но для проекта большого масштаба я бы рассмотрел вариант создания своего дистрибутива линакса. Собственно говоря, гугль вроде бы тем путем и пошел.

К сожалению у нас дела обстоят несколько по иному, к мнению программистов и админов никто не прислушивается. С бизнесом такая политика никак не связана, просто мы в этом ничего не понимаем.

Никто тут свои операционки, web-сервера и мега-фреймворки не пишет, все занимаются своим делом, я пытаюсь сказать другое - если есть возможность (время и скилы) лучше не рисковать и написать самому (понятное дело openssl я не буду переписывать).

А что Вы имеете против lua? Это отличный клей.. маленький, быстрый, расширяемый, много на чем собирается с сями вяжется на ура. Конечно Java Script мне ближе по синтаксису, но пока, на мой взгляд, идеальна луа (питон совсем не перевариваю). И не надо изобретать свой скриптинг :)

Приходилось с сями вязать Perl, Java, Lua (питон сам не пробовал, но показывали) - интереснее всего показалась луа.

Правда после выхода v8 может многое измениться.

Если сервер многопоточный, то тут вопросов нет, а я говорю о многопроцессном.
Тут семафоры никак не получается приладить. В серверах на основе FSM
все вертится вокруг мультиплексинга ввода/вывода кучи файловых описателей (серверные сокеты, клиентские сокеты, пайпы с сигналами и т.д.). Т.е. сердце всего это системный вызов типа select, poll и epoll_wait, а там к сожалению нет лишнего параметра на тему семафоров. Все что мы можем совместить - операции ввода/вывода и сигналы. Семафоры остаются в стороне, придется придумывать что-то с управляющим процессом, но ничего внятного в голову не приходит. Ну либо тупо ждем события на сокете из нескольких процессов и надеемся что никто не догадается поставить сотню воркеров и выставить это чудо в интернет.

А вот вариант с SCM_RIGHTS довольно интересен, один из сценариев - несколько процессов выстраиваем в цепочку. Пока клиентов мало все работает как с одним процессом, если места не хватает можно пульнуть сокет следующему процессу (и так по цепочке).
Тут я вижу следующие недостатки - падает основной процесс и привет, не грамотно юзаем проц. Получается мы тупо повышаем максимальное количество клиентов. В общем смысла не очень много.

Интереснее вариант со звездой, основной процесс расфоркивается, потом ждет соединений и раскидывает их по очереди между потомками (ну и себя не забывает). Дальше все работает как FSM.
Получаем тупейшую схему как и на потоках только с изоляцией. Без проблем можно что-то придумать что бы при падении основного процесса его обязанности переходили к другому.

Насколько все это будет эффективным надо пробовать... может кто-то что-то подобное делал?

Нет, операционная система не своя, там дыры пускай латают специально обученные люди. А вот риски поиметь гемороя на прикладном уровне из-за того, что я в своей программе использую сомнительный чужой код на порядок выше (да и логика может быть посложнее). Ключевое слово - "своей", за свое ПО несу ответственность только я, за операционную систему те кто просят за нее деньги или те, кто принял решение заюзать на продакшене open source :)

Я сторонник open source но не будем кривить душой, множество проектов ведут криворукие программеры или куча народа по очереди исправляет друг за другом непонятные места и случайно искажают оригинальные идеи автора.

Я ни на что не претендую, поэтому ничего и не выкладываю.

В общем поддерживаю опасения Анатолия.

Антон, а операционная система тоже своя?

в SSE4 есть много оптимизаций для CRC и криптографии, возможно результаты CPU резко возрастут.

Не, это на двух ядрах.

У меня на 4 ядрах @3Ghz - 219 мегаключей в секунду.

Хотел спросить, что вы думаете по поводу кашерности передачи файловых описателей между процессами с использованием локальных сокетов, sendmsg и SCM_RIGHTS? Недавно об этом узнал и немного удивился, на линуксе проверил, все ОК, на бсде тоже должно работать. Такое есть в винде в winsock2, юзал когда писал мультипроцессный сервер под нее.

В принципе можно обойтись без этого хака, но это единственноый способ, который я смог найти, для раелизации FSM на наскольких процессах без гонок. Интересно как поступил Сысоев в nginx, у него же можно поднять несколько воркеров. Не думаю что у него они все тупо ждут соединения на сокете а потом кто успел.

Я тоже люблю все сам, когда-то COM-объекты микрософтовские руками стряпал (свою либу писал).. дошел до автоматизации, но дальше уже не рискнул, смыла городить такое самому нет. Но для самообразования очень полезно. Боюсь лет через 10 никто уже и знать не будет как оно там работает.

Народ приходит на собеседование... за последний год только 2 человека внятно смогли рассказать как работает sizeof, что такое vtable, какие бывают сегменты памяти и назвали несколько подходов к построению параллельных серверов. Правда и они были зациклины на pthreads... как пользоваться разделяемой памятью и что там за semset`ы такие не в теме. Один ушел в Яндекс, второй в Суп... оба мимо.

В принципе выставить собственный web-сервер наружу я бы рискнул, но пока нет смысла, по крайней мере пока поток не начнем на 7-м уровне делить между апачем и самопиской в зависимости от типа запросов (лень из-за веба cgi, ssl и прочие радости реализовывать).

По поводу HTTP - на позопрошлой неделе на плюсах налабал реализацию с keep-alive, chunked encoding (в сторону клиента), digest авторизацией (правда для упрощения stateless вариант без контроля за значением nonce counter`а) и lua. На все про все ушло порядка 4-х дней. Для внутренних вопросов вполне достаточно, а тратить жизнь на полноценный сервак тоже желания нет, боюсь дальше пойдет рутина и негитавные отзывы избалованных пользователей :)

Но у меня, кстати, не все свое - openssl юзаю. Думаю, как бы его заизолировать - смущает он меня.

И без хлеба.

Я ровно о том, что
а) писать свой HTTP-layer со всеми наворотами (keep-alive, pipelined, chunked, сжатие) - глупо. Протокол сложный, а простой вариант высовывать в сеть под хоть какую-то нагрузку не менее глупо.
б) application layer никто за тебя не напишет
в) разделить понятия ценой 5% производительности - выгодно.

Будет или нет - не знаю, но ребята не странные, а конкурирующие после развода.

HTTP layer вполне безопасен, даже если ты ему не веришь, то есть простые правила гигиены, которые не позволят даже хакнув - все испортить.

А application layer - да, требует аккуратности, но это как раз повод отнести его в отдельный memory space и без всяких тредов.