Асинхронная работа с TCP

Делись идеей, получай поддержку и критику!
Aleksandr

Gold
user
user
Сообщения: 97
Зарегистрирован: 21 июн 2011, 15:05
Награды: 1
Версия LabVIEW: 2009-2017
Откуда: Novosibirsk
Контактная информация:

Асинхронная работа с TCP

Сообщение Aleksandr »

Здравствуйте, сообщество labviewportal!

Представляю на Ваш суд библиотеку для асинхронной работы с TCP протоколом. Пожелания/замечания приветсвуются :wink:
Библиотека тестировалась на LabVIEW версиях 2010-2013, более ранние версии отсутствуют.
Из известных недочетов:
-Работает только под ОС Windows (разработка под Linux в планах (буду рад любому тестеру :) )).
-Одновременно запускать библиотеку на одной машине не представляется возможным (пока).

С уважением,
Александр

PS: Кстати прочитать о проблеме можно здесь.
PSS: Почему нельзя выкладывать архивы с *.7z разрешением?! :nono:
Вложения
Async TCP Event.rar
LabVIEW 2010
(717.3 КБ) 328 скачиваний
Uniscan Research
Borjomy_1

Activity Professionalism Silver
doctor
doctor
Сообщения: 2207
Зарегистрирован: 28 июн 2012, 09:32
Награды: 3
Версия LabVIEW: 2009..2020
Откуда: город семи холмов
Благодарил (а): 27 раз
Поблагодарили: 26 раз

Re: Асинхронная работа с TCP

Сообщение Borjomy_1 »

Почему нельзя выкладывать архивы с *.7z разрешением?
Наверное, потому, что надо уважать других пользователей - нет ничего хорошего в том, что выкладываются проекты, заархивированные экзотическими архиваторами. Я бы и Rar запретил - это платный продукт, у меня, например, его нет. Встроенных в винду средств (Zip) вполне достаточно.
Аватара пользователя
IvanLis

Activity Professionalism Tutorials Gold Man of the year 2012
Автор
guru
guru
Сообщения: 5458
Зарегистрирован: 02 дек 2009, 17:44
Награды: 7
Версия LabVIEW: 2015, 2016
Откуда: СССР
Благодарил (а): 27 раз
Поблагодарили: 86 раз

Re: Асинхронная работа с TCP

Сообщение IvanLis »

Aleksandr писал(а):Почему нельзя выкладывать архивы с *.7z разрешением?! :nono:
На форуме достаточно разрешенных для выкладывания разрешений файлов.
Используйте zip, он и бесплатен и открывает его практически все.
Aleksandr писал(а):-Работает только под ОС Windows (разработка под Linux в планах (буду рад любому тестеру :) )).
Подо Linux потестить я могу.
Вы только вкратце опишите, в чем была проблема и за счет чего она решена.
На каком уровне подразумевается асинхронный режим?
По идее TCP обеспечивает асинхронный режим с вышестоящим уровнем :dntknw:
Не сталкивался я с подобным проблемами.
Aleksandr

Gold
user
user
Сообщения: 97
Зарегистрирован: 21 июн 2011, 15:05
Награды: 1
Версия LabVIEW: 2009-2017
Откуда: Novosibirsk
Контактная информация:

Re: Асинхронная работа с TCP

Сообщение Aleksandr »

К сожалению, встроенными в LabVIEW средствами работы с TCP невозможно определить когда на порту появились данные, кроме как попытаться прочесть их. Это несет ряд неудобств, например, нельзя одновременно прослушивать разных пользователей в одном потоке. А если обходить это как показано в примере от NI, то придется отсылать некую "метку", подтверждающую намерение отослать данные и в цикле с некой задержкой проверять весь массив подключенных соединений.
Функция же библиотеки заключается в том, что она отсылает событие с ссылкой на подключение в том момент, когда на данное подключение пришли данные либо оно разорвало соединение.
Uniscan Research
Аватара пользователя
IvanLis

Activity Professionalism Tutorials Gold Man of the year 2012
Автор
guru
guru
Сообщения: 5458
Зарегистрирован: 02 дек 2009, 17:44
Награды: 7
Версия LabVIEW: 2015, 2016
Откуда: СССР
Благодарил (а): 27 раз
Поблагодарили: 86 раз

Re: Асинхронная работа с TCP

Сообщение IvanLis »

Aleksandr писал(а):К сожалению, встроенными в LabVIEW средствами работы с TCP невозможно определить когда на порту появились данные, кроме как попытаться прочесть их. Это несет ряд неудобств, например, нельзя одновременно прослушивать разных пользователей в одном потоке. А если обходить это как показано в примере от NI, то придется отсылать некую "метку", подтверждающую намерение отослать данные и в цикле с некой задержкой проверять весь массив подключенных соединений.
Функция же библиотеки заключается в том, что она отсылает событие с ссылкой на подключение в том момент, когда на данное подключение пришли данные либо оно разорвало соединение.
Т.е. реализовано и используется (с точки зрения пользователя) по принципу очереди - Queue или Notification?
Borjomy_1

Activity Professionalism Silver
doctor
doctor
Сообщения: 2207
Зарегистрирован: 28 июн 2012, 09:32
Награды: 3
Версия LabVIEW: 2009..2020
Откуда: город семи холмов
Благодарил (а): 27 раз
Поблагодарили: 26 раз

Re: Асинхронная работа с TCP

Сообщение Borjomy_1 »

Вообще-то правильнее при установлении подключения создавать отдельный независимый поток (вызывая реентрантную :vi: ), который безо-всяких изысков просто читает данные по своему соединению.
Аватара пользователя
IvanLis

Activity Professionalism Tutorials Gold Man of the year 2012
Автор
guru
guru
Сообщения: 5458
Зарегистрирован: 02 дек 2009, 17:44
Награды: 7
Версия LabVIEW: 2015, 2016
Откуда: СССР
Благодарил (а): 27 раз
Поблагодарили: 86 раз

Re: Асинхронная работа с TCP

Сообщение IvanLis »

Borjomy_1 писал(а):Вообще-то правильнее при установлении подключения создавать отдельный независимый поток (вызывая реентрантную :vi: ), который безо-всяких изысков просто читает данные по своему соединению.
Но тогда в чем отличие?
Сейчас тоже реализуется через периодический опрос порта (в независимом цикле) и в случае если данные пришли, то передаются в другой цикл..
Аватара пользователя
Andrew Lunev

Activity Professionalism
VIP
VIP
Сообщения: 957
Зарегистрирован: 11 дек 2010, 12:31
Награды: 2
Версия LabVIEW: 2014-2021
Откуда: Москва
Благодарил (а): 4 раза
Поблагодарили: 10 раз

Re: Асинхронная работа с TCP

Сообщение Andrew Lunev »

На сколько я понял, это попытка создать аналог Network Streams из LabView. Преимущество я вижу только в том, что через Network Streams могут общаться программы созданные на LabView, а в этом варианте можно организовать передачу и от сторонних контроллеров.
Borjomy_1

Activity Professionalism Silver
doctor
doctor
Сообщения: 2207
Зарегистрирован: 28 июн 2012, 09:32
Награды: 3
Версия LabVIEW: 2009..2020
Откуда: город семи холмов
Благодарил (а): 27 раз
Поблагодарили: 26 раз

Re: Асинхронная работа с TCP

Сообщение Borjomy_1 »

Самая главная проблема в том, что:
Размер пакета нигде не задается (иногда это и невозможно). Таким образом, предположить, сколько времени продлится передача, нельзя. Остальные соединения будут ждать. Нарушение отправки данных по одному соединению стопит все остальные.
Далее - как будет реагировать Listener, если в процессе передачи, он зафиксирует изменение размера данных в буфере? Потенциально возможен конфликт - или будет лишний вызов события по пакету, который сейчас считывается, либо новый пакет, который пришел в процессе считывания, будет пропущен.
Aleksandr

Gold
user
user
Сообщения: 97
Зарегистрирован: 21 июн 2011, 15:05
Награды: 1
Версия LabVIEW: 2009-2017
Откуда: Novosibirsk
Контактная информация:

Re: Асинхронная работа с TCP

Сообщение Aleksandr »

IvanLis писал(а):Т.е. реализовано и используется (с точки зрения пользователя) по принципу очереди - Queue или Notification?
Почти, через Event.
Borjomy_1 писал(а): Вообще-то правильнее при установлении подключения создавать отдельный независимый поток (вызывая реентрантную :vi: ), который безо-всяких изысков просто читает данные по своему соединению.
Не вижу в каком месте это правильнее. 1000 пользователей - 1000 потоков? Весьма сомнительно.
IvanLis писал(а):Сейчас тоже реализуется через периодический опрос порта (в независимом цикле) и в случае если данные пришли, то передаются в другой цикл..
Эм, не совсем Вас понял. Если Вы утверждаете, что каждое подключение где-то в фоновом режиме опрашивается в цикле, то это не так.
Andrew Lunev писал(а):На сколько я понял, это попытка создать аналог Network Streams из LabView. Преимущество я вижу только в том, что через Network Streams могут общаться программы созданные на LabView, а в этом варианте можно организовать передачу и от сторонних контроллеров.
Если мои знания верны, то механизм Network Streams предполагает работу point-to-point, а данная библиотека не зависит от количества пользователей.
Borjomy_1 писал(а):Самая главная проблема в том, что:
Размер пакета нигде не задается (иногда это и невозможно). Таким образом, предположить, сколько времени продлится передача, нельзя. Остальные соединения будут ждать. Нарушение отправки данных по одному соединению стопит все остальные.
Никто не будет никого ждать. Вы можете, например, создать Callback и, скажем, передавать ему очередь, которую опрашивают N потоков. В эту очередь передается ID подключения и тот из потоков, кто "успел" быстрей взять из очереди уже будет работать с данным соединением. Решать обрабатывать пришедшие данные в Event структуре или же отсылать их в очередь - задача разработчика.
По поводу сколько байт нужно считать с порта: библиотека не отображает это никак, она лишь сообщает если пришли какие-либо данные в каком-либо количестве. Отправлять размер пакета задача разработчика.
Uniscan Research
Borjomy_1

Activity Professionalism Silver
doctor
doctor
Сообщения: 2207
Зарегистрирован: 28 июн 2012, 09:32
Награды: 3
Версия LabVIEW: 2009..2020
Откуда: город семи холмов
Благодарил (а): 27 раз
Поблагодарили: 26 раз

Re: Асинхронная работа с TCP

Сообщение Borjomy_1 »

Решать обрабатывать пришедшие данные в Event структуре или же отсылать их в очередь - задача разработчика.
И опять - для независимой обработки приходим к тому, что необходимо создавать реентрантные потоки. Иначе проблема стопорения передачи не решается - вы ведь не отдаете размер пришедшего пакета. Получается ситуация: я получаю событие, что в буфере есть массив данных, размером, отличным от нуля. Это и так можно сделать, запустив чтение в режиме Immediate.
По поводу сколько байт нужно считать с порта: библиотека не отображает это никак, она лишь сообщает если пришли какие-либо данные в каком-либо количестве.
я правильно понимаю, что можно получить несколько событий на один блок данных (например, 1Мб)?
Аватара пользователя
Andrew Lunev

Activity Professionalism
VIP
VIP
Сообщения: 957
Зарегистрирован: 11 дек 2010, 12:31
Награды: 2
Версия LabVIEW: 2014-2021
Откуда: Москва
Благодарил (а): 4 раза
Поблагодарили: 10 раз

Re: Асинхронная работа с TCP

Сообщение Andrew Lunev »

Aleksandr писал(а):Если мои знания верны, то механизм Network Streams предполагает работу point-to-point, а данная библиотека не зависит от количества пользователей.
Да, Network Streams работает именно point-to-point, но ничто не мешает создать соединение динамически с каждым вновь подключаемым клиентом.
Аватара пользователя
IvanLis

Activity Professionalism Tutorials Gold Man of the year 2012
Автор
guru
guru
Сообщения: 5458
Зарегистрирован: 02 дек 2009, 17:44
Награды: 7
Версия LabVIEW: 2015, 2016
Откуда: СССР
Благодарил (а): 27 раз
Поблагодарили: 86 раз

Re: Асинхронная работа с TCP

Сообщение IvanLis »

Andrew Lunev писал(а):
Aleksandr писал(а):Если мои знания верны, то механизм Network Streams предполагает работу point-to-point, а данная библиотека не зависит от количества пользователей.
Да, Network Streams работает именно point-to-point, но ничто не мешает создать соединение динамически с каждым вновь подключаемым клиентом.
Я что-то совсем запутался :crazy: .
За половину для Вы у меня полностью перевернули представления о сетевых протоколах и технологиях.

Речь же идет о TCP протоколе...
Это же и есть протокол point-to-point, протокол с предварительной установкой соединения.
Т.е. один пользователь - одно соединение.

Либо мы говорим о разных вещах.
Aleksandr

Gold
user
user
Сообщения: 97
Зарегистрирован: 21 июн 2011, 15:05
Награды: 1
Версия LabVIEW: 2009-2017
Откуда: Novosibirsk
Контактная информация:

Re: Асинхронная работа с TCP

Сообщение Aleksandr »

Borjomy_1 писал(а):И опять - для независимой обработки приходим к тому, что необходимо создавать реентрантные потоки.
Создавать потоки нужно, но не на каждого клиента, а столько, сколько нужно, чтобы полностью загрузить процессор(ы).
Borjomy_1 писал(а):Иначе проблема стопорения передачи не решается - вы ведь не отдаете размер пришедшего пакета.
Решается. См. use case ниже.
Borjomy_1 писал(а):Получается ситуация: я получаю событие, что в буфере есть массив данных, размером, отличным от нуля.
Абсолютно верно.
Borjomy_1 писал(а):Это и так можно сделать, запустив чтение в режиме Immediate.
Неверно в случае, когда клиентов больше одного. В таком случае нужно мультиплексирование ввода-вывода, а данная библиотека как-раз позволяет это сделать.
Borjomy_1 писал(а):я правильно понимаю, что можно получить несколько событий на один блок данных (например, 1Мб)?
Можно, только если Вы этого захотите и явно сделаете.
При создании события "мониторинг" соединения прекращается. Вы должны указать, что хотите и дальше "мониторить" данное соединение (это делается с помощью функции Continue tracking). Обычно это делается после считывания блока данных.
Andrew Lunev писал(а):Да, Network Streams работает именно point-to-point, но ничто не мешает создать соединение динамически с каждым вновь подключаемым клиентом.
К сожалению, я не работал с данным механизмом. Не могли бы Вы привести пример? Заранее благодарен.


Use case:
1. Создать callback для объекта Event из библиотеки, который добавляет события в очередь.
2. Создать поток, принимающий входящие соединения от клиентов и регистрирующий их в библиотеке.
3. Создать N потоков (где N - количество ядер), которые будут:
- читать событие из очереди
- читать данные с соответствующего сокета в режиме Immediate
- записывать данные в буфер, ассоциированный с сокетом/клиентом
- если в буфере достаточно для обработки данных, то обрабатывать их и сбрасывать буфер
Uniscan Research
Borjomy_1

Activity Professionalism Silver
doctor
doctor
Сообщения: 2207
Зарегистрирован: 28 июн 2012, 09:32
Награды: 3
Версия LabVIEW: 2009..2020
Откуда: город семи холмов
Благодарил (а): 27 раз
Поблагодарили: 26 раз

Re: Асинхронная работа с TCP

Сообщение Borjomy_1 »

ИМХО - слишком сложно, медленно и с дополнительным расходом памяти. И только из-за нежелания каждого клиента выделять в отдельный поток.
Borjomy_1 писал(а):
Иначе проблема стопорения передачи не решается - вы ведь не отдаете размер пришедшего пакета.

Решается. См. use case ниже.
Т.е вместо того, чтобы использовать сбор пакетов операционной системой, предлагается изобретать велосипед и вручную отслеживать дополнительно созданный буфер, не говоря уже о том, что под :labview: работа со строками предполагает выделение памяти под строку при каждой операции, в результате чего невозможно организовать честный строковый буфер постоянного размера?
Borjomy_1 писал(а):
Получается ситуация: я получаю событие, что в буфере есть массив данных, размером, отличным от нуля.

Абсолютно верно.
Сложно добавить в событие размер пакета, это событие вызвавшего?
Можно, только если Вы этого захотите и явно сделаете.
При создании события "мониторинг" соединения прекращается. Вы должны указать, что хотите и дальше "мониторить" данное соединение (это делается с помощью функции Continue tracking). Обычно это делается после считывания блока данных.
Операционная система Windows не является операционной системой реального времени. Между окончанием считывания блока данных и командой Continue tracking может пройти неопределенное количество времени. Можно получить пропуск события прихода пакета.
Ответить
  • Похожие темы
    Ответы
    Просмотры
    Последнее сообщение

Вернуться в «Проекты»