Проблема чтения шестнадцатеричного буфера из сокета C - PullRequest
Новая
       13

Проблема чтения шестнадцатеричного буфера из сокета C

2 голосов
/ 18 марта 2010

Я использую API сокетов SDL_net для создания сервера и клиента. Я легко могу прочитать строковый буфер, но когда я пытаюсь отправить шестнадцатеричные данные, recv получает длину, но я не могу прочитать содержимое буфера. 

IPaddress ip;
TCPsocket server,client;
int bufSize = 1024;
char message[bufSize];
int len;

server = SDLNet_TCP_Open(&ip);
client = SDLNet_TCP_Accept(server);
len = SDLNet_TCP_Recv(client,message,bufSize);

Вот фрагмент. длина буфера " len " установлена ​​(то есть длина сообщения), но я не могу добраться до содержимого данных в буфере сообщений. Некоторые примеры данных bind_transmitter PDU были отправлены случайным клиентом на сервер в этом порту. Я не могу прочитать PDU (SMPP).

Ответы [ 3 ]

1 голос
/ 07 сентября 2012

используйте этот фрагмент в c ++ для неформатированного дампа шестнадцатеричного потока, предварительно сохраненного в буфере 

#include <ctype.h>
#include <stdio.h>
void hexdumpunformatted(void *ptr, int buflen) {
  unsigned char *buf = (unsigned char*)ptr;
  int i, j;
  for (i=0; i<buflen; i++) {
    printf("%02x ", buf[i]);
    printf(" ");
  }
}

вызов с 

hexadumpunformatted(buffer, bytecount);

адаптировано из превосходного фрагмента от Epatel (этот дает вам полностью отформатированный дамп).

1 голос
/ 23 ноября 2013

У меня была та же проблема, что и у вас на этой неделе. Я тестировал комбинацию сервер / клиент для отправки текстовых сообщений. Я подумал, что сделаю это таким образом, прежде чем перейти в гекс, просто чтобы проверить, так сказать, воду.

Но переход на двоичный файл был определенно болью. Для меня лучше всего работал такой буфер (только для recv (ing), я использовал другой буфер для объединения всех частей recv (ed)) 

unsigned char Buffer[data_size];
memset(Buffer, 0, data_size);

Выполнение этого способа работало очень хорошо для моих целей, один байт ff вывел бы хорошо 

0xff

вместо того, чтобы быть только буфером подписанных символов, который оставил бы мне 

0xffffffff

Таким образом, с точки зрения минимизации кода, было бы хорошо, если бы не нужно было останавливать любое форматирование.

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

1 голос
/ 20 марта 2010

Я бы посоветовал сначала проверить, что происходит на проводе, с помощью сниффера, например tcpdump или wireshark . Убедитесь, что отправленные байты соответствуют любому SMPP PDU . Если все в порядке, выведите буфер, считанный с помощью SDLNet_TCP_Recv(), с помощью hexdump(3) и посмотрите, соответствует ли он.

Некоторые примечания по коду:

  • Я не вижу, чтобы ip инициализировался где-либо, но я предполагаю, что вы просто пропустили эту часть при вставке кода.
  • int bufSize = 1024; char message[bufSize]; действительно только в C99 . Предполагая GCC , всегда компилируйте по крайней мере -Wall -pedantic, чтобы перехватить все предупреждения.
  • Буфер находится в стеке, поэтому, если вы передадите его какой-либо функции по цепочке вызовов, результат будет U ndefined B ehavior .

Я бы также попытался воспроизвести это с помощью простых сокетов Беркли , которые не намного сложнее, чем SDL, но гораздо веселее:)

...