Помогите разобраться с архитектурой

[PSD]

Есть задание на разработку сервера опроса приборов.
Приборы имеют интерфейсы   RS232/RS422/RS485.
Физически связь будет осуществляется через Ethernet при помощи  устройств  типа Nport 5230, DE-311 и им подобных, соответственно на  принимающей стороне мы имеем дело либо с виртуальным СОМ  портом, либо с портом TCP/IP (или UDP).

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

Для себя  я вы вырисовал следующую структуру,

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

Как это сделать не прибегая к архитектуре COM/DCOM я при мерно себе представляю.

Вопрос как это переложить на технологию COM/DCOM. Привествуются отвес с конкретным указанием как реализовывать компоненты.

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

[Dimka]

Могу описать архитектуру реальной системы для проведения техосмотра автомобиля: несколько машин (компьютеров), на каждую машину (хост) через плату расширения до 8 COM-портов с приборами, на каждом порту может висеть несколько приборов.

Перво-наперво был создан протокол, по которому приборы обмениваются информацией с хостом. Каждый прибор имел уникальный идентификатор, имеющий часть "тип прибора", и часть "номер прибора" - по аналогии с MAC-адресами сетевых карт, только вместо вендора тип. Хост тоже имел уникальный идентификатор. Обмен данным осуществлялся в виде передачи пакетов данных, описанных в протоколе. Каждый пакет имел адрес получателя. Далее было соглашение, что прибор лишь откликается на запрос хоста, но сам "голос не подаёт" - некоторая аналогия с сетями с передачей маркера. Хост периодически рассылал пакеты прибора, а каждый прибор по адресу определял "свой" пакет и откликался на него. Пакеты помимо адреса содержали команды и данные для работы с приборами, причём для каждого типа прибора был свой набор команд и свой формат данных.

В приборах были соответствующие прошивки контроллеров, на хосте система из COM-объектов, которая всем делом управляла.

Теперь про хост.

На конце каждого канала со стороны хоста висел один объект, который можно назвать диспетчером канала. Задача у него была маленькая: открывать и закрывать каналы, настраивать их, буферизировать и передавать данные, контролировать связь (повторно передавать пакеты в случае ошибок чётности и т.п.). Это канальный уровень.

Над диспетчером канала висел объект, управляющий протоколом: он знал так сказать "ядро" протокола - имел средства преобразования запросов в пакеты (последовательности байтов) и, наоборот, средства преобразования пакетов в ответы - осуществлял сериализацию. Запросы и ответы являлись структурами данных, содержащими адреса приборов и данные - пока ещё последовательности байтов.

Над управляющим протоколом объектом висел диспетчер устройств. Диспетчер конфигурировался на хосте - т.е. ему сообщалось, какие приборы подключены к каналу. PnP не было. Задачами диспетчера устройств являлось: а) периодический опрос устройств - поддержание связи с устройствами (согласно протоколу), б) сортировка принимаемых ответов по устройствам. По адресу ответа определялось  устройство, и данные пакета передавались на более высокий уровень (см. ниже).

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

Ну и наверху находился объект - контроллер прибора, который обеспечивал API конкретного прибора. К контроллеру (находящемуся на логическом уровне) подключались объекты, создающие всякие настроечные диалоги и окошки мониторинга работы (уровень представления) и объекты, обеспечивающие протоколирование работы в БД (уровень данных), а также прочие объекты логического уровня, инициирующие сеансы работы с устройствами и обрабатывающие полученные результаты.

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

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

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

[PSD]

Все таки СОМ объекты в качестве диспечера канала?
А фабрика объектов была или они создавались в "ручную" диспечером устройств?

У меня проблема, компортов у меня не 8 реальных а теоретически 256 виртуальных (практически я так думаю будет штук по 20-30 на хосте )

Посему была идея реализовать фабрику СОМ объектов которая будет создавать каждый канальный диспетчер в отдельном потоке и транслировать ему команды предварително разрешая адрес и создавая канальный диспечер вы том случае если его еще нет и уничтожая в случае долгого простоя....

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

 

[Dimka]

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

В мною описанной системе не было объектов, подгружаемых "на лету", да и скорости были 9600 бод, поэтому использование COM-объектов "тяжёлым" не было - они один раз загружались при запуске приложения и перегружались при переконфигурации каналов, а в остальное время работы висели в "горячем" состоянии. В случае PnP устройств и автоматической смены конфигурации нужно разбираться отдельно, соотнося возможности машины и скорость обмена данными. Возможно будет целесообразно всё держать на готове в загруженном виде, так как загрузка COM-объектов есть тяжёлая операция - держать DCOM сервер, обеспечивающий API всех устройств, к которому возможно подключение разных программ, в том числе удалённых, но вот сколько это ресурсов хоста займёт... Т.е. система на COM-объектах хорошо работает в постоянных режимах, но плохо при частой и резкой смене режимов, влекущих загрузки и выгрузки объектов.

[PSD]

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

Как пример  лежали DLL  на шаре

регились
regSVR32 /c/s "\\server\shara\name.dll"
Реально они лежали
\\server\e$\papka\shara\name.dll
Перемещаем их в 
\\server\e$\shara\name.dll
 и расшариваем  оттуда подтемже имнем
получаем тотже путь
\\server\shara\name.dll

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

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