Что может привести к тому, что порядок байтов в моем пакете станет частично зашифрованным?

Question

Что может привести к тому, что порядок байтов в моем пакете станет частично зашифрованным?

Я отправляю пакеты через сокет TCP между машиной Linux Centos 4 и машиной Windows XP, на которой работает Interix с Gentoo. Когда пакет получен Interix, около 10% символов последовательно скремблируются с одинаковыми смещениями от начала пакета. На отправляющей стороне Linux пакет имеет следующее правильное содержимое:

Но на Interix содержимое пакета слегка перемешано (но большинство верно):

Я указал на различия с ^ символы выше. Там может быть еще пара символов вокруг y учитывая повторное / будет скрывать дополнительные символы, которые были перемещены в этом разделе.

Этот код отлично работает между несколькими парами платформ:

Linux и Linux
Linux и BSD
Linux и Cygwin

Может ли это быть ошибкой в коде Interix и Gentoo? Я работаю на Windows XP, Interix v3.5. Я заметил, что все правильные символы присутствуют, но их порядок последовательно зашифрован, части поменялись местами, другие вырезаны и вставлены заново в другом месте. Пакет читается на принимающей стороне с ::read() в дескрипторе файла сокета TCP. Здесь много кода, поэтому я не уверен, какие части будут наиболее релевантными для включения, но постараюсь добавить больше кода, если будут сделаны конкретные запросы.

const int fd; // Passed in by caller.
char *buf;    // Passed in by caller.

size_t want = count; // This value is 625 for the packet in question.
// As ::read() is called, got is adjusted, until the whole packet is read.
size_t got = 0;

while (got < want) {
// We call ::select() to ensure bytes are available before calling ::read().
ssize_t result = ::read(fd, buf, want - got);

if (result < 0) {
// Handle error (not getting called, so omitted).
} else {
if (result != 0) {
// We are coming in here in one try and got is set to 625, the amount we want...
// Not an error, increment the byte counter 'got' & the read pointer,
// buf.
got += result;
buf += result;
} else { // EOF because zero result from read.
eof = true; // Connection reset by peer.
break;
}
}
}

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

4

c++corruption endianness sockets tcp

Решение

Другие решения

Тайна разгадана! Проблема заключалась в том, что off_t был 32-разрядным на компьютере с Windows XP и 64-разрядным на компьютере Centos. Когда пакет отправлен, его структура памяти включает в себя off_t Объекты помещаются из хоста в сетевой порядок байтов (от младшего к старшему), а затем на машине с Windows, когда он получает пакет, он возвращается из сети на хост. Поскольку расположение памяти отличалось, я видел скремблирование, показанное выше.

Я решил проблему, используя свой собственный soff_t везде это 64 бит в ширину.

Однако затем я столкнулся с другой проблемой, когда компилятор не упаковывал структуру одинаково на обеих машинах и в окнах вставлял 4 байта, чтобы выровнять длинные длинные 8 байтов, тогда как на Centos он этого не делал:

typedef struct Option
{
char[56]    _otherStuff;
int         _cpuFreq;
int         _bufSize;
soff_t      _fileSize;    // Original bug fixed by forcing these 8 bytes wide.
soff_t      _seekTo;      // Original bug fixed by forcing these 8 bytes wide.
int         _optionBits;
int         _padding;     // To fix next bug, I added this 4 bytes
long long   _mtime;
long long   _mode;
} __attribute__ ((aligned(1), packed)) Option;

Я использовал __attribute__ ((aligned(1), packed)) заставить упаковку быть последовательной и плотной, но в Windows XP это не было или не могло быть выполнено. Я решил это, добавив _padding заставить следующий 8-байтовый элемент выровняться по 8 байтам на Centos и, таким образом, согласиться с Windows XP.

0

Источник

Accepted Answer

Я бы сказал, что у вас есть ошибка параллелизма на ‘buf’ или, возможно, дубликат free() или повторное использование после free(),

0