Перейти к содержанию
    

а не изобретаю ли я tcp ?

Теперь уж и не знаю зачем разработчики протоколов добавляют байт длины пакета во все протоколы где payload может иметь разную длинну))

программисты, сэр (с)

это вы ещё ip/tcp не видели - вот где курево

загадка, как они смогли, ибо верхние rfc - более чем вполне

Изменено пользователем Огурцов

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Та я и сам уже запутался ))))

Теперь уж и не знаю зачем разработчики протоколов добавляют байт длины пакета во все протоколы где payload может иметь разную длинну))

. . .

Например, для USART-канала, где должно быть обеспечено максимальное по скорости прием-обработка пакета и без его "накопления" в RAM.

Часть парсера распололожена в векторе прерывания. Это базовый анализ:

- тест на сигнатуру заголовка пакета (у меня это 00-00-00-55-AA)

- тест на длину пакета

- тест на правильную CRC

ЭТО проходит "налету". У меня по "результату" выдается 2 "положительных" кода возврата, когда пакет правильный, и штук 5 - "ошибочных" минусовых.

 

Длина пакета в заголовке нужна для правильной "засечки" что "пора проверять CRC", не дожидаясь завершения "паравоза", если

идет длинный некорректный пакет и в других случаях. CRC также считается налету, и при правильном пакете и его длине в аккумуляторе CRC == 0x0000.

 

 

 

 

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Длина пакета в заголовке нужна для правильной "засечки" что "пора проверять CRC

поздравляю, чо

 

CRC также считается налету, и при правильном пакете и его длине в аккумуляторе CRC == 0x0000

а без длины crc на ноль проверить - никак ?

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

. . .

а без длины crc на ноль проверить - никак ?

И что, после приема КАЖДОГО байта проверять CRC ? :)

К томуже есть большая вероятность, практически - гарантия, что в Вашем пакете подберется комбинация,

когда проверка CRC "сработает", и по такой методе будет принято решение что:

- пакет пришел полностью

- пкет правильный

Разве что использовать SHA256 какойнибудь :) . . . . :)

 

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

И что, после приема КАЖДОГО байта проверять CRC ? :)

Вообще Вы правы, но вот эта ^^^^^^^^^^^^^^^^ирония неуместна.

В большинстве случаев CRC апдейтится ("проверяется") таки на каждом байте, при его приеме и помещении во входной буфер - в обработчике прерывания по приему байта, если хотите.

Это ничего не стОит.

 

А вот Огурцову стОит рассмотреть ситуацию радиолинка, когда пойман маркер начала пакета, отловлен конец, и (о Боже!) CRC равна нулю, но было радиомолчание (или помеха) посредине, и по факту отловлено начало первого пакета и конец второго. Приехали? Знал бы длину, жил бы в Сочи...

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

CRC равна нулю, но было радиомолчание (или помеха) посредине, и по факту отловлено начало первого пакета и конец второго. Приехали? Знал бы длину, жил бы в Сочи...

ну приняли полпакета с байтом длины и полпакета с crc, а оно возьми да совпади, ага ?

лучше добавьте этот вредный бесполезный байт длины к crc и уменьшите вероятность ошибки ещё в 256 раз

 

 

И что, после приема КАЖДОГО байта проверять CRC ?

у меня возникает вопрос, почему у вас вообще возникает вопрос

 

К томуже есть большая вероятность, практически - гарантия, что в Вашем пакете подберется комбинация,

и эта вероятность описывается размером crc

если вам важно 2^-256, значит вы должны использовать 256

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Вообще Вы правы, но вот эта ^^^^^^^^^^^^^^^^ирония неуместна.

В большинстве случаев CRC апдейтится ("проверяется") таки на каждом байте, при его приеме и помещении во входной буфер - в обработчике прерывания по приему байта, если хотите.

Это ничего не стОит.

. . .

При наличии аппаратного узла CRC - да, затрат нет. Согласен.

ну приняли полпакета с байтом длины и полпакета с crc, а оно возьми да совпади, ага ?

. . .

Я примерно понял Ваши доп. вопросы, "о чем".

Ответить сразу не смогу, тк это из области мат. статистика и вероятностей, в которых я

не разбираюсь.

Те коды, которые "закрывают" блоки данных, которые передаются по каналам связи, лежан на носителях итд.

эффективны (очень) для единичных ошибок (бит, байт, десяток байт).

А если вы хотите чтобы была защита "от невозможного" - то тут "гарантия незащиты",

так как на бесконечное кол-во комбинаций и размеров данных есть только, например, 65536 - для CRC16 кодов.

Яж без претензий, IMHO

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Блин.

Пацаны.

Вы такую бодягу развели из темы "как два байта передать", что я дивлюсь просто.

А ответ-то простой.

"Каждый дрочет как хочет"©

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

 

Вообщем, "каждый дрочет как хочет".

 

Не существует единственно правильного для всех случаев "передать два байта"

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

Длина пакета в заголовке нужна для правильной "засечки" что "пора проверять CRC", не дожидаясь завершения "паравоза"
Не убедительно. Я могу начать провериять CRC когда принят признак конца пакета.

 

А вот Огурцову стОит рассмотреть ситуацию радиолинка, когда пойман маркер начала пакета, отловлен конец, и (о Боже!) CRC равна нулю, но было радиомолчание (или помеха) посредине
Таки простите за безграмотность, но как оценить вероятность такого исхода для CRC8 и CRC16 при длине пакета 64байта например? Да, логика подсказывает, что такое вполне может быть, вот только раз в сколько пакетов? Во сколько раз дополнительно проверяемый байт длины эту вероятность снижает?

 

К томуже есть большая вероятность, практически - гарантия, что в Вашем пакете подберется комбинация,

когда проверка CRC "сработает", и по такой методе будет принято решение что:

- пакет пришел полностью

- пкет правильный

Разве что использовать SHA256 какойнибудь

Т.е. в итоге получается, что байт длины просто существенно снижает вероятность принять битый пакет за нормальный? И это в итоге получается существенно дешевле, чем считать SHA256?

Такой вывод мы можем сделать из всей дискуссии?

 

лучше добавьте этот вредный бесполезный байт длины к crc и уменьшите вероятность ошибки ещё в 256 раз

Можно с этого момента по-подробнее? Это точно даст тот-же эффект, что и переданный отдельно байт длины или всё-таки нет?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

так и не понял, чем ТС HDLC не подошел. Для повтора есть кадры "неприем" и "селективный неприем". Кадры нумеруются и хранятся в окне вплоть до подтверждения приема канальным уровнем. Если не принят один из кадров окне, то повторяется только этот кадр. Если не приняты все кадры в окне (принят кадр за пределами окна), то повторяется передача всего окна начиная с неподтвержденного номера. Если соединение установлено, подтверждение производится асинхронно и никто никого не ждет.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

так и не понял, чем ТС HDLC не подошел

я застрял в окне

то, что получилось даже как-то работает, но выглядит неэстетично

да, структура кадра сейчас практически один в один, только без хендшейка

 

 

 

Изменено пользователем Огурцов

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Однако точно существует накопленный человечеством опыт, который где-то однозначно обобщен.

а чего-то там обобщать-то?

Если проблема решается путем 30-ти секундного размышления

Может Вам еще и как пользоваться туалетной бумагой нужно "обобщить опыт человечества"?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

минимум это и надо

Поскольку я говорил о полнодуплексном протоколе, Ваш ответ трактуется в т.ч. как "и мне бы такого хотелось, но не всё в моей власти".

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Может Вам еще и как пользоваться туалетной бумагой нужно "обобщить опыт человечества"?
Человечество обобщило очень много опыта, перед вводом в эксплуатацию туалетной бумаги )))

Было бы вам что ответить, Вы бы тут не пантовались, а что-то конкретное писали

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Поскольку я говорил о полнодуплексном протоколе, Ваш ответ трактуется в т.ч. как "и мне бы такого хотелось, но не всё в моей власти".

нет, он трактуется как минимум, т.е. окно размером 1 (или 2, как правильно)

а вот окно размером с размер буфера - это уже максимум

 

 

Если проблема решается путем 30-ти секундного размышления

и родится очередное "а первым байтом у нас пойдёт размер пакета"

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
К сожалению, ваш контент содержит запрещённые слова. Пожалуйста, отредактируйте контент, чтобы удалить выделенные ниже слова.
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...