Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Отображение байтового формата в структуру.
|
|||
|---|---|---|---|
|
#18+
Доброго времени! Вопрос касается сетевого программирования. Есть предзаданный байтовый формат пакета. Их очень много различных. Хотелось бы минимальными усилиями и максимально эффективно описать формирователь каждого из пакетов. Видел очень много закрытого продакшн кода использующего для этого PACKED структуры. Их не рассматриваем: 1-е это не переносимо, так как многие процессоры генерируют исключение при доступе к невыровненному адресу. 2-е даже когда это перенеслось, все работает медленно. 3-е сам умею их готовить :)) У меня по сабжу два вопроса 1. Какие методы применяете вы для работы с конкретными байтовыми форматами 2. Если знаете будет классно привести ссылку на оперсорсный код по сабжу Код никсовых сетевых утилит смотрел, все пакеты разработаны так, чтобы доступ к полям автоматически получался выровненным, поэтому там просто описываются структуры без PACKED. Мне приходится иметь дело с пакетами с невыровненными полями. Самое первое что приходит в голову, так это делать как приведено ниже. Получается довольно громоздко. Причем, с ростом кол-ва полей, растет код функции установки каждого следующего поля. Посоветуйте какова общепринятая практика. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.08.2013, 11:30 |
|
||
|
Отображение байтового формата в структуру.
|
|||
|---|---|---|---|
|
#18+
sherzod_Мне приходится иметь дело с пакетами с невыровненными полями. Ну так тогда у тебя и выбора нет. Лично я пишу что-то такое: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. Всю магию по преобразованию endianess и прочие внутриформатные мелочи берут на себя геттеры. Всё знание о данных пакета инкапсулировано в классе. Вся иерархия классов легко разбивается по модулям для упрощения чтения. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.08.2013, 12:50 |
|
||
|
Отображение байтового формата в структуру.
|
|||
|---|---|---|---|
|
#18+
Мне в свои времена пришлось потратить не один человекомесяц на парсеры и мейкеры сетевых потоков. Паковка структуры как и сами структуры не очень подходят если протокол обмена имеет диалекты и может меняться и дополняться за время жизненного цикла. Я использовал интерфейсный класс над бинарным дампом, и синглетон-конфигуратор длин и смещений полей внутри дампа. Сначала такой подход кажется сложным, но потом решение получается более менее универсально-масштабируемо за разумное время. зы А почему не XML ?( риторический вопрос) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.08.2013, 19:53 |
|
||
|
Отображение байтового формата в структуру.
|
|||
|---|---|---|---|
|
#18+
Dimitry Sibiryakov Спасибо, за интересный метод. Возможно применю его при создании иерархии пакетов. Но для заголовков оверхед виртуальных функций и наследования мне немного не подходит. ДохтаР, Не XML и не protobuf, и не boost::serialization и не много чего еще потому, что форматы пакетов предзаданы. Так-то я бы что-нибудь из перечисленного использовал для транспорта. Вообще я поигрался с макросами и для заголовков пакетов у меня таки получился инструмент очень компактный, зацените (в перспективе его можно расширить и для поддержки массивов, но это еще вопрос надо ли): Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. что в итоге позволяет описывать структуру пакета с аксессорами (как в первом посте) вот так: Код: plaintext 1. 2. 3. 4. 5. 6. и работать с ней: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. PS Код макрофорича нарыл вот здесь . Только все это С++11, так как основано на variadic макросах. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.08.2013, 10:33 |
|
||
|
Отображение байтового формата в структуру.
|
|||
|---|---|---|---|
|
#18+
sherzod_ ДохтаР, Не XML и не protobuf, и не boost::serialization и не много чего еще потому, что форматы пакетов предзаданы . Так-то я бы что-нибудь из перечисленного использовал для транспорта. У меня тоже были предзаданы Спецификация формата обмена у вас есть ? или вы реверсинженерите? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.08.2013, 11:05 |
|
||
|
Отображение байтового формата в структуру.
|
|||
|---|---|---|---|
|
#18+
ДохтаРsherzod_ДохтаР, Не XML и не protobuf, и не boost::serialization и не много чего еще потому, что форматы пакетов предзаданы . Так-то я бы что-нибудь из перечисленного использовал для транспорта. У меня тоже были предзаданы Спецификация формата обмена у вас есть ? или вы реверсинженерите? Описания пакетов есть. Тогда я не очень понял зачем здесь XML. Мне нужно формировать пакет в массиве байт и считывать пакет из массива байт, в обоих случаях, конечно же логические оффсеты и размеры в массиве и составляют этот самый формат. Обычные сетевые заморочки. То есть заданы не структура сообщения, а именно структуры пакетов. То есть принимающая сторона или отправляющая, ожидают конкретные оффсеты и размеры в байтовом представлении. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.08.2013, 11:24 |
|
||
|
Отображение байтового формата в структуру.
|
|||
|---|---|---|---|
|
#18+
sherzod_ДохтаРпропущено... У меня тоже были предзаданы Спецификация формата обмена у вас есть ? или вы реверсинженерите? Описания пакетов есть. Тогда я не очень понял зачем здесь XML. По поводу XML был риторический вопрос. sherzod_Мне нужно формировать пакет в массиве байт и считывать пакет из массива байт, в обоих случаях, конечно же логические оффсеты и размеры в массиве и составляют этот самый формат. Обычные сетевые заморочки. То есть заданы не структура сообщения, а именно структуры пакетов. То есть принимающая сторона или отправляющая, ожидают конкретные оффсеты и размеры в байтовом представлении. В общем случае да, если нет метаполей, которые определяют длину поля. у меня такие извраты былиLL может быть длиной 1 или 2 байта. Например, если оно упаковано как один шестнадцатеричный байт, 0x27 означает, что далее следует 27 байт поля VAR. Если формат ASCII, два байта 0x32, 0x37 означают, что далее следует 27 байт (так как 0x32 - это код символа '2' в кодировке ASCII и т.п.). 3-цифирная длина поля LLL использует 2 байта с лидирующим 0x00 в упакованном режиме, или 3 байта в формате ASCII. Формат элемента данных VAR зависит от типа элемента данных. Если число было упаковано, то 87456 будет представлено 3 байтами 0x087456. В формате ASCII будет использоваться один байт для каждой цифры или символа, оно будет выглядеть, как 0x38 Длина разных полей могла кодироваться по разному , для каждого поля нужно было задавать свое правило. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.08.2013, 11:31 |
|
||
|
Отображение байтового формата в структуру.
|
|||
|---|---|---|---|
|
#18+
ДохтаРВ общем случае да, если нет метаполей, которые определяют длину поля. у меня такие извраты былиLL может быть длиной 1 или 2 байта. Например, если оно упаковано как один шестнадцатеричный байт, 0x27 означает, что далее следует 27 байт поля VAR. Если формат ASCII, два байта 0x32, 0x37 означают, что далее следует 27 байт (так как 0x32 - это код символа '2' в кодировке ASCII и т.п.). 3-цифирная длина поля LLL использует 2 байта с лидирующим 0x00 в упакованном режиме, или 3 байта в формате ASCII. Формат элемента данных VAR зависит от типа элемента данных. Если число было упаковано, то 87456 будет представлено 3 байтами 0x087456. В формате ASCII будет использоваться один байт для каждой цифры или символа, оно будет выглядеть, как 0x38 Длина разных полей могла кодироваться по разному , для каждого поля нужно было задавать свое правило. А, ну да, есть еще же всякие условности делающие структуру неоднозначной. Мне придется с этим еще только столкнуться. Для статичных заголовков, то что я привел выше на мой взгляд идеально. А для динамичных это да ручками придется делать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.08.2013, 12:10 |
|
||
|
Отображение байтового формата в структуру.
|
|||
|---|---|---|---|
|
#18+
sherzod_ДохтаРВ общем случае да, если нет метаполей, которые определяют длину поля. пропущено... Длина разных полей могла кодироваться по разному , для каждого поля нужно было задавать свое правило. А, ну да, есть еще же всякие условности делающие структуру неоднозначной. Мне придется с этим еще только столкнуться. Для статичных заголовков, то что я привел выше на мой взгляд идеально. А для динамичных это да ручками придется делать. Ручками поковыряться в коде, а потом подебаджить по локоть в ...... и ручками в конфигурации , как говорят в Одессе 2 большие разницы. Если писать универсальный код под конфигуратор , особое внимание нужно уделить отлову внештатных ситуаций , что бы при подсовывании конфига , по которуму нельзя распарсить правильный пакет вся программа не падала в кору. У меня библиотека парсинга-сборки около 7 000 строк получилась. где то 30 -40% кода в генераторах и обработчиках исключений . ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.08.2013, 12:18 |
|
||
|
Отображение байтового формата в структуру.
|
|||
|---|---|---|---|
|
#18+
ДохтаР если можно, разъясните подробнее в чем заключается ваш метод. Структуру метода, ключевые сущности, из вашего короткого описания, видимо по неопытности, я не могу ее представить: ДохтаРЯ использовал интерфейсный класс над бинарным дампом, и синглетон-конфигуратор длин и смещений полей внутри дампа. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.08.2013, 12:27 |
|
||
|
Отображение байтового формата в структуру.
|
|||
|---|---|---|---|
|
#18+
sherzod_ДохтаР если можно, разъясните подробнее в чем заключается ваш метод. Структуру метода, ключевые сущности, из вашего короткого описания, видимо по неопытности, я не могу ее представить: ДохтаРЯ использовал интерфейсный класс над бинарным дампом, и синглетон-конфигуратор длин и смещений полей внутри дампа. Класс поле. Класс сообщение ( массив или список полей). Иерархия классов конфигуратор поля( опрделяет длины смещения, нетривиальные кодировки и прочие параметры из конфигурационого файла). Класс конфигуратор сообщения ( массив, список или дерево конфигураторов полей). Иерархия классов нетривиальных кодировок, для правильного преобразования LL и LLL в числа из цитаты выше итд итп. Класс конфигуратор загружет метаинформацию из конфигурационного файла . Класс сообщение при создании обьекта инстанциируется конфиругатором. 3 класса в иерархии наследованной от std:logic_error один для выброса исключений с уровня обработчика поля, другой для выброса с уровня отработчика сообщения. Третий класс в иерархии обработки ошибок - отладочный. Список ошибок парсинга- сборки с расшифровками кодов . Циклы и рекурсии в обработчике сообщений. Приблизительно так. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.08.2013, 13:02 |
|
||
|
Отображение байтового формата в структуру.
|
|||
|---|---|---|---|
|
#18+
ДохтаР, Да вобщем-то, интересно. Своеобразное обскриптовывание парсинга. Можете показать пример конфигурации поля если это возможно? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.08.2013, 13:17 |
|
||
|
Отображение байтового формата в структуру.
|
|||
|---|---|---|---|
|
#18+
sherzod_ДохтаР, Да вобщем-то, интересно. Своеобразное обскриптовывание парсинга. Можете показать пример конфигурации поля если это возможно? Это было 10 лет назад , я даже не помню где исходники. приблизительно так Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. V - переменная длина поля( информаци о длине поля содержится в метаинформации поля) описание параметров метаинформации длины поля: 2 - длина длины ( LL из цитаты). R- правило выравнивание по левому или право краю. BCD - имя нетривиальной кодировки длины. 0x00 - символ заполения пустоты . F - фиксированная длина 19 - максимальная длина поля для полей переменной длины или длина для фиксированной. L - правило выравнивание поля по левому или право краю. ASCI кодировка поля 0xFF- символ заполения пустоты AMOUNT - название поля. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.08.2013, 13:46 |
|
||
|
Отображение байтового формата в структуру.
|
|||
|---|---|---|---|
|
#18+
ДохтаР, понятно спасибо. По сути это довольно простой конечный автомат. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.08.2013, 14:00 |
|
||
|
Отображение байтового формата в структуру.
|
|||
|---|---|---|---|
|
#18+
sherzod_ДохтаР, понятно спасибо. По сути это довольно простой конечный автомат. Был рад помочь. Логика конечного автомата простая, но на реализацию ушло не меньше 3 месяцев. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.08.2013, 14:08 |
|
||
|
Отображение байтового формата в структуру.
|
|||
|---|---|---|---|
|
#18+
ДохтаР, да я конечно имел в виду механизм работы:). Безусловно написание грамматики для него дело непростое совсем. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.08.2013, 14:23 |
|
||
|
Отображение байтового формата в структуру.
|
|||
|---|---|---|---|
|
#18+
в протоколе H.323 для описания структур используется ASN.1 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.08.2013, 14:43 |
|
||
|
Отображение байтового формата в структуру.
|
|||
|---|---|---|---|
|
#18+
Все это затевалось для того что бы эту штуку Код: plaintext 1. На лету для прикладного разработчика можно было преобразовать в эту Код: plaintext 1. 2. 3. Не изменив ни строчки кода в парсере-сборщике. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.08.2013, 14:43 |
|
||
|
|

start [/forum/topic.php?fid=57&msg=38364716&tid=2020045]: |
0ms |
get settings: |
8ms |
get forum list: |
12ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
72ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
46ms |
get tp. blocked users: |
1ms |
| others: | 13ms |
| total: | 168ms |

| 0 / 0 |
