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

← →
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.. Зависит от условий задачи. Об этом я тоже писал. И что? в итоге ты меня читаешь внимательно, а я тебя нет? Когда у меня были вопросы в понимании того, что ты написал, я их задал, если где-то понял не верно, то так и написал, Ответа от тебя не получил почти не на один вопрос. От тебя вопросов нет, есть утверждения и предположения.

← →
Palladin © (2008-06-06 13:18) [48]

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

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

← →
Игорь Шевченко © (2008-06-06 13:28) [49]

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

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

← →
Palladin © (2008-06-06 13:43) [50]

> Игорь Шевченко © (06.06.08 13:28) [49]

какие?

← →
Игорь Шевченко © (2008-06-06 13:49) [51]

Palladin © (06.06.08 13:43) [50]

Натурально LPC :)

← →
Anatoly Podgoretsky © (2008-06-06 13:59) [52]

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

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

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

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

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

← →
Palladin © (2008-06-06 14:17) [54]

> Игорь Шевченко © (06.06.08 13:49) [51]

хем ) интересно... ты меня заинтриговал...

← →
Palladin © (2008-06-06 14:18) [55]

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

← →
Игорь Шевченко © (2008-06-06 15:19) [56]

Palladin © (06.06.08 14:17) [54]

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

← →
Palladin © (2008-06-06 15:32) [57]

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

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

← →
Anatoly Podgoretsky © (2008-06-06 15:36) [58]

> 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-порта Найти похожие ветки