Писал как-то Alexey Khromov к Dmitriy Romanov примерно 28 Авг 24 в 22:44 А я смотрю и фигею.
DR>> Это тоже мысль, и я ее подумаю. Вот думаю, как в мейлере реализовать DR>> логику работы с нодлистом. Пока что получается прописываем все способы DR>> связи руками. Можно сделать либо вручную чтобы из нодлиста подтягивал, DR>> либо автоматически. Но как тогда обрабатывать случай, если из нодлиста DR>> подтянул, но принудительно отключил этот способ связи. А потом DR>> в нодлисте реквизиты поменялись... и что тогда автомату делать? DR>> Включать его автоматически? А в нодлисте их может быть несколько... в DR>> общем тут еще стоит подумать, и наверное не здесь, а где-нибудь в DR>> *.DEVELOP
AK> В bforce по-умолчанию из нодлиста INA берется, если не указано ручками или AK> конфиге. К сожалению пока поддерживается только один флаг INA. Для других AK> мейлеров, как вариант, обрабатывать перл-хуками (если они есть в мейлере), AK> либо полностью отключать демон/сервис (он отвечает за сканирование outbound) AK> и писАть свою сканилку - там не сильно упорото - проверять по нодлисту адрес AK> и создавать на него poll с указанным в .*lo приоритетом. Не, перл и что-то подобное я прикручивать не буду. Мне в этом плане проще - у меня свой мейлер, как хочу так и пишу. Но пока находится в стадии перехода с делфи-4 на лазарус-фрипаскаль, а развивать буду уже после завершения этого перехода. А там много где надо колдовать, все-таки разница в несколько десятилетий, надо много кода править. Тут больше интересна логика. На текущий момент для каждого линка заводятся одна или несколько записей "телефонной книги", где указаны способы соединения - модем, ip различных протоколов, у каждой записи свое время работы, некоторые можно галочкой отключить. Мне представляется, что при чтении нодлиста будут добавлены еще по несколько записей там же. Непонятки возникают вот в каком моменте. Допустим, я вручную в конфиге запретил один из способов исходящего соединения на линк, который прочитался из нодлиста. Как при очередном чтении нодлиста их идентифицировать в дальнейшем? Вот я запретил один. А на нем потом поменялся айпишник к примеру. Получится, что старая запись удалится, но появится новая, которая по умолчанию снова станет активной. Либо их сразу по умолчанию делать неактивными, а включать вручную. Но тогда теряется весь смысл автоматического чтения нодлиста - старый способ связи станет неактуальным, а новый не активируется автоматически.
Hа сем разрешите письмо закончить. Elec (RA2FDR) --- NoSFeRaTU's GoldED+/W32-MINGW 1.1.5-b20090603 * Origin: В свинарнике не стыдно быть свиньей (2:6078/1)
