Задержка передачи данных по TCP/IP

[Vitekkz88]

Добрый день, коллеги!
Столкнулся с проблемой и не могу понять по какой причине возникает.
Суть: соединение по TCP/IP, два порта.
По одному из портов данные принимаю, по второму порту отправляю только команды(в примере в виде чисел,если "1" получили - то отправляем данные, если получили что-то другое, то отправляем вместо данных "0"). В перспективе использовать буду 4-5 портов. Работу сервера эмулирую пока что в LabVIEW.Далее буду использовать "железо".
Всё прекрасно работает на одной машине. Без всяких задержек. Но стоит мне проекты разнести по разным машинам,то начинается...Данные принимаются нормально, а команды доходят по 5-10 секунд до сервера.
Подскажите,где касячу?

[dadreamer]

Сложно сказать конкретно, в чём проблема. Пробовали уменьшать таймауты у TCP Read / Write на обеих сторонах? По дефолту стоит там 25 секунд. Если связь нарушается по какой-либо причине, то будет ждать её восстановления в течение указанного времени, потом установит кластер error out в True/False. Ошибок никаких не возникает при работе ? Я ничего не имею против TCP инструментов, но на мой взгляд Network Streams проще и предоставляют некоторые дополнительные возможности при работе по сети (авто-переподключение, счётчик разрывов и т.п.). Проверьте также, чтобы был отключен фаерволл в Windows, хотя бы временно, это относится и к антивирусу. И надеюсь службы NI не трогали в системе (особенно, NI PSP Service Locator).

[Vitekkz88]

Пробовали уменьшать таймауты у TCP Read / Write на обеих сторонах? По дефолту стоит там 25 секунд. Если связь нарушается по какой-либо причине, то будет ждать её восстановления в течение указанного времени, потом установит кластер error out в True/False. Ошибок никаких не возникает при работе ?

Да,конечно. Я игрался с таймаутами. Статус кластера ошибок как и положено,выдавал ошибку по истечению N секунд. Затем через еще N секунд связь возобновляется.

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

Да,смотрел в эту сторону,но что-то остановился на TCP.

надеюсь службы NI не трогали в системе (особенно, NI PSP Service Locator).

Нееее,я службы NI не отключаю(ну разве что только update).

Вобщем,я отключил брандмауэры на машинах,отключил антивирусы и вообще всё отключил что только могло блокировать передачу данных. Один фиг,тормоза.Попробовал кабель поменять(мало ли... ).
А потом я просто поменял номер порта. Заменил 10000 на 6340 и всё заработало как надо. Что за прикол,так и не понял...Каким образом номер порта может приводить к таким эффектам?Может кто-то в курсе этого?

[mzu2006]

Кто-то ещё в сети использует этот порт? netstat делали? sniffer'ом подслушать пытались?

[Vitekkz88]

Кто-то ещё в сети использует этот порт?

Похоже так и было.
Соединился напрямую и с портами проблем не стало.
Отключил антивирусы(включая проверку пакетов по TCP, в ESET SS это нужно делать вручную) ,брандмауэры.
Оптимизировал клиента и сервера. Уж проще некуда.
Работает, но только при условии наличия задержки в цикле отправки команды(клиентская сторона,на скриншоте выделил). Убираю эту задержку в цикле и начинаются тормоза в передаче команд.
Пробовал различные вариации time-out-а для TCP-блоков. Если ставлю 2 секунды(или меньше),то связь периодически пропадает.
Если вношу в цилк задержку, то не пропадает ничего.
Как с этим бороться?Задержка в цикле не очень устраивает...Может с очередями что не так?Или работать с двумя портами не есть гуд?

[Vitekkz88]

Господа,тема всё еще актуальна

[Borjomy_1]

А вы в курсе, что даже на 1 байт в сеть может отдаваться пакет, длиной от 256 байт? и вы что хотели, реалтайма от обычной сети Ethernet? Когда вы отдаете в сеть байт без задержек, в вашем цикле - они просто забивают буфер TCP соединения, причем буфер этот практически бесконечен и нет никакой связи между выполнением функции и реальной отдачей данных сеть. Только Sockets Windows определяют, как отдавать набранный буфер. Причем вы хотите отдавать команду, она что, отдается непрерывно и с максимальной скоростью? Либо отдавайте ее только при изменении значения или отдельной команде (что логичнее), например при нажатии кнопки. Либо отдавайте команду, когда пришел предыдущий ответ.

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

[Vitekkz88]

А вы в курсе, что даже на 1 байт в сеть может отдаваться пакет, длиной от 256 байт?

Да,конечно вкурсе.

и вы что хотели, реалтайма от обычной сети Ethernet?

Неа, хотел минимум ожидания доставки команды на сервер.
Про реал-тайм упоминать как минимум неуместно,вы же понимаете почему. Язвить не надо.

Либо отдавайте ее только при изменении значения или отдельной команде (что логичнее)

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

[Borjomy_1]

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

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

Задержка в цикле вас не устраивает - почему? Какая частота выдачи команд вам нужна? Попробуйте отдавать "пакет" команд. Например, если отдать сразу массив в 10 команд, с задержкой в 1мс, то получите в среднем 100мкс/команду. Все равно пакетом придет. А вы и так вычитываете заданное число байтов на другой стороне.

[Vitekkz88]

Попробуйте отдавать "пакет" команд.

Кстати,верно...я зациклился на одной команде. Попробую.

Задержка в цикле вас не устраивает - почему?

Потому что к задержкам отношусь как к средству снятия нагрузки с процессора.Ну или "тики" посчитать и померить скорость выполнения работы vi-ек некоторых. В остальном я предпочитаю нагружать процессор на максимум,а синхронизацию выполнять с помощью очередей и уведомителей.

В вашем случае команда отдается (если без установленной задержки) с максимальной частотой, которую обеспечивает процессор

дыа

Пасиб за советы. Попробую,отпишусь.

[AndreyDmitriev]

Коллега Vitekkz88, ваше желание передавать данные без задержек вполне понятно, но это делается немного не так. Вы пытаетесь непрерывно писать данные в TCP, совершенно не обращая внимания, успевает ли интерфейс проглатывать эти данные. А его пропускная способность ограничена. Ну вот представьте себе, вы нагнали канистру самогона и пытаетесь перелить его в бутылку, используя воронку. За столом уже собрались друзья и орут "тащи скорей горилку", и вы начинаете лить быстрее, но пропускная способность бутылочного горлышка с воронкой ограничена - в какой-то момент воронка наполняется полностью и драгоценный напиток льётся прямо на стол - это как раз тот момент, когда TCP Write отдаёт вам ошибку (то ли 56, то ли 63 - проверьте сами). Возможное решение в данном случае - обработать эту ошибку, и послать данные ещё раз, но это не лучшее решение, поскольку ваша воронка будет постоянно полна самогонки. Более правильное решение - не допускать полного наполнения воронки до краёв, а для этого надо получать от сервера подтверждение о том, что он принял данные и лишь затем передавать следующие. Если хочется поднять скорость до предела, то данные надо передавать блоками. Размер можно выставить достаточно большим, но следующий блок передавать только после обработки предыдущего. В общем передалайте программу, используя получаемые от сервера данные как подтверждение и сделайте буфер для передачи. На гигабитном интерфейсе можно выжать примерно 80 мегабайт в секунду, но больше не получится. А так вы просто переполняете буфер TCP.

[Vitekkz88]

Ну вот представьте себе, вы нагнали канистру самогона и пытаетесь перелить его в бутылку, используя воронку. За столом уже собрались друзья и орут "тащи скорей горилку", и вы начинаете лить быстрее, но пропускная способность бутылочного горлышка с воронкой ограничена - в какой-то момент воронка наполняется полностью и драгоценный напиток льётся прямо на стол - это как раз тот момент, когда TCP Write отдаёт вам ошибку (то ли 56, то ли 63 - проверьте сами).

Прям от души посмеялся С утра это как раз кстати

надо получать от сервера подтверждение о том, что он принял данные и лишь затем передавать следующие

Дыа,сделал. Соединился с сервером и жду от него команды для начала передачи данных. Получил команду - отправил свою. Опять получил от него команду - еще свою отправил. Всё работает без задержки.