a id у нас тут же нет ? оно же в хидере... тогда уж,  да и наглядней будет.. rpc_packet(_header, _data))

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


Добавлено через 2 минуты и 43 секунды

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


Добавлено через 3 минуты и 56 секунд
другое дело, если мпл структорой задавать и формат и длину, как для сервера так и для клиента..
наверно это и имелось ввиду, а я сначала не так понял 

Добавлено через 6 минут и 49 секунд
и так что у нас терь на планах ?

ага.


у нас проблема с сервером.
код: http://liveworkspace.org/code/dda59b3f3ab3...ce824a4aa58ec89
это стандартная модель сервера основанная на enable_shared_from_this.
а проблем у нас две:
1. класс usercontext наследуется от этого шаблона. он живет в смарт поинтере. и живет он только благодаря тому, что счетчик ссылок постоянно больше нуля. это происходит потому что каждая асинхронная операция, создает хэндлер не на this, а используя метод предка shared_from_this(). этот метод инкрементирует счетчик ссылок, только по этому объект не убивается. сейчас нам нужно решить, каким образом инкрементировать счетчик ссылок при асинхронных операциях.
2. согласно этой схеме, usercontext содержит член-сокет который передает по ссылке методом socket() в async_accept() класса сервер. в нашей текущей структуре rpc_net_io этого сходу не сделаешь. придется допиливать. вот только как именно?

Это сообщение отредактировал(а) boostcoder - 1.11.2010, 22:38

надеюсь что в контексте сказанного, она не подразумевается usercontext`ом ?

нет.

Добавлено через 1 минуту и 27 секунд
но ведь в usercontext`е она должна жить.

Добавлено через 14 минут и 35 секунд
самый простой вариант, для сервера, выкинуть rpc_net_io + rpc_inkom + rpc_outgo, и написать все методами. тогда вообще теряется весь смысл этих классов даже для клиента. т.к. не получится повторного использования кода.

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

но это я так, на крайний случай...

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

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



Это сообщение отредактировал(а) mes - 1.11.2010, 23:58

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

Добавлено через 2 минуты и 46 секунд
если в rpc_net_io добавить свойство-тип_поинтера - счетчик инкрементируется. но декрементируется он тогда, когда rpc_net_io будет разрушен. но в текущей его архитектуре он не может быть разрушен... контексты удаляться не будут..

вроде я все правильно понимаю..

зачем инкрементировать в нет_ио ?

а где? нам куда-то нужно создать копию. эта копия должна разрушится тогда, когда последняя асинхронная операция вернет управление.

Это сообщение отредактировал(а) boostcoder - 2.11.2010, 00:10

если соединение закрыто с сервера, то толку от выполнения ассинхронных операций ?
а если не закрыто, то какую операцию считать последней ?

не понял. мы ведь о сервере и говорим.


у нас в любом случае получается последней операция чтения. т.к. клиент и сервер ждут данных от с противоположного конца.

я имел ввиду сам объект сервер.. который когда ему не нужно отпускает(удаляет) юзерконтекст..

.

Добавлено @ 00:26

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

сейчас тогда подумаю.. 

Это сообщение отредактировал(а) mes - 2.11.2010, 00:26

все равно не понял  

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

Добавлено через 11 минут и 35 секунд
посмотрев освеженным взглядом.. согласен , что net_io как объект лишний..
тем более что он включает в себя кучу лишнего..хотя бы тред... 
но сами его операции, не лишние.. как инком и оутго.. 



Это сообщение отредактировал(а) mes - 2.11.2010, 00:30

да.


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

принцип согласно этому коду: http://liveworkspace.org/code/dda59b3f3ab3...ce824a4aa58ec89
 после прихода нового клиента, вызывается метод server::handle_accept. в нем происходит вызов new_connection->start()
так вот, если user_context::start не создать асинхронную операцию типа такой:


Это сообщение отредактировал(а) boostcoder - 2.11.2010, 00:41