это опечатка, которая зародилась у меня, а Вы ее подмножили   




нет такого.. id сырья хранит пакет.. 


Это сообщение отредактировал(а) mes - 29.10.2010, 19:18

понял.

еще момент..

в классе rpc_sender, в методе send есть такая конструкция:

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

с этим все понятно. нас не интересует момент, когда пакет будет реально отправлен.

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

так сойдет?

Добавлено через 25 секунд
гляньте пожалуйста, с отправкой пакета все гуд?

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


для того, чтоб мы могли протестировать взаимодействие сетевой части в одном процессе, нужно выполнять asio::io_service::run в потоке. так что не удивляйтесь тому, что в классе клиента и сервера добавятся потоки.

сейчас гляну..

а Вам если хотите отвлечься , посмотрите набросок :
http://liveworkspace.org/code/16a8c06a8c47...a16e5f2977fb7f6
на грязь не обращайте.. это черновик..


обратите внимание на класс distributor, и в особенности как идет доставка контролерам клиента.. 
 

Добавлено через 5 минут и 26 секунд

ага.. 


ну если эта оболочка которая будет добавлена в очередь, то она не sender a holder.. 
а если это сендер, то он должен брать сообщение из очереди, а не хранить его.. 

сейчас дальше гляну..

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

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

Добавлено через 9 минут и 7 секунд
а если боитесь лишних биндеров, они уйдут позже.. но нам они сейчас упрощают композицию..

Добавлено через 11 минут и 31 секунду

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

Добавлено через 14 минут и 1 секунду

вижу что тот простой трюк ( с биндами ) понравился 
   

Добавлено через 14 минут и 39 секунд
вроде все просмотрел.. если не на все ответил, уточните 


Это сообщение отредактировал(а) mes - 29.10.2010, 20:35

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


в контексте программирования это как переводится?


ок.

держатель 

мне кажется на ресивер. т.к. именно ресивер содержит карту инвокеров и метод dispatch()
его нужно вязать к rpc_receiver::dispatch(rpc_packet const& pack)

Добавлено через 1 минуту и 9 секунд

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

Добавлено через 1 минуту и 35 секунд
сейчас ваш код усваивать буду..

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

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

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

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

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

поясните..

1.dispatch принимает рпц_пакет, а с сервера приходит чистый буфер..
заставлять делегата расшифровывать не хорошо.. так как могут потрбоваться знания которыми обладает только клиент..
2. диспатчеризироваться объект может более чем одному ресиверу (например на выбор) и только клиент знает кому и когда.. 

значит holder

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

нужен еще один тип? расшифровщик?
тогда нужен и шифровщик, который сейчас у меня в конструкторе real_sender

и даже не на очередь а на клиента.. 
и он даже не сендер , а write_action 

интуитивно лезет что от типа такого :

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

Добавлено @ 21:07

скорее не типы, а функции, на подобиe pack/unpack 

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

Добавлено @ 21:18

а клиент после отправки асио объекта с ссылкой, может быть уверен, что объект не будет жить дольше клиента ?


Это сообщение отредактировал(а) mes - 29.10.2010, 21:18

в деструкторе io_service`а все объекты которые еще лежат в очереди будут разрушены.

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

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

тут не понял...
какого типа ссылка на объект m_client?
что подразумевается по словом "клиент" ? и что подразумевается под словом "очередь" ?

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

это понял.

ага..так и предполагал .. 


net_client




к примеру стд::очередь рпц_пакетов..

к тому  же write_action может сбросить в сокет более одного пакета.. если есть время и место для этого .. 


Это сообщение отредактировал(а) mes - 29.10.2010, 21:57

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

Добавлено через 2 минуты и 9 секунд
а если мой вариант реал_сендера переделать так, чтоб он не выполнял упаковку рпц_пакета, чем он не устраивает?

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

ну и называть его холдером