Надежность потока TCP и USB bulk, Возможна ли потеря данных? Опции

[Avensis]

Всем добрый день.

Заранее прошу прощения за возможный оффтоп, но я не нашел более подходящей ветки. Перенесите плз, если не прав.

Теперь к вопросу. Планируется выпуск устройства на базе ARM, которое будет получать инструкции от ПК. Должно поддерживать несколько интерфейсов, в т.ч. Ethernet и USB. Поток до 1 МБит/с. Данные представляют собой управляющие команды (как следствие, планируется пакетная передача) и терять их никак нельзя.
Возникает главный вопрос: возможна ли теоретически потеря или порча данных в потоке TCP или USB? Вроде бы такого быть не должно, однако даже поиск по этой конференции показывает, что крайне редко в том же ТСР встречаются пакеты с битой КС на уровне приложения.
Если допустить что раз в год и палка стреляет, то возможна такая ситуация, что будет испорчен заголовок команды. Тогда пакет будет принят некорректно, но самое страшное, что будет потеряно ожидаемое начало следующего пакета и т.п. Короче, возможен рассинхрон.
Во избежание, придется любо городить некие таймауты для восстановления синхронизации, что не очень хорошо скажется на скорости работы, либо делать стаффинг, но мне не очень нравится реализовывать логику по сути канального уровня поверх транспортного. Либо делать еще что-то, чего мне в голову пока не пришло.
Гуру, подскажите, как все таки правильно сделать надежный пакетный обмен?

[Konst_777]

...Планируется выпуск устройства на базе ARM, которое будет получать инструкции от ПК. Должно поддерживать несколько интерфейсов, в т.ч. Ethernet и USB. Поток до 1 МБит/с. Данные представляют собой управляющие команды...
...возможна ли теоретически потеря или порча данных в потоке TCP или USB?...
... подскажите, как все таки правильно сделать надежный пакетный обмен?

У нас был следующий случай при выдаче команд от ПК модулю через USB. На ПК был установлен неверный драйвер для chipset-а материнской платы. В результате в модуль поступали совершенно произвольные данные. Модуль не подвисал только потому, что все команды были завернуты в пакеты (на уровне приложения) со следующей структурой: Тип пакета, Длина пакета, Команда и параметры, Контрольная сумма. То есть, не совпадала контрольная сумма и модуль отбрасывал все пакеты.

Предположим, что Ваш модуль - это универсальный управляемый источник питания, формирующий на выходе питающие напряжения от 1.8 В до 48 В...

[Avensis]

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

Это все понятно, только Ваш случай (по крайней мере, как он здесь описан) не дает желаемой защиты. Предположим, что у Вас в результате ошибки приема исказились первые 2 слова пакета. Безусловно, контрольная сумма не совпала, только вот незадача: Вы больше не знаете сколько еще нужно выгрести мусора из потокового канала, чтобы попасть на границу следующего пакета.
Именно о подобных ньюансах восстановления синхронизации я и спрашиваю в данной ветке.

[Konst_777]

...Предположим, что у Вас в результате ошибки приема исказились первые 2 слова пакета...Вы больше не знаете сколько еще нужно выгрести мусора из потокового канала, чтобы попасть на границу следующего пакета...

В нашем случае длина пакета, в который была завернута команда, не превышала 64 байт. То есть, одного Bulk (Int) пакета USB в режиме Full Speed USB. А при обмене через USB, контроллер все равно принимает данные пакетами. Это при обмене по TCP/IP уже имеем дело с потоком. То есть, Вы хотите использовать TCP/IP over USB и таким образом использовать одно и то же ПО при обмене и через USB и через Ethernet?

...но мне не очень нравится реализовывать логику по сути канального уровня поверх транспортного...

Просто я привел пример, показывающий, что Вам все равно придется делать это.

[ReAl]

В нашем случае длина пакета, в который была завернута команда, не превышала 64 байт. То есть, одного Bulk (Int) пакета USB в режиме Full Speed USB.

А что, при переходе от RS232 к USB из протокола обмена командами SLIP-рамку убрали?
Я бы оставил... Свечка-то оно свечка, но бережёного…