[Николай Семёнович 0]

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

Согласитесь, что это очень удобно.

Но если Вам это не нравится, поставьте байт длины в конец пакета и создайте себе геморой на пустом месте.

Говорю же "каждый дрочит как хочет"

 

И кстати. вначале может идти преамбула, потом адрес, а уж потом длина пакета.

 

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

[_pv 52]

esc последовательностью добавьте в поток данных пару команд,

1) комадна CRC, после которой идёт CRC последнего куска данных, которая заодно и на пакеты поток делит.

2) команда ACK, которую другая сторона посылает по получении комады CRC если контролная сумма совпала,

3) команда NACK, которую другая сторона посылает по получении комады CRC если контролная сумма не совпала, соответственно кусок данных с момента предыдущего CRC перепосылается.

 

а с Consistent Overhead Byte Stuffing можно без 100% оверхэда обойтись если данные в худшем случае из одних только esc. а то и поджать даже немножно с Zero Pair Elimination

[VCucumber 0]

Согласитесь, что это очень удобно.

геморрой - это не очень удобно

 

Говорю же "каждый дрочит как хочет"

жениться тебе, барин, надо

 

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

так же всё же как понять длину пакета по битому полю длины пакета ?

 

[sigmaN 0]

А он не понимает постановку вопроса. У него просто "дрочит как хочет" и всё ))

[Николай Семёнович 0]

так же всё же как понять длину пакета по битому полю длины пакета ?

А CRC в конце пакета на что?

Или сэру религия запрещается использовать её?

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

Чего тут обсуждать-то так долго? "Проблема" выеденного яйца не стоит.

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

Боишься что байт длины будет покоцан - ставь CRC в конце. Или передавай его трижды в разных форматах

Хочешь распознавать начало очередного пакета - делай преамбулу.

Что сложного то?

Чего тут обсуждать-то так долго?

Изменено 30 июля, 2017 пользователем Николай Семёнович

[VCucumber 0]

А CRC в конце пакета на что?

а конец где ?

 

Чего тут обсуждать-то так долго?

вычислить всех фанатов длины ?

 

hdlc https://git.kernel.org/pub/scm/linux/kernel...9811ebe443dafaa

[Николай Семёнович 0]

а конец где ?

В Караганде.

Толсто троллите :bb-offtopic:

[VCucumber 0]

это простой вопрос

из него следует следующий вопрос, который показывает абсурдность вашего утверждения

что вы в общем-то уже поняли

 

[Николай Семёнович 0]

Вот что тут может быть не понятно?

Байт длины в начале. Байт CRC в конце.

Положение "конца" определяем по байту длины.

Если байт длины испортился, то и CRC окажется не на своем месте и "испорченное" окажется.

Так узнаем что пакет "битый".

Что тут сложного-то?

:1111493779:

 

[VCucumber 0]

Если байт длины испортился

ок, был байт 1, стал 129 (ах как хорошо, что это не слово)

вы приняли 32 пакета по 4 байта как 1 пакет и отправили всё в мусорку, ибо crc не совпал

дальше вы принимаете следующий байт как длину, но это уже не длина, а какое-нибудь данное, ага

насяльника, всё паламалася

 

Что тут сложного-то?

действительно, нельзя же так тупить

Изменено 30 июля, 2017 пользователем Огурцов

[Николай Семёнович 0]

ок, был байт 1, стал 129 (ах как хорошо, что это не слово)

вы приняли 32 пакета по 4 байта как 1 пакет

Я чо?

Дурак что ли?

Я же знаю, что у меня пакеты длиной не более 6-ти байт

 

А если у вас признак конца пакета "испортился" и Вы приняли гигабайт пока не получили преамубулу очередного пакета?

То что Вы будете делать?

 

дальше вы принимаете следующий байт как длину, но это уже не длина, а какое-нибудь данное, ага

Повторяю вопрос: я что? Дурак что ли?

Может Вы и принимаете очередной байт за длину, а я жду преамбулу

 

действительно, нельзя же так тупить

Эвон как Вы себя.

Очень самокритично. Уважаю :beer:

 

Не тупите больше :beer:

 

И Вы так и не сказали, что за задача стоит?

Сделать супер пупер надёжный способ обнаружения порчи данных в канале?

Тогда смотрите в сторону CAN, там что пакет коцаный Вы определите уже на следующий бит.

Или нужно повысить надежность канала?

Тогда смотрите в сторону кодов с исправлениями ошибок.

Или используйте резервирование

А не велосипед изобретатйте.

Все спизж ... придумано уже до нас

[VCucumber 0]

А если у вас признак конца пакета "испортился" и Вы приняли гигабайт пока не получили преамубулу очередного пакета?

и чем же это плохо ? пакет по-любому битый, какая разница, когда буфер почистить, по концу этого или по началу следующего

 

Повторяю вопрос: я что? Дурак что ли?

в контексте обсуждаемого определённо да

 

Может Вы и принимаете очередной байт за длину, а я жду преамбулу

т.е. у вас есть какая-то преамбула, которая делит поток на пактеы

повторяю вопрос ещё раз - зачем посылать потенциально ошибочную длину пакета, если она без ошибок вычисляется во время приёма ?

 

Тогда смотрите в сторону CAN, там что пакет коцаный Вы определите уже на следующий бит.

вы читать умели ? - в компьютере нет can, но есть rs232

 

А не велосипед изобретатйте.

велосипед изобретать интереснее и полезнее, чем сломанные костыли

 

[Николай Семёнович 0]

и чем же это плохо ? пакет по-любому битый

У.. как все запущено.

Вы даже этого не понимаете?

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

Для Вас это не критично?

 

т.е. у вас есть какая-то преамбула, которая

Что значит "то есть"?

Вы не читаете что ли то, что я пишу? Тогда чего я стараюсь, объясняю? :maniac:

Я про преамбулу уже не раз писал

 

еы

повторяю вопрос ещё раз - зачем посылать потенциально ошибочную длину пакета, если она без ошибок вычисляется во время приёма ?

1) Почему Вы решили что "без ошибок"

2) Почему Вы решили, что "ошибочную". Её можно сделать не менее ошибочной, чем Ваш признак конца пакета

3) Чем раньше знаешь длину принимаемого пакета - тем лучше (надеюсь почему не нужно разжёвывать?)

4) "Каждый дрочит как хочет"© но в рамках ТЗ

 

вы читать умели ? - в компьютере нет can, но есть rs232

Конвертер "RS232 <-> CAN" религия не позволяет купить если Вы так боитесь что пакеты попортятся?

И Вы так не пояснили, какую цель преследуете

[Shivers 0]

Автор топика уже сам себе ответил в первом посте - TCP over RS-232. Видел такую штуку в действии. TCP вообще можно поверх любого физического уровня пустить, главное дрова найти.

Или здесь троллинг ради троллинга? :-)

[mantech 35]

Или здесь троллинг ради троллинга? :-)

По моему, здесь уже что-то, скатывающееся в маразм. Автор - явный перфекционист, хочет и на елку залезть и не поцарапаться. Уже сказано, что должна быть преамбула, я 2 ffки использую, как начало кадра, если кадр битый, жду снова преамбулу, затем адрес и длина пакета, данные и КС. Для лучшей синхронизации оставляю время "пустой линии", на 10 тактов уарта. Это протокол работает уже 10 лет в условиях помех и наводок по линиям 232 и 485 интерфейсов.