Задержка передачи данных по TCP/IP
-
Vitekkz88
- expert
- Сообщения: 1100
- Зарегистрирован: 21 янв 2014, 15:45
- Награды: 3
- Версия LabVIEW: 12,13,14
- Откуда: Томск
- Контактная информация:
Задержка передачи данных по TCP/IP
Добрый день, коллеги!
Столкнулся с проблемой и не могу понять по какой причине возникает.
Суть: соединение по TCP/IP, два порта.
По одному из портов данные принимаю, по второму порту отправляю только команды(в примере в виде чисел,если "1" получили - то отправляем данные, если получили что-то другое, то отправляем вместо данных "0"). В перспективе использовать буду 4-5 портов. Работу сервера эмулирую пока что в LabVIEW.Далее буду использовать "железо".
Всё прекрасно работает на одной машине. Без всяких задержек. Но стоит мне проекты разнести по разным машинам,то начинается...Данные принимаются нормально, а команды доходят по 5-10 секунд до сервера.
Подскажите,где касячу?
Столкнулся с проблемой и не могу понять по какой причине возникает.
Суть: соединение по TCP/IP, два порта.
По одному из портов данные принимаю, по второму порту отправляю только команды(в примере в виде чисел,если "1" получили - то отправляем данные, если получили что-то другое, то отправляем вместо данных "0"). В перспективе использовать буду 4-5 портов. Работу сервера эмулирую пока что в LabVIEW.Далее буду использовать "железо".
Всё прекрасно работает на одной машине. Без всяких задержек. Но стоит мне проекты разнести по разным машинам,то начинается...Данные принимаются нормально, а команды доходят по 5-10 секунд до сервера.
Подскажите,где касячу?
- Вложения
-
- Два порта.zip
- (49.25 КБ) 186 скачиваний
Инженер - это открыто светящийся интеллект, свободный и не обидный юмор, это легкость и широта мысли...Это воспитанность, тонкость вкусов, хорошая речь, плавно согласованная и без сорных словечек...
-А. И. Солженицын
-А. И. Солженицын
-
dadreamer
- professor
- Сообщения: 3926
- Зарегистрирован: 17 фев 2013, 16:33
- Награды: 4
- Версия LabVIEW: 2.5 — 2022
- Благодарил (а): 11 раз
- Поблагодарили: 127 раз
- Контактная информация:
Re: Задержка передачи данных по TCP/IP
Сложно сказать конкретно, в чём проблема. Пробовали уменьшать таймауты у TCP Read / Write на обеих сторонах? По дефолту стоит там 25 секунд. Если связь нарушается по какой-либо причине, то будет ждать её восстановления в течение указанного времени, потом установит кластер error out в True/False. Ошибок никаких не возникает при работе ? Я ничего не имею против TCP инструментов, но на мой взгляд Network Streams проще и предоставляют некоторые дополнительные возможности при работе по сети (авто-переподключение, счётчик разрывов и т.п.). Проверьте также, чтобы был отключен фаерволл в Windows, хотя бы временно, это относится и к антивирусу. И надеюсь службы NI не трогали в системе (особенно, NI PSP Service Locator).
-
Vitekkz88
- expert
- Сообщения: 1100
- Зарегистрирован: 21 янв 2014, 15:45
- Награды: 3
- Версия LabVIEW: 12,13,14
- Откуда: Томск
- Контактная информация:
Re: Задержка передачи данных по TCP/IP
Да,конечно. Я игрался с таймаутами. Статус кластера ошибок как и положено,выдавал ошибку по истечению N секунд. Затем через еще N секунд связь возобновляется.Пробовали уменьшать таймауты у TCP Read / Write на обеих сторонах? По дефолту стоит там 25 секунд. Если связь нарушается по какой-либо причине, то будет ждать её восстановления в течение указанного времени, потом установит кластер error out в True/False. Ошибок никаких не возникает при работе ?
Да,смотрел в эту сторону,но что-то остановился на TCP.на мой взгляд Network Streams проще и предоставляют некоторые дополнительные возможности при работе по сети (авто-переподключение, счётчик разрывов и т.п.).
Нееее,я службы NI не отключаю(ну разве что только update).надеюсь службы NI не трогали в системе (особенно, NI PSP Service Locator).
Вобщем,я отключил брандмауэры на машинах,отключил антивирусы и вообще всё отключил что только могло блокировать передачу данных. Один фиг,тормоза.Попробовал кабель поменять(мало ли... ).
А потом я просто поменял номер порта. Заменил 10000 на 6340 и всё заработало как надо. Что за прикол,так и не понял...Каким образом номер порта может приводить к таким эффектам?Может кто-то в курсе этого?
Инженер - это открыто светящийся интеллект, свободный и не обидный юмор, это легкость и широта мысли...Это воспитанность, тонкость вкусов, хорошая речь, плавно согласованная и без сорных словечек...
-А. И. Солженицын
-А. И. Солженицын
-
mzu2006
- doctor
- Сообщения: 2456
- Зарегистрирован: 16 авг 2008, 02:12
- Награды: 3
- Версия LabVIEW: 7.1 10 11 12
- Откуда: St-Petersburg (RU), Phila, Boston, Washington DC
- Контактная информация:
Re: Задержка передачи данных по TCP/IP
Кто-то ещё в сети использует этот порт? netstat делали? sniffer'ом подслушать пытались?
Правила форума (Forum rules in Russian)
rm -rf /mnt/windows
rm -rf /mnt/windows
-
Vitekkz88
- expert
- Сообщения: 1100
- Зарегистрирован: 21 янв 2014, 15:45
- Награды: 3
- Версия LabVIEW: 12,13,14
- Откуда: Томск
- Контактная информация:
Re: Задержка передачи данных по TCP/IP
Похоже так и было.Кто-то ещё в сети использует этот порт?
Соединился напрямую и с портами проблем не стало.
Отключил антивирусы(включая проверку пакетов по TCP, в ESET SS это нужно делать вручную) ,брандмауэры.
Оптимизировал клиента и сервера. Уж проще некуда.
Работает, но только при условии наличия задержки в цикле отправки команды(клиентская сторона,на скриншоте выделил). Убираю эту задержку в цикле и начинаются тормоза в передаче команд.
Пробовал различные вариации time-out-а для TCP-блоков. Если ставлю 2 секунды(или меньше),то связь периодически пропадает.
Если вношу в цилк задержку, то не пропадает ничего.
Как с этим бороться?Задержка в цикле не очень устраивает...Может с очередями что не так?Или работать с двумя портами не есть гуд?
- Вложения
-
- Client-Server.zip
- (35.77 КБ) 170 скачиваний
Инженер - это открыто светящийся интеллект, свободный и не обидный юмор, это легкость и широта мысли...Это воспитанность, тонкость вкусов, хорошая речь, плавно согласованная и без сорных словечек...
-А. И. Солженицын
-А. И. Солженицын
-
Vitekkz88
- expert
- Сообщения: 1100
- Зарегистрирован: 21 янв 2014, 15:45
- Награды: 3
- Версия LabVIEW: 12,13,14
- Откуда: Томск
- Контактная информация:
Re: Задержка передачи данных по TCP/IP
Господа,тема всё еще актуальна
Инженер - это открыто светящийся интеллект, свободный и не обидный юмор, это легкость и широта мысли...Это воспитанность, тонкость вкусов, хорошая речь, плавно согласованная и без сорных словечек...
-А. И. Солженицын
-А. И. Солженицын
-
- doctor
- Сообщения: 2211
- Зарегистрирован: 28 июн 2012, 09:32
- Награды: 3
- Версия LabVIEW: 2009..2020
- Откуда: город семи холмов
- Благодарил (а): 27 раз
- Поблагодарили: 27 раз
Re: Задержка передачи данных по TCP/IP
А вы в курсе, что даже на 1 байт в сеть может отдаваться пакет, длиной от 256 байт? и вы что хотели, реалтайма от обычной сети Ethernet? Когда вы отдаете в сеть байт без задержек, в вашем цикле - они просто забивают буфер TCP соединения, причем буфер этот практически бесконечен и нет никакой связи между выполнением функции и реальной отдачей данных сеть. Только Sockets Windows определяют, как отдавать набранный буфер. Причем вы хотите отдавать команду, она что, отдается непрерывно и с максимальной скоростью? Либо отдавайте ее только при изменении значения или отдельной команде (что логичнее), например при нажатии кнопки. Либо отдавайте команду, когда пришел предыдущий ответ.
Чтобы убедиться в том, что забивается буфер, к вместе с командой отдавайте и индекс цикла, в приеме также настройте считывание двух значений. Вы увидите, что без таймера счетчики будут разбегаться.
Чтобы убедиться в том, что забивается буфер, к вместе с командой отдавайте и индекс цикла, в приеме также настройте считывание двух значений. Вы увидите, что без таймера счетчики будут разбегаться.
-
Vitekkz88
- expert
- Сообщения: 1100
- Зарегистрирован: 21 янв 2014, 15:45
- Награды: 3
- Версия LabVIEW: 12,13,14
- Откуда: Томск
- Контактная информация:
Re: Задержка передачи данных по TCP/IP
Да,конечно вкурсе.А вы в курсе, что даже на 1 байт в сеть может отдаваться пакет, длиной от 256 байт?
Неа, хотел минимум ожидания доставки команды на сервер.и вы что хотели, реалтайма от обычной сети Ethernet?
Про реал-тайм упоминать как минимум неуместно,вы же понимаете почему. Язвить не надо.
Разные команды есть.Одни по событию, другие должны постоянно отправляться без постороннего участия.Либо отдавайте ее только при изменении значения или отдельной команде (что логичнее)
Инженер - это открыто светящийся интеллект, свободный и не обидный юмор, это легкость и широта мысли...Это воспитанность, тонкость вкусов, хорошая речь, плавно согласованная и без сорных словечек...
-А. И. Солженицын
-А. И. Солженицын
-
- doctor
- Сообщения: 2211
- Зарегистрирован: 28 июн 2012, 09:32
- Награды: 3
- Версия LabVIEW: 2009..2020
- Откуда: город семи холмов
- Благодарил (а): 27 раз
- Поблагодарили: 27 раз
Re: Задержка передачи данных по TCP/IP
В вашем случае команда отдается (если без установленной задержки) с максимальной частотой, которую обеспечивает процессор, поскольку этот поток лишь пишет в буфер TCP соединения. В любом случае непрерывный поток должен быть синхронизирован.Разные команды есть.Одни по событию, другие должны постоянно отправляться без постороннего участия.
Задержка в цикле вас не устраивает - почему? Какая частота выдачи команд вам нужна? Попробуйте отдавать "пакет" команд. Например, если отдать сразу массив в 10 команд, с задержкой в 1мс, то получите в среднем 100мкс/команду. Все равно пакетом придет. А вы и так вычитываете заданное число байтов на другой стороне.
-
Vitekkz88
- expert
- Сообщения: 1100
- Зарегистрирован: 21 янв 2014, 15:45
- Награды: 3
- Версия LabVIEW: 12,13,14
- Откуда: Томск
- Контактная информация:
Re: Задержка передачи данных по TCP/IP
Кстати,верно...я зациклился на одной команде. Попробую.Попробуйте отдавать "пакет" команд.
Потому что к задержкам отношусь как к средству снятия нагрузки с процессора.Ну или "тики" посчитать и померить скорость выполнения работы vi-ек некоторых. В остальном я предпочитаю нагружать процессор на максимум,а синхронизацию выполнять с помощью очередей и уведомителей.Задержка в цикле вас не устраивает - почему?
дыаВ вашем случае команда отдается (если без установленной задержки) с максимальной частотой, которую обеспечивает процессор
Пасиб за советы. Попробую,отпишусь.
Инженер - это открыто светящийся интеллект, свободный и не обидный юмор, это легкость и широта мысли...Это воспитанность, тонкость вкусов, хорошая речь, плавно согласованная и без сорных словечек...
-А. И. Солженицын
-А. И. Солженицын
-
- VIP
- Сообщения: 1339
- Зарегистрирован: 03 фев 2010, 00:42
- Награды: 6
- Версия LabVIEW: 6.1 - 2024
- Откуда: Германия
- Благодарил (а): 1 раз
- Поблагодарили: 44 раза
- Контактная информация:
Re: Задержка передачи данных по TCP/IP
Коллега Vitekkz88, ваше желание передавать данные без задержек вполне понятно, но это делается немного не так. Вы пытаетесь непрерывно писать данные в TCP, совершенно не обращая внимания, успевает ли интерфейс проглатывать эти данные. А его пропускная способность ограничена. Ну вот представьте себе, вы нагнали канистру самогона и пытаетесь перелить его в бутылку, используя воронку. За столом уже собрались друзья и орут "тащи скорей горилку", и вы начинаете лить быстрее, но пропускная способность бутылочного горлышка с воронкой ограничена - в какой-то момент воронка наполняется полностью и драгоценный напиток льётся прямо на стол - это как раз тот момент, когда TCP Write отдаёт вам ошибку (то ли 56, то ли 63 - проверьте сами). Возможное решение в данном случае - обработать эту ошибку, и послать данные ещё раз, но это не лучшее решение, поскольку ваша воронка будет постоянно полна самогонки. Более правильное решение - не допускать полного наполнения воронки до краёв, а для этого надо получать от сервера подтверждение о том, что он принял данные и лишь затем передавать следующие. Если хочется поднять скорость до предела, то данные надо передавать блоками. Размер можно выставить достаточно большим, но следующий блок передавать только после обработки предыдущего. В общем передалайте программу, используя получаемые от сервера данные как подтверждение и сделайте буфер для передачи. На гигабитном интерфейсе можно выжать примерно 80 мегабайт в секунду, но больше не получится. А так вы просто переполняете буфер TCP.
-
Vitekkz88
- expert
- Сообщения: 1100
- Зарегистрирован: 21 янв 2014, 15:45
- Награды: 3
- Версия LabVIEW: 12,13,14
- Откуда: Томск
- Контактная информация:
Re: Задержка передачи данных по TCP/IP
Прям от души посмеялся С утра это как раз кстатиНу вот представьте себе, вы нагнали канистру самогона и пытаетесь перелить его в бутылку, используя воронку. За столом уже собрались друзья и орут "тащи скорей горилку", и вы начинаете лить быстрее, но пропускная способность бутылочного горлышка с воронкой ограничена - в какой-то момент воронка наполняется полностью и драгоценный напиток льётся прямо на стол - это как раз тот момент, когда TCP Write отдаёт вам ошибку (то ли 56, то ли 63 - проверьте сами).
Дыа,сделал. Соединился с сервером и жду от него команды для начала передачи данных. Получил команду - отправил свою. Опять получил от него команду - еще свою отправил. Всё работает без задержки.надо получать от сервера подтверждение о том, что он принял данные и лишь затем передавать следующие
- Вложения
-
- Client-Server.zip
- (88.29 КБ) 196 скачиваний
Инженер - это открыто светящийся интеллект, свободный и не обидный юмор, это легкость и широта мысли...Это воспитанность, тонкость вкусов, хорошая речь, плавно согласованная и без сорных словечек...
-А. И. Солженицын
-А. И. Солженицын
-
- Похожие темы
- Ответы
- Просмотры
- Последнее сообщение
-
- 38 Ответы
- 13314 Просмотры
-
Последнее сообщение AndreyDmitriev
-
- 5 Ответы
- 253 Просмотры
-
Последнее сообщение IvanLis
-
- 3 Ответы
- 881 Просмотры
-
Последнее сообщение IvanLis
-
- 13 Ответы
- 1232 Просмотры
-
Последнее сообщение Boxa
-
- 0 Ответы
- 506 Просмотры
-
Последнее сообщение Juri