Почему я теряю этот байт в функции send ()? - PullRequest
Новая
       7

Почему я теряю этот байт в функции send ()?

1 голос
/ 12 февраля 2010

Наше приложение представляет собой сервер C (эта проблема относится к порту Windows указанного сервера), который взаимодействует с клиентом Windows Java. В этом конкретном случае мы отправляем данные клиенту, в частности, сообщение состоит из 7-байтового заголовка, где все первые 3 байта имеют определенное значение (тип операции, флаги и т. Д.), А последние 4 байта содержат размер Остальная часть сообщения. По какой-то причине я абсолютно не могу понять, третий байт в заголовке как-то меняется; если я ставлю точку останова на send(), я вижу, что третий байт - это то, что я ожидаю (0xfe), но когда я проверяю клиента, этот байт устанавливается в 0. Каждый другой байт в порядке , Я сделал некоторый захват трафика с помощью WireShark и увидел, что байт равен 0, покидая сервер, что я нахожу еще более странным. Третий байт устанавливается через определение, ala: 

#define GET_TOP_FRAME   0xfe

Некоторые тесты, которые я провел, еще больше запутывают проблему:

  1. Я изменил значение с использования определения на первое 0x64, 0xff, 0xfd: все попадало на клиента.
  2. Я изменил значение с использования определения на само использование 0xfe: значение было нулевым на клиенте.
  3. Я изменил значение самого определения с 0xfe на 0xef: значение было нулевым на клиенте.

Ничто в этом не имеет смысла. Код проходит несколько уровней функций, но вот основная часть кода: 

int nbytes; /* network order bytes */
static int sendsize = 7;
unsigned char tbuffer[7];
tbuffer[0]= protocolByte;
tbuffer[1]= op;
tbuffer[2]= GET_TOP_FRAME;
nbytes = htonl(bytes);
memcpy((tbuffer+3), &nbytes, JAVA_INT);

send(fd, tbuffer, sendsize, 0);

Где fd - это предварительно собранная розетка, protocolByte, op и bytes предварительно установлены. Затем он отправляет оставшуюся часть сообщения с очень похожей командой отправки сразу после этой. Как я уже говорил, если я поставлю точку останова на эту функцию отправки, tbuffer будет содержать именно то, что я ожидаю.

У кого-нибудь есть идеи? Я полностью в тупике; Ничто об этом не имеет смысла для меня. Спасибо.

Ответы [ 2 ]

1 голос
/ 12 февраля 2010

Возможно, где-то в вашей системе есть простая ошибка, которая делает простое переполнение буфера или подобное, но трудно сказать, где, учитывая эту небольшую информацию. Однако имейте в виду:

TCP не отправляет сообщения - это поток. Один вызов send () может занять несколько вызовов recv () для получения. один вызов recv может получить частичные «сообщения», определенные вашим приложением.

Проверяете ли вы возвращаемое значение send? А возвращаемые значения recv? send может отправить меньше байтов, чем вы говорите. recv может получить меньше байтов, чем вы говорите, или может получить больше данных, чем одно из «сообщений» вашего приложения, если вы предоставили ему достаточно большой буфер.

0 голосов
/ 12 февраля 2010

Оказывается, что-то еще мешало: в дополнение к серверу C у нас есть сервер Tomcat / Java, который как бы работает поверх всего; Я буду честен, я не вовлечен в эту часть развития, поэтому я не очень хорошо ее понимаю. Как выясняется, у нас есть некоторый код, который разделяется между этой промежуточной частью и нашим клиентом; этот общий код принимал этот конкретный байт, когда он покинул сервер, и, если он был установлен в 0xfe, устанавливал для него неинициализированное значение (отсюда и ноль). Затем, когда он добрался до клиента, это было неправильно. Вот почему, когда я устанавливал значения на разные вещи в коде C, он делал это с другой стороны, а также почему поведение казалось противоречивым; Я немного переключал значения в Java, чтобы увидеть, что происходит.

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

...