Перейти к содержанию
    

Надежность потока TCP и USB bulk

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

 

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

 

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

Возникает главный вопрос: возможна ли теоретически потеря или порча данных в потоке TCP или USB? Вроде бы такого быть не должно, однако даже поиск по этой конференции показывает, что крайне редко в том же ТСР встречаются пакеты с битой КС на уровне приложения.

Если допустить что раз в год и палка стреляет, то возможна такая ситуация, что будет испорчен заголовок команды. Тогда пакет будет принят некорректно, но самое страшное, что будет потеряно ожидаемое начало следующего пакета и т.п. Короче, возможен рассинхрон.

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

Гуру, подскажите, как все таки правильно сделать надежный пакетный обмен?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

однако даже поиск по этой конференции показывает, что крайне редко в том же ТСР встречаются пакеты с битой КС на уровне приложения.

 

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Если TCP/IP через Ethernet

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

 

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Был не прав, признаю. :)

Однако как расценить Вашу реплику:

вероятность такой ситуации крайне мала

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Вероятность таки существует?

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

Нет, космические временные интервалы меня не интересуют. Достаточно нескольких суток стабильной работы.

Теперь про TCP/IP примерно понятно, спасибо!

А про USB никто ничего не подскажет?

Изменено пользователем Avensis

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

А про USB никто ничего не подскажет?

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

 

Ненадежен не USB, а потребительская техника.

Работая с силовой электроникой постоянно наблюдаю как отваливается не только USB клавиатура, но USB COM порты, USB накопители, USB осциллографы.

Монитор отваливается, который по VGA присоединен.

Отваливается Ethenet свитч возле компа. Виснет Ethernet роутер.

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

Там элементарно сетевой интерфейс может начать шалить, искажать пакеты, а потом добавлять к ним правильную CRC.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Работая с силовой электроникой постоянно наблюдаю как отваливается не только USB клавиатура, но USB COM порты, USB накопители, USB осциллографы.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

В течение рабочего дня просто гнали поток данных порядка 35-40 Мбайт/сек данных с проверкой на PC. Ни одного неправильного принятого байта.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

...возможна ли теоретически потеря или порча данных в потоке TCP или USB?...

... подскажите, как все таки правильно сделать надежный пакетный обмен?

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

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

Именно о подобных ньюансах восстановления синхронизации я и спрашиваю в данной ветке.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

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

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...