Оффтоп по М2М серверам GPS мониторинга. Опции

[Alt.F4]

Добрый день.
Я думаю, эта самая популярная ветка среди людей, которые работают в сфере GPS мониторинга.
Хочу задать вопрос, можно ли у кого купить:
1) голый каркас для создания своего сервера М2М: надежный парсер TCP пакетов с сохранением всех параметров в быструю БД?
2) исходники с комментариями готового серверного ПО для GPS мониторинга?

Нагуглил вот этих ребят, почти готовый продукт, но:
1) исходники для редактирования своего протокола обмена с сервером продавать не хотят, добавить пожалуйста, а изменять нельзя.
2) поддержка всевозмжных датчиков пока отсутсвует
3) смущает использование тормознутой MySQL database (видел как она за месяц ставит на колени сервер по обработке клиентов автомобильной стоянки по карточкам).

С удовольствием заюзал бы Wialon, но для Беларуси у них почему-то ценовая политика сложилась в 3 раза дороже, чем для других регионов СНГ.
Буду очень благодарен за какую-либо информацию.
Спасибо.

Сообщение отредактировал Alt.F4 - Apr 18 2013, 20:12

[GeGeL]

Я уже как то писал, если кому скучно покажется - не пинайте сильно: может, кому и полезно будет.
Даже дети уверены, что тсп надежнее удп, т.к. обеспечивает гарантийность доставки данных (так в учебниках пишут).
Давайте выйдем из плоскости стандартного мышления и разберемся: каким способом тсп обеспечивает гарантийность доставки пакета.
15 минут чтения вики - и ответ:
- принимающая сторона подтверждает полученное количество цельных (без пропусков) байт (поле ACK в TCP-пакете)
- отправляющая сторона, не получив подтверждения, отсылает неподтвержденные данные повторно, с геометрически нарастающем интервалом времени (от 0.5 до 30 сек)
- если исчерпан лимит повторов и подтверждения все нет (через 30 сек), то соединение разрывается.

Теперь построим такую модель: пусть каждые 10 сек у нас появляются данные, которые надо передать на сервер (например, координаты).
- дописываем к ним номер пакета (ID) и запускаем демон отправки, отсылающий ежесекундно удп-пакет на сервер;
- при получении пакета сервер подтверждает его, отсылая обратно его ID;
- при получении подтверждения, если ИД совпадает, останавливаем демон;
- если подтверждение не получено, а готовы новые данные, то заменяем ими старые и увеличиваем ИД на 1, перезапускаем демон.

Отличается ли надежность доставки данных в такой схеме от тсп? Абсолютно ничем.

Вы можете спросить: а зачем тогда придуман ТСП? Представьте, что описанным выше способом надо передать большой файл, разбив его на кусочки размером с пакет.
Надо передать кусочек, дождаться поlтверждения, передать следующий и т.д. Т.е. время передачи будет равно пингу, умноженному на к-во кусочков. Это очень долго.
Изюминка ТСП заключается в концепции окна:
- получатель может подтверждать не каждый пакет, а группу пакетов сразу;
- отправитель может отправлять некоторое к-во данных наперед, не дожидаясь подтверждения предыдущих.

Вопрос: в приложении жпс-трекинга нам это надо? У нас есть длинные файлы? Есть непрерывный поток данных?
Нет. Есть небольшие структурированные по времени отдельные пакеты. И поэтому нет смысла тратить ресурс на совершенно бесполезные вещи.

Вы можете возразить: но данные все же могут потеряться, если следующие поступят раньше подтверждения?
Да, так и есть. Но так же и в тсп. Хуже того, там мы рискуем потерять и следующие данные, пока будем перезапускать соединение.

Если система требует абсолютно гарантийной доставки отдельных данных (например, сработка сигнализации), есть несколько вариантов
(причем не зависимо от того, используется тсп или удп):
а) биты критических данных сделать в виде триггеров: устанавливать при сработке, передавать в каждом пакете, сбрасывать при первом подтверждении;
б) кешировать неподтвержденные пакеты в файловую систему трекера (или ОЗУ), передавая вновь поступившие. При получении первого же подтверждения запускать параллельно демон отправки кешированных пакетов от последнего.
Именно так сделано в моем проекте. Результат прекрасный: никаких стрел на треке даже при работе на суррогатную GSM-антенну при слабом покрытии.

Если все еще сомневаетесь, сделайте простой эксперимент: в прошивке трекера отправляйте каждые 10 сек пакет с инкементируемыми данными, а на сервере пишите в файл.
Сначала через тсп (естественно, предусмотрите автопереподключение), потом через удп, как я описал выше.
Через сутки сравните количество пропусков номеров в файлах на сервере. Очень удивитесь, но пропусков в удп-варианте будет меньше.
Вот так то: если на заборе написано ***, то не всегда он там есть...