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

ага.. о чем то в этом роде я тоже думал.. но пока этого не надо.. 

mes, пересматриваю Ваши коды, и голова кругом...
сейчас напишу огромный пост..

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


Добавлено @ 23:03
давайте ввод/вывод пока не обсуждать. как будто его и вовсе нет  
когда заработает каркас целиком - тогда многие моменты станут очевиднее. вот тогда можно оптимизировать код.

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


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

далее.. пишу...

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

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


имеется ввиду сетевая часть, давайте.. я с этого и начинал 

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


тогда уж просто клиент (без нет_), чтоб в лишних детали не путаться 

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

ждем-с 

а понял вас интересует взаимодействие клиента и юзер_контекста ... так ?

mes, скажите, это http://liveworkspace.org/code/93bbe9011487...5ee4e2130e216d3 Ваш последний код?
т.е. мне опираться на него?


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

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

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

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

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

  

вопрос:
в классах one_ctrl, two_ctrl, main_ctrl есть конструктор принимающий ссылку на тип junction. собственно не понял зачем это?
поясните пожалуйста 

Добавлено через 1 минуту и 25 секунд
согласно этому коду: http://liveworkspace.org/code/42e7f0049659...d81b881b3baf4e2
ради эксперимента, из класса one_ctrl я это все убрал. результат тот же. может быть есть какой-то смысл, мне не очевидный?

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

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

понял..сейчас..

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

гляньте плиз: http://liveworkspace.org/code/fc0b10348bcd...394a1a052b6befc
обратите внимание на two_ctrl. я добавил метод call_main(). я правильно понял предназначение этой ссылки?

вот схематично.. насколько смог :


Добавлено через 2 минуты и 22 секунды
client  (ну и соответсвенно user_context) являются тригерами, которые переключают куда направить поток, или наружу или внутрь по кругу..
P.S. под потоком команд подразумеваются любые команды, как наши , так и обычный вызов функции

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

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

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

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

mes, это ответ на это?:


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

удобнее мне кажется будет в junction добавить метод типа "get<controller>()". т.к. я понял, реализация junction от юзера скрыта. так?


ок.
закрыли этот вопрос.


т.е. вместо add_handler() и всех его внутренностей, создать карту сигналов?

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

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

адд_хэндлер замениться на гет_сигнал..

Добавлено @ 01:20
или на просто on<>

Добавлено @ 01:24

по идеи каждый подраздел представлен двумя классами.. например  auth_iface и auth_ctrl.
где ctrl это скрытая реализация, а iface - интерфейс пользователя являющийся прокси (*) для контролера.. 

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

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

Это сообщение отредактировал(а) mes - 4.11.2010, 01:25

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


не очень понял о чем конкретно идет речь..

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