Как организовать одновременное чтение из 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 © (2008-06-05 11:53) [29]

да.

← →
Evgeny V © (2008-06-05 12:37) [30]

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

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

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

← →
Anatoly Podgoretsky © (2008-06-05 12:53) [31]

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

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

← →
sniknik © (2008-06-05 13:17) [32]

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

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

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

← →
Evgeny V © (2008-06-05 14:29) [33]

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

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

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

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

← →
tesseract © (2008-06-05 14:55) [34]

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

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

← →
sniknik © (2008-06-05 15:29) [35]

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

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

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

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

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

← →
Evgeny V © (2008-06-05 15:47) [36]

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

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

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

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

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

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

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

← →
sniknik © (2008-06-05 16:08) [37]

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

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

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

← →
kami © (2008-06-05 19:09) [38]

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

> Германн © (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 клиентов/серверов.

← →
sniknik © (2008-06-05 19:38) [39]

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

← →
Evgeny V © (2008-06-06 06:33) [40]

> 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... - то вопрос отпадает.

← →
sniknik © (2008-06-06 10:55) [41]

> то по TCP я плюнул пакет и тоже забыл о нем.
поздравляю, молодец, сделал иp TCP UDP, читай sniknik © (05.06.08 13:17) [32] почему я это считаю идиотизмом (тогда сказал мягче, но теперь...)

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

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

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

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

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

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

← →
Evgeny V © (2008-06-06 11:23) [42]

> sniknik © (06.06.08 10:55) [41]

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

Ты как-то в штыки воспринял вопросы. Там в конце предложений стоял знак вопроса - во такой ?

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

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

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

> не надо приписывать мне то что я не говорил, я писал что

да согласен - ты не писал, что сделал, ты писал, что рассматривал - извини, мне просто показалось, что делал...

> поздравляю, молодец, сделал иp TCP UDP, читай sniknik ©
> (05.06.08 13:17) [32] почему я это считаю идиотизмом (тогда
> сказал мягче, но теперь...)

Я вижу ты не владеешь темой, а потому объяснять, что ошибки при работе с TCP возвращаются в виде кодов возрата фукнций, и ждать на каждый пакет подтверждения от клиента нет необходимолсти ( опять таки зависит от задачи) видимо проблематично, так же у меня возникло сомнение и в том что ты знаешь о тайм-ауте - это я про

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

Мне очень интересно было услышать о TCP переделанном в UDP - это словосочетание можно назвать абракадаброй....

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

Оставлю многоточия, в надежде, что модераторы не удалят:-)

← →
Anatoly Podgoretsky © (2008-06-06 11:54) [43]

> Evgeny V (06.06.2008 11:23:42) [42]

> Я вижу ты не владеешь темой, а потому объяснять, что ошибки при работе с TCP возвращаются в виде кодов возрата фукнций, и ждать на каждый пакет подтверждения от клиента нет необходимолсти ( опять таки зависит от задачи) видимо проблематично, так же у меня возникло сомнение и в том что ты знаешь о тайм-ауте - это я про

Мне кажется, что это ты не владеешь темой, если это код возврата функции, то ты будешь ждать и даже отказаться не сможешь.

← →
Evgeny V © (2008-06-06 12:12) [44]

> Anatoly Podgoretsky © (06.06.08 11:54) [43]

Анатолий, чего ждать - с блокирующим сокетом буду ждать ошибки SOCKET_ERROR, которая может прийти сразу или в течении определенного тайм-аута. При неблокирующем и аснхронном сокете она вернется позже. Но даже если я работаю с блокирующим сокетом, я работаю с ним в отдельном потоке на сервере и ждет этот поток, на работу с другими клиентами это не скажется.
Если вы восприняли мои слова, как-то, что TCP не ждет подтверждения от клиента, то вы просто не внимательно прочитали ветку, а взяли один пост. Разговор шел о том, что работа с одним слиентом не блокирует работу с другими клиентами по TCP, каждый из них работает со своим сокетом. Впрочем вы то это знаете.
Насчет не смогу отказаться - под виндами отказываюсь - закрывая сокет в другом потоке (для блокирующего сокета) и можно в этом же для неблокирующего.

← →
sniknik © (2008-06-06 12:35) [45]

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

при этом (опять дежавю) если второй протокол использовать по назначению с ответами то с ними придется чтото делать... т.е. лишний код, лишние действия, дополнительная обработка для времени ожидания т.к. в этот период нельзя послать следующий пакет. и т.д. т.е. дополнительный геморрой. ради чего все? про дополнительные факторы, которые вынудят делать именно так, ничего не сказано (а после даже было подтверждение, что их и нет -> [38]).

p.s. наверное достал уже всех повторами... сорри, не смог удержаться.

← →
Slym © (2008-06-06 12:45) [46]

Вообщето IP предназначен для меж "компового" взаимодействия впервую очередь...
для локального решения в первую очередь нужно применять локальные решения такие как OPC, Messages тп и тд, и их высокоуровневые реализации DDE, OLE тп и тд

← →
Evgeny V © (2008-06-06 13:08) [47]

> sniknik © (06.06.08 12:35) [45]

Подтверждение о приеме пакета по TCP формируется ситемой независимо от клиента, для этого ему даже не обязательно вызвать recv. Подтверждение о расшифровке пакета, о работе с протоколом уровня приложения -это уже дело клиента, но оно не всегда нужно или не на каждый пакет. Это зависит от задачи. В случае рестрансляции байтов от СOM порта, от программы-сервера не требуется играть роль клиента приложения или устройства подключенного к порту и являющегося источником данных. Это транспорт, считай виртуальный виртуальный COM порт своего рода. Если клиент должен послать какое-либо подтверждение программе идли COM порту это дело клиента. Если мы только читаем данные - то клиент только принимает и ничего не посылает и сам ничего не подтверждает. АСК по TCP клиентское приложение не делает, это делается мимо него. Для приложения сервера в этом случае все выглядит так - послал пакет, ждешь следующий для отправки. На приеме стоишь для проверки "живости соединения", для тех случаев когда есть значительная пауза между данными с порта. Да код несколько больше чем при UDP клиенте, но не используя бродкаст или мультикаст ты в итоге сделаешь почти то же самое,единственно в случае работы с пакетами UDP проще. А если ты попытаешься сделать "сниффером", то код проще не будет.
Но пакеты не обязательное в случае TCP в некоторых случаях. При определнных условиях достаточно просто завернуть поток с порта на TCP. Насчет использования протокола не по назначению - это зависит от ситуации. Я писал, что на одном компе я и сам скорее использовал бы UDP, но в локале может быть и так, что только TCP.. Зависит от условий задачи. Об этом я тоже писал. И что? в итоге ты меня читаешь внимательно, а я тебя нет? Когда у меня были вопросы в понимании того, что ты написал, я их задал, если где-то понял не верно, то так и написал, Ответа от тебя не получил почти не на один вопрос. От тебя вопросов нет, есть утверждения и предположения.

> для локального решения в первую очередь нужно применять
> локальные решения

подскажи локальное решение общения между сервисом и клиентским приложением

> подскажи локальное решение общения между сервисом и клиентским
> приложением

натурально порты :)

> Evgeny V (06.06.2008 12:12:44) [44]

При неблокирующем режиме, никакие ошибки не возвращаются.
Если ты не сообразил, то я именно это и подчеркнул своим сообщением.

> Anatoly Podgoretsky © (06.06.08 13:59) [52]

Не сообразил, увы еще не телепат. Но и про это я тоже вам написал в ответе, ошибки вернуться к вам позже, тем или иным способом, зависит от того в как вы работаете с неблокирующим сокетом.
> Evgeny V © (06.06.08 12:12) [44]

кажись самое оно под мою задумку...

Palladin © (06.06.08 14:17) [54]

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

> наиболее геморройный способ

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

> Palladin (06.06.2008 15:32:57) [57]

Просто и надежно, работает и через Интернет и любые шлюзы.

← →
ага0 (2008-06-06 15:48) [59]

> Игорь Шевченко © (06.06.08 13:49) [51]
> Palladin © (06.06.08 13:43) [50]
>
> Натурально LPC :)

А я чет не въехал:( Я так понял, шо в LPC сервак не могет сам по себе че-нит слать клиенту, тока в ответ. Если ет так, то как ево к ентой теме прикрутить? Аль не так?

И ишшо - сервак по LPC могет клиентов тока последоватно обслужить, то бишь пока одному отвечает принять запрос от другого не могет? Или могет? А как?

> Anatoly Podgoretsky © (06.06.08 15:36) [58]
> > Palladin (06.06.2008 15:32:57) [57]
>
> Просто и надежно, работает и через Интернет и любые шлюзы.
>

Хто, LPC? А как?

← →
ага0 (2008-06-06 15:52) [60]

2 Palladin ©

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

Крута:)) Да выбери хоть шо, какая разница-та:))

> ага0 (06.06.2008 15:48:59) [59]

Чуть, чуть не дописал - сокеты, наиболее беспроблематичное и маштабируемое.

ни в пайпах и ни в сокетах не шарю... вот какая...)

> Palladin (06.06.2008 15:58:02) [62]

Ну примеров в Дельфи достаточно, это по сути чат и такой пример как старт есть.
Принцип простой, слушать порт, пока кто то не постучится, можно обойтись даже и без множественных подключений, если сервер простой, одно соединение за раз. Для серверов самое сложное это не сокете/покеты, а что бы сервер крутился при любых условиях.

я Сергея М. начитался... все получается куда хуже чем простой чат :)

> А я чет не въехал:(

тормозишь

> Palladin (06.06.2008 16:24:04) [64]

Я говорил похоже, поскольку надо еще разработать протокол обмена, но это касается любого метода.
Принцип то простой.
Подключился, спросил, отключился или сново пункт 2.
Обычный разговор, да и термин часто используется Conversation
Я говорил, что сервер надо так написать, чтобы не падал при любых ошибках.

← →
ага0 (2008-06-06 17:47) [67]

> тормозишь

Да? Та не, наверна проста глуп до изумлению, ага. Эх, жаль не знам смайлика "пожал плечами":(

2 Anatoly Podgoretsky © (06.06.08 15:57) [61]

>Чуть, чуть не дописал

Понял, отстал:))

> Palladin © (06.06.08 15:58) [62]
> ни в пайпах и ни в сокетах не шарю... вот какая...)

Да ладно те, въедешь, че там сложнова. Глано - нАчать:) Тады бери пайпы - с имя с нуля проще разбираться по-мойму. Эта опять-же ежель АПИ. А ежель компаненты - дык вон хоть TTcpServer/TcpClient - куды уж проще. Хошь на то, хошь на друго - недели точна не понадобитси:))

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