тема предназначена для обсуждения вопросов возникшей в теме : 
библиотека распределенного общения

Добро пожаловать ! 


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

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

модель по первому пункту:
 сеть состоит из узлов-объектов, каждый из которых имеет вход и выход:

, где msg (сообщение) - полиморфный пакет аргументов (в коде назывался migrant)..

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


тогда для замыкания клиента на канал, код будет условно таким:


Добавлено через 11 минут и 58 секунд
Переходим ко второму пункту и начнем с проблем:

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

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


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

цель аргументирована и представлена правильно.

НО:

это сделано только для разного кол-ва аргументов?



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



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


в этой теме:

я так понял, пример приведен для регистрации методов самого client? а как будет выглядеть это все, если, к примеру, нужно зарегистрировать объекты-члены client`а?

да.. чтоб получить удобный синтаксис вызова и инвокинга.. 


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



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


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

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

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

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

явных дырок вроде не видно..

вот пока прообраз определения отправителя :
http://liveworkspace.org/code/cf501477e6dc...0a837667a76b96f

P.S. то что в namespace dy {} - библиотечные сущности, вне его пользовательские.. 

для того, чтоб было более понятно, добавил client , принимающего испускаемое сообщение..
по сути его (сообщение)  можно как сразу диспатчеризовать как объекту-исполнителю, так и прокси-объекту, например пересылающему каналу..
http://liveworkspace.org/code/f20d825e29ee...b19775061507791


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

дополнил картину условной картой и  зачатком вызова метода :
http://liveworkspace.org/code/3fb0a366fb31...cb548bb3c26dbe5

более полный прообраз dy::map в соседней теме.. 

еще немного подправил, убрал лишнее, чтоб  все с одного обзора видно было..
http://liveworkspace.org/code/bc23e9e011e5...76ba0bc2ff9ca5d

mes, скажите, Вы сейчас исследуете связывание со статической проверкой на соответствие?

зы
еще, мне кажется, сильно неудобным такой способ:

много ручного кода юзеру писать придется. :(
и "struct stc" тоже ручной код :(

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

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


ну так сигнал определен как функция, а не как функция объекта.. поэтому и бинд.. 
при использовании cls_map, код инициализации был бы :



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

это я понимаю. просто мысль высказал 

и еще. для чего _stc является глобальным объектом? это обязательно? почему?

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

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

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

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

а счетчик на каждый Тraits  будет свой, для исключения конфликтов между разными протоколами..
также у пользователя должна быть возможность определить принцип построения ид, например добавить префикс..
итого :
http://liveworkspace.org/code/8934bc564df5...bb91362ac1f5376

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

из за статического счетчика,  при создании двух экземпляров stc элементы получат разные id..
а также нет контроля выхода за пределы позволенной енумерации.. 
решить проблемку можно двумя способами.. 
1. сделать stc синглетоном
2. задавать при создании группы (stc) возможный  диапазон значений..
вот в грязном виде :
http://liveworkspace.org/code/c09a3d8b8c97...3f6c4dfdd44114f

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

Добавлено через 2 минуты и 56 секунд
только мне названия ни sender, ни call не нравятся.. 

опробуем "превращение" функции, в функцию-член :
http://liveworkspace.org/code/5e6c6afcb028...ee90364f5ab5631

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