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

да, я тоже прочитал, по старой памяти думал там больше полезного 

Добавлено @ 11:03
вот например метод login... напишите отдельно, как Вы представляете, клиентскую и серверную часть функционала не затрагивая реализацию rpc, т.е. фактически конечные точки Вашей схемы.

Это сообщение отредактировал(а) mes - 9.10.2010, 11:05

mes, а что именно описать? как это все происходит сейчас? или что?...
метод login - просто метод. вызывая его на стороне клиента, его аргументы отправляются на сервер, десериализуются, вызывается назначенный для этого типа запроса обработчик, тот в свою очередь получает дополнительный аргумент по ссылке в который кладет ответ, ответ сериализуется, отправляется клиенту, клиент десериализует его, и возвращает юзеру объект типа ответа.

имелся ввиду код взаимодействия.. как Вы его видите..
например так :


Добавлено @ 11:37

это как раз лишнее, так как  



Это сообщение отредактировал(а) mes - 9.10.2010, 11:45

понял.
вот нынешний реальный код на стороне клиента. он даже работает  

client::query<>() возвращает смарт-поинтер.

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

что-то у меня это по удобнее получилось 

Добавлено через 4 минуты и 21 секунду
на стороне сервера, каждый тип команды, ассоциирован с методом обработчиком.

первое что бросается в глаза, value_type не очень удачное название.. 

mes, почему? как тогда его лучше назвать?
мне многие названия в моем коде не нравятся, наверное фантазии не хватает)

второе, что у Вас не ассинхронный обмен - так и нужно ?

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

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

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

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

не до конца понял..
запрос к серверу идет здесь

или здесь 

?

да, так лучше.

т.е. ассинхронность введена специально ? или все ж так получилось ?

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

ну так не удивительно.. я то написал спонтанно 

здесь:

он ставится в очередь на основе boost::thread + asio::io_service + boost::packaged_task<>

но при вызове любого из методов результата, вызывается boost::unique_future::get(), который приостанавливает вызывающий цикл.

Добавлено @ 12:08

да, специально.

Добавлено @ 12:14
хотя в этом есть некоторое не очевидное поведение: если вдруг asio::io_service::run выполнить в нескольких потоках(типа пул потоков), и сделать один запрос к серверу ничего не возвращающий но сохраняющий в объект сессии некоторое значение, и следом за ним сделать запрос получающий это значение, то может получится так, что второй запрос придет на сервер раньше  
чтоб исключить такую ситуацию, в тип нужно добавить служебный метод, что-то типа wait(). сделаю... позже..

Добавлено @ 12:19


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

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

http://liveworkspace.org/?id=bb4bddf94368b...b96872fa347ec98
connection - объект сессии с клиентом.

Это сообщение отредактировал(а) boostcoder - 9.10.2010, 21:13

интуитивно напрашивается такой псевдо-код :

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

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

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

Это сообщение отредактировал(а) mes - 9.10.2010, 12:41