AV>>> могу предположить, что при исходящей сессии обрабатывается только AV>>> .dlo, а соответствующий .hlo не обрабатывается. SM>> Вот, хорошо бы, коли только так, а когда .cut и .dut отдались, а SM>> .hut - нет, возникает вопрос, правильно ли я понимаю идею BSO? AV>>> Лично я сделал бы так: проводим сессию в соответствии с .dlo, а AV>>> после ее завершения,
AV> Здесь я неточно выразился:
...что на тебя не похоже. ;)
AV> правильнее - "после завершения обмена файлами".
Разумеется.
AV>>> когда эхотаг в течение ${rescan_delay} секунд проверяет, не AV>>> появилось ли еще чего-нибудь для этого линка,
AV> ... пока соединение еще не разорвано.
Конечно. Только зачем рескан, если перед сессией уже было известно, что на этого линка с каким флавором лежит.
AV>>> разрешить (или запретить) заглядывать еще и в .hlo
AV> Пусть, например, этот параметр называется rescan_include_hold
Скорре send_hold_if_outgouing ...
SM>> ммм... не уверен, что стоит "звонить" если есть долько hold. SM>> По идее он для того и выдуман, что бы не звонить...
AV> Еще раз: соединение _уже_ установлено, и даже обмен файлами из .dlo _уже_ AV> произошел.
Отправлаять .?ut после .?lo IMHO не совсем верно, даже с учетом флавора. Ожидаемый порядок отправки выглядит приблизительно так:
*.cut *.iut *.dut *.fut *.hut
*.clo *.ilo *.dlo *.flo *.hlo
SM>> С другой стороны, привычное для меня поведение мейлера - рескан SM>> (может быть запрещен в конфиге) аутбаунда после дозвона, перед SM>> началом сессии и отправка всего, что есть на этот узел. Входящей-то SM>> сессии может и не быть уже после этого.
AV> Ну вот я и предлагаю при rescan_include_hold == yes отдавать еще и то, что AV> накопилось в .hlo, а при rescan_include_hold == no ждать входящего AV> соединения.
Можно сделать и опциональным, но я не вижу причины не отдавать при исходящей сессии...
Have nice nights. Stas Mishchenkov.
--- Если ложка не стоит в сметане, очевидно, виновата не ложка! * Origin: Lame Users Breeding. Simferopol, Crimea. (2:460/58)
