всем доброго дня.
имеем тип T:

в runtime мы получаем id`ы.
хочу реализовать что-то вроде типозависимого прокси callable`ра(хз как правильно назвать).

сигнатура методов/объектов такая:


нужна возможность регистрировать методы/объекты имея в runtime только id, и ин compile_time T::id.
т.е. зная T::id ат compile_time и id в runtime, назначать методы/объекты принимающие соответствующие им типы.

пример конечного использования:


как-то так...
запутался, и ничего в голову не лезет...

Это сообщение отредактировал(а) boostcoder - 3.4.2011, 01:58

IMHO сие невозможно. Либо id должен быть известен в compile time, либо реализация proxy вообще не должна зависеть от id

Либо я не понял требования задачи - что с чем и по каким признакам надо связать? Во что должен развернуться
?

это разные числа , или одно и то же ? 

если id == type1::id, то должен произойти вызов method1(...)



int id имеет диапазон type1::id ... typeN::id

два уточнения:
1. typeN::id - это enum. так что можно использовать в mpl.
2. у всех typeN общий предок.


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

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

вот на полусне : http://liveworkspace.org/code/c8cf16a805aa...0bc837af0545038
в том хоть направлении ?

Добавлено через 3 минуты и 27 секунд
это Вы удаленный вызов реализуете ?

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


а что ж тогда не объект класса typeN передается  ?

в параметрах должны быть типы или значения соответствующих типов?

да.


похоже на то. покурю...


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


значения.

при использовании структуры кол-во аргументов функции постоянно.

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


подправленная версия :  http://liveworkspace.org/code/3b42cd08948e...84cf01e63c3374e

можно упаковывать полученные аргументы в boost::any
а методы оборачивать во что-то шаблонное, унаследованное от общего интерфейса (который и принимает эти boost::any)

Добавлено через 55 секунд
(правда, не получится пользоваться неявными преобразованиями)

в примере обработчиками выступают функции, но у конечному пользователь захочется иметь что либо более универсальное..поможет класс Dispatchera, для конвертации параметра и класс функции (напр boost::function)
http://liveworkspace.org/code/09b6daf1e59d...aee0c15a1aff76d

на "ляпы"  не относящиеся к сути проблемы (такие как неподходящий способ хранения) внимания не обращать 

кстати вспомнил, goldfinch  одно время на форуме разбирал темы связанные с удаленными вызовами..
не помню к чему он там конкретно пришел, но думаю Вам будет тематически полезно ознакомиться с этим материалом.. 
если найдете прикрепите ссылки к теме, плиз

я даже аккаунта такого не могу найти. и функцию поиска аккаунтов тоже :(

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

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

mes, сделал так, как вы предложили:


используется это дело так:


метод proxy_caller::call() вызывается из сетевой части после того, как буфера на которые ссылается proxy_caller заполнены.
как видно из реализации метода methods_dispatcher::dispatch(), ответ отправляется обратно при выходе из тела этого метода.
не худшая реализация RPC из тех что я видел  
но хочется большего.
а именно: скрыть от юзера все, кроме самого implementation.

в идеале, цель хочу видеть такой:

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

ну проще было искать тему, и поставить ограничение по юзеру..
вобщем вот об этой я говорил :
http://forum.vingrad.ru/forum/topic-269086...tml#st_0_view_0


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

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

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

Добавлено @ 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

для этого, нужен метагенератор, генерирующий метаинформацию из к примеру, такого макроса:

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

т.е. для этого интерфейса должна быть такая реализация:


есть идеи?

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

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


нет. на каждый тип команды свой метод обработчик на сервере.

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

сообщение про список типов видели ? если приведете функции обработчики к одному имени, то выгадаете (не кодогенеруеммую, а шаблонную) автоматизацию


естественно разный, но с таким же именем ))



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

  нет.

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

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

что имеется в виду?

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

имена у них тоже разные:


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

у буста что то в этом роде : 


ну а сервер выглядит так

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


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

фактически именем метода будет выступать имя типа пакета..
а чем неудобно одинаковое имя ?

Добавлено через 51 секунду

да список типов будет определять какие обработчики предоставляет сервер.

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

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

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

Добавлено через 4 минуты и 56 секунд
сейчас еще одна идея пришла... надо обдумать.. 

имел в виду их и разобрать.

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

клиент заканчивается отправкой сериализированного объекта в _сокет_.

Добавлено через 1 минуту и 30 секунд
хотя да.. я забыл что еще ответ надо ждать.. вот тут есть проблемка... 

угу.
но вроде как можно приблизительно так(мысли в слух):
на стороне клиента, сгенериный интерфейс используется совместно с классом client<interface>
на стороне сервера, сгенериный интерфейс используется совместно с классом server<interface>
то что генерится, должно содержать в себе какое-то значение времени компиляции которое client<> и server<> будут читать, то можно реализовать их таким образом, чтоб каждый брал для себя только то, что ему нужно. 

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

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

как-то так...

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

и возвращаемся к старому вопросу:
1. что должен генерировать метагенератор на стороне клиента?
2. что должен генерировать метагенератор на стороне сервера?
3. как связать сгенерированную информацию с реальным, написанным нами, классом?

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

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

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

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

Добавлено через 5 минут и 18 секунд
ну так и получается, что имя функции нам не нужно.. 

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

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

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

да.
я понимаю, что можно запросам присваивать ID`ы. но это пока не главный вопрос.

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

да.


можно реализовать следующим образом: в client<> добавить deadline_timer, который сам будет слать серверу запросы, и при получении ответов, вызывать некоторый обработчик.

но и это не главное.

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


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

Добавлено через 1 минуту и 17 секунд
итак Вы решили (с чем я не согласен) что синхронность будет удобнее..

Добавлено через 2 минуты и 12 секунд
тогда у нас есть rpc::client, к которому мы можем посылать запросы и получать ответ

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

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

Добавлено через 8 минут и 32 секунды
допустим это будет выглядить так :



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

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


Добавлено @ 21:16
теперь нам необходимо как то зарегистрировать функции 
можно сделать массив/карту делегатов и связать их,

Добавлено @ 21:21
а можно отделить внутренности сервера от методов обработчиков .. 
тогда вместо методов обработчиков определяем таблицу вызовов
и тогда регистриуемая функция будет иметь вид


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

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

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

пишу мысли... минутку..

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

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

Добавлено @ 21:30
итого значит у нас есть rpc::server и rpc::client (не пустать с rpc::server::client ) осуществляющие связь посредством сырых данных и взаимодействующие с пользователем типизированным пакетами.

Добавлено @ 21:36
т.е общий код выглядит так 


Добавлено через 9 минут и 58 секунд
писал rpc::login но по сути пакеты должны находится в другом неймспейсе, например название протокола..

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


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

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


тогда, в дополнение, было бы мегаудобным, реализовать в классе client<> запрос, типа create_session<type>(). который будет на стороне сервера создавать объект сессии, и переключать контекст клиента на этот объект.
если пойти немного дальше, то класс server<> можно реализовать так, чтоб список шаблонных аргументов был переменным. в таком случае, клиент, может делать запросы на создание какого-то конкретного объекта сессии, и пользоваться им.


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

Это сообщение отредактировал(а) boostcoder - 10.10.2010, 01:58

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


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




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

Добавлено @ 09:39
список типов определяет какими сообщениями они могут обмениваться, а также для для сервера служит основой для таблицы регистрации..

Добавлено @ 09:44
как выглядит пакет и какие данные он должен содержать зависит от клиента и сервера.. поэтому имхо первостепенный вопрос стоит не в кодогенераторе, а в проектирование конечных точек соединения.. при том для упрoщения можно реализовывать в одной проге и  передавать данные напрямую, как в начале темы через  функции типа  void call(id, void*);

Это сообщение отредактировал(а) mes - 10.10.2010, 09:44

сессия - контекст пользователя/соединения.
комнаты - некоторые объекты, взаимодействие с которыми происходит посредством сессий.


наверное я вас не понимаю.. поясните пожалуйста.

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


сервер:



Это сообщение отредактировал(а) boostcoder - 11.10.2010, 02:39

ловите в упрощенном виде : http://liveworkspace.org/code/bbc75134b93c...914597f9c23e38b
с односторонним обменом клиент->сервер

rpc - библиотека конечных точек взаимодействия
ptcl -(кодогенерируемый) протокол обмена
my_server - оболочка реализующая поведение сервера (может быть определена как неймспейсом, так и классом)

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

mes, большое спасибо  
сейчас буду разбираться.

зы
на liveworkspace работает табуляция в коде. еще Ctrl+G, Ctrl+F, Ctrl+R, Ctrl+Z. оцените  

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

  

даже не ожидал  ! учту, спасибо )

и я еще раз насчет (а)синхронности...  мне кажется вместо классического вызова функций с получением ответа, где сервер выступает в пассивной форме,
удобнее было бы воспользоваться системой взаимообмена сообщений, тогда клиент будет обладать такой же таблицей методов, как и сервер
а пакеты разделяться на две группы (client_to_server, server_to_client);




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

да. согласен. это хороший вариант.

продолжим-с...
что у меня есть сейчас:

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

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

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


mes, вы в теме?  

Это сообщение отредактировал(а) boostcoder - 25.10.2010, 23:43

не до конца понятно о чем тут.. 

над кодом сейчас подумаю.. но сразу чувствуется, что пока это не то что надо .. 


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

вот:

но это плохая реализация. нелепо как-то, в один интерфейс пихать сотни методов  

понял.. Вы о том что у сервера только один исполнитель...  ага.. это не то.. но по этому поводу у мя вопрос : 
исполнители должны иметь каждый свою группу сообщений или некоторые сообщения будут для исполнителей общие ?

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

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

Добавлено через 2 минуты и 15 секунд
сейчас приведу структуру классов для понимания..

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

где IF - тип исполнителя.

опять на помню, может уговорю пересмотреть контракт с сервером с запрос->ответ, на вызов<->вызов




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

Добавлено через 42 секунды
как вариант передавать библиотеке ссылку на фабрику..

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

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

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


да, вариант.. набросаю пример..