Сообщение Re[7]: Как вышло, что наложение предполагается по умолчанию? от 20.09.2021 16:20
Изменено 20.09.2021 16:22 Videoman
Re[7]: Как вышло, что наложение предполагается по умолчанию?
Здравствуйте, netch80, Вы писали:
N>Это был пример на заголовок IPv4 пакета. Там ровно эта проблема — порядок битов (даже не байтов). Сейчас из-за отсутствия таких определений приходится писать так:
N>
N>ну и далее по тексту.
N>Мало того, в IPv6 ещё злобнее получилось — поле flow label занимает в BE нумерации биты 12-31 (не знаю, нафига им столько), и если смотреть по байтам или шекам, то на LE машине оно разорвано на два несвязанных куска.
Ну было бы странно из-за одного IP заголовка тащить в стандарт такое сложное описание всяких возможных раскладок в памяти. Будет проще, если проблему big-endian/little-endial рассматривать просто как вариант очередной упаковки при сериализации. Мне кажется идея сразу работать с сетевым порядком пакетов в памяти не работает в общем виде. Дальше у нас появляются пакеты, где переменная (в битах) длина полей или наличие отсутствие полей зависит от каких-то дополнительных условий и что делать в этом случае?
Часто лучше "распаковать" пакет, поработать с ним, изменить как угодно, и "запаковать" обратно, чем пытаться работать с маппингом в памяти. Конечно, если у нас есть какая-то уже готовая структура, например на диске, и в ней нужно заменить один бит, тогда подход с распаковкой/запаковкой не сработает эффективно.
N>Это был пример на заголовок IPv4 пакета. Там ровно эта проблема — порядок битов (даже не байтов). Сейчас из-за отсутствия таких определений приходится писать так:
N>
N>struct iphdr
N> {
N>#if __BYTE_ORDER == __LITTLE_ENDIAN
N> unsigned int ihl:4;
N> unsigned int version:4;
N>#elif __BYTE_ORDER == __BIG_ENDIAN
N> unsigned int version:4;
N> unsigned int ihl:4;
N>#else
N># error "Please fix <bits/endian.h>"
N>#endif
N>N>ну и далее по тексту.
N>Мало того, в IPv6 ещё злобнее получилось — поле flow label занимает в BE нумерации биты 12-31 (не знаю, нафига им столько), и если смотреть по байтам или шекам, то на LE машине оно разорвано на два несвязанных куска.
Ну было бы странно из-за одного IP заголовка тащить в стандарт такое сложное описание всяких возможных раскладок в памяти. Будет проще, если проблему big-endian/little-endial рассматривать просто как вариант очередной упаковки при сериализации. Мне кажется идея сразу работать с сетевым порядком пакетов в памяти не работает в общем виде. Дальше у нас появляются пакеты, где переменная (в битах) длина полей или наличие отсутствие полей зависит от каких-то дополнительных условий и что делать в этом случае?
Часто лучше "распаковать" пакет, поработать с ним, изменить как угодно, и "запаковать" обратно, чем пытаться работать с маппингом в памяти. Конечно, если у нас есть какая-то уже готовая структура, например на диске, и в ней нужно заменить один бит, тогда подход с распаковкой/запаковкой не сработает эффективно.
Re[7]: Как вышло, что наложение предполагается по умолчанию?
Здравствуйте, netch80, Вы писали:
N>Это был пример на заголовок IPv4 пакета. Там ровно эта проблема — порядок битов (даже не байтов). Сейчас из-за отсутствия таких определений приходится писать так:
N>
N>ну и далее по тексту.
N>Мало того, в IPv6 ещё злобнее получилось — поле flow label занимает в BE нумерации биты 12-31 (не знаю, нафига им столько), и если смотреть по байтам или шекам, то на LE машине оно разорвано на два несвязанных куска.
Ну было бы странно из-за одного IP заголовка тащить в стандарт такое сложное описание всяких возможных раскладок в памяти. Будет проще, если проблему big-endian/little-endial рассматривать просто как вариант очередной упаковки при сериализации. Мне кажется идея сразу работать с сетевым порядком пакетов в памяти не работает в общем виде. Дальше у нас появляются пакеты, где переменная (в битах) длина полей или наличие отсутствие полей зависит от каких-то дополнительных условий и что делать в этом случае?
Часто, лучше "распаковать" пакет, поработать с ним, изменить как угодно, и "запаковать" обратно, чем пытаться работать с маппингом в памяти. Конечно, если у нас есть какая-то уже готовая структура, например на диске, и в ней нужно заменить один бит, тогда подход с распаковкой/запаковкой не сработает эффективно.
N>Это был пример на заголовок IPv4 пакета. Там ровно эта проблема — порядок битов (даже не байтов). Сейчас из-за отсутствия таких определений приходится писать так:
N>
N>struct iphdr
N> {
N>#if __BYTE_ORDER == __LITTLE_ENDIAN
N> unsigned int ihl:4;
N> unsigned int version:4;
N>#elif __BYTE_ORDER == __BIG_ENDIAN
N> unsigned int version:4;
N> unsigned int ihl:4;
N>#else
N># error "Please fix <bits/endian.h>"
N>#endif
N>N>ну и далее по тексту.
N>Мало того, в IPv6 ещё злобнее получилось — поле flow label занимает в BE нумерации биты 12-31 (не знаю, нафига им столько), и если смотреть по байтам или шекам, то на LE машине оно разорвано на два несвязанных куска.
Ну было бы странно из-за одного IP заголовка тащить в стандарт такое сложное описание всяких возможных раскладок в памяти. Будет проще, если проблему big-endian/little-endial рассматривать просто как вариант очередной упаковки при сериализации. Мне кажется идея сразу работать с сетевым порядком пакетов в памяти не работает в общем виде. Дальше у нас появляются пакеты, где переменная (в битах) длина полей или наличие отсутствие полей зависит от каких-то дополнительных условий и что делать в этом случае?
Часто, лучше "распаковать" пакет, поработать с ним, изменить как угодно, и "запаковать" обратно, чем пытаться работать с маппингом в памяти. Конечно, если у нас есть какая-то уже готовая структура, например на диске, и в ней нужно заменить один бит, тогда подход с распаковкой/запаковкой не сработает эффективно.