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

[Alt.F4]

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

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

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

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

[Alt.F4]

Поступила информация, что используя UDP, от сервера можно и не дождаться потом ответа. Я не сильно разбираюсь, но объяснили, что не все роутеры (если клиент спрятан за NAT'ами) умеют передавать обратный пакет клиенту, там порты пробрасываются и все пакеты не доходят.

[Alechek]

Поступила информация, что используя UDP, от сервера можно и не дождаться потом ответа. Я не сильно разбираюсь, но объяснили, что не все роутеры (если клиент спрятан за NAT'ами) умеют передавать обратный пакет клиенту, там порты пробрасываются и все пакеты не доходят.

Кстати, по поводу UDP. Как показала практика,
1. длина пакета по заголовку UDP и фактическая могут отличатся.
2. на CRC UDP пакета надеяться нельзя. Бывает, приходят данные, CRC в порядке, а внутри, в середине пакета, либо FF либо просто набор битов и байтов.. Замечено у Мегафона во внутресетевом роуминге.

[GeGeL]

Кстати, по поводу UDP. Как показала практика,
1. длина пакета по заголовку UDP и фактическая могут отличатся.
2. на CRC UDP пакета надеяться нельзя. Бывает, приходят данные, CRC в порядке, а внутри, в середине пакета, либо FF либо просто набор битов и байтов.. Замечено у Мегафона во внутресетевом роуминге.

100% согласен. Для UDP-based протоколов необходима своя философия:
1. каждый пакет должен содержать идентификатор трекера. Обычно это строка imei, но чтобы не быть расточительным, можно использовать crc32 от нее или даже двухбайтный назначаемый номер трекера для парка из 65535 машин.
2. На сервере держим массив из нужного к-ва (по к-ву машин) u32 IP и u16 port, и обновляем при получении валидного пакета. Еще можно писать в массив таймстемп. Это на пару порядков меньше ОЗУ, чем используют такое же к-во открытых тсп-сокетов.
3. Конечно, на CRC заголовка нельзя полагаться (кстати, допускается нулевая). В каждом пакете должна содержаться crc32 или хотя-бы crc16. Конечно, это дополнительная нагрузка на обработчик сервера, без этого никак. В TCP, кстати, аналогично: если длина там строго контролируется по SEQ, то целостность данных - только обычным суммированием по модулю.
4. Длину можно брать и из заголовка: если используется crc, то при неверной длине она в любом случае не совпадет, и пакет отвергается.