да, уже разобрался. все просто.


тут нужно начать с написания теста по предыдущей реализации, и задуманной. этим и займусь.

и да, если с докой что-то не так, всегда можно исходники почитать. ну, на крайняк, самому написать доку и отослать автору патч. не думаю что он сильно расстроится.

Это сообщение отредактировал(а) boostcoder - 9.1.2012, 15:51

Я бы на его месте поленился тащить такую ношу (+ несколько платформ) в одиночку да еще и бесплатно. Видимо, он что-то имеет с консультаций. Вроде что-то проскакивало про Австралию и custom-solution для гос/научного учреждения... Вот посмотрите на ACE. Сколько гос-бабла туда вбухали США? И как Вам документация (я уж молчу про код и что про него мне сказали в Y).

дока ужасная, какой всегда и была, сколько я ее помню.

вот только на один момент никто(?) не обратил внимания: используя asio::buffered_stream мы избавляемся от длиной цепочки вызовов и одного сискола, но взамен добавляем операцию копирования из asio::buffered_stream в передаваемый буфер. а это не малое копирование. это копирование всего трафика.
как считаете, будет ли такая оптимизация оправданна?


Это сообщение отредактировал(а) boostcoder - 16.4.2012, 07:17

А разве могло быть иначе?


Я думал, что на этом и последующих ответах тема себя исчерпала.
Это почти стандартный подход:

• (циклический) буфер;
• читаем (read_some) столько, сколько влезает в свободную часть буфера, т.е. стремимся сократить кол-во обращений к сокету - можно добавить asio::transfer_at_least(подсказка от парсера по минимальному кол-ву байт для завершения разбора очередного сообщения);
• парсер входящих сообщений на КА;
• копирование разобранного сообщения в отдельный объект и передача его через указатель (можно с shared-семантикой) дальше в логику обработки сообщений (еще один или несколько КА).

Это сообщение отредактировал(а) mabrarov - 16.4.2012, 11:29

я тоже так думал. но как дошел до реализации, одумался 

Почему? Реализация описанного выше (буфер, чтение, парсер на КА, логика на КА) получается слишком запутанной? Или Вы написали это про asio::buffered_stream? 
IMHO: asio::buffered_stream не стоит тянуть в свои проекты. "Чтение с запасом + парсер-КА" универсальнее.

Это сообщение отредактировал(а) mabrarov - 16.4.2012, 14:02

и это тоже. но основное - копирование всего трафа. но, как я понимаю, по другому быть не может. это я, хочу странного =)

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


по Вашему мнению, почему?


объясните плиз более развернуто, для чего тут КА и кем является "парсер"?

Это возможно, когда десериализация не требует ничего кроме копирования. Тогда по заголовку сообщения можно сразу выделять буфер нужного размера и тогда же не удастся сэкономить на обращениях к сокету.


У нас наметилось явное недопонимание: 
парсер == десериализатор.


Потому что это лишнее, если Ваш десериализатор умеет парсить данные из буфера приема и может продолжать парсить частично полученные сообщения. Обработка того же протокола заголовок-с-размером-тела+тело - есть простейший парсер/десериализатор.. в книжках по ACE эту часть называют... эээ... frame protocol, что ли.

что-то я совсем запутался %)

сначала я запрашиваю у сокета прочитать заголовок. из него я узнаю размер тела. и делаю еще один запрос на чтение тела.
это сейчас так. и тут у нас проблема с двумя цепочками вызовов для получения одного пакета.

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

к тому же, то, что я описал в топике, не предполагало копирование всего трафа, ибо там я предполагал передавать итераторы.
как-то так:


Это сообщение отредактировал(а) boostcoder - 17.4.2012, 03:12

я думаю скопипастить реализацию asio::buffered_read_stream и переделать ее для работы с итераторами...

Добавлено через 3 минуты и 34 секунды
проблему неизвестного максимального размера буфера, я думаю, можно решить дополнительным буфером, который будет создаваться если запрошен размер превышающий максимальный размер дефолтного буфера.
большинство пакетов имеют размер до 20ти байт.