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

← →
kami © (2008-06-04 23:38) [0]

Вечер добрый.
Столкнулся с такой задачей:
имеется устройство, подключенное к COM-порту и программа, получающая из него данные. Необходимо дать возможность получения этих данных как другими модулями самой программы (с чем проблем, в принципе, нет), так и другими процессами (созданы на Delphi, мной), причем их количество заранее неизвестно. Нужно только чтение, запись не предусмотрена де-юре и де-факто.
На данном этапе имею возможность организовать "распараллеливание" чтения данных при помощи установки виртуальных COM-портов, по паре на каждого "читателя". Но...это на мой взгляд неправильно.

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

← →
sniknik © (2008-06-05 00:11) [1]

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

← →
Ляпа (2008-06-05 00:14) [2]

А может, имеет смысл покопать в сторону OPC?

← →
kami © (2008-06-05 00:31) [3]

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

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

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

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

← →
kami © (2008-06-05 00:41) [4]

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

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

← →
Германн © (2008-06-05 00:56) [5]

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

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

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

← →
sniknik © (2008-06-05 01:03) [6]

> почему именно UDP? Не знаю преимуществ у него перед асинхронными TCP сокетами
да какие преимущества... просто мне кажется он более подходящий для описанной ситуации.
не нужен ответ от клиента, пусть и асинхронно (TCP это с подтверждением доставки, асинхронно это значит ожидание в другом потоке, но все одно ожидание, следующую порцию не послать)
и скажи что ты будеш на "сервере" делать с ответом "клиента"? с таймаутом например? когда уже пришли новые данные надо посылать всем, а один, первый еще занят ожиданием ответа.

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

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

← →
sniknik © (2008-06-05 01:05) [7]

> общающиеся с клиентами по TCP/IP и никаких проблем.
о проблемах я и не говорил.

← →
Германн © (2008-06-05 01:21) [8]

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

Ты их в [1] наметил. Но по-моему Коль, твои советы в данном случае (как и предположения о возможном поведении клиентов) немного более общие, нежели реальная работа с внешним нестандартным железом.

← →
kami © (2008-06-05 01:28) [9]

> sniknik © (05.06.08 01:03) [6]

> и скажи что ты будеш на "сервере" делать с ответом "клиента"?
> с таймаутом например? когда уже пришли новые данные надо
> посылать всем, а один, первый еще занят ожиданием ответа

В этом плане техника уже отработана: на каждое созданное клиентом (неблокирующее) соединение - свой экземпляр класса-обработчика со своей очередью на прием/передачу. "Сервер", приняв данные из COM-порта отдает их всем обработчикам соединений, а дальше хоть трава не расти. Занят один из клиентов - и пусть, данные спокойно подождут в очереди. Разорвалось соединение (по любой причине, в том числе и при проверке "живучести" своим же классом-обработчиком) - экземпляр уничтожается, прихватив с собой все не переданные из очереди данные.

← →
Германн © (2008-06-05 01:36) [10]

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

Нифига. Все данные пишутся в лог. И при следующем подключении выдаются клиенту.

← →
sniknik © (2008-06-05 01:55) [11]

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

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

допустим заменили callback TCP протоколом, посылаем данные им. та же проблема протокол передает не пакет, а поток данных, и ждет ответа. при передаче/ожидании следующую порцию не пошлешь даже если асинхронно (не делал, но сужу по поведению асинхронных команд в ADO)
т.е. таже (теоретическая) ситуация когда отсылка притормаживается/(невозможна ввиду "слета" клиента) а данные на входе (COM порт) не ждут... что делать?

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

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

← →
sniknik © (2008-06-05 01:59) [12]

> Все данные пишутся в лог. И при следующем подключении выдаются клиенту.
в лог? х.м. об этом я както не подумал, но вообщето я писал по такому принципу dll для 1C, по работе со сканером штрихкодов... прикидываю как бы все выглядело... после сбоя, запускают 1С-ку и она тебе в первом же окне кучеу баркодов, которые уже и не нужны и по идее только в накладной действительны. :)

← →
Германн © (2008-06-05 02:03) [13]

> sniknik © (05.06.08 01:55) [11]
>
> > нежели реальная работа с внешним нестандартным железом.
>
> реально можно долго по какойто методе и так и не встретить
> проблем...
> но разве это означает, что они невозможны?
> я гдето неправ в рассуждениях?
>

Прав безусловно! Но только в этом конкретном высказывании.

> допустим сделали все на callback-ах, т.е. клиент инициализируется,
> передает на сервер свою функцию, сервер по приему данных
> с COM порта, их все по очереди вызывает... ок.

А не надо на такой сервер передавать функцию. Достаточно передать данные для отправки в порт.

← →
sniknik © (2008-06-05 02:10) [14]

> Достаточно передать данные для отправки в порт.
ну так я это и предложил, взамен авторского callback-а...
???

← →
Германн © (2008-06-05 02:31) [15]

> sniknik © (05.06.08 02:10) [14]
>
> > Достаточно передать данные для отправки в порт.
> ну так я это и предложил, взамен авторского callback-а..
> .
> ???
>

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

Тогда ещё раз, пожалуйста, про "обязательность" UDP.

← →
Slym © (2008-06-05 07:28) [16]

я бы написал COM (Component Object Model) сервер который цепляется к COM порту (простите за тафталогию :)), а приложения уже цепляются к серверу

← →
Evgeny V © (2008-06-05 08:49) [17]

Мы решаем такие задачи в основном на TCP, и есть еще виртуальный порт для одной из задач. Тоже работает хорошо.
Пр обязательно UDP - это просто мне кажется вырвалось отчасти случайно у автора поста. Можно и UDP и TCP. Задача сервера( и клиента тоже) в случае необходимости проверять "живость" соединений при длительных перерывах между отправками данных.
При "малых" скоростях передачи (имеется в виду не скорость соединения по COM порту, а объем информации в канале) и остсутствии необходимости быстрого отклика ( или не нужен отклик от всех клиентов данных - только мониторинг) - вообще ложим данные в БД в том или ином виде (в том каком пришли или уже в представлении БД, удобном для клиентов).
А например приложения оператора уже видят и обрабатывают данные в удобном для них виде.
Вариантов много и все зависит от задачи и ее условий.

← →
sniknik © (2008-06-05 10:47) [18]

> Тогда ещё раз, пожалуйста, про "обязательность" UDP.
еще раз. > [11] 3 абзац.

> это просто мне кажется вырвалось отчасти случайно у автора поста.
не случайно, я бы и сейчас, после обсуждения обязательно делал бы на UDP. т.к. удобнее, не нужна своя очередь, не нужно обрабатывать таймауты/обрывы обязательные к обработке при TCP. что имхо, лишнее в этом случае.

> вообще ложим данные в БД в том или ином виде
это вариант как раз для "гарантированной" доставки данных клиентам. а заодно и история. сделал бы также, но база не вяжется с например с той же компонентой для 1С, о которой упоминал. для такого решения задача должна быть другой.

← →
sniknik © (2008-06-05 11:00) [19]

блин, понял в чем меня "обвиняют", в свою очередь вопрос/обвинение вы читаете все предложение или только понравившиеся фразы?...

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

← →
Evgeny V © (2008-06-05 11:27) [20]

> sniknik © (05.06.08 10:47) [18]

> для такого решения задача должна быть другой.

согласен, зависит от задачи и ее условий.

> не случайно, я бы и сейчас, после обсуждения обязательно
> делал бы на UDP

Про UDP - бродкаст или мультикаст? Это хорошо, посылаем один раз и всем. Хорошо работает на одной машине, в локальной сети, где не теряются пакеты,где есть мультикаст, если передаем группе (у нас например в разных подсетях мультикаст не ходит, разделено фаерволом). Увы такая такая сеть не везде и не всегда. И в этом случае я бы предпочел TCP ( или БД, смотря по задаче).
Правда у автора вопроса вроде все на одной машине и UDP ложится замечательно, пока на одной... Может в дальнейшем будет и в сети:-)

> допустим заменили callback TCP протоколом, посылаем данные
> им. та же проблема протокол передает не пакет, а поток данных,
> и ждет ответа. при передаче/ожидании следующую порцию не
> пошлешь даже если асинхронно (не делал, но сужу по поведению
> асинхронных команд в ADO)
> т.е. таже (теоретическая) ситуация когда отсылка притормаживается/(невозможна
> ввиду "слета" клиента) а данные на входе (COM порт) не ждут.
> .. что делать?

Клиент-то в своем потоке передает и/или асинхронно , тормозов нет для общей(основной) задачи. Отвалился один клиент - его проблема, текущие данные потеряны для него. UDP в этом случае имеет то же самое.
Я же не посылаю непосредственно из потока управления сразу сетевому клиенту, у него своя очередь, свой поток, вот туда я и ложу данные. А когда поток клиента готов передать данные, он берет из очереди.

Если данные важны и по истечении какого-либо интервала - то тогда база и история (или какое-то хранилище).

← →
Evgeny V © (2008-06-05 11:31) [21]

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

Если выкинуть слово обязательно, то и я бы возможно делал на UDP, тем более на одной машине, хотя и не уверен:-)

← →
Ega23 © (2008-06-05 11:31) [22]

Named Pipe ?

← →
sniknik © (2008-06-05 11:44) [23]

> Про UDP - бродкаст или мультикаст? Это хорошо, посылаем один раз и всем.
да как угодно, но я имел ввиду адресную посылку, каждый на свой порт, т.к.
> Хорошо работает на одной машине
речь как раз и шла про одну машину, а на ней, одной, кучу клиентов слушающих один порт организовать трудновато.

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

> Отвалился один клиент - его проблема, текущие данные потеряны для него.
в моем примере первый вариант не "отвалился", а "заснул", и в этом варианте по UDP будет очередь из посылок которая в конце концов дойдет до "сони".
> UDP в этом случае имеет то же самое.
получается что нет.

> Я же не посылаю непосредственно из потока управления сразу сетевому клиенту, у него своя очередь, свой поток, вот туда я и ложу данные.
ну, а я про что? неудобно же!
см. [11]
> что делать? самим организовывать буфер... проблема. нафиг не нужные, лишние действия.
> а посылка по UDP естественным путем сделает очередь данных. и больше делать ничего не надо.
поток твой лишний получается, очередь лишняя, куча кода лишняя, вместо простого действия целый наворот... разве это не неудобство?

← →
Anatoly Podgoretsky © (2008-06-05 11:44) [24]

> Ega23 (05.06.2008 11:31:22) [22]

С этим поосторожнее, пойдет по всем протоколам

← →
sniknik © (2008-06-05 11:45) [25]

> Если выкинуть слово обязательно
его и нет! есть словосочетание "я бы делал обязательно ...так..."

← →
Anatoly Podgoretsky © (2008-06-05 11:47) [26]

> sniknik (05.06.2008 11:44:23) [23]

> а на ней, одной, кучу клиентов слушающих один порт

Это не возможно, только одна программа может слушать один порт.

← →
sniknik © (2008-06-05 11:49) [27]

> Это не возможно, только одна программа может слушать один порт.
можно. когдато я рассматривал такую задачу, из интереса. не помню подробности, но помню что можно. правда геморрой.
но речь не об этом. это и не предполагалось сдесь использовать.

← →
Anatoly Podgoretsky © (2008-06-05 11:52) [28]

> sniknik (05.06.2008 11:49:27) [27]

Это хакерские решения.

да.

> sniknik © (05.06.08 11:45) [25]

Сорри, но словосочетание воспринялось видно как обязательная рекомендация, а был другой контекст.:-)
А что такое заснул? И почему дойдет до UDP не дойдет до TCP клиента? Тут я маленько заблудился и извиняюсь не понял идеи. Я согласен, что UDP может дать определенное преимущество при парсинге сообщений -а что собственно парсить, границы определены, есть и другие удобства...

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

> sniknik (05.06.2008 11:53:29) [29]

А я говорю про нормальные документированые. А то что возможно это и так понятно и путей несколько, только это не наш путь.

> А что такое заснул?
никогда машину надолго включенной не оставлял? когда проги к которым не обращаются уже скидываются в своп, а диск уходит в "стендбай" (или как там называется, останавливается в общем), потом подходишь чегото нажимаешь и он начинает медленно со скрипом "просыпаться"...
у меня из такого состояния удавалось проги которые "однозапускные с проверкой по мьютексу" две, три штуки запустить (даже виндовый диспетчер задач). вот, это оно.
причем бывало комп долго "прочухивался", до пары минут. TCP за это время три раза по таймауту отвалится, а UDP пакет просто подвиснет в недрах системы вместе с ней... в итоге "гарантированная" доставка в TCP сыграет злую шутку не доставкой пакета..., т.к. ты ее сам при таймауте прервешь (следующий же надо посылать), или если ты предусмотрел эту ситуацию то усложненной обработкой ошибки, и перепосылкой потом.

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

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

> sniknik © (05.06.08 13:17) [32]

Машина у меня просто не выключается месяцами, ночью на ней может никто не работает (на некоторых работают 24*7), но много активных задач и сервисов.
В такой "стендбай" машина и диск у меня не попадали, просто не случалось, да и у нас на "рабочих лошадках" спящий режим просто не включен (на некоторых монитор может выключаться)

Программы крутятся и обращение есть постоянно. COM порт что-то принимает, даже если есть пауза, то сокеты по 10 секундному тайм-ауту отсутствия данных (активности), шлют проверочные сообщения, для того что бы знать, что соединение не умерло, а потому доставка есть или ее нет. Данные с порта получаю по разному, чаще всего пакетом и тут есть момент, что и отправлять лучше пакетом и на получении лучше собирать в пакет (ИМХО), хотя для ретранслятора это и не есть обязательное условие ибо пакет или последовательность пакетов тоже можно представить потоком. Да и поток собрать - я посылаю пакеты через send сокета, что для UDP, что для TCP.(ну для UDP бывает SendTo). Кстати для TCP в этом случае, может быть полезен алгоритм Nagle - но это опять надо смотреть по задаче.

Вот про подвисание пакетов на приеме в стандбае я честно говоря опять не понял, куда делись пакеты , почему они подвисли, даже если диск остановился (уснул). Я что-то не знаю видно. Мне так казалось, что если задача активна, регулярно что-то шлет (в моем случае не реже раз в 10 сек), а реально чаще, то вроде такой ситуации возникнуть не должно.. Но честно говоря про стандбай я не могу ничего сказать - не знаю.
Я так понимаю, что в таком случае надо запрещать диску уходить спячку. В любом случае это не есть рабочий режим, если такое происходит, то и UDP не гарантирует правильной доставки. А то, что TCP может в этом случае потерять связь я считаю даже за плюс, есть повод помигать оператору красной лампочкой на экране, мол поставщик данных отвалился и попытаться реанимировать соединения. В данном случае считаю это плюсом для TCP:-) (а вот то, что границы сообщения четко определены - это плюс к UDP) :-)

> TCP это потоковые данные, протокол сделан кстати на основе
> UDP,

TCP выполняет установку "сеанса" UDP нет, UDP может игнорировать CRC, TCP нет. А потоки то тут причём ?

Evgeny V © (05.06.08 14:29) [33]
> просто не случалось
т.е. ты пишешь под "частный случай", у тебя чегото нет, ты считаеш что этого нет вообще.

> в моем случае не реже раз в 10 сек
смотрим вопрос. нет такого условия. разве невозможно предположить, что и посылки неравномерные и стендвай не отключен?

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

tesseract © (05.06.08 14:55) [34]
> А потоки то тут причём ?
не причем. читай все, не выдирай из контекста... (tread <> stream)

p.s. нафиг. надоело. воистину чем больше объяснений тем тем больше простора буквоедам... читать местами и докапываться. а не понимать смысл.

> sniknik © (05.06.08 15:29) [35]

> т.е. ты пишешь под "частный случай", у тебя чегото нет,
> ты считаеш что этого нет вообще.

Я такого не говорил, что такого нет вообще, и даже не высказывал сомнения, правда их имею, ибо не знаю. Но это решается опытным путем:-)
Я конечно знаю, что компьютер выключают, но код для такого общего случая, который работал бы на выключенном компе я еще писать не умею:-) (шутка)
Если есть опыт, поделись - это серьезно, если есть что сказать - напиши статью для сайта, почитаю с интересом, да и сайту будет полезно и людям. Тема -работа с сетью, с БД (или что-то еще) в спящем.ждущем режиме компьютера. Или просто разработка приложений с учетом .... и т.п.

> смотрим вопрос. нет такого условия. разве невозможно предположить,
>
> что и посылки неравномерные и стендвай не отключен?

Условия нет, это просто своего рода Keep Alive на уровне приложения - вещь весьма полезная надо сказать. Если данные к тебе приходят и ты посылаешь свои данные успешно, то проверять связь необходимости нет, а если возникла пауза - то рекомендуется периодически через какое-то время это делать.

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

Ок - в этом случае это проблема клиента и его прикладного уровня. Я вообще делаю посылку keep alive в своем классе сокета cкорее для транспортного уровня - что бы получить ошибку SOCKET_ERROR или не получить ее, а прикладной уровень и кривой клиент проткол проверяется уже на уровне протокола между клиентом и сервером. Это ошибка другого уровня, хотя в частном случае восстановление нормального общения между сервером и клиентом на какой-то срок возможна разрывом соединения. От кривого клиента UDP тоже не спасет. плюс и минус ни тому ни тому протоколу не идет в этом случае:-)

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

> От кривого клиента UDP тоже не спасет.
как раз таки спасет, т.к. нет взаимодействия с клиентом (ожидания ответа), сервер "выплюнул" пакет, хоть в кривой, хоть в нил хоть в бездну, и забыл про него тутже. работа не нарушится.

> плюс и минус ни тому ни тому протоколу не идет в этом случае:-)
ну вот теперь тема оказывается UDP vs TCP
хотя изначально я объяснял (пытался) почему я бы сделал именно так. не более.

Спасибо всем за обсуждение.

> Германн © (05.06.08 01:36) [10]
> Нифига. Все данные пишутся в лог. И при следующем подключении
> выдаются клиенту.

Нифига :) Нет необходимости, данные утрачивают свою актуальность через 1-3 секунды после получения их из порта.

> sniknik © (05.06.08 01:55) [11]
> аварийная ситуация - к клиентам долго не обращались, они
> все ушли в спячку

Так же невозможно - после инициализации устройства пакетные данные идут постоянно 4 раза в секунду, размером по 50-100 байт и так и будет продолжаться до выключения устройства, а с ним и всех обрабатывающих программ (да, этого не было в [0], но изначально я искал общее решение, которое можно будет применить не только в этой задаче. Но, для общего решения - абсолютно верно, нужно будет это предусматривать).

> Evgeny V © (05.06.08 11:27) [20]
> Про UDP - бродкаст или мультикаст? Это хорошо, посылаем
> один раз и всем. Хорошо работает на одной машине, в локальной
> сети

Локальная сеть не предусматривается - все на одной машине. Хотя, тут я уже противоречу себе - по поводу "общего" решения.

> sniknik © (05.06.08 11:44) [23]
> речь как раз и шла про одну машину, а на ней, одной, кучу
> клиентов слушающих один порт организовать трудновато.

Кстати, да - из того, что мне доступно - передавать по UDP могут только TXXXUDPClient. Соответственно, у каждого модуля, которому нужны эти данные, должен быть TXXXUDPServer. А на одной машине... я смогу это сделать только по количеству сетевых интерфейсов, привязав каждый UDPServer к одному из них. А в общем случае - количество нуждающихся в данных неограничено. В дополнение - как Com-port_модуль узнает, что ему нужно создать(али уничтожить) TUDPтраляля, чтобы отдавать данные какому либо модулю? С TCP делаем проще (imho, просто я больше всего работал с TServer|ClientSocket) - у модуля, работающего с COM-портом ставим TXXXServerSocket, а остальные, которым нужны данные подключаются с помощью TXXXClientSocket. Нужно - подключился, не стало нужно - отключился. В дополнение можно привязать TServerSocket к 127.0.0.1, чтобы никакая бяка не подцепилась. Где я ошибаюсь?

Вопрос действительно не стоит в обязательности/необязательности какого-либо протокола(тьфу, и я туда же :) ), выбор уже сделан - сокеты, как общее решение для меж... в общем, взаимодействия. Осталось только выяснить - какие. С UDP действительно - гораздо проще обрабатывать, так как данные приходят пакетами(меньше кода - меньше вероятность ошибок и т.д), в TCP это дополнительная обработка. Но - см. предыдущий абзац про "состыковку" UDP клиентов/серверов.

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

> sniknik © (05.06.08 16:08) [37]

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

Извини, если речь о кривом клиенте, то по TCP я плюнул пакет и тоже забыл о нем. Не клиент дает ACK на пакет, а система...

> ага, и говорить ты это надо авторам нормальных клиентов

Кстати у меня работа сервера из-за кривого сервера ну никак не нарушается. Проблемы кривого клиента его проблемами и остаются.

> ну вот теперь тема оказывается UDP vs TCP
> хотя изначально я объяснял (пытался) почему я бы сделал
> именно так. не более.

А я не против UDP или TCP/ Я просто изначально не понял аргумент о спящем клиенте... и TCP В связи с чем прошу все таки уточнить, так как я не не знаю работы машины в спящем или ждущем режиме...

Вопросы по спящему режиму:

1)
Ты утверждаешь, что UDP пакет в спящем режиме будет принят системой и потом из ее "недр" передан клиентскому приложению?

2) Могу ли я понять твои слова о TCP для спящего клиента так, что возможно пакет будет принят системой, но ACK на него не будет сформирован или будет сформирован с такой задержкой что на сервере возникнет ошибка тайм-аута?
3) И еще, если ты это пробовал - а как ведет себя прием данных напрямую из COM порта на "спящем клиенте", есть ли потери данных в этом случае?

И вопрос по сети:
Ты писал, что сделал в свое время прием на одной машине UDP пакетов по одному адресу и по одному порту. как? Если из разряда снифферов -ioctlsocket ( sock , SIO_RCVALL... - то вопрос отпадает.

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