Расписание доставки почты
Соединения серверов для доставки почты задаются набором документов Connection в адресной книге.
· Документ Connection требуется только для соединения с серверами в разных поименованных сетях Notes внутри домена и соединения с серверами из других доменов; он не требуется для доставки почты в той же самой поименованной сети того же самого домена.
· Обычно документы Connection должны присутствовать на обеих сторонах соединения, чтобы имелась возможность инициализации связи каждым из серверов.
· Для сокращения количества документов Connection рекомендуется между двумя поименованными сетями Notes делать только пару документов - между одним сервером в одной сети и одним сервером в другой, а не между каждым сервером из одной и каждым сервером из другой.
· Фактический вызов согласно документу Connection осуществляется только при наличии почты на указанный в документе сервер назначения, поэтому можно не беспокоиться относительно "холостых звонков". По этой же причине рекомендуется задавать в документе Connection временной диапазон с коротким интервалом повторения.
· Расписание из документа Connection не принимается во внимание в случаях, когда достигнут порог "Route at once if..." ("Рассылать немедленно при..."), ожидает отправки почта высокого приоритета, или с консоли сервера введена команда Route <сервер назначения>.
· Соглашение о приоритетах следующее: High - отправка немедленно; Medium - отправка по расписанию или порогу; Low - использует соединения между 12:00 часами ночи и 6:00 утра (или как то указано в файле NOTES.INI в переменной MailLowPriorityTime).
· Приоритеты "соблюдаются" только для почты, передаваемой "согласно документа Connection" - почта в пределах поименованной сети Notes доставляется сразу, а приоритеты игнорируются.
Администратор составляет расписание передачи почты, руководствуясь следующими принципами.
· Необходимо учитывать существующее расписание репликаций, поскольку передача почты обычно сопровождает репликации. Не следует нужно создавать дополнительных документов Connection, если можно ограничиться существующими. Например, два вызова в день и для репликаций, и для передачи почты: утром и после полудня.
· Следует планировать вызовы для передачи почты среднего и низкого приоритета на время наименьшей загрузки сети. Например, до начала или после окончания рабочего дня в организации.
· По возможности следует стремиться ограничивать количество серверов, в одно и то же время вызываемых одним сервером, чтобы избежать перегрузки сервера большим количеством задач или подпроцессов. Производительность сервера может резко падать, когда этот сервер пытается выполнять излишне большое количество вызовов. Типичный признак перегрузки сервера - вызовы выполняются, но почта "не проходит". Поэтому рекомендуется "сдвигать по времени" диапазоны вызовов, например, вызов первого сервера для передачи почты с 8:00 до 10:00, второго сервера с 8:05 до 10:05, и так далее. Целесообразно также ограничивать возможность вызова одного и того же сервера только через один порт.
Передача почты, когда только один сервер может выполнять вызов другого
Иногда требуется, чтобы почта могла передаваться в обе стороны между серверами, но в условиях, что только один из серверов может выполнять вызов другого. Обычно эти условия определяется финансовыми соображениями, но могут быть и чисто технические причины. Например, если сервер B оснащен картой X.25, а сервер A лишь модемом, то сервер A
может вызывать сервер B через асинхронный PAD, тогда как сервер B не может вызывать сервер A.
Когда один сервер Notes соединяется с другим сервером по документу Connection типа Dialup Modem или X.25, задача Router вызываемого сервера получает об этом событии "уведомляющее сообщение" от программного обеспечения сетевого уровня. Если на вызванном сервере имеется ожидающая отправки на вызванный сервер почта, эта почта передается Router-ом вызванного сервера в MAIL.BOX на вызвавшем сервере по уже установленному соединению. Если входящий вызов "приходится" на диапазон времени для доставки почты низкого приоритета, "обратно" отправляется почта всех приоритетов. Если же вызов осуществлен во время вне диапазона для доставки почты низкого приоритета, "обратно" отправляется только почта высокого и среднего приоритетов.
Рассмотрим подробнее, как решить эту проблему.
Предположим, сервер A может вызывать сервер B, а сервер B не может вызывать сервер A.
Чтобы почта, предназначенная серверу A, "скапливалась" в MAIL.BOX на сервере B, приходится создать "макетный" документ Connection с сервера B на сервер A, указав в нем "неправильную" информацию, чтобы сервер B в самом деле не мог установить это соединение. В этом "макетном" документе Connection
нужно указать недопустимый телефонный номер, "разрешить" использование по расписанию, а в расписании выбрать вызов только один раз в день и всего один день в неделю. Кроме того, во избежание "бессмысленных" вызовов следует также позаботиться о том, чтобы пользователи либо не отправляли сообщений высокого приоритета, либо попросту не могли этого сделать.
Когда же сервер A установит соединение с сервером B, Router на сервере B воспользуется уже установленным соединением, чтобы передать "ожидающую" в своем MAIL.BOX на сервер A. Необходимо, чтобы сервер A вызывал сервер B хотя бы раз в сутки, чтобы "накопившаяся" на сервере B почта не возвращалась с уведомлением о недоставке. Более правильно планировать по крайней мере один вызов вне диапазона времени для доставки почты низкого приоритета и один вызов в диапазоне для доставки почты низкого приоритета. Если с сервера A на сервер B имеется "регулярный поток" почты, на сервере A можно обойтись документом Connection
только для передачи почты. Если регулярного потока почты нет, следует сделать по крайней мере один документ Connection для репликаций (чтобы обеспечить регулярность вызова) и передачи почты.
