Как лучше реализовать подключеня к удаленному серверу?

[Mihail_]

Здравствуйте, подскажите пожалуйста как лучше реализовать клиент-серверное приложение по удаленному мониторингу и контролю некоторых устройств:

Есть сотни устройств, с которых нужно иметь возможность получать статусы и посылать им в ответ исполнительные команды - вопрос в том чтобы делать это с минимальным расходом трафика и небольшими задержками.

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

Как бы вы подошли к реализации такой задачи? Возможно ли использовать веб-сервер в качестве серверного приложения?

Заранее спасибо за ваши ответы!

[Хакер]

Какие устройства? Сетевые?

Возможно ли использовать веб-сервер в качестве серверного приложения?

Вполне.

[Antonariy]

Оперативность нужна только в момент захода оператора на сайт, в остальное время достаточно просто отсылать свой статус раз в 10-15 минут.

Веб-сервер не сможет сам обратиться к устройству, находящемуся за шлюзом. А если взвалить инициативу на устройство, даже если с очередным ответом на статус придет указание сократить паузу, администратору придется маяться до 10и-15и минут.
Придется писать свое серверное приложение, которое постоянно поддерживало бы соединение с клиентом по его запросу. Тогда сервер сам сможет постучаться к клиенту.

[Mihail_]

устройства сетевые, да, за NATом и входящие соединения установить нет возможности
речь как раз о том, каким образом это лучше реализовать чтобы оператор не маялся - это только постоянно открытое TCP соединение до сервера? можно ли к веб-серверу такой подход применить? (с апачем ничего не будет от нескольки сотен постоянно открытых соединенией? и вообще по какой технологии тогда с ним общаться?)

[Antonariy]

Веб-сервер (в смысле http-сервер) не сможет не только сам обратиться к устройству, но и не умеет поддерживать открытые соединения. Соединение разрывается после отдачи ответа. А апач это тоже http-сервер. Если под апач предполагались какие-нибудь никсы, придется писать своего демона, если винда — сервис.

с апачем ничего не будет от нескольки сотен постоянно открытых соединенией

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

А вообще достаточно сделать оповещалку раз в минуту. Допустим объем сообщения 1кб, чтобы с запасом. За сутки наберется 60 * 24 = 1440кб. На одну дискету. Мне кажется это не очень много даже для мобильного интернета, хотя я не очень в курсе расценок на него, не пользуюсь. Но если устройств много, это может стать заметной статьей расходов.

[djalex777]

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

Умеет и поддерживает, в частности апач.

Он не поддерживает несколько сотен соединений

Поддерживает.

устройства сетевые, да, за NATом и входящие соединения установить нет возможности
речь как раз о том, каким образом это лучше реализовать чтобы оператор не маялся - это только постоянно открытое TCP соединение до сервера? можно ли к веб-серверу такой подход применить? (с апачем ничего не будет от нескольки сотен постоянно открытых соединенией? и вообще по какой технологии тогда с ним общаться?)

Если ничего на сервере больше установить не можешь, то используй тот же apache. Общаться будешь по той же технологии - http. Не забудь включить и настроить keep-alive только.

[Хакер]

Antonariy. Мне нравится как ты стал писать большое кол-во ерунды. Такое впечатление, что ты на большой срок отходил от дел, и многое у тебя в голове исказилось.

Так вот:

Веб-сервер не сможет сам обратиться к устройству, находящемуся за шлюзом.

С чего бы это?

[Хакер]

устройства сетевые,

SNMP не поддерживают?

[Mihail_]

Веб-сервер не сможет сам обратиться к устройству, находящемуся за шлюзом.

С чего бы это?

Хакер, поясни пожалуйста - каким образом можно? Напомниаю что устройства за NATом и порт для входящих соединений пробросить нет возможности..

SNMP в случае необходимости можно реализовать, но как я понимаю он работает по типу UDP? В таком случае нет возможности поддерживать одно постоянное соединение и несколько сотен устройств будут все время флудить на сервер что-то типа "нет ли новых инструкций для меня?" - это же и лишний трафик и бОльшая нагруженность сервера? Поправь если где не прав.

Если ничего на сервере больше установить не можешь, то используй тот же apache. Общаться будешь по той же технологии - http. Не забудь включить и настроить keep-alive только.

Ну впринципе можно и что-то другое установить, много ли достойных альтернатив под эту задачу.
Хорошо, допустим подправили конфиг апача, что он начнет поддерживать keep-alive по полчаса - в двух словах, как ты предлагаешь дальше общаться с сервером?
Апач точно переварит несколько сотен таких одновременно висящих соденинений? И это не слишком криво получается, я просто не слышал раньше чтобы так использовали..)

Буду рад услышать любые предложения как еще это можно было бы реализовать!

[Хакер]

Хакер, поясни пожалуйста - каким образом можно? Напомниаю что устройства за NATом и порт для входящих соединений пробросить нет возможности..

Давай так. NAT всё-таки несимметричен. Со одной стороны NAT-а другая сторона видна как есть. Со второй стороны NAT-а другая сторона не видна вообще, а виден только сам NAT как один узел.

С какой стороны веб-сервер (или не веб-) и с какой стороны устройства?

Но, в принципе, это не так важно. Кто на второй стороне — тот пусть и выступает инициатором подключения.

В таком случае нет возможности поддерживать одно постоянное соединение и несколько сотен устройств будут все время флудить на сервер что-то типа "нет ли новых инструкций для меня?" - это же и лишний трафик и бОльшая нагруженность сервера? Поправь если где не прав.

Зачем отправлять на сервер «нет ли новых инструкций для меня», если можно молча ждать от сервера новых инструкций?


Ты ещё конкретизируй, что за сервер, то за по на нём, где этот сервер ну и т.п.

[alibek]

Давай так. NAT всё-таки несимметричен. Со одной стороны NAT-а другая сторона видна как есть. Со второй стороны NAT-а другая сторона не видна вообще, а виден только сам NAT как один узел.

NAT бывает разным. Есть и симметричный.

[Antonariy]

Умеет и поддерживает, в частности апач.

Рад оказаться неправым. )
Апач мне не интересен, как это делается в IIS?

[Хакер]

Нехорошо удалять сообщения, перед тем, как ответ на них чуть было не запостили.

[Antonariy]

Мне бы твои проблемы.

Ответ djalex777 я не сразу заметил и он полезнее твоего.

Antonariy. Мне нравится как ты стал писать большое кол-во ерунды. Такое впечатление, что ты на большой срок отходил от дел, и многое у тебя в голове исказилось.

Мне самому нравится. Если я не прав, заклинание циничной ерунды с высокой долей вероятности провоцирует саммон лолодина истины, который уничтожает воинствующее невежество for teh great justice. Профит.

[Mihail_]

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

Пока что вырисовывается вариант постоянно держать открытое TCP соединение от клиента к серверу и по нему с сервером общаться. Я в TCP/IP стеке не силен, поэтому спрашиваю мнение аудитории, какую технологию для этого лучше использовать. Делюсь мыслями о том - можно ли веб-сервер с каким-нибудь php использовать для работы с такими соединениями, чтобы свое небезопасное и баговое приложение с кучей сокетов вместо уже готового и отлаженного веб-сервера не писать? И какие еще возможны варианты?

Заранее спасибо за ответы!

[Mihail_]

Подскажите плз еще один момент - реально ли сделать что-то типа прокси, чтобы общаться с устройствами, обращаясь через сервер напрямую к каждому (есть возможность поднять на каждом исполнительном устройстве простенький веб-сервер)?
Как тогда будет выглядеть логика работы? Есть ли готовые решения в виде софта?

[iGrok]

Вот тебе пара кейвордов для поиска и изучения информации: "long poll", "comet".
Учитывая кол-во соединений, вместо апача лучше взять что-нибудь полегче. Я предпочитаю nginx.
Решений существует куча, оптимального не подскажу, т.к. никогда такого не делал, но в гугле всё есть.

[Mihail_]

спасибо за ответ, с веб-сервером и keep-alive соединениями понятно, сейчас я предлагаю рассмотреть вариант децентрализованного решения когда мини-веб сервер будет крутиться на каждом исполнительном устройстве, а самый главный сервер будет выполнять роль прокси (т.е. устройства за NAT'ом) - это реально? Как тогда будет выглядеть логика работы?

[alibek]

Нет, это все усложнит и запутает.
Трехзвенные архитектуры делаются не так.
Тебе нужна трехзвенная архитектура, в которой второе звено будет децентрализованным.