Pull to refresh

Comments 20

Идея с опорными кадрами в общем-то неплохая, но со стороны видны некоторые минусы.

1. В отладочных целях при разборе полетов протокол сам по себе теряет свою «самодостаточность». То есть произвольный кусочек лога протокла не несет всей полноты информации.

2. При потере связи чуть-чуть «правее» ключевого кадра ваша система будет назодиться в состоянии кирпича и обязана будет где-то буферизировать данные, ничего не показывая, пока не придет старый опорный кадр, за который мы «зацепимся» и от которого начнем плясать. А 5 минут — это время.

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

И самое главное. С моей точки зрения, неприемлимо обзывание таких протоколов словами «патент» и «изобретение». Это обычная техническая реализация, у каждого таких наберется не один десяток. Потому побойтесь Летающего Макаронного Монстра, он вас проклянет.

1. На самом деле, DDF — лишь часть общей технологии передачи данных. Помехозащищённый протокол передачи — другая её часть. Он-то и не позволить оказаться на сервере «кусочкам лога». У всех «кусочков» есть уникальные номера, и прибор не успокоится, пока сервер не соберёт их все.
2. Почему? Есть последний опорный кадр, есть изменения. Где закончили там и начали. Это в Вас говорит страх потерять пакеты, но обсуждаемый протокол пакетов не теряет.
3. TCP не используется
Патент нужен не для понтов, а для реальной защиты. Интересный факт — патентный юрист в США, занимавшийся проектом, сам бывший электронщик и у него даже есть патент в области мониторинга. Он капитально переработал текст, великолепная работа, выполненная с пониманием и профессионально.
Собственно интерес к теме весьма радует и сам по себе показателен.
UFO just landed and posted this here
Теория поверяется практикой, нет? Практика говорит о том, что потерь нет. Потери данных были на начальных этапах, в течение 2010 года, скорее даже первой его половины, когда отрабатывались элементы, не описанные в обсуждаемом посте. Собственно, суть DDF, описанная в патентах — не изменялась, изменялся «транспорт» до сервера.
UFO just landed and posted this here
В первую очередь — в расчёте на стремительный рост потребности в увеличении объёма передаваемых данных в будущем. Задача «посмотреть на карте — где этот охламон?» уже не то чтобы не интересна, но она как бы банальна. Сегодня интересно знать — как ездил. А тут или надеяться на обработку в приборе (что не есть гуд, ибо возможности оперативной кастомизации такой обработки сильно ограничены, да и мощности не беспредельны), или — всё-таки передавать всё. Скажу больше — есть ряд потребителей, для которых алгоритмы обработки данных суть коммерческая тайна. Им нужны только сырые данные.
А сети развиваются (за пределами городов) не столь быстро, как растёт объём передаваемых по ним данных. Так что конкуренция между устройствами за доступ к каналу пока что растёт.
UFO just landed and posted this here
285-й появился позже. С другой стороны, «терминал-285» в чистом виде не решит многих задач. Он решит надуманные задачи («сферический конь в вакууме»?), которые за клиентов сформулировали в Москве. Но их-то не спросили — чего им нужно. Это сегодня. Завтра разрыв «устройства 285» с реальностью будет ещё больше.
Я сейчас говорю: потребность в передаче данных растёт быстрее, чем развиваются сети за пределами мегаполисов. Дальнейшее увеличение пропускной способности лежит в области более высоких частот, а физика нам как бы намекает, что при этом дальность радиосвязи отнюдь не возрастает, а как бы катастрофически падает. То есть для охвата федеральных трасс сетью 4G понадобится вышек в разы больше, и большей высоты. Отражёнка падает, поглощение растёт…
Так что передача фото за городом — пока что из области фантастики.
UFO just landed and posted this here
Вы читали 285-й? Он регламентирует оснащение ТС, лицензируемых для перевозки опасных грузов и для коммерческой перевозки пассажиров. Всё. У нас из этого Приказа делают фетиш лишь те, у кого нет нормальных продаж. Приходят к руководителям автопредприятий и пугают страшным 285-м Приказом :)
Про распространённость давайте не будем, это Хабр, тут неуместно обсуждать коммерцию. В принципе. Зря я вообще упомянул об этом, mea culpa, mea maxima culpa! Компания существует, цель компании чётко сформулирована на оф. сайте, и она не предусматривает прогиб под 285-й Приказ и многое другое. В том числе тотальное завоевание рынка. Скажем так: мы делаем то, что нам интересно делать, и получаем за это достаточно, чтобы продолжать. Мы довольны существующим положением вещей, как и наши клиенты.
UFO just landed and posted this here
Я считаю наши продажи нормальными для компании с такой численностью сотрудников. Если бы нас было втрое больше при наших продажах — это был бы epic fail. Если бы нас было при наших оборотах втрое меньше — это навело бы на мысли о том, что мы тут героин расфасовываем.
Вы действительно настроены обсуждать коммерческие вопросы? Я — нет.
Всегда интересно знать как он ездил.
Возьмите бумажку, и сделайте расчет в сутки: что будет, если вам вдруг придется настолько увеличить плотность пакетов, что их нужно будет слать пусть раз в 2 секунды. И посчитайте с учетом оверхеда от TCP сколько получится объем если посылать всегда полные пакеты, и по вашей сехе дельта-пакетыю. Вы удивитесь итоговой «экономии».

А при чём тут TCP? Он не используется.
Если придётся увеличить плотность пакетов…
Понимаете, DDF разрабатывался не как универсальный способ сжатия любых данных вообще. А как способ сжатия именно и только данных спутникового мониторинга транспорта, см. тексты патентов. Никаких претензий на универсальность, помилуй Бог!
То есть специфика отрасли учтена. Передавать раз в 2 секунды — что именно? Если речь о качестве вождения, то даже тогда это нереально много, при настройке минимально разумного порога изменения — водитель не жамкает настолько часто на педаль газа, да и обороты так быстро не меняются на трассе. Нет, можно настроить так, чтобы через педаль газа фиксировалось сердцебиение :)
DDF — мощное оружие, а всякое оружие нужно использовать с умом и осторожностью.
Давайте тогда с самого начала :)
Какой у вас используется протокол под вашим DDF?
UDP?
Тогда вам нужен еще +1 слой программнго потверждения передачи данных, что тащит за собой еще больший оверхед по трафику, чем средства, предоставляемые TCP

Рассказывайте :)
Да, UDP. Что значит «ещё +1»?.. Один и есть.
И почему Вы решили, что «ещё больший»? Наш протокол менее избыточен, чем TCP, без потери надёжности.
Результат можно оценить примерно так: легковой автомобиль, подключен контроль расхода по сигналу с форсунки, пробег примерно 100 км в день по мегаполису, трафик 300 кБ в месяц. Качество трека отличное, никаких ломаных линий.
Естественно, могут быть (и будут) обрывы со стороны опсоса, с округлениями вверх. Я говорю о идеальной ситуации. И само собой, есть средства решения вопросов с такими округлениями. В ущерб оперативности, но мало ли какие у кого задачи…
Скажите, сколько за месяц по этому автомобилю С НЕГО ушло на ваш сервер пакетов?

В любом случае — формат данных и количество их источников, жёстко определяется на этапе разработки протокола. Изменить в нём что-либо — означает обречь все группы прикладных разработчиков на мучения, а себя — на проклятия.

Феерически. Это ж как надо было напроектировать
Вариантов протоколов с динамическим наполнением, в т.ч. у ГПС трекеров — тьма тьмущая.
Sign up to leave a comment.

Articles