ну да..это я погорячился  

поразмышляем дальше..

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

на 3м фронту нам требуется размер данных и сами данные, 
 // возможно также еще некие данные для маршрутизации, но нас пока не интересуют

на 2м также некоторый ид (скорей всего msg_id, a не method_id), на основании которого сообщения будет (де)серелизоваться

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

Добавлено @ 17:44
попробуем отразить кодом :




Добавлено @ 17:46
значит сендер должен быть объеденен с сериализатором.. 
также как и диспатчер с десерилизатором... 
но все ж получается два типа msg/method и пакет.. 


Это сообщение отредактировал(а) mes - 7.12.2010, 17:46

пока к следующему вопросу.. 

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

пока прерываюсь времени больше нет.. 

а понял в чем дело, я не правильно фронты представлял 
1. create / invoke
2. send / receive
3.  transport

Добавлено через 1 минуту и 17 секунд
итого получается : 
method->msg->packet->msg->method.. 

сейчас пересмотрю код... возможно рефакторинг проведу..

сильно не торопитесь пока.. мож еще что стукнет  я сейчас как раз размышляю насчет стыка между 2й->1й фронт.. 
точнее над тем , что есть invoke в нашей задаче..

Это сообщение отредактировал(а) mes - 7.12.2010, 19:02

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


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

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

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

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

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

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

4. для простых случаев предоставлять готовую схему
и многое другое...



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

Цитата

code formating/refactoring

кому то не нравятся фигурные скобки на новой строке   

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

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

Цитата(boostcoder @  8.12.2010,  00:50 )

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

aa ) я о такой ситуации чего то и не подумал...

lws чего-то барахлит  :

хм... сейчас буду разбираться..  

зы
это Вы LWS сломали?  

вроде уже работает 


я не специально  

Добавлено через 59 секунд
зато я разобрался со вторым фронтом 

Добавлено через 12 минут и 5 секунд
итак..
для начала немного по терминам :
слово "packet" мне кажется больше всего подходит для типизизованного сообщения.. 
после добавления в него концепции accept(invoker_t) он служит как раз для упаковки и передачи аргументов.. 
для миграционного сообщения пока остановился на слове "rawblock"
nid пока временное обозначение идентификатора..

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

вот условный пример :
http://liveworkspace.org/code/dc60c4f5ca6d...0cd97806e6cf1b2

для наглядности :


Это сообщение отредактировал(а) mes - 8.12.2010, 17:00

немного расширил схемку :


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