Структура сеанса связи
К моменту завершения "рукопожатия" (процедуры handshake) T-Mail
выбирает стратегию, по которой будет происходить сеанс связи. В общем
случае, если сняты ВСЕ многочисленные ограничения, сеанс строится так:
Для ВЫЗЫВАЮЩЕЙ системы (при исходящем звонке):
# передать всю почту без атрибута hold (.рkt и затем .?ut файлы,
кроме .hut, содержащие письма) для основного адреса удаленной системы;
# передать REQ-файлы (*.req), если для основного адреса удаленной
системы есть файловые запросы;
# передать все файлы из файлбокса по умолчанию (default filebox),
соответствующего основному адресу удаленной системы;
# передать все файлы (fileattached), "прицепленные" к письмам для
основного адреса удаленной системы. Если используется Bink-Style
Outbound, то затем будут последовательно переданы и файлы,
перечисленные в файлах *.clo, *.ilo, *.flo, *.nlo, *.dlo;
# передать файлы из дополнительного файлбокса (user filebox), заданного
в файле подстановок ключевым словом BOX для основного адреса удаленной
системы;
# повторить передачу файлов для дополнительных адресов (AKA) удаленной
системы (все пункты, указанные выше);
# после этого ПОВТОРНО проверяется наличие файлов в файлбоксе по
умолчанию для основного адреса удаленной системы и, если там появились
новые файлы, производится передача этих файлов. Таким образом,
добавленные до этого момента в файлбоксы файлы будут отосланы.
# принять почту и файлы от удаленной системы.
Для ВЫЗЫВАЕМОЙ системы (при входящем звонке):
# принять почту и файлы от удаленной системы;
# обработать пришедшие файловые и прочие запросы, выполнить Process
Online;
# передать всю почту без атрибута hold (.рkt и затем .?ut файлы,
кроме .hut, содержащие письма) для основного адреса удаленной системы;
# передать всю почту с атрибутом hold (.рkt и затем .hut файлы,
содержащие письма) для основного адреса удаленной системы;
# передать все файлы из файлбокса по умолчанию (default filebox),
соответствующего основному адресу удаленной системы;
# передать все файлы из неактивного файлбокса по умолчанию (hold
default filebox), соответствующего основному адресу удаленной системы;
# передать все файлы (fileattached), "прицепленные" к письмам для
основного адреса удаленной системы, в том числе неактивные (hold).
Если используется Bink-Style Outbound, то после этого будут
последовательно переданы и файлы, перечисленные в файлах *.clo, *.ilo,
*.flo, *.nlo, *.dlo, *.hlo;
# передать файл, заданный переменной BroadCast в t-mail.ctl . (если такая
переменная определена, файл существует и адрес системы входит в список
адресов, задаваемый в переменной BroadCast).
# передать файлы из дополнительного файлбокса (user filebox), заданного
в файле подстановок ключевым словом BOX для основного адреса удаленной
системы;
# повторить передачу файлов для дополнительных адресов (AKA) удаленной
системы (все пункты, указанные выше);
# передать ответ на файловые запросы, принятые от удаленной системы.
Этот ответ может состоять из:
- найденных запрашиваемых файлов;
- письма с указанием причин отказа в запросе;
- письма-подтверждения обработки файлового запроса.
# после этого ПОВТОРНО проверяется наличие файлов в файлбоксах (простом
и неактивном) по умолчанию для основного адреса удаленной системы и,
если там появились новые файлы, производится передача этих файлов.
Таким образом, добавленные до этого момента в файлбоксы файлы будут
отосланы.
Далее рассмотрим некоторые из ограничений, которые может устанавливать
системный оператор.
Переменная Accept_AKAs в t-mail.ctl определяет список адресов
удаленных систем, за исключением основного адреса, которые будут
восприниматься и обрабатываться T-Mail'ом. Не вошедшие в этот список
дополнительные адреса, сообщаемые удаленной системой игнорируются и
пропускаются соответствующие действия в сеансе связи.
При определенных обстоятельствах не будут передаваться файловые запросы
на удаленную систему. Во-первых, удаленная система может не поддерживать
файловые запросы (или они могут быть запрещены в текущий момент для вашего
адреса). Во-вторых, Вы сами можете установить временные ограничения для
передачи файловых запросов на конкретную удаленную систему:
- используя директиву NoReq в файле событий events.ctl ;
- задав интервал времени файловых запросов на удаленной системе полем
Ftime в файле подстановок subst.lst .
Если удаленная вызываемая система не поддерживает файловые запросы,
она сообщает об этом специальным полем в посылке handshake. При обычной
работе, получив такой флаг, T-Mail отложит файловые запросы на этот узел на
час. Благодаря этому, периодически опрашивая удаленную систему, T-Mail
может дождаться момента, когда файловые запросы будут разрешены.
Для определенных адресов можно задать режим "только почта". Этот режим
задается директивой MailOnly в файле событий events.ctl . При этом в
большинстве случаев происходит обмен только почтовыми пакетами (.рkt). Этот
режим может быть рекомендован для так называемых "почтовых часов", т.е.
интервалов суток, когда создаются наиболее благоприятные условия для
быстрой доставки персональной сетевой почты. Этому режиму соответствует
флагу HXT в посылке EMSI.
Для определенных адресов можно задать режим "только передача". Этот
режим задается директивой SendOnly в файле событий events.ctl . При этом
происходит только передача файлов. Этот режим действует только в случае
входного звонка и если мэйлер удаленной системы также понимает такой режим.
Этому режиму соответствует флаг HAT в посылке EMSI.
Наконец, при входящем звонке можно задать условия, когда удаленная
система будет отвергнута и сеанс связи проводится не будет. Переменная
Accept_Nodes в t-mail.ctl задает адреса систем, с которыми возможен сеанс
связи. Кроме того, можно задать минимальную скорость соединения переменной
Min_Baud в t-mail.ctl .
Для передачи информации во время сеанса связи T-Mail использует два
встроенных способа: с помощью однонаправленного протокола Zmodem и с
помощью двунаправленного протокола Janus. Выше был описан порядок работы
T-Mail при использовании однонаправленного протокола, то есть прием и
передача информации осуществляется поочередно. В случае, если соединение
было установлено с возможностью использования двунаправленного протокола,
передача и прием информации осуществляется одновременно, при этом порядок
действий аналогичен первому случаю. Повторная проверка наличия информации
производится как по завершении приема, так и по завершении передачи -
независимо.