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

Как пишут, облака позволяют ускорить сборку любого проекта, используя готовые 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, то при неверной длине она в любом случае не совпадет, и пакет отвергается.