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

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

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

Postby Aleksandr on 18 Oct 2013, 09:30

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

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

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

PS: Кстати прочитать о проблеме можно здесь.
PSS: Почему нельзя выкладывать архивы с *.7z разрешением?! :nono:
Attachments
Async TCP Event.rar
LabVIEW 2010
(717.3 KiB) Downloaded 173 times
Uniscan Research
Aleksandr
user
user
 
Posts: 96
Joined: 21 Jun 2011, 15:05
Location: Novosibirsk
Medals: 1
Gold (1)
LabVIEW Version: 2010-2014
Karma: 61
students

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

Postby Borjomy_1 on 18 Oct 2013, 10:28

Почему нельзя выкладывать архивы с *.7z разрешением?

Наверное, потому, что надо уважать других пользователей - нет ничего хорошего в том, что выкладываются проекты, заархивированные экзотическими архиваторами. Я бы и Rar запретил - это платный продукт, у меня, например, его нет. Встроенных в винду средств (Zip) вполне достаточно.
Borjomy_1
expert
expert
 
Posts: 1826
Joined: 28 Jun 2012, 09:32
Location: город семи холмов
Medals: 3
Activity (1) Professionalism (1) Silver (1)
LabVIEW Version: 4-8.6,9-14
Karma: 319
VIP

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

Postby IvanLis on 18 Oct 2013, 12:27

Aleksandr wrote:Почему нельзя выкладывать архивы с *.7z разрешением?! :nono:

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

Aleksandr wrote:-Работает только под ОС Windows (разработка под Linux в планах (буду рад любому тестеру :) )).

Подо Linux потестить я могу.
Вы только вкратце опишите, в чем была проблема и за счет чего она решена.
На каком уровне подразумевается асинхронный режим?
По идее TCP обеспечивает асинхронный режим с вышестоящим уровнем :dntknw:
Не сталкивался я с подобным проблемами.
User avatar
IvanLis
professor
professor
 
Posts: 4628
Joined: 02 Dec 2009, 17:44
Location: СССР
Medals: 7
Activity (2) Professionalism (1) Tutorials (1) Gold (1) Man of the year 2012 (1)
Автор (1)
LabVIEW Version: 2010
Karma: 727
hardware VIP bloggers teachers

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

Postby Aleksandr on 18 Oct 2013, 12:56

К сожалению, встроенными в LabVIEW средствами работы с TCP невозможно определить когда на порту появились данные, кроме как попытаться прочесть их. Это несет ряд неудобств, например, нельзя одновременно прослушивать разных пользователей в одном потоке. А если обходить это как показано в примере от NI, то придется отсылать некую "метку", подтверждающую намерение отослать данные и в цикле с некой задержкой проверять весь массив подключенных соединений.
Функция же библиотеки заключается в том, что она отсылает событие с ссылкой на подключение в том момент, когда на данное подключение пришли данные либо оно разорвало соединение.
Uniscan Research
Aleksandr
user
user
 
Posts: 96
Joined: 21 Jun 2011, 15:05
Location: Novosibirsk
Medals: 1
Gold (1)
LabVIEW Version: 2010-2014
Karma: 61
students

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

Postby IvanLis on 18 Oct 2013, 13:12

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

Т.е. реализовано и используется (с точки зрения пользователя) по принципу очереди - Queue или Notification?
User avatar
IvanLis
professor
professor
 
Posts: 4628
Joined: 02 Dec 2009, 17:44
Location: СССР
Medals: 7
Activity (2) Professionalism (1) Tutorials (1) Gold (1) Man of the year 2012 (1)
Автор (1)
LabVIEW Version: 2010
Karma: 727
hardware VIP bloggers teachers

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

Postby Borjomy_1 on 18 Oct 2013, 13:13

Вообще-то правильнее при установлении подключения создавать отдельный независимый поток (вызывая реентрантную :vi: ), который безо-всяких изысков просто читает данные по своему соединению.
Borjomy_1
expert
expert
 
Posts: 1826
Joined: 28 Jun 2012, 09:32
Location: город семи холмов
Medals: 3
Activity (1) Professionalism (1) Silver (1)
LabVIEW Version: 4-8.6,9-14
Karma: 319
VIP

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

Postby IvanLis on 18 Oct 2013, 13:15

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


Но тогда в чем отличие?
Сейчас тоже реализуется через периодический опрос порта (в независимом цикле) и в случае если данные пришли, то передаются в другой цикл..
User avatar
IvanLis
professor
professor
 
Posts: 4628
Joined: 02 Dec 2009, 17:44
Location: СССР
Medals: 7
Activity (2) Professionalism (1) Tutorials (1) Gold (1) Man of the year 2012 (1)
Автор (1)
LabVIEW Version: 2010
Karma: 727
hardware VIP bloggers teachers

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

Postby Andrew Lunev on 18 Oct 2013, 13:56

На сколько я понял, это попытка создать аналог Network Streams из LabView. Преимущество я вижу только в том, что через Network Streams могут общаться программы созданные на LabView, а в этом варианте можно организовать передачу и от сторонних контроллеров.
User avatar
Andrew Lunev
leader
leader
 
Posts: 870
Joined: 11 Dec 2010, 12:31
Location: Москва
Medals: 2
Activity (1) Professionalism (1)
LabVIEW Version: 2018
Karma: 250
hardware I/O VIP teachers

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

Postby Borjomy_1 on 18 Oct 2013, 14:07

Самая главная проблема в том, что:
Размер пакета нигде не задается (иногда это и невозможно). Таким образом, предположить, сколько времени продлится передача, нельзя. Остальные соединения будут ждать. Нарушение отправки данных по одному соединению стопит все остальные.
Далее - как будет реагировать Listener, если в процессе передачи, он зафиксирует изменение размера данных в буфере? Потенциально возможен конфликт - или будет лишний вызов события по пакету, который сейчас считывается, либо новый пакет, который пришел в процессе считывания, будет пропущен.
Borjomy_1
expert
expert
 
Posts: 1826
Joined: 28 Jun 2012, 09:32
Location: город семи холмов
Medals: 3
Activity (1) Professionalism (1) Silver (1)
LabVIEW Version: 4-8.6,9-14
Karma: 319
VIP

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

Postby Aleksandr on 18 Oct 2013, 14:28

IvanLis wrote:Т.е. реализовано и используется (с точки зрения пользователя) по принципу очереди - Queue или Notification?

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

Не вижу в каком месте это правильнее. 1000 пользователей - 1000 потоков? Весьма сомнительно.
IvanLis wrote:Сейчас тоже реализуется через периодический опрос порта (в независимом цикле) и в случае если данные пришли, то передаются в другой цикл..

Эм, не совсем Вас понял. Если Вы утверждаете, что каждое подключение где-то в фоновом режиме опрашивается в цикле, то это не так.
Andrew Lunev wrote:На сколько я понял, это попытка создать аналог Network Streams из LabView. Преимущество я вижу только в том, что через Network Streams могут общаться программы созданные на LabView, а в этом варианте можно организовать передачу и от сторонних контроллеров.

Если мои знания верны, то механизм Network Streams предполагает работу point-to-point, а данная библиотека не зависит от количества пользователей.
Borjomy_1 wrote:Самая главная проблема в том, что:
Размер пакета нигде не задается (иногда это и невозможно). Таким образом, предположить, сколько времени продлится передача, нельзя. Остальные соединения будут ждать. Нарушение отправки данных по одному соединению стопит все остальные.

Никто не будет никого ждать. Вы можете, например, создать Callback и, скажем, передавать ему очередь, которую опрашивают N потоков. В эту очередь передается ID подключения и тот из потоков, кто "успел" быстрей взять из очереди уже будет работать с данным соединением. Решать обрабатывать пришедшие данные в Event структуре или же отсылать их в очередь - задача разработчика.
По поводу сколько байт нужно считать с порта: библиотека не отображает это никак, она лишь сообщает если пришли какие-либо данные в каком-либо количестве. Отправлять размер пакета задача разработчика.
Uniscan Research
Aleksandr
user
user
 
Posts: 96
Joined: 21 Jun 2011, 15:05
Location: Novosibirsk
Medals: 1
Gold (1)
LabVIEW Version: 2010-2014
Karma: 61
students

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

Postby Borjomy_1 on 18 Oct 2013, 14:56

Решать обрабатывать пришедшие данные в Event структуре или же отсылать их в очередь - задача разработчика.

И опять - для независимой обработки приходим к тому, что необходимо создавать реентрантные потоки. Иначе проблема стопорения передачи не решается - вы ведь не отдаете размер пришедшего пакета. Получается ситуация: я получаю событие, что в буфере есть массив данных, размером, отличным от нуля. Это и так можно сделать, запустив чтение в режиме Immediate.
По поводу сколько байт нужно считать с порта: библиотека не отображает это никак, она лишь сообщает если пришли какие-либо данные в каком-либо количестве.
я правильно понимаю, что можно получить несколько событий на один блок данных (например, 1Мб)?
Borjomy_1
expert
expert
 
Posts: 1826
Joined: 28 Jun 2012, 09:32
Location: город семи холмов
Medals: 3
Activity (1) Professionalism (1) Silver (1)
LabVIEW Version: 4-8.6,9-14
Karma: 319
VIP

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

Postby Andrew Lunev on 18 Oct 2013, 15:14

Aleksandr wrote:Если мои знания верны, то механизм Network Streams предполагает работу point-to-point, а данная библиотека не зависит от количества пользователей.
Да, Network Streams работает именно point-to-point, но ничто не мешает создать соединение динамически с каждым вновь подключаемым клиентом.
User avatar
Andrew Lunev
leader
leader
 
Posts: 870
Joined: 11 Dec 2010, 12:31
Location: Москва
Medals: 2
Activity (1) Professionalism (1)
LabVIEW Version: 2018
Karma: 250
hardware I/O VIP teachers

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

Postby IvanLis on 18 Oct 2013, 19:59

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

Я что-то совсем запутался :crazy: .
За половину для Вы у меня полностью перевернули представления о сетевых протоколах и технологиях.

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

Либо мы говорим о разных вещах.
User avatar
IvanLis
professor
professor
 
Posts: 4628
Joined: 02 Dec 2009, 17:44
Location: СССР
Medals: 7
Activity (2) Professionalism (1) Tutorials (1) Gold (1) Man of the year 2012 (1)
Автор (1)
LabVIEW Version: 2010
Karma: 727
hardware VIP bloggers teachers

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

Postby Aleksandr on 19 Oct 2013, 20:45

Borjomy_1 wrote:И опять - для независимой обработки приходим к тому, что необходимо создавать реентрантные потоки.

Создавать потоки нужно, но не на каждого клиента, а столько, сколько нужно, чтобы полностью загрузить процессор(ы).

Borjomy_1 wrote:Иначе проблема стопорения передачи не решается - вы ведь не отдаете размер пришедшего пакета.

Решается. См. use case ниже.

Borjomy_1 wrote:Получается ситуация: я получаю событие, что в буфере есть массив данных, размером, отличным от нуля.

Абсолютно верно.

Borjomy_1 wrote:Это и так можно сделать, запустив чтение в режиме Immediate.

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

Borjomy_1 wrote:я правильно понимаю, что можно получить несколько событий на один блок данных (например, 1Мб)?

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

Andrew Lunev wrote:Да, Network Streams работает именно point-to-point, но ничто не мешает создать соединение динамически с каждым вновь подключаемым клиентом.

К сожалению, я не работал с данным механизмом. Не могли бы Вы привести пример? Заранее благодарен.


Use case:
1. Создать callback для объекта Event из библиотеки, который добавляет события в очередь.
2. Создать поток, принимающий входящие соединения от клиентов и регистрирующий их в библиотеке.
3. Создать N потоков (где N - количество ядер), которые будут:
- читать событие из очереди
- читать данные с соответствующего сокета в режиме Immediate
- записывать данные в буфер, ассоциированный с сокетом/клиентом
- если в буфере достаточно для обработки данных, то обрабатывать их и сбрасывать буфер
Uniscan Research
Aleksandr
user
user
 
Posts: 96
Joined: 21 Jun 2011, 15:05
Location: Novosibirsk
Medals: 1
Gold (1)
LabVIEW Version: 2010-2014
Karma: 61
students

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

Postby Borjomy_1 on 21 Oct 2013, 08:50

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

Решается. См. use case ниже.

Т.е вместо того, чтобы использовать сбор пакетов операционной системой, предлагается изобретать велосипед и вручную отслеживать дополнительно созданный буфер, не говоря уже о том, что под :labview: работа со строками предполагает выделение памяти под строку при каждой операции, в результате чего невозможно организовать честный строковый буфер постоянного размера?

Borjomy_1 писал(а):
Получается ситуация: я получаю событие, что в буфере есть массив данных, размером, отличным от нуля.

Абсолютно верно.

Сложно добавить в событие размер пакета, это событие вызвавшего?

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

Операционная система Windows не является операционной системой реального времени. Между окончанием считывания блока данных и командой Continue tracking может пройти неопределенное количество времени. Можно получить пропуск события прихода пакета.
Borjomy_1
expert
expert
 
Posts: 1826
Joined: 28 Jun 2012, 09:32
Location: город семи холмов
Medals: 3
Activity (1) Professionalism (1) Silver (1)
LabVIEW Version: 4-8.6,9-14
Karma: 319
VIP

Next

Return to Проекты

Who is online

Users browsing this forum: No registered users and 3 guests

cron