то, что вы языком C плохо владеете, было ясно еще по первому сообщению. совершенно не обязательно выставлять это напоказ.
то, что вы языком 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?
Ваши права
Ответить с цитированием