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

Я отправляю пакеты через сокет 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; 
    } 
    } 
}

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

источник

2013-04-28 WilliamKF

Это выглядит нормально _if_ вы не переполняете 'buf'.(BTW, редактирование комментариев не отправляет уведомление.) – Mat

Вы можете использовать сниффер пакетов, чтобы выяснить, есть ли проблема на отправке или получении. –

@Mat Buf имеет длину около 1500 байтов, поэтому чтение 625 здесь значительно ниже размера buf. – WilliamKF

Тайна решена! Проблема заключалась в том, что 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.

источник

2013-05-24 23:57:57 WilliamKF

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

источник

2013-04-29 05:49:14 EJP

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

ответ

Смежные вопросы