Помогите оценить сложность создания фреймворка. Фреймворк должен позволят программисту явно описывать необходимые модели предметной области и прозрачно для программиста (неявно) расшаривать эти самые модели на всех узлах сети, где запущено данное приложение. Т.е я создал объект "автомобиль", задал его местоположение и скорость на одном узле и на остальных узлах эти данные появились без моего явного участия.
Я представляю это дело в виде фабрики, которая создает объекты заранее определенных классов и вся магия в этой фабрике заключается. С объектами работаю дальше как с обычными, без явных команд передать, засинхронизировать и т.д. Что посоветуете? Куда двигаться, что почитать.

Немного похоже на DCOM. Можно с него и начать (в смысле ознакомления)

DCOM не подходит - слишком универсально. Я. правда, и не обрисовывал конкретную ситуацию. Область применения - сеть приложений, которые должны взаимодействовать друг с другом в различных сочетаниях. Например, есть узлы У1, У2 и У3 - узел У1 изменяет у себя величину В233, при этом У2 получает изменение величины В233, а У3 не заинтересован в ней и ему такие данные не нужны. Но он может быть заинтересован в других данных, которые не нужны У2. Т.е. связи между узлами довольно сложные, хотя формируются по простым алгоритмам - каждый узел избирательно подписывается на нужную ему информацию у всех нужных ему узлов. При этом все должно происходить прозрачно для программиста-пользователя фреймворка.
Лично у меня идея изобрести велосипед создать класс-фабрику, которая будет создавать базовый класс-контейнер плюс хранить в себе все данные в виде таблицы ключ-значение. Этот базовый класс-контейнер хранит в себе экземпляры другого базового класса-величины. Класс-величина преобразует свои значения в данные нижнего слоя - пары ключ-значение. Где ключом является номер узла, порядковый номер записи, идентификатор базового-класса контейнера и идентификатор базового класса-величины, а значением является собственно значение. А если в ключ добавить номер версии, то можно некоторое подобие персистентности организовать. 
Таким образом, возможно из пар ключ-значение данные вернуть в виде класса и класс преобразовать в пары ключ-значение. И смысл разделения на два слоя в том, что нижний слой - эти самые записи, можно передавать между узлами независимо от верхнего слоя. При чтении значения из экземпляра класса-величины происходит поиск по ключу и возврат значения. Конечно, тут издержки по времени и по памяти, но память сейчас дешевая, а скорость при необходимости можно увеличить за счет кэширования данных в критичном месте.
Да, еще в основе лежит утверждение, что каждый узел генерирует уникальную информацию, не пересекающуюся с другими узлами и не конфликтующую. Т,е. если мы имеем кучу складов, то каждый склад отвечает сам за себя. А если мы хотим отгрузить со склада находясь в офисе, то должны запрос отправить складу и только после обработки складом можем реально отгружать. Таким образом (имхо, конечно) избегаются лишние блокировки - они возникают, только когда несколько запросов к одному складу. Но это ограничение накладывается не программной моделью, а самой бизнес-моделью - если поставить на один склад несколько кладовщиков и они не будут согласовывать между собой свои действия, то ничего хорошего из этого не выйдет.
Покритикуйте, пожалуйста.

Это сообщение отредактировал(а) drug007 - 16.1.2013, 07:09

Задача понятна, но вы подходите к ее решению не с той стороны   Сначала определитесь как будут взаимодействовать узлы в сети. В частности как будет происходить исследование топологии сети - какие узлы в ней есть и какие значения есть у каждого узла. Должна ли быть топология динамической (что делать при добавлении новых узлов и при исчезновении старых)?


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

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

А интерфейса как такового и нет. В этом то и смысл фреймворка. Т.е. если я создаю класс

я максимум что делаю, объявляю мемберы через шаблон и делаю скрытым конструктор (у меня же фабрика):

Ну возможно еще геттеры/сеттеры. Вот и весь интерфейс. Все остальное должно обрабатываться автомагически в классе-фабрике. Топология сети динамическая, на первом этапе информация тупо дублируется между всеми узлами, позже добавлю управление обменом. Так как выделено два слоя, то отработкой взаимодействия на сетевом уровне можно заниматься независимо от уровня интерфейса, что одна из целей.
Discovery service я планирую решать позднее, ибо вещь нужная, но независимая. 
Определить у кого какая информация можно на основе того, что каждый узел генерирует уникальную информацию в масштабах всей системы (это важное условие в основе моего подхода - возможно ошибочное, что и хочу обсудить), то узлы легко могут оповестить друг друга о том, какой информацией они обладают - тупо по своему номеру (узла) и идентификатору последнего сообщения.
Типы значений пока предполагаю только POD. Но не вижу проблем позднее добавить поддержку указателей и классов. В конце концов можно взять библиотеку сериализации - тогда можно будет использовать все типы, поддерживаемые библиотекой, но здесь нужно на практике проверить.

Это сообщение отредактировал(а) drug007 - 16.1.2013, 14:03

Вполне нормальный интерфейс, но явно не полный. У вас в интерфейсе должно быть определено, как разделяются инстансы классов, а не их типы (т.е. не class A, а A my_class_a)
Вот у инстансов и должны быть какие то идентификаторы, что бы их можно было опознать из других узлов сети.
Далее, как узлы сети должны получать разделенные объекты из других узлов? Это не могут быть те же инстансы классов, что и их собственные объекты - т.е. нужно их как то отдельно именовать


Пока нет, а должен быть   


Это не так - вполне зависимая. 

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

Я это представляю через константы:

Т.е. фабрика имеет уникальный ид, контейнер имеет уникальный внутри фабрики ид и величина имеет уникальный ид внутри контейнера  - втроем они составляют уникальный ид в масштабах всей системы. Фабрика(на самом деле получается не фабрика, а хранилище - так правильнее, создает динамически контейнеры через вызов makeContainer, а контейнеры внутри себя создают величины напрямую. Потом идет работа с величинами, а их изменения обрабатываются хранилищем. Взять какое-нить бинарное дерево для этого, хранить пары ключ-значение упорядоченно - т.е. добавить еще один ключ из номера хранилища и порядкового номера пары, а пару ключ-значение использовать как значение. И чтобы синхронизироваться, нужно просто обменяться данными - для какого хранилища какая последняя пара хранится. Отсюда можно легко определить какие данные куда нужно передать и делать это можно в другом потоке. Как думаете?
код не компилил, не обессудьте 

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


А я только про динамику и думаю. Честно говоря не знаю, как это можно в компайл-тайм сделать. Расскажите подробнее, пожалуйста.


Это сообщение отредактировал(а) drug007 - 16.1.2013, 20:42

А как другие узлы узнают, какой именно 'уникальный ID' им нужен и с какого узла его брать?


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

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

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


Устроит?

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

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

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

Как-то так...

Это сообщение отредактировал(а) drug007 - 17.1.2013, 16:59

Я имел в виду не типы, а экземпляры


Согласен.

Немного по поводу кода - я бы не стал генерить классы через new. Все же С++ это не Java, в нем можно экземпляры классов делать и не на куче, даже лучше делать не на куче.
Далее, все манипуляции с контейнером и конфигурацией лучше оставить внутри фреймворка - програмисту о них знать не имеет смысла. 

Связывать переменные SharedVar[RO] можно по их строковым именам, не привязываясь ни к каким конфиг файлам, при этом все равно где именно они находятся.
В принципе SharedVar может быть сделан не только от int и string, но и от любого класса, поддерживающего стриминг (определенный набор методов)

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

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


Имеете в виду кастомный аллокатор? Или стек?

Согласен, я на черновую просто написал для примера.

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

Вы были абсолютно правы про интерфейс - я подумал как будет работать пользователь и пришел к выводу, что без персистентности не получится адекватной работы. Смысл в том, что обмен данными между узлами асинхронный (синхронность предъявит жесткие требования к аппаратной части). А значит, возможна ситуация, когда на разных узлах разные данные и решить эту проблему можно путем версий значения - т.е. если узлу нужно произвести какие-то расчеты, для расчетов нужно, например, 3 величины. Он берет их значения, находит их время обновления, выбирает величину с наименьшим, а по остальным величинам еще раз запрашивает значения, но уже с наименьшим временем и на основании этих данных производит расчет и ему присваивает это же самое время. А это означает, что нужно продумать еще алгоритм. Правда, получается, что часть проблем я все-таки выношу из фреймворка и программист уже должен будет учитывать время обновления значения величины, но думаю, это оправдано будет в данном случае, как думаете?
С эфемерными величина проще конечно было бы написать реализацию, но как тогда решить проблему рассинхронизации?


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

Это можно учесть, введя тип разделяемой переменной - массив. Тогда новых переменных в процессе работы программы появляться не будет


Я имею в виду обычные глобальные статические переменные.


Это требует наличие синхронизированного времени на всех узлах (например в виде NTP клиента), что в свою очередь требует единого сервера для задания этого самого времени.

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


Я думаю, что проблема тут сложнее, чем кажется. Что считать синхронизацией значений, если учитывать то, что эти значения вырабатываются асинхронно работающими узлами? Для того, что бы вообще говорить о 'синхронизации' в любом понимании нужно иметь точку отсчета, одинаковую на всех узлах. И узлы должны знать об этом и учитывать в своей работе. Синхронизация по времени в принципе не самая удачная методика.

Зачем вообще нужна синхронизация?

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


Да, там где динамического изменения нет - так лучше А у меня же возможно изменение числа контейнеров с разделяемыми переменными - причем это важный аспект. Тип данных, с которыми работает узел определен в компайл-тайме, а объем данных в рантайме.


Совершенно верно. Но я боюсь, что может получится такая ситуация - узел У1 изменил переменную П1, узел У2 изменил переменную П2, а узел У3 начал какие-то вычисления (запустил отчет, например) на основе переменной У1.П1 и У2.П2, но при этом от узла У1 пришло новое значение, а от У2 еще не успело - т.е. получится наполовину правильные расчеты. Можно поставить дело так, что У3 получив новое значение У2 заново выполняет отчет и тогда все становится действительно актуальным. И моя мысль сделать это как бы более явным с помощью временной метки - тогда узел У3 просто бы пометил свои расчеты меткой самых молодых данных. Но пишу и чувствую, как все усложняется резко с этими метками...    Про метки я подумал еще в связи с тем, что ряд данных в приложении должны регулярно записываться в лог с такой временной меткой - вот я и подумал про метки, но чувствую, что не то это...


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

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


С учетом того, что узлы работают асинхронно, вполне законным будет любой порядок вычислений: старое значение П1+новое значение П2, или новое значение П1+старое П2, или оба старых или оба новых. 

Например - 2 узла вырабатывают новые значения 2х переменных каждую миллисекунду, со сдвигом в 0.5ms. Когда брать 'новое' значение с обоих узлов?

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

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

я все-таки разделяю эти два момента:
SharedVar<int> sv_arr1[10];
SharedVar<int[10]> sv_arr2;
Ведь в первом случае мы можем индивидуально менять значение каждого элемента массива. А во-втором случае мы будем менять весь массив сразу. В принципе результат будет один и тот же, но первый вариант оптимален когда мы часто меняем элементы массива по одному, а второй когда меняем весь массив сразу.


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

Тут я думаю синхронизация как внутри процесса будет гиблым делом. Слишком разные среды. Я думаю, что эти вопросы надо выносить на уровень пользователя библиотеки, пусть у него голова болит. Т.о. нужно предоставить программисту возможность самостоятельно определять какие данные актуальны - т.е. если ему нужно определить актуальность данных пусть делает сам. Нужно какую-то метку ставить - пусть сам ставит. А задача фреймворка только расшаривать данные. Как думаете?