Оффтоп по М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]

Да, такая беда есть, и тема действительно занятная. Но за 4-5 сек трекер получит подтверждение сервера, т.к. реально пинг гораздо меньше даже в жпрс. Т.е. в итоге будем иметь "мертвые периоды" между посылками трекера (если они реже 5 сек), в которые трекер будет не доступен с сервера. Но после каждого очередного пакета от трекера он будет доступен в течение этих 4-5 сек, и можно давать ему управляющие данные.
И верно замечено, что TCP не спасает. Ведь NAT не отслеживает tcp-сессию по syn и fin (он бы замахался, да и проблемы зависших сессий сразу). Точно так же после очередного ip-tcp-пакета обновляется таймаут таблицы портмапинга. Просто tcp-сокет имеет встроенный таймер KeepAlive, гоняющий пустые пакеты при отсутствии обмена. Это и создает иллюзию, что в случае ТСП трекер доступен с сервера всегда, а в случае удп - не всегда.
Да только если NAT удаляет запись портмапинга в удп, то первый же пакет от трекера создает ее вновь, и если исходящий порт другой, ничего страшного: сервер то отвечает по адресу отправителя.
А вот если такое случится на тсп-сесии, то серверный сокет ну никак не примет пакет с другого порта, и реконект неизбежен.
На самом деле ничто не мешает ввести keepalive таймер в удп-модель и получить в результате постоянную доступность трекера с сервера. И преимущества:
- интервал keepalive будет настраиваемым (можно даже сделать умную адаптацию), в то время как в тсп он определяется настройками сокета (параметрами стека), недоступными в большинстве ОС. В итоге можно подобрать нужный интервал KeepAlive и экономить трафик, лишний раз не гоняя пустые пакеты.
- "нулевой" удп-пакет короче, чем тсп (за счет заголовка, за который тоже, кстати, идет оплата), опять же экономия трафика.
А что касается идеальных реализаций, то их просто не бывает: всегда что-нибудь вылезет рано или поздно. И чем пытаться создать идеальную реализацию, лучше обеспечить максимально оперативное устранение (типа апгрейда firmware и т.п.).

[Velund]

А что касается идеальных реализаций, то их просто не бывает: всегда что-нибудь вылезет рано или поздно. И чем пытаться создать идеальную реализацию, лучше обеспечить максимально оперативное устранение (типа апгрейда firmware и т.п.).

Согласен. Каждый год что то, да вылезает.

А насчет последнего предложения - это сильно осложняет жизнь при подходе "купил готовый компонент и забыл о нем". С мечты о котором началась ветка, кстати.