Решение: удалить DrWeb

Послылаю подряд два пакета по 16 байт
Получаю задержку в отправке 200мс

Посылаю один пакет 16. Отправляется сразу. Без задержки

От размера пакета не зависит. Два пакета по 512 так же тормозят

Но если послать перед ними или после них 2048 отправляется без задержки

Пробовал вставлять между пакетами Sleep(100), Sleep(50) — не помогает

Как он определяет что пакеты посланны один за другим?
Ведь если посылаю один пакет он отправляется тут же

Nagle выключен. То есть setsockopt TCP_NODELAY = 1

Проверял на разных компьютерах. На каких-то проблема есть. На каких то нет. Не зависит от версии винды.
Антивирус выключал

Что делать? Помогите!

Здравствуйте, TailWind, Вы писали:

TW>Как он определяет что пакеты посланны один за другим?

Первый пакет уходит сразу. Второй и последующие ждут, пока или не наберётся полный сегмент или не будут подтверждены все ранее отправленные данные или пройдёт 200 ms, whatever is first.

TW>Nagle выключен. То есть setsockopt TCP_NODELAY = 1

Что-то слабо верится. С выйключенным Наглом должно уходить сразу.

Какая ОСь? Венда галимая?

Pzz>Что-то слабо верится. С выйключенным Наглом должно уходить сразу.

Проверил через getsockopt — включен

Pzz>Какая ОСь? Венда галимая?

1 машина Win7 — 0 ms delay
1 машина win10 — 0 ms delay
4 машины Win10 — 200ms delay

Один и тот же exe

Здравствуйте, TailWind, Вы писали:

TW>1 машина Win7 — 0 ms delay
TW>1 машина win10 — 0 ms delay
TW>4 машины Win10 — 200ms delay

TW>Один и тот же exe

Странно.

А у тебя это точно задержки на одной стороне, а не round-trip?

TW>>Nagle выключен. То есть setsockopt TCP_NODELAY = 1
Pzz>Что-то слабо верится. С выйключенным Наглом должно уходить сразу.

Закоментировал setsockopt TCP_NODELAY = 1
На тех машинах где было 0 ms стало 200 ms

Здравствуйте, TailWind, Вы писали:

TW>Что делать?
Используйте UDP

Здравствуйте, TailWind, Вы писали:

TW>>>Nagle выключен. То есть setsockopt TCP_NODELAY = 1
Pzz>>Что-то слабо верится. С выйключенным Наглом должно уходить сразу.

TW>Закоментировал setsockopt TCP_NODELAY = 1
TW>На тех машинах где было 0 ms стало 200 ms

А на тех, где было 200 мс, ничего не изменилось?

Pzz>А у тебя это точно задержки на одной стороне, а не round-trip?

Точно
Компы в соседнем офисе по кабелю. Реальный Ping 0 ms должен быть

// Master

repeat(20)
{
  Win32_Timer  Timer;
  //
  UCHAR a[0x10000];
  //
  Socket.Write(a, 1);
  //
  Socket.Read (a, 16);
  Socket.Read (a, 16);
  //
  Timer.Report(Log);
}

// Slave

repeat(20)
{
  Win32_Timer  Timer;
  //
  UCHAR a[0x10000];
  //
  Socket.Read (a, 1);
  //
  Socket.Write(a, 16);
  Socket.Write(a, 16);
  //
  Timer.Report(Log);
}

TW>>Закоментировал setsockopt TCP_NODELAY = 1
TW>>На тех машинах где было 0 ms стало 200 ms

Pzz>А на тех, где было 200 мс, ничего не изменилось?

Так же и осталось 200 мс

TW>1 машина Win7 — 0 ms delay
TW>1 машина win10 — 0 ms delay
TW>4 машины Win10 — 200ms delay

Ещё один Win10 комп — 0 ms

Так что не версия Windows

Здравствуйте, TailWind, Вы писали:

Pzz>>А на тех, где было 200 мс, ничего не изменилось?

TW>Так же и осталось 200 мс

Вот пишут, например, такие ужасы:

https://github.com/redis/hiredis/issues/785

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

Pzz>Дескать, TCP_NODELAY на некоторых экземплярах венды не очень-то работает с неблокирующимися сокетами, и _sleep(0) помогает.

У меня в блокирующем режиме

На всякий случай попробовал добавить Sleep(500) до и перед setsockopt
Не помогло

Что-то уже начинаю думать о Man in Middle, у которого Naggle не выключен
Типа антивируса

TW>>Что делать?
_>Используйте UDP

Я обломаюсь TCP стэк реализовывать сам
Потом не понятно как отвечать клиенту который за NAT

Проще уж 2048 байт добавлять к каждому пакету
Он тогда их отправляет сразу

Даже если:
2048
16
16
32
Сразу уходят

Здравствуйте, TailWind, Вы писали:

Pzz>>Дескать, TCP_NODELAY на некоторых экземплярах венды не очень-то работает с неблокирующимися сокетами, и _sleep(0) помогает.

TW>У меня в блокирующем режиме

Вообще, странно это очень. Я никогда не испытывал сложностей в венде с TCP_NODELAY и никогда не слышал о проблемах с этим. Что-то тут не так...

TW>Что-то уже начинаю думать о Man in Middle, у которого Naggle не выключен
TW>Типа антивируса

Вот так они и выдают себя, эти неаккуратные мужики посерёдке

Новые вводные

Проблемы только у исходящего подключения
У сокета который делает Connect

У сокета который делает Accept всё нормально

Проверил на двух компах в локальной сети

Там Dr.Web стоит. Думаю что это он.
Мы отключали там все опции, включая родительский контроль
Не помогает. Боюсь он до конца не отключается

Однажды у меня уже была с ним подобная история

Попросил сделать комп на котором стоит чистый Windows. Ждём

Здравствуйте, TailWind, Вы писали:

TW>Я обломаюсь TCP стэк реализовывать сам
TW>Потом не понятно как отвечать клиенту который за NAT
https://librats.com/ ?

TW>Проще уж 2048 байт добавлять к каждому пакету
TW>Он тогда их отправляет сразу

TW>Даже если:
TW>2048
TW>16
TW>16
TW>32
TW>Сразу уходят
Костыли они такие. Никто не гарантирует что в винде еще что-нибудь ещё фатально обновят. И не понадобится новая подпорка.
Просто детектируйте что есть проблемы и сообщайте клиенту, что его ось устарела и пусть обновляет или ставит linux.

ps: а вы смотрели wireshark-ом что там происходит в сети?
и советы от m$ https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/tcpip-performance-known-issues

Удалили DrWeb всё стало нормально

Причём просто выключение в нём всех опций не помогает. Только полное удаление

Здравствуйте, TailWind, Вы писали:

TW>Решение: удалить DrWeb

Если опустить шаманство: какая задача решается? Возможно, принцесса в другом замке, и дракона можно не убивать.