Jump to content

    
syoma

Как оценить надежность декодирования для своего протокола?

Recommended Posts

Quote

А не проще уж тогда дублировать пакет? Все равно у вас почти 64 бита уже получается.

Вы ж смотрите, какие у меня требования.

Во первых канал передачи требует DC- балансировку. Т.е. это уже +2 бита к каждым 8-и, если использовать 8B10B кодирование. То есть получаем из 32-х бит уже 40 бит. Вы хотите дублировать пакет? Тогда это 80 бит.

Во вторых в то время, когда ничего не передается, на линии передается idle последовательность, то есть нужно еще распознавать начало пакета - т.е. нужен Start of Frame - это еще 10 бит. 

 

Вообще я не хочу обсуждать изменение протокола. Мне казалось, что мой вопрос достаточно простой - вот есть конкретные данные и есть контрольная сумма - типичный пакет для передачи по последовательному каналу.  Как просчитать и протестировать, насколько надежно в данном случае защищены эти данные?

Share this post


Link to post
Share on other sites

Нужно знать вероятность возникновения ошибок - одиночных, двойных, и т.д.

Нужно посчитать вероятность обнаружения таких ошибок. 

Ни одна контрольная сумма не соответствует некой уникальной последовательности битов. Есть много других последовательностей с той же суммой.

Share this post


Link to post
Share on other sites
1 hour ago, ViKo said:

Нужно знать вероятность возникновения ошибок - одиночных, двойных, и т.д.

Допустим это вероятность известна отдельно для каждого типа ошибок. Она же будет перемножаться с вероятностью обнаружения этих ошибок?

 

1 hour ago, ViKo said:

Нужно посчитать вероятность обнаружения таких ошибок. 

Вот и вопрос - как ее посчитать, если известен алгоритм подсчета контрольной суммы?

 

1 hour ago, ViKo said:

Ни одна контрольная сумма не соответствует некой уникальной последовательности битов. Есть много других последовательностей с той же суммой.

Это понятно.

Share this post


Link to post
Share on other sites

Если очень важна достоверность сообщения и есть достаточно вычислительных ресурсов посмотрите в сторону хеш функций к примеру MD5

Share this post


Link to post
Share on other sites
2 hours ago, vadon said:

Если очень важна достоверность сообщения и есть достаточно вычислительных ресурсов посмотрите в сторону хеш функций к примеру MD5

Вы цифру назовите!!!

Число, величину, значение, вероятность...

Как вам написать, чтобы было понятно? Вы читать умеете? :)

 

Вот тут:

On 7/30/2020 at 3:02 PM, syoma said:

Вообще я не хочу обсуждать изменение протокола. Мне казалось, что мой вопрос достаточно простой - вот есть конкретные данные и есть контрольная сумма - типичный пакет для передачи по последовательному каналу.  Как просчитать и протестировать, насколько надежно в данном случае защищены эти данные?

:biggrin:

Share this post


Link to post
Share on other sites
Quote

Вы цирфру назовите!!!

Число, величину, значение, вероятность...

на такой длине сообщения MD5 даст 100% достоверность сообщения. :acute:

Share this post


Link to post
Share on other sites
4 minutes ago, vadon said:

на такой длине сообщения MD5 даст 100% достоверность сообщения. :acute:

Вы как тот студент из сельхоза:

Quote

Студент сельхоза выучил на экзамен только строение блохи.

Ну тянет он билет — там строение собаки. Вот он и начинает:
— Собака — животное на четырех лапах, покрыто шерстью. А в шерсти водятся блохи…И дальше про блох все что знает.
Препод:
— Ладно, ладно. Расскажите нам о строении коровы.
— Ну, корова, это животное на четырех ногах, питается травой, покрыто шерстью. А вот в шерсти водятся блохи, ну и дальше по тексту.
— Ладно, хватит. Расскажите нам тогда про строение рыбы.
— Рыба живет в воде, шерсти у нее конечно нет, но вот если бы она у нее была, то в ней обязательно водились бы блохи…

:acute:

Share this post


Link to post
Share on other sites
1 hour ago, vadon said:

на такой длине сообщения MD5 даст 100% достоверность сообщения. :acute:

При длине хэша в 128 бит? Это хорошо, конечно :biggrin:

Share this post


Link to post
Share on other sites
2 hours ago, syoma said:

При длине хэша в 128 бит? Это хорошо, конечно :biggrin:

Ну зато 100%, ничего считать не надо, можно еще и анекдоты про собак почитать :biggrin:
А если по теме это к примеру я дал направление в какую сторону посмотреть хеш функций много и на разные случаи.

Фишка хеш функции что очень тяжело найти на определенной длине одинаковый хеш, это называется колизией (это и отлличает хеш от CRC если расматривать в контексте проверки целостности). В crc найти колизии очень просто. Нахождение колизий в хеш функциях занимается очень много народа за очень большие деньги. 


 

Share this post


Link to post
Share on other sites
25 minutes ago, vadon said:

Фишка хеш функции что очень тяжело найти на определенной длине одинаковый хеш, это называется колизией (это и отлличает хеш от CRC если расматривать в контексте проверки целостности). В crc найти колизии очень просто. Нахождение колизий в хеш функциях занимается очень много народа за очень большие деньги. 


 

CRC и есть хэш.  А вы наверно путаете с криптографическими хэшами типа SHA
Не поленитесь почитать википедию - https://en.wikipedia.org/wiki/List_of_hash_functions

Криптографические заточены на максимальную вариабельность от единственного различия,
а коммуникационные типа CRC  на гарантированную вариабельность от n-битного различия.

Так что советовать криптографические хэши здесь довольно глупо.

Share this post


Link to post
Share on other sites
On 7/30/2020 at 11:24 AM, arhiv6 said:

В этой статье сравнивали стойкость различных видов контрольных сумм. Т

в статье автор классифицирует стойкость CRC в зависимости от битности, что не совсем корректно,

вот тут постарался раскрыть почему это не так: http://idoka.ru/who-is-better-than-crc32/

 

 

On 7/30/2020 at 10:40 AM, syoma said:

В общем упрощаю задачу:

Надо передать четыре 8-и битных числа по последовательному каналу в виде одного пакета.

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

 

посмотрите что-то типа СС1101 TI - там в даташите хорошо расписано как сделана встроенная защита при передаче "коротких" пакетов

Share this post


Link to post
Share on other sites
On 8/3/2020 at 12:25 PM, vadon said:

на такой длине сообщения MD5 даст 100% достоверность сообщения. :acute:

про коллизии всё верно, но в данном кейсе хеши использовать небюджетно и расточительно:

получаем хеш из 32бит (перед этим "добив" нулями и длиной сообщения до 512бит) длиною 128 бит:

и получим что при равномерном распределении одиночных ошибок 80% сообщений с неповреждённым 32битным "телом" будут отбрасываться как повреждённые из-за md5.

 

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

 

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.