Avensis 0 13 августа, 2012 Опубликовано 13 августа, 2012 · Жалоба Всем добрый день. Заранее прошу прощения за возможный оффтоп, но я не нашел более подходящей ветки. Перенесите плз, если не прав. Теперь к вопросу. Планируется выпуск устройства на базе ARM, которое будет получать инструкции от ПК. Должно поддерживать несколько интерфейсов, в т.ч. Ethernet и USB. Поток до 1 МБит/с. Данные представляют собой управляющие команды (как следствие, планируется пакетная передача) и терять их никак нельзя. Возникает главный вопрос: возможна ли теоретически потеря или порча данных в потоке TCP или USB? Вроде бы такого быть не должно, однако даже поиск по этой конференции показывает, что крайне редко в том же ТСР встречаются пакеты с битой КС на уровне приложения. Если допустить что раз в год и палка стреляет, то возможна такая ситуация, что будет испорчен заголовок команды. Тогда пакет будет принят некорректно, но самое страшное, что будет потеряно ожидаемое начало следующего пакета и т.п. Короче, возможен рассинхрон. Во избежание, придется любо городить некие таймауты для восстановления синхронизации, что не очень хорошо скажется на скорости работы, либо делать стаффинг, но мне не очень нравится реализовывать логику по сути канального уровня поверх транспортного. Либо делать еще что-то, чего мне в голову пока не пришло. Гуру, подскажите, как все таки правильно сделать надежный пакетный обмен? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Rst7 5 13 августа, 2012 Опубликовано 13 августа, 2012 · Жалоба однако даже поиск по этой конференции показывает, что крайне редко в том же ТСР встречаются пакеты с битой КС на уровне приложения. Если TCP/IP через Ethernet, то вероятность такой ситуации крайне мала - все таки две контрольных суммы (Ethernet и собственно TCP (хотя как раз у TCP слабенький контроль)). Так что можете забить. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Avensis 0 13 августа, 2012 Опубликовано 13 августа, 2012 · Жалоба Если TCP/IP через Ethernet Да, планируется использовать Ethernet. Так что можете забить. Вот тут говорят, что такое все же бывает. 1 раз в 25Мбайт в моем случае это раз в 3-4 минуты, что совершенно неприемлемо. Неприемлемо даже получать одну ошибку в несколько часов и если такая возможность существует, значит на уровне приложения необходимо принять меры для контроля и исправления ошибок. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Rst7 5 13 августа, 2012 Опубликовано 13 августа, 2012 · Жалоба Вот тут говорят, что такое все же бывает. 1 раз в 25Мбайт в моем случае это раз в 3-4 минуты, что совершенно неприемлемо. Разве там разговор за Ethernet? ;) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Avensis 0 13 августа, 2012 Опубликовано 13 августа, 2012 · Жалоба Разве там разговор за Ethernet? ;) Был не прав, признаю. :) Однако как расценить Вашу реплику: вероятность такой ситуации крайне мала Вероятность таки существует? Вообще, интересует как это делают серьезные ребята в промышленных протоколах? К сожалению в голову не идет ни один, который можно было бы посмотреть не утонув в нем на несколько дней . Там делают проверку данных на уровне приложения или нет? И как быть с USB? Там в Bulk передачах насколько я знаю тоже обещают гарантированную доставку как и в TCP/IP. Этому транспорту тоже можно верить? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Rst7 5 13 августа, 2012 Опубликовано 13 августа, 2012 · Жалоба Вероятность таки существует? Согласно квантовой теории существует ненулевая вероятность того, что правильный (с точки зрения CRC) пакет сам по себе в канале связи возникнет - флуктуации, все дела ;) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
KRS 0 13 августа, 2012 Опубликовано 13 августа, 2012 · Жалоба Согласно квантовой теории существует ненулевая вероятность того, что правильный (с точки зрения CRC) пакет сам по себе в канале связи возникнет - флуктуации, все дела ;) Если посадить за печатную машинку миллион обезьян-по теории вероятности, должен появиться еще один том "Войны и мир".... Однако, с развитием Интернета, стало понятно,что это не так! Автору - если у вас соединение с ПК в одном сегменте (т.е. без маршрутизаторов и т.п.) можно вообще обойтись без TCP и использовать UDP, а там если боитесь использовать еще и хеш и т.п. и конечно подтверждать прием команд. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Rst7 5 13 августа, 2012 Опубликовано 13 августа, 2012 · Жалоба Автору - если у вас соединение с ПК в одном сегменте (т.е. без маршрутизаторов и т.п.) можно вообще обойтись без TCP и использовать UDP, а там если боитесь использовать еще и хеш и т.п. и конечно подтверждать прием команд. Да излишне это все. TCP через Ethernet (особенно в одном сегменте) можно считать абсолютно надежным. Ну, если конечно, топикстартера не интересуют временные интервалы порядка возраста Вселенной ;) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Avensis 0 13 августа, 2012 Опубликовано 13 августа, 2012 (изменено) · Жалоба Автору - если у вас соединение с ПК в одном сегменте (т.е. без маршрутизаторов и т.п.) можно вообще обойтись без TCP и использовать UDP Не, UDP точно не пойдет. Предполагается работа в одном сегменте сети, но в условиях довольно серьезных помех и практика показала, что UDP очень даже ненадежен, если не прикрутить поверх него свою "гарантию" доставки. Да излишне это все. TCP через Ethernet (особенно в одном сегменте) можно считать абсолютно надежным. Ну, если конечно, топикстартера не интересуют временные интервалы порядка возраста Вселенной ;) Нет, космические временные интервалы меня не интересуют. Достаточно нескольких суток стабильной работы. Теперь про TCP/IP примерно понятно, спасибо! А про USB никто ничего не подскажет? Изменено 13 августа, 2012 пользователем Avensis Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
gerber 7 14 августа, 2012 Опубликовано 14 августа, 2012 · Жалоба А про USB никто ничего не подскажет? USB - в условиях сильных ЭМ помех крайне ненадёжен в плане передачи данных. Лично видел, как отваливалась USB клавиатура от компьютера при включении рядом мощной нагрузки. Могу порекомендовать посмотреть в сторону CAN - там на физическом уровне гарантируется доставка посылки с правильным CRC (передатчик передаёт до тех пор, пока приёмник не подтвердит аппаратно получение посылки). Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AlexandrY 2 14 августа, 2012 Опубликовано 14 августа, 2012 · Жалоба USB - в условиях сильных ЭМ помех крайне ненадёжен в плане передачи данных. Лично видел, как отваливалась USB клавиатура от компьютера при включении рядом мощной нагрузки. Могу порекомендовать посмотреть в сторону CAN - там на физическом уровне гарантируется доставка посылки с правильным CRC (передатчик передаёт до тех пор, пока приёмник не подтвердит аппаратно получение посылки). Ненадежен не USB, а потребительская техника. Работая с силовой электроникой постоянно наблюдаю как отваливается не только USB клавиатура, но USB COM порты, USB накопители, USB осциллографы. Монитор отваливается, который по VGA присоединен. Отваливается Ethenet свитч возле компа. Виснет Ethernet роутер. Бессмысленно говорить о надежности интерфейсов если они подключены к бытовому компу через дешевые свитчеры или хабы, без специальной инфраструктуры защит и заземлений. Там элементарно сетевой интерфейс может начать шалить, искажать пакеты, а потом добавлять к ним правильную CRC. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
aaarrr 56 14 августа, 2012 Опубликовано 14 августа, 2012 · Жалоба Работая с силовой электроникой постоянно наблюдаю как отваливается не только USB клавиатура, но USB COM порты, USB накопители, USB осциллографы. Ну, клавиатура - это все же особый случай. Развесистая такая антенна, если в дешевом исполнении. Особо продвинутые экземпляры виснут от срабатывания на небольшом отдалении зажигалки с пьезоэлементом. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
dinam 1 14 августа, 2012 Опубликовано 14 августа, 2012 · Жалоба Насчет надежности USB. Подключал своё устройство 5м кабелем напрямую PC. Щёлкали статикой по USB разъёмам и кабелю. Добились нормальной работы без глухих зависаний, ну т.е. когда спасает только отсоединение устройства. В течение рабочего дня просто гнали поток данных порядка 35-40 Мбайт/сек данных с проверкой на PC. Ни одного неправильного принятого байта. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Konst_777 0 14 августа, 2012 Опубликовано 14 августа, 2012 · Жалоба ...Планируется выпуск устройства на базе ARM, которое будет получать инструкции от ПК. Должно поддерживать несколько интерфейсов, в т.ч. Ethernet и USB. Поток до 1 МБит/с. Данные представляют собой управляющие команды... ...возможна ли теоретически потеря или порча данных в потоке TCP или USB?... ... подскажите, как все таки правильно сделать надежный пакетный обмен? У нас был следующий случай при выдаче команд от ПК модулю через USB. На ПК был установлен неверный драйвер для chipset-а материнской платы. В результате в модуль поступали совершенно произвольные данные. Модуль не подвисал только потому, что все команды были завернуты в пакеты (на уровне приложения) со следующей структурой: Тип пакета, Длина пакета, Команда и параметры, Контрольная сумма. То есть, не совпадала контрольная сумма и модуль отбрасывал все пакеты. Предположим, что Ваш модуль - это универсальный управляемый источник питания, формирующий на выходе питающие напряжения от 1.8 В до 48 В... :crying: Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Avensis 0 14 августа, 2012 Опубликовано 14 августа, 2012 · Жалоба Тип пакета, Длина пакета, Команда и параметры, Контрольная сумма. То есть, не совпадала контрольная сумма и модуль отбрасывал все пакеты. Это все понятно, только Ваш случай (по крайней мере, как он здесь описан) не дает желаемой защиты. Предположим, что у Вас в результате ошибки приема исказились первые 2 слова пакета. Безусловно, контрольная сумма не совпала, только вот незадача: Вы больше не знаете сколько еще нужно выгрести мусора из потокового канала, чтобы попасть на границу следующего пакета. Именно о подобных ньюансах восстановления синхронизации я и спрашиваю в данной ветке. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться