Ошибки в Работе с TCP/IP в Delphi: Проблемы Сегментирования и Передачи Пакетов через Winsock2

Delphi , ОС и Железо , Windows

При работе с TCP/IP в среде Delphi могут возникать различные проблемы, связанные с сегментированием данных и передачей пакетов через Winsock2. Одной из таких проблем является некорректное поведение при передаче данных, превышающих размер MTU (Maximum Transmission Unit), что приводит к сегментации пакетов. В данной статье мы рассмотрим типичную проблему, связанную с ретрансляцией сегментов и увеличением номера последовательности в Winsock2, а также методы её решения.

Проблема

Разработчик столкнулся с проблемой при общении с кастомным клиентом, который представляет собой самодельную плату с FPGA, использующей Intel FPGA IP для Triple-Speed Ethernet. Проблема возникала независимо от наличия или отсутствия коммутатора между ПК и платой.

Проблемный процесс с точки зрения сервера (Windows ПК) выглядит следующим образом:

1. Установка соединения (Syn - Syn/Ack - Ack) с помощью функции Winsock2.connect.
2. Отправка данных, превышающих размер MTU, с использованием Winsock2.WSASend (4092 байта на MTU 4088 байт).
3. Сегментация пакета на два, при этом установлен бит "don't fragment".
4. Происходит ретрансляция (возможно, из-за медленного ответа клиента?).

Разработчик использует Delphi 10.4 и функции Winsock2. Перед каждой отправкой данных проверяется, что fdwrite установлено (с помощью FD_Isset). Алгоритм Nagle отключен.

Ретрансляция не происходит каждый раз и не поддается выявлению четкого паттерна. Однако чаще всего она возникает, когда клиент нуждается более чем в 30 миллисекундах для отправки ACK.

При ретрансляции не переотправляются первые два пакета, а первый пакет переотправляется со смещением, равным размеру полезной нагрузки второго пакета (60 байт), при этом номер последовательности первого пакета увеличивается на 60. Данные в переотправленном пакете корректны, и увеличение номера последовательности также верное (например, при отправке 6000 байт увеличивается на 1968).

Решение

После детального анализа проблемы было выявлено, что проблема заключается в так называемой "хвостовой потере" (tail loss probe), когда ответ от удаленного хоста запаздывает, и таймаут SRRT (Smooth Round Trip Time) истекает. Это означает, что проблема заключалась не в клиентском коде, а в поведении удаленного хоста, некорректно обрабатывавшего поступившие пакеты.

Примеры кода

Для демонстрации, ниже приведен пример функции отправки данных, использующей Winsock2:

function TZWinTCPSock.SendData(out ErrMsg: TAPILogStruct; SendOffset: Cardinal = 0): Boolean;
var
  WSABuff: WSABUF;
  res: Integer;
  IPFlags: Cardinal;
  WSAErr: Cardinal;
begin
  Result := FALSE;
  WSAErr := WSAGetLastError;
  try
    if not CheckSockValid(ErrMsg) then
    begin
      exit(false);
    end;
    try
      WSABuff.len := FMem.SendLength;
      WSABuff.buf := @FMem.SendData[SendOffset];
      IPFlags := 0;
      res := WSASend(FSocket, @WSABuff, 1, FMem.sentBytes, IPFlags, nil, nil);
      // Проверка результата выполнения WSASend и последующие действия
      // ...
    end;
  except
    on E: Exception do
    begin
      // Обработка ошибок
    end;
  end;
end;

Заключение

При работе с Winsock2 важно учитывать особенности протоколов передачи данных, такие как размер MTU и алгоритмы управления потоком, такие как Nagle. В данном случае проблема была не в коде клиента, а в поведении удаленного хоста, что подчеркивает важность тщательной диагностики при возникновении подобных ошибок.

Создано по материалам из источника по ссылке.

В статье рассматривается проблема сегментирования и передачи пакетов через Winsock2 при работе с TCP/IP в Delphi, связанная с неправильным поведением при ретрансляции и увеличением номера последовательности, что вызвано ошибками в обр

Комментарии и вопросы

Получайте свежие новости и обновления по Object Pascal, Delphi и Lazarus прямо в свой смартфон. Подпишитесь на наш Telegram-канал delphi_kansoftware и будьте в курсе последних тенденций в разработке под Linux, Windows, Android и iOS

:: Главная :: Windows ::