| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > C/C++: Общие вопросы > библиотекa распределенного общения |
| Автор: mes 27.2.2011, 18:52 |
| просьба эту тему не засорять, чтоб не было разрыва между фрагментами кода.. вопросы для обсуждения задавать в соседней теме: http://forum.vingrad.ru/forum/topic-323648/anchor-entry2306940/0.html тема создана как ветвь в продолжение одной сильно разросшейся темы: http://forum.vingrad.ru/forum/topic-311688.html в которой по-моему уже никто не ориентируется.. В ней обсуждались разные приемы для реализация прослойки для распределенной коммуникации. В этой теме я попытаюсь определить сущности и собрать приемы помогающие реализовать подобное.. Т.е. другими словами хочу выразить свой взгляд на проблему.. легенда используемыx ниже терминов : type - тип вызова migrant - сериализованный пакет аргументов i_invoke - интерфейс выполнения для мигранта channel - передача мигранта внутри и за границы приложения map - карта соответствий ид и инвокера mapper - передача мигранта конкретному инвокеру из ассоциированной карты.. function_cb - шаблон callback`a основаннoго на function signal_cb- шаблон callback`a основаннoго на signal и так поехали.. |
| Автор: mes 27.2.2011, 19:10 | ||||||||
| изначально коды будут приводиться с допущениями выражая только основную суть и не акцептируя внимание на мелочах.. основой распределенного общения выступает удаленный вызов.. он характеризуется двумя параметрами идентификатором, и сигнатурой... идентификатор, как предложил boostcoder, удобнее (для пользователя) использовать строковой.. чтоб связать сигнатуру и ид, заведем шаблон описывающий тип
так же нам нужна структура, которая будет переносить аргументы через границу приложения.. назовем ее мигрантом, она состоит из ид вызова и сериализованных аргументов..
при получении мигранта ,надо его выполнить.. заведем интерфейс для этого :
для начала реализуем шаблон инвокера на основе std::function, хотя стратегию можно будет выбирать любую..(например boost::signal)
|
| Автор: mes 27.2.2011, 19:28 | ||||
| для преодоления расстояния нам нужен канал, тип которого зависит от способа соединения.. для начала пусть будет
отправлять мы теперь можем., но нм нужно еще получать.. для того чтоб выбрать по имени нужный инвокер нужна карта, но
перекладывает гарантию типобезопасности на программиста.. |
| Автор: mes 27.2.2011, 20:04 | ||||
| сделаем обертку над картой, которая будет предоставлять доступ к элементам, только в соответствии с нашим типом. на скорую руку выглядит так:
Добавлено через 4 минуты и 58 секунд напишем пример по использованию :
|
| Автор: mes 27.2.2011, 20:33 | ||
| но нам также нужно обращаться к карте по id... В этом случае мы можем возвращать только общий интерфейс исполнителя (i_invoke), но для исполнения мигранта, нам будет достаточно.. тогда добавим в карту :
|
| Автор: mes 27.2.2011, 21:58 | ||||
сделаем пока условный "локальный" канал, который будет посылать мигранта сразу на выполнение
тогда пользование условно будет:
http://liveworkspace.org/code/c2d8ebdb654c780a77751350124981c2 |
| Автор: mes 27.2.2011, 22:40 | ||||||
| попробуем отделить карту от канала.. для этого напишем адаптер инвокера для карты :
также определим в канале вектор инвокеров, установку и вызов для них:
теперь код тестовый код выглядит так :
http://liveworkspace.org/code/49e6f85dff002d9787576ee504f10809 |
| Автор: mes 27.2.2011, 23:04 | ||||
| теперь попробуем облагородить вызов .. перегрузим тип для каждой сигнатуры, добавив ему оператор(), выполняющий роль конструктора :
тогда вызов будет выглядеть так :
http://liveworkspace.org/code/cc96889ac487a17f23a8103d5d5fb7a4 |
| Автор: mes 27.2.2011, 23:06 | ||
сделаем ответное для инвокера :
добавим сериалицию и в итоге работающий каркас готов: http://liveworkspace.org/code/07f972915fb8c6c2be174b5bb3e4a6b9 осталось облагораживание и исправление ошибок.. |
| Автор: mes 27.2.2011, 23:50 |
| избавился от маппера в пользу boost::signal, заодно добавил разветление для каналов: http://liveworkspace.org/code/39b7b6fd4079482bf7eeed50555a3614 добавил возможность выбора для политики инвокинга (signal, function) : http://liveworkspace.org/code/6a215a11ed054ae3eef1d636c03b2d1d также добавлен выбор политики и для канала : http://liveworkspace.org/code/184cb6d498753cfc83538549dfa54124 |
| Автор: mes 28.2.2011, 12:48 | ||||
| чтоб не нарушать ODR, типы должны быть определены в .cpp, а в хидере объвлены, что вызывает двойную работу программиста.. один из способов избежать лишней работы - это объединить группы типов в структуру:
тогда тестовый пример выглядит так :
http://liveworkspace.org/code/8ded5287fb75e4099fe0ec911ca91999 |
| Автор: mes 27.3.2011, 16:53 | ||||||||
| немного изменив подход (подробности размышлений приведены в соседней теме) продолжаем.. легенда : :: dy - общие элементы обеспечения взаимодействия :: dyco - описание конкретного протокола :: - клиентская приложение dy::proto<> - класс описывающий группу вызовов dy::proto<>::call<Args...> - вызов группирующий из аргументов пакет сообщения dy::free_fn<> - дин. интерфейс передачи сообщения как к свободной функции dy::member_fn<> - дин. интерфейс передачи сообщения, как члену классу dy::method<> - реализация вышеназванных интерфейсов dy::map<>- карта соответствий вызова к методу dy::channel - класс реализующий транспорт сообщения dyco::msg - условное сообщение dyco::msg_traits - свойства условного сообщения, необходимые для взаимодействия с dy client, service - условные обработчики сообщений пример : http://liveworkspace.org/code/2bcfd7f5fc99b7139883f65a343e569d //--------------------- :: dy описание функторов формирующих пакеты сообщения, и их группы (протокола):
динамические интерфейсы метода исполнения сообщения
реализации метода исполнения сообщения
карта соответствий типа сообщения к вызову
|
| Автор: mes 27.3.2011, 17:08 | ||||
| ::dyco описание правил формирования сообщения :
условные типы вызовов протокола
|
| Автор: mes 27.3.2011, 17:54 | ||||||||
пример сервиса
пример пользователя
инициализация условных "таблиц виртуальных функций"
пример взаимодействия :
|