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

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

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

На какое количество устройств сервер должен быть рассчитан?

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

Я тоже так думал. К тому же все к кому мы обращались с вопросом разработки сервера, называли цифру до 5000 модулей И не более 300 одновременных подключений клиентов.
Такой расклад нас не устроил в связи с чем сейчас сами разрабатываем сервер. Эти цифры далеко в прошлом и количество сокетов будет ограничено лишь шириной канала, который обеспечит дата-центр. А сколько именно будем тестировать когда закончу.

Самая главная сложность, как я вижу, это написать надежный TCP сервер (так называемый демон) обработки данных от приборов. Или такие уже существуют?
А подключения клиентов обработает без проблем тот же Apache через 80 порт.

Каждый сокет и особенно Апач отъедает ресурсы процессора и самое главное память. В это все и упираются.

У Wialon смотрели сколько?
Причём 100000 праздновали всего несколько месяцев назад.

для этого есть erlang и другие серверы на базе легковесных процессов (на scala, clojure, nodejs)

Во... На нем и пытаюсь...

Вы пытаетесь на nodejs написать и TCP-сервер обработки данных от устройств и HTTP-сервер для пользователей?

Если планируется такой парк устройств, то зачем вам тсп? Используйте удп, и проблемы с ресурсами на сокет отпадают. Причем, поверьте, в надежности Вы ничего не теряете при вдумчивой реализации протокола.
И еще: зачем создавать монстра с огромной емкостью, когда можно распределить ресурс? В идеале вообще перенести вычисления, тайлы и т.п. на диспетчерское ПО, оставив на сервере только транспорт и архивирование в БД. Это нетривиальное и смелое решение, но оно того стоит.

Ага. И ведь получается.

GeGeL, TCP все-таки надежнее. Предполагается использовать только веб интерфейс, без диспетчерских ПО.
В общем все по аналогии с Wialon.
sobr, какую БД используете?

Я бы вам предложил не париться, и реализовать не TCP сервер, а HTTP. Проще в поддержке, есть масса готовых решений. Минусы: больше расход трафика и открытое соединение не принято держать. Готовых GPS серверов не знаю, разве что Wialon тот же.

Это в смысле HTTP от трекера на сервер? Т.е. трекер периодически устанавливает http-соединение и методом POST отправляет данные, я так понял?

>>Предполагается использовать только веб интерфейс

Если так, тогда да. Но все ж с надежностью не согласен: смотря что в это понятие вкладывается, и какие требования поставлены.

А что мешает создать свой TCP парсер и набивать базу данных? После чего демоном обрабатывать эти данные?

Имхо это правильнее т.к. взаимозаменяемость ПО и возможностей последующего расширения гораздо больше.



Чо только люди не придумают, чтобы жизнь себе усложнить

Мешает отсутствие опыта.
Если у Вас есть какие-либо наработки, готов приобрести исходники с комментариями.

Да собственно там и нечего приобретать и опыта особо много не надо.
Любая готовая либа с серверсокетными соединениями разве не катит?
Я взял Qt-шную, переопределил ряд методов под свои задачи, вогнал по 100 соединений в поток и подключил нужные драйвера БД и парсер с собственным протоколом.
Всё остальное делают отдельные демоны или вобще php скрипты.

В качестве исходника использовал пример однопоточного неблокирующего сервера из тех же примеров для Qt. А там просто навернул...)))
Исходники давать не вижу смысла так как там 60% копипаста с примеров и 40% свой протокол.

Погуглил заточенные языки для сетевых приложений, лидирующие позиции у Erlang, как советовал уважаемый zöner.
Попробуем его пощупать, а что можете посоветовать по БД?
Спасибо.

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

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

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

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

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

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

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

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

GeGeL, да, Вы на 100% правы! Я раньше как-то не задумывался над этим.
А на чем, в таком случае, лучше всего написать парсер UDP-пакетов?
Спасибо.

Я, к сожалению, только на С/С++ умею Все зависит от того, что у вас есть на сервере и как/с чем вы хотите связать ваш парсер. Сам парсер (хоть тсп, хоть удп) не проблема: пишете демон на С, в сети масса примеров по использованию сокетов в линукс. Это самый эффективный по производительности способ. Получаете данные, а вот как их передать вашему серверу - зависит скорее от самого сервера (на чем он написан). Можно попробовать прицепить с-исходник драйвера БД к парсеру: парсер пишет в БД, а сервер читает. Возможно, проще будет написать демон вместе с сервером: это и на php можно сделать, но вот производительность никакая будет.

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

Яркий пример нашей системы образования...
Вместо понятийного уровня, используя тесты типа "один ответ из 4-х верный",
не заботясь о том, как потом знания интерпретируют и применят на практике...
А потом удивляемся, почему ракеты падают на старте

NAT - он для того и существует, чтобы передавать обратный пакет клиенту,
и это он обязан делать по определению.
Посоветуйте источнику вашей информации почитать в вики о 4-х основных типах NAT и разобраться,
в чем их отличие и как они работают. Затем, для закрепления материала, поиграть с любым STUN-сервером
с помощью утилиты, наблюдая сетевым анализатором, что посылается, и какие ответы приходят и не приходят.
Возможно, после этого его жизнь разделится на две половины

Естественно, ваш сервер должен иметь внешний IP или же, если он за роутером, то необходимо в роутере
статически открыть используемый порт на LAN-IP машины с запущенным сервером. Обычно сервер располагают на VDS, и там внешний IP.
Что касается GPRS-сисопов, то, как писал выше, их NAT ОБЯЗАН пробросить соединение от трекера к серверу и обратно, это его основная функция.
Иначе это уже аварийная ситуация, и в равной мере это может быть как с удп, так и тсп.
(если не в курсе: NAT совершенно одинаково работает с обоими протоколами, т.к. он работает на IP-уровне, но почему-то никто не помнит, что
он точно так же открывает и поддерживает TCP-соединение, применяя адрес-трансляцию и порт-маппинг к TCP-IP-заголовкам).

Ограничение на количество открытых сокетов накладывает операционка и платформа.
Под настольный ПК с Windows реальная цифра будет 1-3 тыс. сокетов, не более.
И при этом будет большой риск отказов.

Т.е. вопрос надежного M2M сервера это вопрос аппаратного обеспечения и его масштабирования.

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

Облака - это VDS/VPS?

Если имеется в виду этот VPS , то это те же грабли одиночной операционки.
Я говорю про облачные сервисы.
Сервисы пишете вы сами на основе предоставляемого API облачных сервисов.

Сервисы и серверы это разные вещи.

А что по цене с облаками? Не будет ли дороже в последствии? И не попадаете ли в зависимость от них?

Загуглил тему, но пока не понятен принцип работы. А какой из типов облачных сервисов Вы имеете ввиду.
SaaS — Software as a Service (программное обеспечение в качестве сервиса). Предоставляет потребителю возможность использовать ПО, работающее в облаке. Ярчайший пример: gmail.
PaaS — Platform as a Service (платформа в качестве сервиса). Позволяет потребителю развертывать собственные приложения на подготовленной для этого платформе. В качестве примера можно привести среду Java, работающую удаленно.
IaaS — Infrastructure as a Service (инфраструктура в качестве сервиса). Дает потребителю целую инфраструктуру, позволяющую запускать виртуальные машины, налаживать межу ними связь и использовать дисковое пространство.

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

Я бы предложил делать SaaS используя PaaS на основе IaaS. Как-то так...

думаю можно обойтись и без облака

Как пишут, облака позволяют ускорить сборку любого проекта, используя готовые API.
Определение и назначение хорошее, но где это все лежит и как собирать, информации нет...

Мне это пока и не надо. Я вам показал направление на которое я на данный момент ориентируюсь. Куда понесет вас - вам решать.

Да, совершенно верно. Ничего тут сложного (как считают некоторые посетители форума) нет. HTTP + JSON это стандарт де факто для большинства существующих API, в том числе и высокопроизводительных.
Кстати, опыт разработки на Эрланге у меня есть. Это совершенно великолепный язык, позволяющий вашу задачу решить в порядка 100 строк. Но у него своя совершенно особая философия, требующая глубокого погружения. И для него практически однозначно нужен линукс - под виндой глючит. Да, для справки, программисты на Эрланге ненавидят node.js (это к sobr'у).

Согласен, сложного ничего нет. Наоборот, все слишком просто. Но слишком неэффективно. Если посмотреть на диаграмму в статье по ссылке от sobr, то видим огромные пики нагрузки при массовом отключении клиентов. А Вы предлагаете делать это постоянно и часто.
Конечно, может, я не прав, но код на Эрланге, или на node.js в любом случае обращается сисколом к ядру ОС, к тем же сокетам. И эти языки сделаны для упрощения разработки, облегчения переносимости и обслуживания кода как компромисс с эффективностью, но никак не для эффективности.
В полном идеале для максимальной эффективности надо написать на ассемблере свой заточенный драйвер езернет-карты, свой стек, парсер и БД Ясно, что это фантастика, но оптимизированный демон на С с минимумом сисколов будет всегда эффективнее любых высокоуровневых надстроек, несмотря на их новомодные названия. Но вот отточить его весьма непросто.

Да топик стартеру эффективности большой не требуется - до 10000 клиентов, а отдавать данные можно раз в 10 минут, например. Нагрузка детская.

Это конечно. Но вот сделать хороший сервер хоть TCP, хоть HTTP на C задача очень нетривиальная. Неопытный программист сделает в лоб по потоку на клиента и сразу же проиграет решению на эрланге.
Тем не менее, я не советую топикстартеру браться за эрланг (хотя для самообразования очень даже советую), а порекомендую:
1. Поискать готовый сервис и присоседиться к нему.
2. Если не найдёт и решение нужно долгоиграющее и расширяемое, то взять веб сервер и прикрутить свой обработчик. Данные складировать сразу в БД картографического сервера.
3. Если совсем нет времени и хочется TCP, могу дать свой сервер на C#. Там по потоку на клиента, винда, бинарный протокол и прочая ересь, зато TCP сервер сразу заработает.

Этим как раз упорно и занимаюсь. Причем хочется купить сервис и поставить на свой физический сервер (ну или виртуальный).
Одно не нравится, что потом ничего изменить нельзя будет, если потребуется.

HTTP использовать категорически неприемлемо, данные отдаю каждые 3-9сек.
А чтобы поднять систему с нуля и до вести до ума , потребуется как минимум полгода.

Мне что-то так чудится, что Вы и без HTTP не сможете отдавать данные каждые 3-9 сек. Подумайте на досуге, что Ваши устройства будут делать в те моменты, когда связи не будет. Что-то мне подсказывает, что данные они должны накапливать, а передавать при появлении связи. Так что мешает и по HTTP аналогично работать: данные накапливать, а передавать блоками с заданным интервалом?

Информация в общих чертах правильная, но в ней не упомянуты граничные условия ее применимости. NAT у некоторых провайдеров скидывает UDP "сессию" через 4-5 секунд в периоды пиковой загрузки.

И, кстати, не надо раскатывать губу на то,что TCP от этого спасет. Не спасает. Сносят малоактивные сессии на своих NAT провайдеры только так.

Вообще тема эта занятная. Можно сделать реализацию протокола, отточить, отполировать до блеска, гордиться за себя... И потом СИЛЬНО удивиться, получив первого клиента с симкой из какой то новой сетки.

От первой работоспособной реализации до действительно беспроблемного продукта примерно тот же путь, какой бывает от студенческого курсового, сданного на "отлично" до серийно выпускаемого изделия на его базе.

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

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

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

Программисты под 1С думаю тоже. Мне то зачем об этом знать?

И что, обеспечит 10000 соединений? Дайте потестить.

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

"И что, обеспечит 10000 соединений? Дайте потестить."
Нет, не обеспечит. Я же говорю, там всякая ересь. Но если нужен образец, от чего плясать, то очень даже подойдет. Там пул соединений добавить, потюнить винду на предмет ограничения сокетов, может и вытянет в итоге.

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

Для меня проще было взять демо версию от gpsgate и за 1 час получить готовую систему для приема данных и отображения. Потом конечно пришлось расширить кол-вво клиентов до 200, но это уже потом.

x893, а у них демо доступ есть? Весь сайт облазил, нигде не нашел.

Добавлено:
Посмотрел на их цены и энтузиазм поутих:
GpsGate Server Starter Pack Subscription 30 day free trial, then USD $49.75 monthly
GpsGate Server Subscription (5 device free) Monthly: USD $9.95

Образец расчета абонентки: All devices sending data to your server require a subscription (e.g. vehicles, assets and users with personal trackers). If you have 12 vehicles, 2 operators and 1 Administrator you need 12 subscriptions. For that you need one GpsGate Server Starter Pack Subscription and 7 additional GpsGate Server Subscriptions.

Выходит, x893, Вы каждый месяц им отстегиваете 200-5=195$+49.75$ = почти 250$?

http://gpsgate.com/download
Устанавливается у себя. + SMS proxy.
Вопрос платить или не платить каждый решает сам.
Сейчас пришлось немного изменить структуру данных для уменьшения нагрузки на сервер.
Но как fronе-end меня устраивает.