Алгоритм соединения с сервером Domino

[Bonyfather]

Соединение с сервером возможно при использовании аж 4-ч IP-адресов.
У клиента в адресной книге созданы 4 одинаковые (за исключением адреса конечного сервера) документа Connection. При них состоит один документ Location.

Мыслилось, что при попытке установки связи документы Connection будут перебираться, пока не будет найден обеспечивающий соединение документ.

Реальность оказалась суровой: похоже где-то запоминается документ, обеспечивающий последнее успешное соединение и он тупо начинает жеваться - в результате соответствующий ALARM!

Существет ли надежный программный (на худой конец организационно-системный) способ автоматической установки связи в данной ситуации?

Заранее спасибо всем, кто чем-нибудь пособит горю!

 

[puks]

А названия Connection одинаковые?

 

[Bonyfather]

Т.е. по существу интересует алгоритм выбора документа Connection, удовлетворяющего текущему документу Location, а так же, запоминается ли его ID где-нибудь

Connection, в отличие от Location, не имеет поля Name.
Можно, конечно указать LocationName (использовать только для места вызова), но это в данном случае не принципиально

Connection, в отличие от Location, не имеет поля Name.
Можно, конечно указать LocationName (использовать только для места вызова), но это в данном случае не принципиально

 

[puks]

Тяжко с утра соображается.

Можно попробовать через создание нескольких портов в User Preferences. Потом каждому соединению дать отдельный порт.
Другой вариант прописать имя, а несколько адресов в хост файле.
Не знаю можно ли прописывать несколько адресов в одном соединении.

Сейчас вспомнилось, что как-то была конфигурация клиента с несколькими соединениями и все работало нормально.

Кстати, сервер ведь нормально отрабатывает несколько конекшн.

Последний ip кэшируется, но обычно, это не мешает соединиться при его недоступности.

 

[puks]

А объясни цель. Сервер имеет 4 адреса. Все они смотрят в одну сетку и при этом все доступны? Или каждый для какой-то определенной цели?

Еще вопрос. А ты соединение лотусовым trace проверял? Это чтобы точно понимать что именно из-за наличия нескольких соединений вылетает Alarm. Потому что, по логике, если он перебирает, то должен перейти к следующему. А если нет - то сказать, что не может соединиться.

На чем вылетает аларм?
Что будет, если ты просто выбираешь сервер, чтобы открыть базу?
Что trace выдает?

Если в соединении прописано имя, то получение адреса - дело днс.

 

[collection]

может быть это поможет
Disable the use of the cached addresses by using the following NOTES.INI setting:
Solution
DONT_USE_REMEMBERED_ADDRESSES=1
If the client uses multiple or slow port technologies, we discourage the use of this technique because it
can cause a long delay in reporting that a server is down

 

[Bonyfather]

Наш сервер ходит в Интернет через 4 шнурка (разные провайдеры).
Удаленных юзеров как всегда много и они, как обычно, бестолковы.
Максимум, что юзер соображает - внизу между ключиком и конвертиком д.б. написано USERNAME (так уж места вызова именуются).

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

Из-за кэширования адреса сервера (или ID документа подключения - бог его знает!) если использовавшийся последний раз адрес кажет в бездну -> ALARM (не можу подключиться...)!

 

[puks]

Как раз сегодня пришлось решать подобную задачу, но для сервера. Поэтому сделал тесты и для клиента по полной программе. Конфигурация: форточки хп проф, лотусовый клиент 6.5.4. Сервер имеет 2 адреса. Создал 2 соединения в локальной адресной книге. На закладке Advanced есть поле Usage priority. Вот его описание.

Select Normal or Low to specify when to use this connection information in a search for the destination server path. Default is Normal.

Notes and Domino use the following steps when determining how to connect to a server:

1. Try to determine a path to the destination by examining all Connection documents with the Usage priority set to Normal.

2. If step 1 fails, ask the home server for connection information and/or probe all enabled ports.

3. If step 2 fails, look at all Connection documents with the Usage priority set to Low.

4. If step 3 fails, attempt to use a default passthru server to connect.

Set the Usage priority to Low if you only want the Connection documents used after attempting to connect over the LAN.

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

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

Таким же макаром я проверил и просто открытие базы на сервере. Все работает, как часы.

Так что уже извини. Как говорится, продукт работает, как и предполагалось. Что-то видно в консерватории надо подправлять.

Надеюсь, что все вышеописанное заглаживают мою утреннюю сонливость.

 

[Bonyfather]

Спасибо, puks!

1) Мои юзеры используют Notes 5.08 rus
2) служба поддержки клянется, что такой тест проводился и якобы даже неоднократно, но безушпешно.

Может быть корень зла в версии клиента?

Все-равно придется пробовать самому.

В крайнем случае попробую работать с одной парой Location+Connection, изменяя параметры программно и так же программно переключаясь между местами вызова:

Сеть - Нет связи - Сеть (это работает точно!)

 

[Constantin A Chervonenko]

1) Мои юзеры используют Notes 5.08 rus
2) служба поддержки клянется, что такой тест проводился и якобы даже неоднократно, но безушпешно.

Может быть корень зла в версии клиента?

Может. Где-то между 5 и 6 этот алгоритм правили. В 4-ке так точно перебор коннектов происходил только при (определенном) ответе сервера.
Т.е. если сервак просто молчал в тряпочку, выводилось сообщение о таймауте - и все, следующий коннект не проверялся