Универсальная COM / UDP передача

← →
Пробегал2... (2008-04-25 17:10) [0]

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

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

Для этих модулей нужно предоставить универсальный транспорт. Пока устройства могут висеть или на 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-протоколе, а там такая регистрация излишняя, данные можно посылать в любое время...

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

← →
DVM © (2008-04-25 17:16) [1]

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

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

← →
DVM © (2008-04-25 17:19) [2]

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

← →
Пробегал2... (2008-04-25 17:20) [3]

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

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

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

← →
DVM © (2008-04-25 17:21) [4]

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

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

← →
Пробегал2... (2008-04-25 17:24) [5]

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

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

← →
tesseract © (2008-04-25 20:54) [6]

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

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

> $AE 00 B5 C4

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

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

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

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

← →
Пробегал2... (2008-04-25 21:46) [7]

Удалено модератором

← →
tesseract © (2008-04-25 21:48) [8]

Удалено модератором

← →
Пробегал2... (2008-04-25 22:33) [9]

Удалено модератором

← →
tesseract © (2008-04-25 22:39) [10]

Удалено модератором

← →
Пробегал2... (2008-04-25 23:42) [11]

Удалено модератором
Примечание: Последнее китайское предупреждение, не надо оффтопика

← →
jack128 © (2008-04-26 00:07) [12]

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

если же из разных потоков, то ком-портовый траспорт должен делать так, чтобы вызывающий поток подвешивался, пока с транспортом другой поток работает(ну так SendData, Sleep(50), ReadData вызываются). а потом уже начинал передавать данные вызвающего потока.

← →
Германн © (2008-04-26 00:59) [13]

> Пробегал2... (25.04.08 17:24) [5]
>
> DVM © (25.04.08 17:21) [4]
> 100$ может и дорого, но оно того стоит
>
> стоит ли оно того не я определяю. Например, одно из подключаемых
> устройств стоит $50. Соответственно, к нему переходник за
> $100 - это как-то круто.

Хм. А ты собственно кто? Разработчик или "программист" ака Желтый Земляной Червяк? Кто же покупает переходники на рынке? Нормальные фирмы находят поставщиков или сами изготовляют такие переходники. Тем более что там и разрабатывать ничего особо и не нужно. Готовые микросхемы уже давно есть в продаже.

> И еще плюс перетягивать провод
> с COM на Ethernet - некошерно, клиенты нас проклянут.
>

Ни разу за последний десяток лет не видел ни одной конторы, в которой не было бы локальной сети. Так зачем тянуть дополнительно ещё одну?

← →
Германн © (2008-04-26 01:01) [14]

Точнее "Нормальные фирмы находят изготовителей".

← →
Anatoly Podgoretsky © (2008-04-26 01:05) [15]

> () []

Ты что переключился на tesseract или расширяешь зону обслуживания?

← →
Пробегал2... (2008-04-26 02:48) [16]

jack128 © (26.04.08 0:07) [12]
хм. Многопоточная работа то??

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

jack128 © (26.04.08 0:07) [12]
если же из разных потоков, то ком-портовый траспорт должен делать так, чтобы вызывающий поток подвешивался, пока с транспортом другой поток работает

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

Германн © (26.04.08 0:59) [13]
Хм. А ты собственно кто?

да нуб полный, кто ж еще

Германн © (26.04.08 0:59) [13]
Разработчик или "программист" ака Желтый Земляной Червяк? Кто же покупает переходники на рынке? Нормальные фирмы находят поставщиков или сами изготовляют такие переходники

я не знаю кто что там разрабатывает. Наша фирма переходники не разрабатывает и заниматься этим не намерена, а покупать невыгодно.

Германн © (26.04.08 0:59) [13]
Ни разу за последний десяток лет не видел ни одной конторы, в которой не было бы локальной сети. Так зачем тянуть дополнительно ещё одну?

очень многие клиенты не допускают постороннее ПО в свою локальную сеть. Это не моя прихоть. Это первое.

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

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

Германн © (26.04.08 1:01) [14]
Точнее "Нормальные фирмы находят изготовителей".

ну то что моя фирма ненормальная - это и так понятно. Но решению проблемы это не способствует.

Anatoly Podgoretsky © (26.04.08 1:05) [15]
Ты что переключился на tesseract или расширяешь зону обслуживания?

я к сожалению сужу не по нику, а по деяниям.

> пока с транспортом другой поток работает(ну так SendData,
> Sleep(50), ReadData вызываются). а потом уже начинал передавать
> данные вызвающего потока.

На самом деле проще всего очередь ставить.
Один поток чисто разруливает приём - второй передачу. Саму очередь потокобезопасную слиз с Бакнела.
Но, если там не просто тупая запись / считывание, а реально надо общаться с устройством в синхроне - то там нужно уже через переменные состояния передач курить. Делал такое + TCP/IP для кучи весов.

В итоге плюнул - разруливать очень тяжело, и сделал класс чисто изолированного потока, который всё разруливает с девайсом , и отсылает состояние в основной. Другой поток уже обрабатывал запросы по UDP от клиента и брал с основного потока данные, всё строилось на секциях, от TEvent / сообщений отказался.

← →
Пробегал2... (2008-04-27 12:48) [18]

Удалено модератором

> проблема в этом подходе в том, что пока поток висит на передаче
> данных - в это время ему могут придти данные (для этого
> модуля), и он не сможет их обработать, поскольку его поток
> висит на передаче.

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

← →
Пробегал2... (2008-04-28 00:25) [20]

jack128 © (27.04.08 21:31) [19]

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

← →
jack128_ (2008-04-28 09:28) [21]

> Просто там синхронизация потоков у каждого модуля... хитрая.
> ..

ну... сделай так, чтоб она была не хитрой ;-)

Универсальная COM / UDP передача Найти похожие ветки