Здравствуйте,
Встала следующая задача:
Делается сервер(C++,работать будет под Windows и Linux,в качестве железа-от тяжелого VPS до более менее приличных "железных" серверов с несколькими процессорами),
его задача принимать коннекты,немного их обрабатывать и передавать данные дальше.
планируется что если клиент сессию один раз установил — то будет этой сессией пользоватся и передавать данные (т.е. коннекты не короткоживующие как например в случае HTTP).Практически-чтото напоминающие SIP-шлюз. С диском особой работы нет.
Клиентских сессий одновременно может быть много (сотни если не тысячи).Логика работы сервера не слишком простая(куча возможных состояний,etc). Клиенты взаимодествуют и между собой тоже(через сервер).
Как лучще это реализовывать?
вариант 1 — решение в лоб — thread per connection+блокирующиеся сокеты — и получаем кучу потоков и (видимо) потерю быстродействия на переключение контекстов.
вариант 2 — ACE(с Reactor'ами,инкапсулирующими select/WFMO)+по классу на клиента+boost::statechart для создание per-client FSM+все это счастью запускается в количестве 1 или 2 потока на доступный процессор. Данное решение кажется наиболее оптимальным.Я прав?


C10K(как и RU.UNIX.PROG.FAQ) прочитан. Но неясность остается.

Насколько эффективно _современные_ версии Linux и Windows Server 2003 работаю с сотнями потоков(большинство которых висит в заблокированном виде на сокетах и мьютексах)?А то может быть вариант в современных условия лучще?
Насколько эффективно в варианте 2 работает ACE?Нет ли ей какой замены более удобной?
(и кроссплатформенной)

Здравствуйте, dmitriy_k, Вы писали:

[cut]

А плюсы это окончательный вариант? Нет желания на Эрланг глянуть? Саму обработку (если тяжёлая) можно на плюсах сделать

Конечно по потоку на клиента делать нельзя. Тем более заранее неизвестно сколько будет клиентов. Хотя, с таким железом
Если обязательны кроссплатформенность и С++ используйте АСЕ, иначе возможны варианты.

Здравствуйте, dmitriy_k, Вы писали:

[]

_>Насколько эффективно _современные_ версии Linux и Windows Server 2003 работаю с сотнями потоков(большинство которых висит в заблокированном виде на сокетах и мьютексах)?А то может быть вариант в современных условия лучще?

Если они висят на сокетах и мьютексах, то эти треды не шедулятся -> оверхэд нулевой. Только вот context switches...

_>Насколько эффективно в варианте 2 работает ACE?Нет ли ей какой замены более удобной?
_>(и кроссплатформенной)

Здравствуйте, Курилка, Вы писали:


К>[cut]

К>А плюсы это окончательный вариант? Нет желания на Эрланг глянуть? Саму обработку (если тяжёлая) можно на плюсах сделать
Собственно не окончательное.
Заказчика(и менеджеров наших) можно попробовать убедить...
Проблема только в том что в Эрланге я не особо разбираюсь мягко говоря на данный момент(и никто насколько я знаю не разбирается у нас)
Кем он кроме Эриксона используется?

Какие стоит учебники взять? Как ссылки на статьи так и книги (Amazon.com не особо страшит)
Реально ли исполняющую систему Эрланга встроить в программу на C++?
В обработке-будет микширование аудиопотоков(ну и работа с диском)

Здравствуйте, Gomes, Вы писали:

G>Конечно по потоку на клиента делать нельзя. Тем более заранее неизвестно сколько будет клиентов. Хотя, с таким железом
G>Если обязательны кроссплатформенность и С++ используйте АСЕ, иначе возможны варианты.
Кроссплатформенность (на уровне линукс+вин) обязательно.
C++ ... тут вполне могут быть варианты.Вопрос в том какие.
но с учетом того что скиллов в том же Эрланге(например) не имеется(будет ли лучще результат если в процессе придется Эрланг учить?

Здравствуйте, dmitriy_k, Вы писали:

_>Собственно не окончательное.
Я бы предложил попробовать сделать небольшой пилот, вопрос в том, есть ли у вас на это время и деньги.
_>Заказчика(и менеджеров наших) можно попробовать убедить...
Попробовать-то всегда можно, вопрос в том, есть ли реальный шанс
Т.е. надо знать какие самые значимые параметры для результирующей системы и самой разработки её.
_>Проблема только в том что в Эрланге я не особо разбираюсь мягко говоря на данный момент(и никто насколько я знаю не разбирается у нас)
у вас — это в компании? "С бухты-барахты" будет сложновато, на вникание в язык и платформу (последняя часть важнее, т.к. язык проще некуда) надо, имхо, ну не меньше пары месяцев.
_>Кем он кроме Эриксона используется?
Ну хоть здесь посмотрите, это лишь часть, есть ещё веб-проекты, но это, думаю, вам будет не показательно.
_>Какие стоит учебники взять? Как ссылки на статьи так и книги (Amazon.com не особо страшит)
см. хотяб тамже в в FAQ, плюс документация на сайте и в дистрибутиве довольно неплохая, на мой взгляд. Ещё с Mirror'ером мы принципы OTP переводили, если на русском проще читать, см. здесь
_>Реально ли исполняющую систему Эрланга встроить в программу на C++?
ну интероперабельность с C там очень важна, т.к. "числодробилки" на эрланге "проседают", поэтому есть реально используемый интерфейс. Правда с нуля "встраивание" врядли покатит, т.к. модель эрланга заметно отличается от традиционной, и её надо будет учитывать.

_>В обработке-будет микширование аудиопотоков(ну и работа с диском)
Это, думаю, скорее стоит оставить на сях (хотя лучше сделать тесты и посмотреть, в микшировании не разбираюсь, может binaries эрланговые будут не бесполезны), а на эрланге сделать обвязку, занимающуюся параллелизацией и координированием процессов. Если же эта часть про параллельность небольшая, то может нафиг эрланг и не нужен будет.
Ещё, если всёж заинтересуетесь — рекомендую мейл-лист, там довольно быстро и внятно на мой вгляд отвечают на вопросы. Ну и поиск по rsdn никто не отменял — топиков про Эрланг тут было довольно много.
Замечу, что сам промышленных (не домашних) проектов, к сожалению, на Erlang не делал, поэтому всё вышесказанное есть почти домыслы