Воскресенье, 12 Июль 2009

как писать сервера под unix

Это настоящий заказной пост :)! Пишу я его для Паши, который спросил, а как писать под unix сервера. Я где-то видел описание, но найти его с ходу не смог. Так что, буду сочинять сам.

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

  1. Сервер можно строить по однопроцессной модели. Используются асинхронные сокеты и информация о их состояние получается из poll/select.
  2. Делать fork() для каждого клиента, и обрабатывать его в отдельном процессе.
  3. Для каждого клиента используем отдельный поток (нить, thread). Сильно зависит от системы.

Любые методы можно комбинировать. Т.е. можно сделать несколько процессов, которые будут использовать первую модель. Или использовать несколько потоков, в которых будет первая модель :)

Написано в: 23:02 | 6 комментариев | | теги: , , , | постоянная ссылка |
Добавить пост в:   Delicious Reddit Slashdot Digg Technorati Google


Последние комментарии

Комментарии

Serj 13.07.2009 12:23

Однако, сразу надо рассказать о плюсах и минусах всех трёх моделей. 1) Асинхронная модель не подходит для случаев, когда “квант” времени, уделяемый сервером клиенту невозможно прогнозировать. К примеру, по такой модели были построены практически все игровые сервера на маленькое количество игроков. Самым большим минусом является то, что если обработка какого-то клиента “тормозит”, то все остальные клиенты от этого страдают. И ещё один минус — абсолютная немасштабируемость.

2) “Копирующая” модель (“вилочная” не звучит) — хорошо подходит для серверов, которым некуда девать мощь — хоть порождение процесса и занимает некоторое время (по разным оценкам, в современных Линуксах — оно на 5-10% накладнее порождения нити), но данная модель является а) простой как веник б) очень надёжной с точки зрения изоляции процессов. Небольшие трудности начинаются в том случае, если приходится работать с общими данными — но тут семафоры и прочие приёмы IPC очень сильно облегчают жизнь. Данная модель идеально масштабируется в кластерах (при должном подходе, разумеется).

3) Многонитиевая модель обладает всеми преимуществами модели из п. 2) в том случае, если мы говорим о многопроцессорной/многоядерной машине. Недостаток — немасштабируемость в кластерах (нити не могут мигрировать между узлами) и слабая изоляция клиентов друг от друга — в том случае, если любой из тредов вызовет SIGSEGV, к примеру, система снимет всё приложение — т.е. пострадают все остальные. Ну и отлаживать такие приложение тоже далеко не сахар.

Могу ещё кучу примеров привести, когда обычно используют каждую из моделей :)

ответить
Kirill A. Korinskiy 13.07.2009 15:53

Знаешь, я все больше прихожу к модели Erlang/OTP для построения именно сетевых приложений. Т.е. к ней все и идет. Просто она сейчас уже есть ;)

ответить
Serj 13.07.2009 17:44

Про Эрланг слышал, что Апач нервно курит в сторонке в сравнении (хотя там просто сетевой сервис приводился), но деталей не знаю. Правда, быстрее, чем быстрее всё равно не получится. И модели _логического_ поведения серверов всё равно никуда не денутся — магии не бывает ;-)

ответить
Kirill A. Korinskiy 13.07.2009 18:10

У eralng свои, оооочень легкие процессы и soft real time.

  • язык без побочных эффектов.

  • интересная модель рабочий-контролер. Рекомендую почитать.

ответить
Serj 13.07.2009 19:31

Да, но опять-таки, в случае проблем с самим супер-пупер процессом, который и реализует все эти легковесные процессы — имеем бяку. Правда, в данном случае, подобную ситуацию можно и не рассматривать — бо падение сервера (физического железа) из той же категории (как и падение ОС, впрочем).

ответить

Форма комментирования для «как писать сервера под unix »

Обязательное поле. Не больше 30 символов.

Обязательное поле

Kirill A. Korinskiy 13.07.2009 23:29

Не, если задаться целью уронить beam можно. Только вот зачем задаваться целью?

Пока Erlang/OTP это крайне интересная платформа для построения систему. На вид сторить что-то тяжелое под web — будет интересно. Осталось найти кому бы посторить что-то такое :)

ответить