Как обслуживать данные без открытия порта для прослушивания?

Question

Я разработал приложение, которое в основном обслуживает данные из большой базы данных. Клиенты - это мобильные приложения, которые извлекают данные с клиентского ПК, где работает это серверное приложение.

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

Моей первой попыткой было разработать нормальное серверное приложение. Когда это приложение запускается, оно открывает порт и прослушивает его. Мобильному приложению требуется только подключение к IP-адресу пользователя для получения данных. Он работал нормально, но эта попытка не является хорошим решением. Прежде всего, поскольку каждый пользователь должен настроить маршрутизаторы, прокси и т. Д., И во многих случаях они не являются компьютерными грамотными. На втором месте другой разработчик сказал мне, что в 2015 году никто не должен устанавливать приложения, открывающие порты на клиентских ПК, потому что это действительно опасно. (Я не знал об этом).

То, что я хотел бы это:

1) Избегайте настройки прокси, маршрутизаторы и т.д. Установка клиента должна быть очень легкой.

2) Мобильное приложение должно запрашивать данные на клиентском ПК. Когда и что необходимо, неизвестно до тех пор, пока мобильный сервер не отправит запрос.

Кто-то предложил систему опроса, но я не понимаю, как это работает. Клиентское приложение должно будет потребовать, чтобы главный сервер каждые несколько секунд был «в режиме реального времени», и это не кажется жизнеспособным.

Другой человек предложил периодически передавать данные на главный сервер, а затем мобильный мог запросить эти данные на главный сервер. Я не могу выталкивать данные от клиента на наш главный сервер. Я понятия не имею, что потребуется мобильному приложению.

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

Спасибо

Answer 1

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

Мобильное устройство может затем отправить запрос на сервер CloudAMQP, который будет получен сервером пользователя/клиента. Оба являются клиентами с точки зрения брокера сообщений CloudAMQP. Сервер клиентов доставляет запрашиваемые данные на сервер CloudAMQP и, в свою очередь, будет настроен на мобильное устройство.

Для такого типа связи с запросом/ответом, ориентированного на ориентированное на сообщение промежуточное программное обеспечение, существуют стандартные решения, например временные очереди: мобильное устройство подключается и создает очередь назначения на сервере AMQP, которая существует только на протяжении времени подключение. Затем каждый запрос может использовать временную очередь в качестве адреса ответа для сервера клиента. Сервер клиентов подбирает запросы, генерирует ответ и отправляет его на заданный адрес ответа. Примеры RabbitMQ (сообщение брокера за CloudAMQP) доступны на RabbitMQ домашней странице:

Remote procedure call (RPC) (с помощью клиенту Java, также available in C# и другими языками)

Я портировал пример код в демо Delphi для клиент Habari для библиотеки RabbitMQ (который я являюсь автором).

Обратите внимание, что CloudAMQP - это только один вариант размещения брокера сообщений.Конечно, вы можете размещать брокера сообщений (RabbitMQ, ActiveMQ, Apollo ...) в своей собственной системе. Этот бесплатный брокер сообщений с открытым исходным кодом готов к производству, и вашим клиентам не нужно открывать порты для входящих подключений.