NAT traversal (постановка)

Описанная ниже схема не отменяет действующего механизма, когда на мобильном устройстве прописан адрес с портом, а на файрволле предприятия настроен статический роут на внутренний компьютер.

Терминология:

• Сервер предприятия -- gedemin.exe в качестве веб-сервера, обслуживающий запросы мобильных приложений.
• Хаб -- gedemin.exe в качестве веб-сервера, где регистрируются серверы предприятий и куда мобильные приложения обращаются за адресами серверов предприятий.
• Мобильное приложение -- android приложение, которое обращается к серверу предприятия за данными. Адрес сервера предприятия мобильное приложение узнает, послав запрос на хаб.

Хаб

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

Сервера предприятий мы прописываем в таблице GD_WEBHUB:

 ...
 allowedip   -- список допустимых адресов. Если пустой, то мы разрешаем
                регистрацию сервера предприятия с любым внешним 
                адресом.
 aliases     -- список алиасов, обслуживаемых данным сервером предприятия.
                если пустой, то мобильные приложения смогут подключиться
                только по адресу.
 companyruid -- РУИД организации.
 computerid  -- id компьютера сервера.
 adminemail  -- адреса электронной почты для уведомления о недоступности 
                сервера.
 lastactive  -- дата и время последней регистрации сервера на хабе.
 accessdenied-- отказано в доступе. Адрес сервера предприятия не будет 
                передан в мобильное приложение. Вместо этого будет передан 
                код и текстовое сообщение.
 usermessage -- сообщение которое будет передано пользователю.
                мобильное приложение отображает это сообщение на экране.
                используется в коомбинации с флагом accessdenied.
                Например, "Сервер находится на плановом обслуживании.
                С 14:00 до 16:00".
 ...

Сервер предприятия

Сервер предприятия активируется через файл gedemin.ini:

 [WEB SERVER]
 Active          = 1
 Bindings        = можно не указывать, тогда сервер привяжется к 
                   локальному адресу.
 Register        = 1 -- флаг указывает, что веб сервер должен 
                   зарегистрироваться на хабе. По умолчанию равен 0.
 RegisterPeriod  = 580 -- период в секундах, через который сервер
                   обновляет информацию о себе на хабе. По умолчанию
                   580 сек, так как есть информация, что на некоторых
                   свитчах и файрволах используется 10-ти минутный
                   интервал времени, в течение которого сохраняется
                   информация о соответствии внутреннего адреса и
                   внешнего порта. 

Допустимые значения для Bindings:

• адрес:порт
• адрес -- будет использован порт 80
•  :порт будет использован локальный адрес и заданный номер порта
• пустое значение -- локальный адрес и порт 80

Сценарий регистрации

1. запускается веб сервер предприятия
2. если параметры из gedemin.ini указывают на необходимость регистрации на хабе, то шлется запрос на зашитый в экзешник адрес (например, gs.selfip.biz:47002/web_register)
3. на хаб передается id компьютера и ruid организации.
4. если хаб не доступен, то сервер переходит в неактивное состояние. на экран и в лог выдается сообщение о полученной ошибке.
5. хаб сверяет переданный ид компьютера и руид организации с информацией в GD_WEBHUB. Если сервер не прописан то возвращается соответствующий код. Сервер предприятия выдает на экран и в лог сообщение.
6. хаб регистрирует

Мобильное приложение

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

1. Приложение помнит адрес, порт и время последнего сеанса связи с сервером предприятия.
2. Если с момента последней связи прошло времени меньше, чем установлено константой, то пытаемся связаться по сохраненному адресу, не запрашивая хаб.
3. Если мы не можем связаться с сервером предприятия по сохраненному адресу (тайм аут или иной код ошибки), то не выдаем никаких сообщений пользователю, а идем на хаб за новым адресом.
4. Если хаб недоступен, выводим соответствующее сообщение об ошибке.
5. Если хаб вернул код ошибки (алиас неизвестен или отказано в доступе), то выдаем пользователю соответствующее сообщение.
6. Если мы не можем соединиться с сервером предприятия по полученному от хаба адресу (тайм аут или код ошибки), то выдаем пользователю сообщение.
7. Важно, чтобы сообщения пользователю позволяли однозначно идентифицировать проблему. Т.е. при жалобе пользователя мы должны сразу идентифицировать что произошло: недоступен хаб, подключение запрещено, недоступен сервер предприятия и т.п.