Воскресенье, 12 Июль 2009
как писать сервера под unix
Это настоящий заказной пост :)! Пишу я его для Паши, который спросил, а как писать под unix сервера. Я где-то видел описание, но найти его с ходу не смог. Так что, буду сочинять сам.
Как обычно, замечания и прочее буду счастлив прочитать.
- Сервер можно строить по однопроцессной модели. Используются асинхронные сокеты и информация о их состояние получается из
poll
/select
. - Делать
fork()
для каждого клиента, и обрабатывать его в отдельном процессе. - Для каждого клиента используем отдельный поток (нить, thread). Сильно зависит от системы.
Любые методы можно комбинировать. Т.е. можно сделать несколько процессов, которые будут использовать первую модель. Или использовать несколько потоков, в которых будет первая модель :)
Комментарии
Однако, сразу надо рассказать о плюсах и минусах всех трёх моделей. 1) Асинхронная модель не подходит для случаев, когда “квант” времени, уделяемый сервером клиенту невозможно прогнозировать. К примеру, по такой модели были построены практически все игровые сервера на маленькое количество игроков. Самым большим минусом является то, что если обработка какого-то клиента “тормозит”, то все остальные клиенты от этого страдают. И ещё один минус — абсолютная немасштабируемость.
2) “Копирующая” модель (“вилочная” не звучит) — хорошо подходит для серверов, которым некуда девать мощь — хоть порождение процесса и занимает некоторое время (по разным оценкам, в современных Линуксах — оно на 5-10% накладнее порождения нити), но данная модель является а) простой как веник б) очень надёжной с точки зрения изоляции процессов. Небольшие трудности начинаются в том случае, если приходится работать с общими данными — но тут семафоры и прочие приёмы IPC очень сильно облегчают жизнь. Данная модель идеально масштабируется в кластерах (при должном подходе, разумеется).
3) Многонитиевая модель обладает всеми преимуществами модели из п. 2) в том случае, если мы говорим о многопроцессорной/многоядерной машине. Недостаток — немасштабируемость в кластерах (нити не могут мигрировать между узлами) и слабая изоляция клиентов друг от друга — в том случае, если любой из тредов вызовет SIGSEGV, к примеру, система снимет всё приложение — т.е. пострадают все остальные. Ну и отлаживать такие приложение тоже далеко не сахар.
Могу ещё кучу примеров привести, когда обычно используют каждую из моделей :)
Знаешь, я все больше прихожу к модели Erlang/OTP для построения именно сетевых приложений. Т.е. к ней все и идет. Просто она сейчас уже есть ;)
Про Эрланг слышал, что Апач нервно курит в сторонке в сравнении (хотя там просто сетевой сервис приводился), но деталей не знаю. Правда, быстрее, чем быстрее всё равно не получится. И модели _логического_ поведения серверов всё равно никуда не денутся — магии не бывает ;-)
У eralng свои, оооочень легкие процессы и soft real time.
язык без побочных эффектов.
интересная модель рабочий-контролер. Рекомендую почитать.
Да, но опять-таки, в случае проблем с самим супер-пупер процессом, который и реализует все эти легковесные процессы — имеем бяку. Правда, в данном случае, подобную ситуацию можно и не рассматривать — бо падение сервера (физического железа) из той же категории (как и падение ОС, впрочем).
Форма комментирования для «как писать сервера под unix »
Не, если задаться целью уронить beam можно. Только вот зачем задаваться целью?
Пока Erlang/OTP это крайне интересная платформа для построения систему. На вид сторить что-то тяжелое под web — будет интересно. Осталось найти кому бы посторить что-то такое :)