Jump to content

    
Sign in to follow this  
VCucumber

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

Recommended Posts

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

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

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

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

Edited by Огурцов

Share this post


Link to post
Share on other sites
Та я и сам уже запутался ))))

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

. . .

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

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

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

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

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

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

 

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

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

 

 

 

 

 

 

Share this post


Link to post
Share on other sites
Длина пакета в заголовке нужна для правильной "засечки" что "пора проверять CRC

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

 

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

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

 

Share this post


Link to post
Share on other sites
. . .

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

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

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

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

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

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

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

 

 

 

Share this post


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

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

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

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

 

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

Share this post


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

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

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

 

 

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

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

 

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

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

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

Share this post


Link to post
Share on other sites
Вообще Вы правы, но вот эта ^^^^^^^^^^^^^^^^ирония неуместна.

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

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

. . .

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

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

. . .

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

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

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

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

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

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

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

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

Share this post


Link to post
Share on other sites

Блин.

Пацаны.

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

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

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

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

 

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

 

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

Share this post


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

 

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

 

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

 

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

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

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

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

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

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

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

 

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

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
так и не понял, чем ТС HDLC не подошел

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

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

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

 

 

 

Edited by Огурцов

Share this post


Link to post
Share on other sites
Однако точно существует накопленный человечеством опыт, который где-то однозначно обобщен.

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

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

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

Share this post


Link to post
Share on other sites
минимум это и надо

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

Share this post


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

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

Share this post


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

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

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

 

 

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

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

 

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this