NAT traversal (постановка)
Описанная ниже схема не отменяет действующего механизма, когда на мобильном устройстве прописан адрес с портом, а на файрволле предприятия настроен статический роут на внутренний компьютер.
Терминология:
- Сервер предприятия -- gedemin.exe в качестве веб-сервера, обслуживающий запросы мобильных приложений.
- Хаб -- gedemin.exe в качестве веб-сервера, где регистрируются серверы предприятий и куда мобильные приложения обращаются за адресами серверов предприятий.
- Мобильное приложение -- android приложение, которое обращается к серверу предприятия за данными. Адрес сервера предприятия мобильное приложение узнает, послав запрос на хаб.
- Внешний адрес сервера предприятия -- адрес и порт сервера предприятия, под которым он виден из сети интернет.
- Внутренний адрес сервера предприятия -- адрес и порт сервера предприятия в локальной сети предприятия.
Хаб
Один из серверов выступает в роли хаба, где регистрируются сервера предприятий и куда обращаются мобильные приложения за адресами.
Только сервера предприятий, прописанные в таблице GD_WEBHUB, обслуживаются хабом. Структура таблицы:
...
allowedip -- Список допустимых внешних адресов. Может указываться как только
адрес, так и адрес с номером порта. Если пустой, то мы разрешаем
регистрацию сервера предприятия с любым внешним адресом.
aliases -- Список алиасов, через запятую, обслуживаемых данным сервером
предприятия. Если пустой, то мобильные приложения смогут
подключиться только по адресу. Алиасы не чувствительны к регистру.
companyruid -- РУИД организации.
computerid -- id компьютера сервера.
lastactive -- Дата и время последней регистрации (обновления) сервера на хабе.
lastip -- Внешний адрес и порт сервера предприятия из последней
регистрации (обновления).
accessdenied-- Флаг "отказано в доступе". Адрес сервера предприятия не будет
передан в мобильное приложение. Вместо этого будет передан
код и текстовое сообщение.
usermessage -- Сообщение, которое будет передано пользователю.
Мобильное приложение отображает это сообщение на экране.
Используется в коомбинации с флагом accessdenied.
Пример сообщения: "Сервер находится на плановом обслуживании.
С 14:00 до 16:00".
adminemail -- Адреса электронной почты, через запятую, для уведомления о
недоступности сервера.
...
Сервер предприятия
Сервер предприятия активируется через файл gedemin.ini. В рамках решения данной задачи добавляем или расширяем следующие параметры:
[WEB SERVER]
...
Bindings = адрес, к которому будет привязан сервер предприятия.
Register = 1 -- флаг указывает, что веб сервер должен
зарегистрироваться на хабе. По умолчанию равен 0.
RegisterPeriod = 580 -- период в секундах, через который сервер
обновляет информацию о себе на хабе. По умолчанию
580 сек, так как есть информация, что на некоторых
свитчах и файрволах используется 10-ти минутный
интервал времени, в течение которого сохраняется
информация о соответствии внутреннего адреса и
внешнего порта.
Допустимые значения для Bindings:
- адрес:порт
- адрес -- будет использован порт 80
- :порт будет использован локальный адрес и заданный номер порта
- пустое значение -- локальный адрес и порт 80
Если на компьютере несколько локальных адресов и в Bindings адрес не прописан, то будет взят любой из них.
Узнать к какому именно адресу и номеру порта привязан сервер можно в окне О программе.
Сценарий регистрации
- Запускается сервер предприятия.
- Если параметры из gedemin.ini указывают на необходимость регистрации на хабе, то шлется запрос на зашитый в экзешник адрес (например, gs.selfip.biz:47002/web_register).
- На хаб передается id компьютера и ruid текущей рабочей организации.
- Если хаб недоступен, то сервер переходит в неактивное состояние. На экран и в лог выдается сообщение о полученной ошибке.
- Хаб сверяет переданный ид компьютера и руид организации с информацией в GD_WEBHUB.
- Если сервер предприятия не прописан на хабе то возвращается соответствующий код. Сервер предприятия выдает на экран и в лог сообщение.
- хаб регистрирует
Мобильное приложение
Если адрес прописан пользователем непосредственно или используется алиас, прошитый в коде, то все работает по-старому. Алгоритм, описанный ниже, относится только к связи с использованием хаба.
- Приложение помнит адрес, порт и время последнего сеанса связи с сервером предприятия.
- Если с момента последней связи прошло времени меньше, чем установлено константой, то пытаемся связаться по сохраненному адресу, не запрашивая хаб.
- Если мы не можем связаться с сервером предприятия по сохраненному адресу (тайм аут или иной код ошибки), то не выдаем никаких сообщений пользователю, а идем на хаб за новым адресом.
- Если хаб недоступен, выводим соответствующее сообщение об ошибке.
- Если хаб вернул код ошибки (алиас неизвестен или отказано в доступе), то выдаем пользователю соответствующее сообщение.
- Если мы не можем соединиться с сервером предприятия по полученному от хаба адресу (тайм аут или код ошибки), то выдаем пользователю сообщение.
- Важно, чтобы сообщения пользователю позволяли однозначно идентифицировать проблему. Т.е. при жалобе пользователя мы должны сразу идентифицировать что произошло: недоступен хаб, подключение запрещено, недоступен сервер предприятия и т.п.