Алгоритм выбора следующего сервера в маршруте (NextHop)
Алгоритм использует информацию из документов Person, MailInDatabase, Server, Connections и Domain общей адресной книги. Однако необходимая информация не выбирается всякий раз из адресной книги. При старте сервера она загружается в так называемые таблицы маршрутизации, находящиеся в виртуальной памяти сервера. Таблицы маршрутизации обновляются всякий раз, когда в адресную книгу внесено любое изменение. Кроме того, по умолчанию такие обновления выполняются каждые 60 минут. В версиях 4.х в файле NOTES.INI может применяться переменная MailDynamicCostReset, задающая интервал времени (в минутах), с которым Router должен восстановить в таблицах информацию из адресной книги.
Именно по таблицам маршрутизации и выполняется выбор маршрута. С позиций теории графов при этом решается задача выбора пути минимальной длины на графе от заданной вершины-источника до заданной вершины-назначения. В качестве следующего сервера в маршруте выбирается тот, к которому ведет первая дуга в пути минимальной длины.
Практически же дело осложняется следующими моментами.
· Ввиду целочисленности и ограниченности диапазона стоимостей соединений возможно существование нескольких маршрутов наименьшей стоимости. Router выбирает один из них. Известно, что Router с версии 4.11 из нескольких маршрутов наименьшей стоимости выбирает тот, в котором наименьшее количество дуг.
· Учитывается "история" отказов связи по соединению (дуге графа). Если попытка установления соединения терпит неудачу (нет ответа, таймаут и т.п.), Router добавляет единицу к стоимости этого соединения в своей таблице маршрутизации. При попытке повторить передачу сообщения в следующий раз вновь решается задача выбора маршрута наименьшей стоимости, но увеличение стоимости "плохого" соединения, вообще говоря, способствует получению другого оптимального маршрута, чем при предыдущей попытке. Очевидно, такое возможно только при наличии альтернативных путей от сервера-источника к серверу назначения. Логично было бы ожидать, что увеличение стоимости соединения происходит после каждой неудачи установления соединения. Но увеличение стоимости соединения на единицу выполняется только один раз, а не при каждой последующей неудачной попытке (документ 138604 от 26.06.96 из Lotus Notes Knowledge Base). В результате стоимость "плохого" соединения может не возрасти должным образом, чтобы от него отказались при очередной попытке. Например, пусть с сервера A на сервер B для доставки почты имеется два документа Connection, один со стоимостью 5 (дуга AB1), а другой со стоимостью 8 (дуга AB2). В этом случае второй документ Connection
(дуга AB2)
никогда не будет использоваться при доставке почты, поскольку в таблицах маршрутизации сервера A стоимость дуги AB1 может возрасти только до 6. Если вы измените второй документ Connection, уменьшив стоимость дуги AB2 до 6, то после неудачной попытки соединения по дуге AB1, когда ее стоимость в таблицах достигает 6, возникает неопределенность: будет выбираться одна из двух возможных дуг, но непонятно, какая именно. Если вы уменьшите стоимость дуги AB2 до 5, непонятно, какая из двух дуг выбирается при первой попытке установить соединение, зато при повторных попытках установления соединения будет выбираться уже другая дуга. В результате становится понятно, почему большинство попыток администраторов вводить несколько "резервных" маршрутов доставки почты и "глубоко продуманно" управлять стоимостями соединений оканчиваются провалом. К сожалению, рациональная политика на сегодняшний момент (версия 4.51) состоит в том, чтобы вводить "резервные" маршруты с разными приоритетами соединений, но использовать для них стоимости соединений, выбираемые по умолчанию.
· Используется еще одна особенность, называемая "оппортунистической маршрутизацией" (opportunistic routing). Если сервер успешно принимает входящий вызов (типа Dialup Modem или X.25) от другого сервера, Router принявшего вызов сервера восстанавливает в первоначальное значение стоимость соединения с вызывавшим сервером в своих таблицах маршрутизации. Это, вообще говоря, будет способствовать более активному использованию данного соединения в дальнейших попытках передачи почты.
· При передаче сообщений с сервера на сервер возможно появление "петель". Чтобы отследить соединения (дуги графа), по которым сообщение уже передавалось, в сообщении "поддерживается" поле RouteServers. Оно содержит список серверов, "через которые" сообщение "уже прошло". Как только Router обнаруживает петлю, он немедленно восстанавливает первоначальную стоимость соединения в таблицах маршрутизации. Поскольку наличие петли отражено в сообщении в поле RouteServers, впоследствии ни один из Router-ов уже не станет вновь передавать сообщение по этой петле. Однако петля может включать много соединений... Для предотвращения "длинных" петель в сообщении "поддерживается" счетчик пересылок с сервера на сервер (Hop Counter - поле $Hops), начальное значение которого устанавливается равным 25. При каждой передаче сообщения с сервера на сервер Hop Counter уменьшается на единицу. Когда его значение уменьшится до нуля, доставка сообщения прекращается, а отправителю возвращается уведомление о недоставке.
· Адаптивные изменения стоимости соединений производятся только в таблицах маршрутизации, находящихся в виртуальной памяти сервера. Эти изменения не вносятся из таблиц в адресную книгу и, очевидно, не реплицируются на другие серверы домена. Адаптивные изменения в таблицах будут утеряны при перезапуске сервера, при модификации адресной книги или через 60 (или MailDynamicCostReset) минут, и Router "в очередной раз забудет старый опыт и вновь начнет учиться на своих ошибках".
