Сервер не получает конечные длинные значения в сокете c ++

Question

Сервер не получает конечные длинные значения в сокете c ++

0

Я передаю struct over socket с помощью c++. Я прочитал некоторые более ранние вопросы по отправке структур, и один из предложенных методов заключался в передаче с использованием символа char * after cast. Так как сервер и клиент находятся на одной машине, поэтому здесь нет проблем с контентом.

Здесь пара вопросов. Я получаю размер структуры как 48. По моим расчетам не должно быть 43? 8x4 + 10 +1

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

struct testStruct{
    char type;
    char field1[10];
    char field2[8];
    char field3[8];
    long num1, num2;
};


    testStruct ls;
    ls.type = 'U';

    strcpy(ls.field1, "NAVEENSHAR");
    strcpy(ls.field2, "abcd1234");
    strcpy(ls.field3, "al345678");
    ls.num1 = 40;
    ls.num2 = 200;
    char* bytes = static_cast<char*>(static_cast<void*>(&ls));
    bytes_sent = send(socketfd, bytes, sizeof(ls), 0);
    cout << "bytes sent: " << bytes_sent<< "\n";

    //On server sidechar
    incomming_data_buffer[1000];
    bytes_recieved = recv(new_sd, incomming_data_buffer,1000, 0);
    cout << "|" << incomming_data_buffer << "|\n";

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

Naveen Sharma 13 сен. 2014, в 10:12

Источник

1

sizeof(testStruct) - 48 из-за выравнивания . long s должны быть выровнены по sizeof(long) границы, которая, по-видимому, составляет 8 байт на вашем компьютере. char другой стороны, char должны быть выровнены только на 1 байт. У вас есть 27 байтов для первых четырех членов, поэтому компилятор должен добавить дополнительные отступы (5 байтов) между field3 и long для выравнивания для работы. Таким образом, 27 + 5 байтов = 32 байта, обеспечивая правильное выравнивание для двух long s (и объясняет 5-байтовое расхождение).
In silico 13 сен. 2014, в 07:35
1

Также обратите внимание, что ваши строковые поля слишком малы для строк, которые вы копируете в них - очевидно, вы не допустили терминатор \ 0. В будущем используйте strcpy, чтобы избежать повреждения памяти при возникновении такой ошибки.
Paul R 13 сен. 2014, в 07:44
0

@PaulR, \ 0 необходимо? Я использую только strcpy ? Не понял, что ты имел в виду.
Naveen Sharma 13 сен. 2014, в 07:54
0

Строки C всегда имеют завершающий символ \ 0, поэтому, например, «abcd1234» на самом деле состоит из 9 символов, все из которых будут скопированы strcpy и, следовательно, будут field2 после конца поля из 8 символов field2 .
Paul R 13 сен. 2014, в 09:19
0

@PaulR, спасибо, я перешел на memcpy. это должно сделать это.
Naveen Sharma 13 сен. 2014, в 11:42
0

Пока это будет работать, но лучшим решением было бы увеличить строковые поля и использовать strncpy для предотвращения переполнения буфера.
Paul R 13 сен. 2014, в 11:47
0

@PaulR, Дело в том, что сервер указал этот формат 10, 8, 8. Не могу точно сказать, примет ли он более длинные значения. попробую хотя.
Naveen Sharma 13 сен. 2014, в 11:49
0

ОК - в этом случае сохраняйте размеры буфера, но используйте strncpy для предотвращения переполнения.
Paul R 13 сен. 2014, в 11:54

Показать ещё 6 комментариев

Теги:

c++

struct

sockets

1 ответ

Ещё вопросы

sizeof(testStruct) - 48 из-за выравнивания . long s должны быть выровнены по sizeof(long) границы, которая, по-видимому, составляет 8 байт на вашем компьютере. char другой стороны, char должны быть выровнены только на 1 байт. У вас есть 27 байтов для первых четырех членов, поэтому компилятор должен добавить дополнительные отступы (5 байтов) между field3 и long для выравнивания для работы. Таким образом, 27 + 5 байтов = 32 байта, обеспечивая правильное выравнивание для двух long s (и объясняет 5-байтовое расхождение).
Также обратите внимание, что ваши строковые поля слишком малы для строк, которые вы копируете в них - очевидно, вы не допустили терминатор \ 0. В будущем используйте strcpy, чтобы избежать повреждения памяти при возникновении такой ошибки.
@PaulR, \ 0 необходимо? Я использую только strcpy ? Не понял, что ты имел в виду.
Строки C всегда имеют завершающий символ \ 0, поэтому, например, «abcd1234» на самом деле состоит из 9 символов, все из которых будут скопированы strcpy и, следовательно, будут field2 после конца поля из 8 символов field2 .
@PaulR, спасибо, я перешел на memcpy. это должно сделать это.
Пока это будет работать, но лучшим решением было бы увеличить строковые поля и использовать strncpy для предотвращения переполнения буфера.
@PaulR, Дело в том, что сервер указал этот формат 10, 8, 8. Не могу точно сказать, примет ли он более длинные значения. попробую хотя.
ОК - в этом случае сохраняйте размеры буфера, но используйте strncpy для предотвращения переполнения.

Mats Petersson · Accepted Answer · 2014-09-13T05-36-00.000Z

Вы почти наверняка получаете все данные. Проблема заключается в этой строке:

cout << "|" << incomming_data_buffer << "|\n";

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

Вы можете попробовать сделать что-то вроде:

cout << "|";
for (int i = 0; i < bytes_received; i++)
{
    cout << hex << (((int)incomming_data_buffer[i]) & 0xff) << " ";
}
cout << "|\n";

для отображения всех байтов полученного пакета.

Я попробовал это, но получил некоторые странные ошибки cout, которые invalid operands of type int and char[2] for operator <<
Нужен другой набор скобок вокруг математического выражения с & 0xff . Сейчас отредактировано.
Я вижу все полученные байты, но я думаю, что сервер хочет, чтобы long немедленно начал публиковать третье поле char. Есть ли способ добиться этого и избежать заполнения?
Ваш лучший вариант - написать код, который сериализует данные в буфер байтов. Несмотря на то, что существуют способы, которыми можно заставить множество компиляторов упаковать структуру, существует также много процессорных архитектур, в которых чтение невыровненного (не дополненного) фрагмента данных приведет либо к неверному результату, либо к сбою.