Давайте тогда с самого начала :)
Какой у вас используется протокол под вашим DDF?
UDP?
Тогда вам нужен еще +1 слой программнго потверждения передачи данных, что тащит за собой еще больший оверхед по трафику, чем средства, предоставляемые TCP
Всегда интересно знать как он ездил.
Возьмите бумажку, и сделайте расчет в сутки: что будет, если вам вдруг придется настолько увеличить плотность пакетов, что их нужно будет слать пусть раз в 2 секунды. И посчитайте с учетом оверхеда от TCP сколько получится объем если посылать всегда полные пакеты, и по вашей сехе дельта-пакетыю. Вы удивитесь итоговой «экономии».
Идея с опорными кадрами в общем-то неплохая, но со стороны видны некоторые минусы.
1. В отладочных целях при разборе полетов протокол сам по себе теряет свою «самодостаточность». То есть произвольный кусочек лога протокла не несет всей полноты информации.
2. При потере связи чуть-чуть «правее» ключевого кадра ваша система будет назодиться в состоянии кирпича и обязана будет где-то буферизировать данные, ничего не показывая, пока не придет старый опорный кадр, за который мы «зацепимся» и от которого начнем плясать. А 5 минут — это время.
3. Если у вас ТСР, то при оверхеде этого протокола экономия на байтах сжирается заголовками ТСР, которые с радостью вам посчитают операторы.
И самое главное. С моей точки зрения, неприемлимо обзывание таких протоколов словами «патент» и «изобретение». Это обычная техническая реализация, у каждого таких наберется не один десяток. Потому побойтесь Летающего Макаронного Монстра, он вас проклянет.
Затруднительным, наверное, я зря назвал. Не настолько комфортным, скажем так, как работать с плеерами на тех же самых современных андроидах с 4х ядерными процессорами. Оно все работат, да. Но не так живо, как хотелось бы.
> Выбираем канал с амплитудой побольше и запускаем перехват на нем. В консоли появятся байтики GSM-трафика:
Ничего не получится. В GSM есть и должно работать по-нормальному такое понятие как frequency hopping, когда частота меняется по кругу около 200 раз в секунду. Это делается для лучшего приема. Если конкретно одна частота тут замирает, то 5 других будут работать, и потери качества будут почти незаметны. Не зная схемы перестановки. вы видите байтики от совершенно разных источников.
В Беларуси frequency hopping работал и работает. Было время, когда в России это дело было чуть ли не искусственно отключено, т.к. «с ним тяжелее перехватывать». Как сейчас обстоит дело — не в курсе.
Есть совершенно объективные «таблицы» и графики, показывающие уровень популярности тех или иных технологий. В РФ и пост-совке — да, Дельфи популярен в сегменте десктопных приложений для Win. Но а если посмотреть в мире?
Я сам писал и пишу на дельфи с 1996 года. Это не мешает мне объективно смотреть на мир и констатировать факт, что при всех плюсах технологии она в настоящий момент не живая. По разным причинам, но поезд этот ушел. Специалистов нет, подготовки нет, ничего нет. Технология стала маргинальной.
Непонятно, для чего это делать? Специалистов на Дельфи в мире почти не осталось. Те, кто остались, менее всего заинтересованы в каких-то планшетах: они сидят по НИИ в лабораториях и ждут пенсии.
Я раньше обожал делать подобные прототипы каких-то топологий, но еще смешне: на текстовых файлах.
То есть рисуется символьное поле, например 40х25, а символ = состояние либо категория
Какой у вас используется протокол под вашим DDF?
UDP?
Тогда вам нужен еще +1 слой программнго потверждения передачи данных, что тащит за собой еще больший оверхед по трафику, чем средства, предоставляемые TCP
Рассказывайте :)
Возьмите бумажку, и сделайте расчет в сутки: что будет, если вам вдруг придется настолько увеличить плотность пакетов, что их нужно будет слать пусть раз в 2 секунды. И посчитайте с учетом оверхеда от TCP сколько получится объем если посылать всегда полные пакеты, и по вашей сехе дельта-пакетыю. Вы удивитесь итоговой «экономии».
1. В отладочных целях при разборе полетов протокол сам по себе теряет свою «самодостаточность». То есть произвольный кусочек лога протокла не несет всей полноты информации.
2. При потере связи чуть-чуть «правее» ключевого кадра ваша система будет назодиться в состоянии кирпича и обязана будет где-то буферизировать данные, ничего не показывая, пока не придет старый опорный кадр, за который мы «зацепимся» и от которого начнем плясать. А 5 минут — это время.
3. Если у вас ТСР, то при оверхеде этого протокола экономия на байтах сжирается заголовками ТСР, которые с радостью вам посчитают операторы.
И самое главное. С моей точки зрения, неприемлимо обзывание таких протоколов словами «патент» и «изобретение». Это обычная техническая реализация, у каждого таких наберется не один десяток. Потому побойтесь Летающего Макаронного Монстра, он вас проклянет.
Вот-вот. Это делает постоянное использование такого плеера затруднительным.
Ничего не получится. В GSM есть и должно работать по-нормальному такое понятие как frequency hopping, когда частота меняется по кругу около 200 раз в секунду. Это делается для лучшего приема. Если конкретно одна частота тут замирает, то 5 других будут работать, и потери качества будут почти незаметны. Не зная схемы перестановки. вы видите байтики от совершенно разных источников.
В Беларуси frequency hopping работал и работает. Было время, когда в России это дело было чуть ли не искусственно отключено, т.к. «с ним тяжелее перехватывать». Как сейчас обстоит дело — не в курсе.
Сейчас к этому в ИТ индустрии несколько иное отношение.
Для чего это все?
Что будет с системой?
А почему генерируемые запросы не форматируются в более аккуратный «человеческий» вид?
То есть рисуется символьное поле, например 40х25, а символ = состояние либо категория
Насколько помню, так прототипировали и описывали движение погрузчиков на складе и т.п. :)