VCucumber 0 27 июля, 2017 Опубликовано 27 июля, 2017 (изменено) · Жалоба Теперь уж и не знаю зачем разработчики протоколов добавляют байт длины пакета во все протоколы где payload может иметь разную длинну)) программисты, сэр (с) это вы ещё ip/tcp не видели - вот где курево загадка, как они смогли, ибо верхние rfc - более чем вполне Изменено 27 июля, 2017 пользователем Огурцов Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
k155la3 27 28 июля, 2017 Опубликовано 28 июля, 2017 · Жалоба Та я и сам уже запутался )))) Теперь уж и не знаю зачем разработчики протоколов добавляют байт длины пакета во все протоколы где payload может иметь разную длинну)) . . . Например, для USART-канала, где должно быть обеспечено максимальное по скорости прием-обработка пакета и без его "накопления" в RAM. Часть парсера распололожена в векторе прерывания. Это базовый анализ: - тест на сигнатуру заголовка пакета (у меня это 00-00-00-55-AA) - тест на длину пакета - тест на правильную CRC ЭТО проходит "налету". У меня по "результату" выдается 2 "положительных" кода возврата, когда пакет правильный, и штук 5 - "ошибочных" минусовых. Длина пакета в заголовке нужна для правильной "засечки" что "пора проверять CRC", не дожидаясь завершения "паравоза", если идет длинный некорректный пакет и в других случаях. CRC также считается налету, и при правильном пакете и его длине в аккумуляторе CRC == 0x0000. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
VCucumber 0 28 июля, 2017 Опубликовано 28 июля, 2017 · Жалоба Длина пакета в заголовке нужна для правильной "засечки" что "пора проверять CRC поздравляю, чо CRC также считается налету, и при правильном пакете и его длине в аккумуляторе CRC == 0x0000 а без длины crc на ноль проверить - никак ? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
k155la3 27 28 июля, 2017 Опубликовано 28 июля, 2017 · Жалоба . . . а без длины crc на ноль проверить - никак ? И что, после приема КАЖДОГО байта проверять CRC ? :) К томуже есть большая вероятность, практически - гарантия, что в Вашем пакете подберется комбинация, когда проверка CRC "сработает", и по такой методе будет принято решение что: - пакет пришел полностью - пкет правильный Разве что использовать SHA256 какойнибудь :) . . . . :) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Gorby 6 28 июля, 2017 Опубликовано 28 июля, 2017 · Жалоба И что, после приема КАЖДОГО байта проверять CRC ? :) Вообще Вы правы, но вот эта ^^^^^^^^^^^^^^^^ирония неуместна. В большинстве случаев CRC апдейтится ("проверяется") таки на каждом байте, при его приеме и помещении во входной буфер - в обработчике прерывания по приему байта, если хотите. Это ничего не стОит. А вот Огурцову стОит рассмотреть ситуацию радиолинка, когда пойман маркер начала пакета, отловлен конец, и (о Боже!) CRC равна нулю, но было радиомолчание (или помеха) посредине, и по факту отловлено начало первого пакета и конец второго. Приехали? Знал бы длину, жил бы в Сочи... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
VCucumber 0 28 июля, 2017 Опубликовано 28 июля, 2017 · Жалоба CRC равна нулю, но было радиомолчание (или помеха) посредине, и по факту отловлено начало первого пакета и конец второго. Приехали? Знал бы длину, жил бы в Сочи... ну приняли полпакета с байтом длины и полпакета с crc, а оно возьми да совпади, ага ? лучше добавьте этот вредный бесполезный байт длины к crc и уменьшите вероятность ошибки ещё в 256 раз И что, после приема КАЖДОГО байта проверять CRC ? у меня возникает вопрос, почему у вас вообще возникает вопрос К томуже есть большая вероятность, практически - гарантия, что в Вашем пакете подберется комбинация, и эта вероятность описывается размером crc если вам важно 2^-256, значит вы должны использовать 256 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
k155la3 27 28 июля, 2017 Опубликовано 28 июля, 2017 · Жалоба Вообще Вы правы, но вот эта ^^^^^^^^^^^^^^^^ирония неуместна. В большинстве случаев CRC апдейтится ("проверяется") таки на каждом байте, при его приеме и помещении во входной буфер - в обработчике прерывания по приему байта, если хотите. Это ничего не стОит. . . . При наличии аппаратного узла CRC - да, затрат нет. Согласен. ну приняли полпакета с байтом длины и полпакета с crc, а оно возьми да совпади, ага ? . . . Я примерно понял Ваши доп. вопросы, "о чем". Ответить сразу не смогу, тк это из области мат. статистика и вероятностей, в которых я не разбираюсь. Те коды, которые "закрывают" блоки данных, которые передаются по каналам связи, лежан на носителях итд. эффективны (очень) для единичных ошибок (бит, байт, десяток байт). А если вы хотите чтобы была защита "от невозможного" - то тут "гарантия незащиты", так как на бесконечное кол-во комбинаций и размеров данных есть только, например, 65536 - для CRC16 кодов. Яж без претензий, IMHO Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Николай Семёнович 1 28 июля, 2017 Опубликовано 28 июля, 2017 · Жалоба Блин. Пацаны. Вы такую бодягу развели из темы "как два байта передать", что я дивлюсь просто. А ответ-то простой. "Каждый дрочет как хочет"© Кому-то больше нравится байт длина в начале. Кому то признак конца пакета. Кому-то нравится резать пакеты на куски одинаковой длины. Вообщем, "каждый дрочет как хочет". Не существует единственно правильного для всех случаев "передать два байта" Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
sigmaN 0 28 июля, 2017 Опубликовано 28 июля, 2017 · Жалоба Не существует единственно правильного для всех случаев "передать два байта" Однако точно существует накопленный человечеством опыт, который где-то однозначно обобщен. Жаль, что никто так и не скинул ничего почитать. Длина пакета в заголовке нужна для правильной "засечки" что "пора проверять CRC", не дожидаясь завершения "паравоза" Не убедительно. Я могу начать провериять CRC когда принят признак конца пакета. А вот Огурцову стОит рассмотреть ситуацию радиолинка, когда пойман маркер начала пакета, отловлен конец, и (о Боже!) CRC равна нулю, но было радиомолчание (или помеха) посрединеТаки простите за безграмотность, но как оценить вероятность такого исхода для CRC8 и CRC16 при длине пакета 64байта например? Да, логика подсказывает, что такое вполне может быть, вот только раз в сколько пакетов? Во сколько раз дополнительно проверяемый байт длины эту вероятность снижает? К томуже есть большая вероятность, практически - гарантия, что в Вашем пакете подберется комбинация, когда проверка CRC "сработает", и по такой методе будет принято решение что: - пакет пришел полностью - пкет правильный Разве что использовать SHA256 какойнибудь Т.е. в итоге получается, что байт длины просто существенно снижает вероятность принять битый пакет за нормальный? И это в итоге получается существенно дешевле, чем считать SHA256? Такой вывод мы можем сделать из всей дискуссии? лучше добавьте этот вредный бесполезный байт длины к crc и уменьшите вероятность ошибки ещё в 256 раз Можно с этого момента по-подробнее? Это точно даст тот-же эффект, что и переданный отдельно байт длины или всё-таки нет? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
psL 0 28 июля, 2017 Опубликовано 28 июля, 2017 · Жалоба так и не понял, чем ТС HDLC не подошел. Для повтора есть кадры "неприем" и "селективный неприем". Кадры нумеруются и хранятся в окне вплоть до подтверждения приема канальным уровнем. Если не принят один из кадров окне, то повторяется только этот кадр. Если не приняты все кадры в окне (принят кадр за пределами окна), то повторяется передача всего окна начиная с неподтвержденного номера. Если соединение установлено, подтверждение производится асинхронно и никто никого не ждет. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
VCucumber 0 28 июля, 2017 Опубликовано 28 июля, 2017 (изменено) · Жалоба так и не понял, чем ТС HDLC не подошел я застрял в окне то, что получилось даже как-то работает, но выглядит неэстетично да, структура кадра сейчас практически один в один, только без хендшейка Изменено 28 июля, 2017 пользователем Огурцов Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Николай Семёнович 1 29 июля, 2017 Опубликовано 29 июля, 2017 · Жалоба Однако точно существует накопленный человечеством опыт, который где-то однозначно обобщен. а чего-то там обобщать-то? Если проблема решается путем 30-ти секундного размышления Может Вам еще и как пользоваться туалетной бумагой нужно "обобщить опыт человечества"? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Plain 226 29 июля, 2017 Опубликовано 29 июля, 2017 · Жалоба минимум это и надо Поскольку я говорил о полнодуплексном протоколе, Ваш ответ трактуется в т.ч. как "и мне бы такого хотелось, но не всё в моей власти". Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
sigmaN 0 29 июля, 2017 Опубликовано 29 июля, 2017 · Жалоба Может Вам еще и как пользоваться туалетной бумагой нужно "обобщить опыт человечества"? Человечество обобщило очень много опыта, перед вводом в эксплуатацию туалетной бумаги ))) Было бы вам что ответить, Вы бы тут не пантовались, а что-то конкретное писали Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
VCucumber 0 29 июля, 2017 Опубликовано 29 июля, 2017 · Жалоба Поскольку я говорил о полнодуплексном протоколе, Ваш ответ трактуется в т.ч. как "и мне бы такого хотелось, но не всё в моей власти". нет, он трактуется как минимум, т.е. окно размером 1 (или 2, как правильно) а вот окно размером с размер буфера - это уже максимум Если проблема решается путем 30-ти секундного размышления и родится очередное "а первым байтом у нас пойдёт размер пакета" Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
