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


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

вот:

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