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

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



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

Сообщение отредактировал MKdemiurg - Apr 19 2013, 13:37

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

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

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

Сообщение отредактировал MKdemiurg - Apr 19 2013, 14:13

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

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

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

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

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

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

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

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

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

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

Сообщение отредактировал Alt.F4 - Apr 19 2013, 17:45

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