Контрольная сумма ТРМ201

[mega]

то, что вы языком C плохо владеете, было ясно еще по первому сообщению. совершенно не обязательно выставлять это напоказ.

интересное умозаключение :)
особенно интересно это слышать от человека, совершенно не понимающего битовую логику (я делаю такой вывод из посыла почитать тот самый документ, очевидные ошибки в котором я уже подчеркнул)

если это техподдержка "овен", сочуствую вашей администрации, т.к. ликбез в культуре общения и программирования тут неизбежен :))

[Дмитрий Егоренков]

это не умозаключение, а факт. ну ладно, я битовую логику не понимаю, вы-то вообще читать не умеете. посмотрите хотя бы раздел "3.3 структура кадра".

[Дмитрий Егоренков]

давайте читать вместе, как сказку на ночь.

--
"2.11 Каждое сообщение и квитанция передается старшими байтами вперед."

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

это положение имеет забавное следствие: строки в поле данных лежат старшим байтом вперед, то есть задом наперед.


"структурная схема протокола овен"

здесь нужно понять два момента. во-первых, пакет кодируется в ASCII прямо перед посылкой, и дальше мы будем обсуждать пакет в двоичном виде. во-вторых, в младших четырех битах второго байта пакета находится размер поля данных. так проще.

о порядке битов менее затейливые умы даже не задумываются. как обычно, старший бит слева, младший -- справа.


"3.1 Метод передачи байта "Тетрада-в-ASCII-символ"

особо сказать нечего. один байт превращается в два. старший из них опять передается первым (сюрприз!). сказкам про избыточность не верьте -- эффективность такой проверки очень низкая.


"3.3 Структура кадра"

для 11-битных адресов в первом байте пакета находятся _старшие_ восемь бит адреса. младшие три бита находятся в _старших_ битах второго байта пакета.

проще всего забыть про 11-битную адресацию, и считать, что весь адрес помещается в первом байте пакета.

дальше все просто. признак удаленного запроса -- это пятый бит второго байта. младшие четыре бита остаются для размера поля данных. несложно догадаться, что поле данных не может быть больше 15 байт.

блок данных канального уровня -- это дань модели взаимодействия открытых систем, применение которой только запутывает описание протокола. проще думать об этом блоке как о двух сущностях -- локальном идентификаторе (hash-коде) параметра и поле данных.

локальный идентификатор вы худо-бедно посчитали, так что перейдем к CRC.


"4.5 Хеширование имен параметров и вычисление контрольной суммы сообщения"

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

контрольная сумма помещается в пакет, (вы не поверите!) старшим байтом вперед.
--


истинному знатоку слова стандарт, виртуозу битовой логики и непревзойденному читателю RFC разобраться во всем этом будет несложно.


n'est ce pas?