задает вопрос TCP_NODELAY в Windows Mobile

Question

У меня проблема с Windows Mobile 6.0. Я хотел бы создать TCP-соединение, которое не использовать алгоритм Nagle, поэтому он отправляет мои данные, когда я звоню "отправить" функцию, и не буферизует звонки, имея слишком небольшое количество данных.

Я попробовал следующее:

BOOL b = TRUE; setsockopt (socketfd, IPPROTO_TCP, TCP_NODELAY, (char *) (& b), sizeof (BOOL));

Отлично работает на рабочем столе. Но на Windows Mobile, если я установить это значение, чем я делаю запрос на него, возвращаемый значение равно 8. И анализ сетевого трафика показывает, что ничего не изменилось.

Есть ли способ вызвать сброс в мое гнездо?

Answer 1

Мне кажется, что опция TCP_NODELAY не поддерживается для Windows Mobile Edition. Посмотрите документацию MSDN, возможно, что-то в этом роде, но я помню, как некоторое время назад пытался установить несколько параметров сокетов, включая TCP_NODELAY и установить буфер отправки и получения, и вызов setsockopt завершился неудачей. Проверьте, что setsockopt возвращает false, если нет, получите :: WSAGetLastError () и посмотрите, приведет ли это вас куда-нибудь. В моем случае я помню, что мне приходилось обходиться без этих опций, поскольку они не поддерживались. Я работал на Windows Mobile 5.

Answer 2

Сервер выдан, я не могу его изменить, а именно: наш клиент Symbian прекрасно работает с этим, с этой опцией. Я пытался установить эту опцию как до, так и после создания соединения но ничего не изменилось. Я использую TCP через Центр устройств Windows Mobile (так как я использую Vista).

Answer 3

Мне просто пришло в голову, (это дикое предположение и, вероятно, маловероятно), но, возможно, у вас возникла проблема с задержкой подтверждения из-за того, что ваш буфер отправки меньше размера данных, которые вы пишете. Нагл может не иметь к этому никакого отношения.

Отправляет ли принимающая сторона данные обратно немедленно? Если нет, то ваш коллега будет задерживать подтверждение до 200 мс, ожидая, когда он получит ответ, а некоторые данные будут использоваться для более эффективного использования пропускной способности.

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

Например, если ваш буфер отправки составляет 8192 байта, а вы отправляете 8193 байта, а ваш одноранговый узел не отправляет данные обратно, тогда ваша запись будет блокироваться на 200 мс (или, как бы долго ни выполнялась ваша одноранговая реализация), эффективно создавая впечатление, будто Nagle убивает вы, даже когда он отключен.

Если это так, вы можете либо увеличить размер буфера отправки, либо ваш коллега всегда отправляет вам обратно нулевой байт, чтобы принудительно отправить ack.

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

Answer 4

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