Какое обходное решение для подтверждения с задержкой TCP?

Начиная с Windows Vista параметр TCP_NODELAY должен быть установлен до вызова connect или (на сервере) до вызова listen . Если вы установите TCP_NODELAY после вызова connect , это не будет фактически отключить алгоритм Nagle, но GetSocketOption укажет, что Nagle отключен! Все это, как представляется, недокументировано и противоречит тому, чему учат многие учебники / статьи по этому вопросу.

Когда Nagle фактически отключен, отложенные подтверждения TCP перестают вызывать задержку.

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

Ваша проблема почти наверняка одна или обе из них:

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

2. Вы не реализовали подтверждения приложений на уровне приложений приложений. Реализуйте их так, чтобы ACK могли копировать их.

  

При таком подходе второй пакет данных будет принят   приемник примерно в то же время, что и предыдущий пакет данных. Как   результат, ACK должен немедленно отправляться от приемника к   отправителя (эмулируя то, что TcpAckFrequency = 1 делает в реестре).

Я не уверен, что это всегда вызовет отправку второго отдельного пакета. Я знаю, что у вас отключен Nagle и буфер нулевой отправки, но я видел более странные вещи. Может быть полезно использование некоторых свалок-сапог.

Одна идея: вместо вашего «канарейного» пакета, являющегося только одним байтом, отправьте полную стоимость данных MSS (как правило, что, 1460 байт в сети 1500 MTU).

Используйте надежные библиотеки UDP и напишите свой собственный алгоритм управления перегрузками, это, безусловно, преодолеет вашу проблему с задержкой TCP.

это следующая библиотека, которую я использую для надежных переносов UDP:

Ссылка

Чтобы решить проблему, необходимо понять нормальное функционирование TCP-соединений. Telnet - хороший пример для анализа.

TCP гарантирует доставку, подтверждая успешную передачу данных. «Ack» может быть отправлен как сообщение сам по себе, но это вводит довольно некоторые накладные расходы - Ack - очень маленькое сообщение, но протоколы более низкого уровня добавляют дополнительные заголовки. По этой причине TCP предпочитает копировать сообщение Ack в другой пакет, который он отправляет в любом случае. Глядя на интерактивную оболочку через Telnet, есть постоянный поток нажатий клавиш и ответов. И если есть небольшая пауза при наборе текста, на экране нечего эха. Единственный случай, когда поток останавливается, - если у вас есть выход без соответствующего ввода. Но так как вы можете читать только так быстро, нормально ждать несколько сотен миллисекунд, чтобы увидеть, есть ли нажатие клавиши, чтобы включить Ack.

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

Вернуться к протоколу: у вас, по-видимому, нет протокола запроса / ответа. Это означает, что Ack не может поддерживаться копией (проблема 1). И в то время как принимающая ОС будет отправлять отдельные Acks, это не будет спамом.

Ваше обходное решение через TCP_NODELAY и два пакета на стороне отправки (Windows) предполагает, что принимающая сторона также является Windows или, по крайней мере, ведет себя как таковая. Это желаемое за действительное, а не инженерное . Другая ОС может решить дождаться three пакетов для отправки Ack, что полностью нарушает ваше использование TCP_NODELAY , чтобы принудительно добавить дополнительный один пакет. «Подождите 3 пакета» - это всего лишь пример; существует много других правильных алгоритмов для предотвращения спама Ack, который не будет обманут вашим вторым однобайтным фиктивным пакетом.

Какое реальное решение? Отправьте ответ на уровне протокола. Вне зависимости от ОС, он будет копировать TCP Ack в ответ на ваш протокол. В свою очередь, этот ответ также заставит Ack в другом направлении (ответ тоже является TCP-сообщением), но вы не заботитесь о латентности ответа. Ответ есть только для того, чтобы принимающая ОС копировала первый Ack.

Я предлагаю вам оставить alogithm Nagle и буферы включенными, поскольку его основная цель - собрать мелкие записи в пакеты с полным / большим размером (это значительно повышает производительность), но в то же время используйте FlushFileBuffers () в сокете после того, как вы сделали отправку на некоторое время .

Я предполагаю, что в вашей игре есть своего рода основной цикл, который обрабатывает материал, а затем ждет времени, прежде чем перейти в следующий раунд:

while(run_my_game)
{
    process_game_events_and_send_data_over_network();
    Sleep(20 - time_spent_processing);
};

Теперь я предлагаю вставить FlushFileBuffers () перед вызовом Sleep ():

while(run_my_game)
{
    process_game_events_and_send_data_over_network();
    FlushFileBuffers(my_socket);
    Sleep(20 - time_spent_processing);
};

Таким образом, вы откладываете отправку пакетов в самое последнее время до того, как ваше приложение перейдет спать, чтобы дождаться следующего раунда. Вы должны получить преимущество по производительности от алгоритма Nagel и с минимальной задержкой.

Если это не сработает, было бы полезно, если бы вы разместили немного (псевдо) код, который объясняет, как работает ваша программа.

EDIT: Еще две вещи, которые приходили мне в голову, когда я снова думал о твоем вопросе:

a) Задержанные ACK-пакеты действительно должны NOT вызывать какое-либо отставание, поскольку они перемещаются в противоположном направлении передаваемых данных. В худшем случае они блокируют очередь отправки. Это, однако, будет разрешено TCP после нескольких пакетов, когда это разрешает полоса пропускания связи и памяти. Поэтому, если у вас нет действительно большой ОЗУ (недостаточно для хранения большей очереди сообщений), или вы действительно трассируете больше данных, чем позволяет ваше соединение, тогда отложенные паки ACK являются оптимизацией и фактически повышают производительность.

b) Вы используете выделенный поток для отправки. Интересно, почему. AFAIK является многопоточным безопасным Socket API, поэтому каждый продуктный поток может отправлять данные сам по себе - если ваше приложение не требует такой очереди, я бы предложил также удалить этот выделенный поток отправки и с ним дополнительные служебные данные синхронизации и задержать его может вызвать.

Я специально упоминаю о задержке здесь. Поскольку операционная система может решить не сразу назначить поток отправки для выполненияg еще раз, когда он будет разблокирован в своей очереди. Типичные задержки повторного планирования в диапазоне 10 мс, но под нагрузкой они могут увеличиться до 50 мс или более. В качестве рабочего стола вы можете попробовать fiddeling с приоритетами планирования. Но это не уменьшит задержку, налагаемую самой операционной системой.

Btw. вы можете легко тестировать TCP и свою сеть, просто имея один поток на клиенте и один на сервере, который просто воспроизводит пинг / понг с некоторыми данными.

  

каждый отправляемый пакет должен прибыть (и быть в порядке);

Это требование является причиной задержки.

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

  

Только когда пакеты могут быть отброшены / неупорядочены, UDP может быть быстрее TCP!

Это легкое предположение, но ошибочное.

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