Здравствуйте!
Стоит задача разработать сервер со следующими особенностями:
а) малое число одновременных соединений (десятки)
б) Соединения длительные - часы, а то и сутки
в) Скорость передачи данных ограничена физическим каналом и небольшая до 1 КБ/с, а то и меньше (минимальная, максимальная неограниченая  ). 
г) Большой пинг (от сотен мс до секунд)
д) Сервер также выполняет тяжёлую обработку данных
е) Объём передаваемых данных незначительный, но частый - много мелких сообщений.
ж) доставка сообщений должна быть гарантированной

Почитав тему про варианты архитектуры ASIO сервера, пришел к выводу что это должен быть:
1) tcp сервер (пункт ж) 
2) с архитектурой типа SEDA (пункты д - разделяем сетевую часть и тяжелую бизнес-логику + пункт е - и там и там сообщения) 
3) с архитектурой поток на сессию (пункт а - будет мало потоков, б -потоки создаются редко, т.е. нет оверхеда на их создание и пункт е -много мелких сообщений приведут к большему числу (системных?) вызовов при асинхронной архитектуре). 
4) Сессии с большим таймаутом?(пункт г)
Пункт В накладывает ограничение скорее на бизнес-логику, чем на сетевую часть.

Может что-то лишнее в моих рассуждениях, а что-то нужно добавить? Прокомментируйте, пожалуйста.

Это сообщение отредактировал(а) drug007 - 10.11.2011, 13:48

эту?: http://forum.vingrad.ru/forum/topic-340251...0%BD%D0%BE.html



это в реализации сложнее. используй пул(хотя из требований, и одного потока будет достаточно).
я, в одной из задач, применил такое необычное решение:
1. отдельный процесс-сервер. принимает соединения, читает пакеты, отправляет пакеты.
2. отдельный процесс-логика.
общаются друг с другом посредством двух IPC очередей. в одну очередь сервер кладет данные, из второй очереди читает ответы от логики и отправляет клиентам. реализация получилась невероятно простой. это был эксперимент.



сколько? приблизительно. в секунду.



опять же, вопрос выше.
и это прочти: http://forum.vingrad.ru/forum/topic-341403/view-all.html

Это сообщение отредактировал(а) boostcoder - 11.11.2011, 06:19

[QUOTE=boostcoder,11.11.2011,  00:15]
А ваш эксперимент реально будет исполнить на практике с такими требованиями?

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

Оно самое



Точных значений сказать не могу - если исходить из ширины канала, точнее из его узости, то в самом худшем варианте десятки сообщений в секунду на одно соединение, не больше. Требование по максимуму же пока можно сформировать только на уровне "чем больше, тем лучше" и "кашу маслом не испортишь", к сожалению. 
За ориентир возьму пока сотни сообщений в среднем размером 50-100 байт (это на уровне приложения), с возможность увеличения количества сообщений до тысяч с тем же размером - это в среднем, периодически (не часто) объем будет возрастать на порядок-два на непродолжительное время.
Бизнес-логика пока смутно выглядит - собственно, для ее исследования и нужен сервер.


Почитал, полезно - я тоже разделял сервер и обработку данных, но, правда, в потоках. Но как то оценить не могу, т.к. опыта не очень много. На тот момент главным было, что работает. Про buffered_stream надо будет почитать, спасибо за ссылку - у меня как раз сначала читается хидер, затем тело - не нравилось уже когда код писал, но пока оставил так.
А вот про большее количество системных вызовов в случае асинхронной архитектуры при небольшом количестве клиентов пока не могу сообразить - вроде согласен в целом, но в деталях в голове не раскладывается, буду думать.

Тут еще нюанс в том, что по сути приложение предназначено для построения распределенной сети по сбору и обработке данных. И по возможности это приложение должно функционировать и на слабых машинах с небольшим объемом памяти. Сразу реализовывать такую возможность нет задачи, но не должно быть принципиальных ограничений на ее реализацию в дальнейшем. Если сервер сможет достойно крутится хотя бы на каком-нить двухядерном Cortex-A8 1.5GHz/512 Мb памяти, это будет заметным плюсом. Ясное дело, что вариант для х86 будет отличаться от варианта на ARM в решении некоторых вопросов, но желательно отличия свести к минимуму. Это я к тому, что закладывать требование в 4Гб на преаллокацию памяти (к примеру) крайне нежелательно.

З.Ы. требования с учетом имеющихся ресурсов становятся похожи на наполеоновские, скорее всего как всегда из высокоадгезионного соединителя на межмолекулярных связях с использованием нанотехнологий получится пусть и качественный, но обыкновенный гвоздь, но будет полезно хотя бы в теории этот вопрос проработать 

  
я в одной из своих реализаций, добился ~470 000 тысяч в сек. а ты переживаешь за несколько тысяч.


это будет весело, учитывая тот факт что доки к нему почти ноль. читать в этом случае нужно исходники. вот, специально для подобных задач создал: boost.asio.


т.е. ты говоришь про сервер? если да - то конфиг к нему прикрутить. или заранее создать набор предустановленных значений(кол-во потоков,сессий,размеры буферов, и т.д.).


запросто.


про конфиг написал несколькими строками выше.

Это сообщение отредактировал(а) boostcoder - 6.8.2012, 11:50

Да просто когда я первый раз столкнулся с такой задачей, канал связи был 50 бод (нужна была совместимость с аппаратурой лохматых годов) и сообщение в 20 байт передавалось пару секунд. Запустил как-то на 1200 бод - это был просто восторг  С тех пор для меня тысяча в сек - это просто ужасно как много  
Всегда упирался в минимальную ширину канала, загрузить цпу бизнес-логикой "удалось" только один раз из-за неправильного алгоритма, поэтому сложно оценить потенциальное количество сообщений. Но сотня тысяч это радует. Это имеется в виду скорость чисто сервера без бизнес-логики?


Исходники буста для меня еще довольно сложная вещь, но почитаю в любом случае.



Прекрасно. 


Т.е. учесть достаточно большое на мой взгляд различие в производительности/области применения/другое вполне можно будет с помощью конфигурации? Это обнадеживает. Главное, чтобы для поддержки конфигурирования не пришлось лишний код писать - выбор между асинхронным сервером с io_service на цпу и синхронным сервером с блокирующими сокетами с потоком на каждого клиента, например,  в конфигурации можно прописать, но фактически же будут запускаться разные куски кода, а не просто буфера с разным размером, а эти куски и поддерживать нужно будет по отдельности, чего не хочется.
Я в связи с этим решил пока остановиться на асинхронном сервере, как более универсальном. То что при небольшом кол-ве клиентов он будет проигрывать серверу с потоком на клиент, будет с лихвой компенсироваться меньшей нагрузкой в целом. А при большом кол-ве клиентов асинхронный уже будет выигрывать. Да и реализован он уже у меня частично, в конце концов. 

да.


да.


не-не-не! это что за зоопарк архитектур? для твоей задачи тебе достаточно одного io_service. а остальное пока не известно.


это еще почему?  

Вот как раз зоопарка я и не хочу.


Дык вот.
Процитирую, на всякий случай:

у тебя производительность затребована на столько низкая, что я думаю тебе для всего сервера хватит единственного потока. еще и много будет.

А я про это и говорил.
Насчет одного потока - у меня сейчас как раз один и в нем и сервер, и клиент, и графика на Qt крутится. Но я его и не нагружал толком, нет возможности пока - бизнес-логику еще надо делать.
В общем, я понял, что для решения моей задачи достаточно простого сервера - я взял за основу пример из asio samples и в принципе, на нем можно и остановится. Пока вопросов больше и нет. Спасибо за ответы. 

Рекомендую брать из trunk-а SVN-репозитория. Нашел недавно пару неприятных ошибок.
P.S. Если Вы имели в виду asio samples а не asio examples 

Это сообщение отредактировал(а) mabrarov - 11.11.2011, 15:33

Марат, Ваш qt_echo_server очень бы подошел к моему проекту, но как выяснилось, требования в моем случае настолько низкие, что я решил обойтись вариантом сервера на основе http::server3 из asio.samples (да, я тут описался), поскольку он заметно проще.
Когда я начал изучать qt_echo_server, я несколько по другому взглянул на C++ и мне стала более понятной точка зрения его противников и его сторонников - когда передо мной стоит задача, которую нужно решить и есть жесткий дедлайн, есть классный пример на boos.asio, который то, что надо, но надо его допилить, но для допиливания мне нужно потратить кучу времени чтобы поднять свой уровень владения языком, то конечно я выберу другой язык попроще и буду кричать на каждом углу, что c++ must die (или вроде того) и приводить аргументы.
Если же передо мной стоит та же задача с тем же дедлайном и мой уровень языка достаточен, чтобы я наслаждался, как тонко я могу выразить термины предметной области в структурах языка c++ и просто восхищался, как богат внутренний мир языка и как другие этого могут не видеть, то я бы быстро допилил найденный пример (и еще сэкономил бы тем время) и на каждом углу кричал бы, что лучше c++ нет и приводил бы аргументы.
И в каждом случае я был бы прав - отношение к языку определяется в первую очередь уровнем владения языком. Имхо, конечно, сорри за оффтоп =)

Спасибо всем, кто выкладывает примеры по использованию boost'а вообще и asio в частности, способствуя их популяризации вы делаете мир лучше! =)

В качестве оффтопа (продолжения не будет).

Ну... там вся сложность (я уже писал где-то в комментариях в своем блоге) связана с:

• Поддержкой и MSVC 9.0 (возможно, MSVC 8) и MSVC 10.0 (т.е. я не могу использовать C++11-лямбды, move-semantic опциональна и разделена на exlicit/implicit move constructor из-за MSVC 10.0/GCC 4.5.x/GCC 4.6.x) - убрать "проклятые" #if и #endif (т.е. заточить под определенную платформу/компилятор) и код сократится в разы.
• Желанием (осознанным) запихнуть в один "sample" максимум "фич" Asio - можно было обойтись и без custom memory allocation.
• Желанием реализовать наиболее обобщенный вариант state machine для компонент сервера и наиболее обобщенную схему работы сервера (в примерах Asio нет "нормальной" остановки сервера - вообще эту тему обходят стороной почти все open source проекты, что я видел - везде останов сервера пишется как концовка фильма, на которую не хватило сил/бюджета).
• Все callback-и выполнены в виде обобщенных функторов C++ - это приводит к засилью (нелюбимых мною из-за усложнения) шаблонов.

Я не придумал ничего нового по сравнению с тем, что есть в документации Asio (в т.ч. примерах). Обобщил в одном месте, немного усовершенствовал - и все.

Многопоточные алгоритмы сложны. На C/C++ особенно. С Asio все же по-легче, но все равно надо четко знать все ограничения и перестаривать логику/мышление/стиль программирования.

Это я о причинах сложности. 

А так - с Вашим мнением я согласен. Где-то на rsdn попадался набор "слайдов" (или как там его), в котором между делом проскакивает, как Бьярн Страуструп оценивает свое владение языком C++ на 8 из 10.    Вообще, я на Java работаю (в смылсе "зарабатываю"), и знания Java даже на 1 из 10 мне пока хватает (что несомненно было бы мало для C++).

Я вот не вижу причин использовать асинхронный ввод вывод для решения этой задачи.
Event driven сервер будет иметь более высокую пропускную способность нежели threaded сервер только тогда, когда I/O сильно превалирует над обработкой, да и то, только до тех пор, пока программа не упрется в процессор. Event driven архитектура тупо сложнее в реализации, так как логика "размазывается" по куче callback вызовов. Threaded сервер сильно проще, там вся логика для отдельного соединения это просто последовательность действий, выполняемых в отдельном потоке. Помимо этого, event driven подход требует большего количества системных вызовов. Я экспериментировал с пайпами под windows, для IPC, у меня был простой RPC сервер и клиент (echo сервер). Threaded версия имела более чем вдвое низкую латентность, нежели event driven версия.

Это сообщение отредактировал(а) Lazin - 15.11.2011, 08:54