Подсчет потеряных пакетов при односторонней передаче данных (идея)

/**
Хотел написать на форум, но уж больно многа текста получилось — тянет на запись в бложике. Поэтому пусть тут полежит.
Эту идею я придумал сам, безо всякого анализа уже готовых решений. Поэтому если сегодня вечером был изобретен очередной велосипед — не ругайтесь :)
**/


Думал сегодня над тем как скрестить ланчапад, пинборд и пару китайских радиомодулей. В итоге получилась схема такого плана: ланчпад замеряет своим термодатчиком температуру и передает по радиоканалу раз в пять секунд; stm8 на пинборде анализирует срач в эфире, выделяет из него полезные данные и выводит на индикатор.

По ходу размышлений захотелось мне странного — анализировать количество потеряных пакетов. Ну и высчитывать из этого всякие прикольные числа и указывать на качество связи.


Концепция такая:
Ланчпад передает в каждом пакете его порядковый номер [packet_n] — 16 бит. При переполнении (ну мало ли, вдруг доживем :)) просто начинает счет с начала.

Принимающая сторона, словив первый пакет (это ведь не обязательно пакет №1 — если передатчик уже был включен), запоминает его номер [first_n]. С каждым пойманым пакетом инкрементируется счетчик принятых данных [data_count]. Так же в каждом пакете у нас есть его порядковый номер (с точки зрения ланчпада-передатчика) — [packet_n].

Теперь можно посчитать количество пакетов, которые успел передать ланчпад с момента включения приемника
= [packet_n] — [first_n] (номер такущего пакета минус номер первого, который мы засекли)
Сравнивая это значение с нашим собственным счетчиком можно узнать сколько пакетов мы пропустили.

Может возникнуть такая ситуация, что номер [packet_n] очередного пакета, внезапно, будет меньше чем номер предыдущего. Это может произойти в том случае, если счетчик у передатчика сбросится в промежутке между двумя долетевшими до приемника пакетами. В этой ситуации передатчик может просто начать счет с начала, приняв номер текущего пакета за [first_n]. Ну или как вариант — тупо увеличить разрядность счетчиков.

Гораздо более опасная ситуация — когда между двумя пакетами, долетевшими до приемника, счетчик на передатчике успеет переполнится и сброситься. Например, пусть счетчик восьмибитный: приемник ловит пакет #23, затем пропускает 300 пакетов и принимает пакет #67. В точки зрения приемника, он пропустил 67-23=44 пакета. Для борьбы с этим надо повышать разрядность счетчика (при 16битном счетчике нам придется пропустить > 65535 пакетов, чтоб вылезла эта ошибка), и/или устраивать таймауты типа «если пакетов нет уже пару минут, то связь упала — сбрасываем счетчики».

Для большей наглядности можно сбрасывать счетчик на приемнике после небольшого числа пакетов — например 10. Таким образом всегда будем знать, сколько пакетов из последних 10 (а не из всех) мы потеряли.

Как вам такое решение?
  • 0
  • 12 февраля 2012, 00:16
  • dcoder

Комментарии (7)

RSS свернуть / развернуть
ожидал что будет как на стороне передающего при односторонней связи определить:) вдуг какой суперхитрый метод для этого придумали:) а так идея конечно хорошая, но очевидная вроде:)
0
  • avatar
  • kest
  • 12 февраля 2012, 00:24
Экспромт:
Допустим у нас есть пульт от освещения, который питается солнечной батарейкой (да-да, зеленые беспроводные технолонии и всетакоепрочее). Пульт живет в том же помещении, что и освещение.
В этой ситуации можно следить за сигналом от солнечной батареи и таким образом проверять — отреагировала ли лампочка на команду.

А вообще в моем случае (датчик+передающий модуль), передатчику как-то насрать на то, дошел пакет или нет — это компенсируется большой частотой следования пакетов по сравнению со скоростью изменения температуры. Нельзя такие сложные предложения в воскресенье утром писать! Короче, посылки идут каждые 5 сек, а температура меняется медленно — пропустим 10 пакетов, не страшно.

А вот вести статистику со стороны приемника, просто для интереса, это ж святое дело :)
0
Абсолютно нормальное решение. Добавлю, что в несколько (существенно) более развернутом и навороченном виде очень похожая идея лежит в основе современных децентрализованных распределенных систем. Если будет к этому интерес, можете поинтересоваться eventual consistency и почитать, например, о zookeeper и системах которые его используют. Не знаю насколько это применимо во встраиваемых системах (просто не задумывался над возможными применениями), но тема сама по себе весьма интересная и, что достаточно редко случается в последние десятилетия в IT, довольно новая и не до конца исследованная.
0
  • avatar
  • evsi
  • 12 февраля 2012, 01:09
На тему встраиваемых систем — в двухстороннем варианте такой метод применён во многих протоколах связи. Например в IEC 60870-5-101/104, которых активно используется во всяких мелких девайсах.
0
В сигнализациях для автомобилей реализовано нечто вроде этого (с целью защиты). Вот хорошая статья на эту тему: steelrats.net/articles.php?article_id=194
0
Попробуй поиграться с синхронизацией на приемнике и передатчике. Профит от этого — можно приемник не держать все время включенным. Второй профит — можно не подрываться на шумы в эфире до истечения таймаута.

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

Сооответственно, количество пропущенных пакетов уже очевидно — по количеству провтыканных тайм-слотов.
0
1 зачем знать пропущенные пакеты при односторонней передаче?
2 если радиотракт без обработки сигнала, то там лучше использовать вышеописанный метод

т.е. приемник должен иметь компаратор, который выдает 1, когда есть уверенный прием на расстоянии хх метров
компаратор внешний обычно ставят или он уже стоит в модулях регенеративных приемниках
выход приемника заводят на инт0, с которого просыпается мк

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

сам снхросигнал длится 600мс, насколько я сейчас помню
0
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.