Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Как организовать одновременное чтение из COM-порта

Страницы: < 1 2 3 4
kami © (2008-06-04 23:38:00)
Вечер добрый.
Столкнулся с такой задачей:
имеется устройство, подключенное к COM-порту и программа, получающая из него данные. Необходимо дать возможность получения этих данных как другими модулями самой программы (с чем проблем, в принципе, нет), так и другими процессами (созданы на Delphi, мной), причем их количество заранее неизвестно. Нужно только чтение, запись не предусмотрена де-юре и де-факто.
На данном этапе имею возможность организовать "распараллеливание" чтения данных при помощи установки виртуальных COM-портов, по паре на каждого "читателя". Но...это на мой взгляд неправильно.

В идеале хотелось бы видеть такую картину : 1 модуль работает непосредственно с портом, а остальные модули/процессы регистрируют в этом модуле callback-функции и "забывают" о необходимости каких-то там настроек портов и тому подобном.
Подскажите пожалуйста, правильно ли мне видится "идеал", и как такое лучше/правильнее сделать.

sniknik (2008-06-05 01:05:00) [61]
> общающиеся с клиентами по TCP/IP и никаких проблем.
о проблемах я и не говорил.

sniknik (2008-06-05 01:03:00) [62]
> почему именно UDP? Не знаю преимуществ у него перед асинхронными TCP сокетами
да какие преимущества... просто мне кажется он более подходящий для описанной ситуации.
не нужен ответ от клиента, пусть и асинхронно (TCP это с подтверждением доставки, асинхронно это значит ожидание в другом потоке, но все одно ожидание, следующую порцию не послать)
и скажи что ты будеш на "сервере" делать с ответом "клиента"? с таймаутом например? когда уже пришли новые данные надо посылать всем, а один, первый еще занят ожиданием ответа.

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

> 2. (в принципе, перекликается с 1) - как узнать о корректном/некорректном завершении процесса, запросившего данные?
корректном, так же как инициализацию сделаешь только действия наоборот - "разинициализацию". некорректном... ну, можно мьютекс созданный в клиенте при инициализации передавать и время от времени проверять их существование. за мьютексами система следит, убьет даже при "слете" клиента.

Германн (2008-06-05 00:56:00) [63]

> sniknik © (05.06.08 00:11) [1]

> имхо нормально. только я бы "callback-функции" заменил чем
> нибудь типа сообщений/посылке по сокету (обязательно по
> UDP протоколу).
> для гарантии чтобы клиент в callback-е не передал бесконечного
> цикла и не остановил всего процесса.

Согласен, но тоже не понимаю "обязательности" UDP. Сколько лет пишем "транспортные серверы" работающие с внешним железом и общающиеся с клиентами по TCP/IP и никаких проблем.

kami (2008-06-05 00:41:00) [64]
> Ляпа (05.06.08 00:14) [2]
> А может, имеет смысл покопать в сторону OPC?

Интересно, сейчас почитаю, что это такое и можно ли его съесть на ужин безболезненно (как в случае с сокетами) :) Спасибо

kami (2008-06-05 00:31:00) [65]
> sniknik © (05.06.08 00:11) [1]

То есть, все-таки сокеты.
Очень хорошо - тема весьма знакомая и с кучей наработок, тем более, что будет задействован только loopback-интерфейс, что несказанно быстро (afaik).
Тогда следующий вопрос - почему именно UDP? Не знаю преимуществ у него перед асинхронными TCP сокетами (на локальном компьютере, естественно; нужна гарантированная доставка, но внутри 1 компьютера UDP вроде не теряются). И сразу (если преимущества есть) -
1. все равно модуль, работающий с COM-портом нужно уведомлять о необходимости создания UDP клиента
2. (в принципе, перекликается с 1) - как узнать о корректном/некорректном завершении процесса, запросившего данные?

Сразу спасибо за
> если клиент "отвалится" неожиданно

как-то об этом раньше думалось только при работе с "удаленными" клиентами :)

Ляпа (2008-06-05 00:14:00) [66]
А может, имеет смысл покопать в сторону OPC?

sniknik (2008-06-05 00:11:00) [67]
> правильно ли мне видится "идеал"
имхо нормально. только я бы "callback-функции" заменил чем нибудь типа сообщений/посылке по сокету (обязательно по UDP протоколу).
для гарантии чтобы клиент в callback-е не передал бесконечного цикла и не остановил всего процесса. и потом если клиент "отвалится" неожиданно, и не сделает "разрегистрацию", то и с этом случае посылка сообщения без ожидания ответа не займет много времени.

Страницы: < 1 2 3 4

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »