сокет-соединение ? нет одно .. 
остальное еще не прочел

Добавлено @ 13:33

я б сказал не так :
есть сокет соединение 
есть rpc соединение 
и само исполнение

естессвенно у каждого модуля(сервер или клинт) своя реализация каждого уровня.. общие только библиотеки.. 

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

..не понимаю..

может обратные вызовы реализовать следующим образом:
у клиента добавить метод типа "set_callback(int id, function)", где id - идентификатор колбэка, function - объект указывающий на функцию/метод на стороне клиента который будет вызываться. т.е. при вызове set_callback() указанный идентификатор регистрируется на сервере. в то время, на сервере добавить метод типа "callback(id, args...)". где id - идентификатор вызываемого на стороне клиента метода. клиент в свою очередь, должен уметь отличать ответы сервера на свои запросы, от вызовов колбэков.

как такая идея?

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

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

такой набор исполнителей 

диспетчера сообщений :


условный сервер приемки сообщений

отправитель :


тестовый пример :

и вывод


http://liveworkspace.org/code/5afd22007254...ad429549e89fe69

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

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

знаков препинания не хватает..смысла не понял...

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

ага

Добавлено через 55 секунд
по остальному - вникаю в суть...

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

ага. понял... щас..

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



могут быть ошибки.. с лямбдами пока еще не приходилось работать.. 

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

вот доработал немного :
http://liveworkspace.org/code/17eb2d53ecbb...5b334c82dbf190e

Добавлено @ 18:11
а вот чистый пример, без классов исполнителей..  
http://liveworkspace.org/code/6e7e20117c85...4e7a337ac958087

Добавлено @ 18:13
вот пока объяснял сам разобрался как происходить должно... 
 

если что осталось непонятным, спрашивайте 




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

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

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

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



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

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

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

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

и это то же.. как подзадачу 

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

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


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

это я понял.. поэтому и написал :

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

Добавлено @ 20:42
ну например клиент может выглядить так :

тут есть вопросы ?

пояснения :
my_protocol  это traits- структура, содержащая список сообщений, допустимых для передачи по соединению.. 
register() - установка делегата
оператор <<  - отправка сообщения в сеть

Цитата(boostcoder @  26.10.2010,  19:28 )

вы на протяжении всей темы

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


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

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

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

приоритеты возможно не в том порядке, т.к. возможно одно зависит от другого.

вот.

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

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

т.е. с приемом/передачей одного сообщения у вас проблем нет ?