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

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

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

Если TCP/IP через Ethernet, то вероятность такой ситуации крайне мала - все таки две контрольных суммы (Ethernet и собственно TCP (хотя как раз у TCP слабенький контроль)).

Так что можете забить.

Да, планируется использовать Ethernet.



Вот тут говорят, что такое все же бывает. 1 раз в 25Мбайт в моем случае это раз в 3-4 минуты, что совершенно неприемлемо. Неприемлемо даже получать одну ошибку в несколько часов и если такая возможность существует, значит на уровне приложения необходимо принять меры для контроля и исправления ошибок.

Разве там разговор за Ethernet?

Был не прав, признаю.
Однако как расценить Вашу реплику:

Вероятность таки существует? Вообще, интересует как это делают серьезные ребята в промышленных протоколах? К сожалению в голову не идет ни один, который можно было бы посмотреть не утонув в нем на несколько дней . Там делают проверку данных на уровне приложения или нет?
И как быть с USB? Там в Bulk передачах насколько я знаю тоже обещают гарантированную доставку как и в TCP/IP. Этому транспорту тоже можно верить?

Согласно квантовой теории существует ненулевая вероятность того, что правильный (с точки зрения CRC) пакет сам по себе в канале связи возникнет - флуктуации, все дела

Если посадить за печатную машинку миллион обезьян-по теории вероятности, должен появиться еще один том "Войны и мир".... Однако, с развитием Интернета, стало понятно,что это не так!

Автору - если у вас соединение с ПК в одном сегменте (т.е. без маршрутизаторов и т.п.) можно вообще обойтись без TCP и использовать UDP, а там если боитесь использовать еще и хеш и т.п. и конечно подтверждать прием команд.

Да излишне это все. TCP через Ethernet (особенно в одном сегменте) можно считать абсолютно надежным. Ну, если конечно, топикстартера не интересуют временные интервалы порядка возраста Вселенной

Не, UDP точно не пойдет. Предполагается работа в одном сегменте сети, но в условиях довольно серьезных помех и практика показала, что UDP очень даже ненадежен, если не прикрутить поверх него свою "гарантию" доставки.

Нет, космические временные интервалы меня не интересуют. Достаточно нескольких суток стабильной работы.
Теперь про TCP/IP примерно понятно, спасибо!
А про USB никто ничего не подскажет?

Сообщение отредактировал Avensis - Aug 13 2012, 13:56

USB - в условиях сильных ЭМ помех крайне ненадёжен в плане передачи данных. Лично видел, как отваливалась USB клавиатура от компьютера при включении рядом мощной нагрузки.
Могу порекомендовать посмотреть в сторону CAN - там на физическом уровне гарантируется доставка посылки с правильным CRC (передатчик передаёт до тех пор, пока приёмник не подтвердит аппаратно получение посылки).

Ненадежен не USB, а потребительская техника.
Работая с силовой электроникой постоянно наблюдаю как отваливается не только USB клавиатура, но USB COM порты, USB накопители, USB осциллографы.
Монитор отваливается, который по VGA присоединен.
Отваливается Ethenet свитч возле компа. Виснет Ethernet роутер.
Бессмысленно говорить о надежности интерфейсов если они подключены к бытовому компу через дешевые свитчеры или хабы, без специальной инфраструктуры защит и заземлений.
Там элементарно сетевой интерфейс может начать шалить, искажать пакеты, а потом добавлять к ним правильную CRC.

Ну, клавиатура - это все же особый случай. Развесистая такая антенна, если в дешевом исполнении. Особо продвинутые экземпляры виснут от срабатывания на небольшом отдалении зажигалки с пьезоэлементом.

Насчет надежности USB. Подключал своё устройство 5м кабелем напрямую PC. Щёлкали статикой по USB разъёмам и кабелю. Добились нормальной работы без глухих зависаний, ну т.е. когда спасает только отсоединение устройства.
В течение рабочего дня просто гнали поток данных порядка 35-40 Мбайт/сек данных с проверкой на PC. Ни одного неправильного принятого байта.

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

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

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