Есть у меня непростой вопрос архитектурного характера, никак не могу выбрать оптимальное решение.

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

Для этих модулей нужно предоставить универсальный транспорт. Пока устройства могут висеть или на RS-232 (COM) интерфейсе, или на IP (UDP). Транспорт знает соответствие собственного адреса устройства и того интерфейса и адреса, по которому находится устройство. Пример:

Модуль по работе с устройством ZZZ посылает такой пакет через транспорт: $AE 00 B5 C4
Причем первый байт говорит об адресе устройства, то есть адрес устройства: 174. Транспорт зная адрес устройства 174, выясняет что оно находится допустим на интерфейсе COM2 - и посылает пакет туда. А например устройство с адресом 125 может находится по IP адресу 192.54.112.3:34900 - и тогда пакет будет послан по IP-протоколу.

В чем же сложности?

1) пакеты надо не только посылать, но и принимать! То есть, транспорт принимает пакет: $00 AE C6 FF, здесь второй байт является адресои отправителя. Транспорт зная от кого пришел пакет (устройство с номером A4 = 174) - передает этот пакет соответствующему модулю, которое занимается общением с этим устройством

2) модули по работе с разными устройствами понятия не имеют друг о друге. Они только сообщают транспорту, пакеты от каких устройств пересылать им.

А самая главная проблема - что приходится смешивать убогий COM-интерфейс и куда более продвинутый UDP.

С UDP работа примитивна - данные гоняются туда обратно без всяких проблем. Модуль приказал отправить данные - транспорт отправил по нужному адресу. Данные приходят - транспорт пересылает их нужному модулю.

С COM-интерфейсом все значительно сложнее, поскольку передача полудуплексная (поскольку на одном RS-232 проводе могут сидеть несколько устройств). То есть, нельзя впрямую отправлять пакеты устройствам, сформированные разными модулями. Ибо сначала нужно отправить один пакет, потом тишина в определенное количество миллисекунд (например, 50) на ожидание ответа. Если ответ получен - передача ответа модулю, если не получен - значит пакет считается потерянным. Только после этого можно передавать другой пакет от другого модуля (или от этого же, в общем следующая отправка данных). Но сами то модули понятия не имеют можно передавать данные сейчас или нет...

Я вижу два варианта пока:

1) разрешить модулям передавать данные всегда. В случае с UDP эти данные всегда уйдут, в случае с COM - модуль может получить отлуп на передачу данных, если в буфере отправки еще есть данные или не прошло время ожидания ответа на предыдущую отправку данных.

Этот подход мне не нравится тем, что непонятно что в результате получится. Например, один из модулей решил отправить данные на устройство. Отправил их в транспорт, получит отказ в передаче... Что дальше ему делать? Ждать? Сколько? Ну допустим, 10 мс, через этот промежуток он повторяет отправку данных... Но ведь модулей много, при большой загруженности, получится хаос, какой-то модуль вообще не сможет достучаться до своего устройства долгое время, а какой-то постоянно будет отправлять данные (попадать в свободные дырки при передаче данных)... Не устраивает какая-то непредсказуемость работы.

2) модули регистрируются у транспорта не только на получение данных от какого-то устройства, но и на передачу данных! После регистрации транспорт постепенно выделяет по списку очередь на передачу данных, вызывая соответствующие методы зарегистрированные.

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

Понимаю, что путанно, задавайте вопросы!

> А самая главная проблема - что приходится смешивать убогий
> COM-интерфейс и куда более продвинутый UDP.

Подключи свои устройства к преобразователям RS232<>Ethernet и избавься от COM портов. Все сведи к UDP/TCP.

Я вообще для подобного взял программируемые контроллеры Moxa, к которым подключается различное оборудование через RS232/RS485 и т.д., написал прошивку для них на Си и унифицировал обмен данными с такими девайсами под один набор команд. Все стало сетевым.

DVM ©   (25.04.08 17:16) [1]
Подключи свои устройства к преобразователям RS232<>Ethernet

1) дорого стоят

2) во многих местах уже проложены магистрали на COM-проводе

> 1) дорого стоят

100$ может и дорого, но оно того стоит. Получаем масштабируемое решение, которым можно хоть через Интернет управлять.

DVM ©   (25.04.08 17:21) [4]
100$ может и дорого, но оно того стоит

стоит ли оно того не я определяю. Например, одно из подключаемых устройств стоит $50. Соответственно, к нему переходник за $100 - это как-то круто. И еще плюс перетягивать провод с COM на Ethernet - некошерно, клиенты нас проклянут.

> 100$ может и дорого, но оно того стоит.


По полтосу покупали оптом.


>  $AE 00 B5 C4


Масса-К что ли ?


> С COM-интерфейсом все значительно сложнее, поскольку передача
> полудуплексная


Это ты прифиздываешь. Полудуплекс намного проще в реализации. И не COM-интерфейс а RS-232C.

ЗЫ : Много умных слов. Такое ощущение, что кроме них ты в задаче не разбираешься.

tesseract ©   (25.04.08 20:54) [6]
Масса-К что ли ?

не знаю что такое Масса-К. Видимо, нет. Я привел для примера, протокол сложнее на самом деле.

tesseract ©   (25.04.08 20:54) [6]
Это ты прифиздываешь

сразу видно - авторитет

tesseract ©   (25.04.08 20:54) [6]
Полудуплекс намного проще в реализации

ты вообще пост сначала от начала до конца прочитай, а потом уже высказывай свое имхо, ок?

tesseract ©   (25.04.08 20:54) [6]
И не COM-интерфейс а RS-232C

это ты понтанулся шоле? Как будто не понял о чем речь идет?

tesseract ©   (25.04.08 20:54) [6]
Много умных слов. Такое ощущение, что кроме них ты в задаче не разбираешься

такое ощущение, что пользы от тебя ровно ноль. Пришел, обосрал, ушел. Кому это нужно? Я в ответ только тебя обосру и все.

Можешь и хочешь помочь - помоги, только сначала вникни в пост, пожалуйста. не можешь или не хочешь помогать - пройди мимо ради бога.

> Пробегал2...   (25.04.08 21:46) [7]


Ну грызи сам.


> это ты понтанулся шоле? Как будто не понял о чем речь идет?


Я написал много COM-интерфейсов для  RS-232.