Nodelist INA:xxx.binkp.net

[Alexey Khromov]

Здраствуйте, Dmitriy!

27 авг 24 22:02, Dmitriy Romanov -> Alex Barinov:

DR> Это тоже мысль, и я ее подумаю. Вот думаю, как в мейлере реализовать
DR> логику работы с нодлистом. Пока что получается прописываем все способы
DR> связи руками. Можно сделать либо вручную чтобы из нодлиста подтягивал,
DR> либо автоматически. Но как тогда обрабатывать случай, если из нодлиста
DR> подтянул, но принудительно отключил этот способ связи. А потом
DR> в нодлисте реквизиты поменялись... и что тогда автомату делать?
DR> Включать его автоматически? А в нодлисте их может быть несколько... в
DR> общем тут еще стоит подумать, и наверное не здесь, а где-нибудь в
DR> *.DEVELOP

В bforce по-умолчанию из нодлиста INA берется, если не указано ручками или
конфиге. К сожалению пока поддерживается только один флаг INA.
Для других мейлеров, как вариант, обрабатывать перл-хуками (если они есть в
мейлере), либо полностью отключать демон/сервис (он отвечает за сканирование
outbound) и писАть свою сканилку - там не сильно упорото - проверять по
нодлисту адрес и создавать на него poll с указанным в .*lo приоритетом.

* Оригинал написан в r50.sysop
* Скопировано в ru.ftn.develop


Alexey Khromov

[Dmitriy Romanov]

Приветики, Alexey!


Писал как-то 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> либо полностью отключать демон/сервис (он отвечает за сканирование
AK> outbound)
AK> и писАть свою сканилку - там не сильно упорото - проверять по нодлисту
AK> адрес
AK> и создавать на него poll с указанным в .*lo приоритетом.
Не, перл и что-то подобное я прикручивать не буду. Мне в этом плане проще - у
меня свой мейлер, как хочу так и пишу. Но
пока находится в стадии перехода с делфи-4 на лазарус-фрипаскаль, а развивать
буду уже после завершения этого перехода.
А там много где надо колдовать, все-таки разница в несколько десятилетий, надо
много кода править.
Тут больше интересна логика. На текущий момент для каждого линка заводятся одна
или несколько записей "телефонной
книги", где указаны способы соединения - модем, ip различных протоколов, у
каждой записи свое время работы, некоторые
можно галочкой отключить. Мне представляется, что при чтении нодлиста будут
добавлены еще по несколько записей там же.
Непонятки возникают вот в каком моменте. Допустим, я вручную в конфиге запретил
один из способов исходящего соединения
на линк, который прочитался из нодлиста. Как при очередном чтении нодлиста их
идентифицировать в дальнейшем? Вот я
запретил один. А на нем потом поменялся айпишник к примеру. Получится, что
старая запись удалится, но появится новая,
которая по умолчанию снова станет активной. Либо их сразу по умолчанию делать
неактивными, а включать вручную. Но тогда
теряется весь смысл автоматического чтения нодлиста - старый способ связи
станет неактуальным, а новый не активируется
автоматически.

Hа сем разрешите письмо закончить. Elec (RA2FDR)

[Alexey Khromov]

Здраствуйте, Dmitriy!

30 авг 24 21:56, Dmitriy Romanov -> Alexey Khromov:

DR> все-таки разница в несколько десятилетий, надо много кода править. Тут
DR> больше интересна логика. На текущий момент для каждого линка заводятся
DR> одна или несколько записей "телефонной книги", где указаны способы
DR> соединения - модем, ip различных протоколов, у каждой записи свое
DR> время работы, некоторые можно галочкой отключить. Мне представляется,

У каждого соединения есть свойства - тип, от типа пляшет адрес/телефон/е-мейл,
и время.

DR> что при чтении нодлиста будут добавлены еще по несколько записей там
DR> же. Непонятки возникают вот в каком моменте. Допустим, я вручную в
DR> конфиге запретил один из способов исходящего соединения на линк,
DR> который прочитался из нодлиста. Как при очередном чтении нодлиста их
DR> идентифицировать в дальнейшем? Вот я запретил один. А на нем потом

Либо запретить обновлять все соединения - замок на линк
Либо запретить обновлять соединения определенного типа - замок на способ
(вкладку)
Либо запретить обновлять соединения определенного типа с тем же временем
доступа (замок на строку)
Любое соединение, обновленное с нодлиста не попавшее под запрет генерит
лог-мессагу + в файл сисуведомлений. Файл сисуведомлений при открытии мейлера
сисопом показывается в окошке сисопу и очищается.
Ой, чот разбежался я.

DR> поменялся айпишник к примеру. Получится, что старая запись удалится,
DR> но появится новая, которая по умолчанию снова станет активной. Либо их
DR> сразу по умолчанию делать неактивными, а включать вручную. Но
DR> тогда теряется весь смысл автоматического чтения нодлиста - старый
DR> способ связи станет неактуальным, а новый не
DR> активируется автоматически.

Вот куда замок поставишь - там голова и будет болеть.
Еще мысля до кучи - галочка "основной способ связи обновлять всегда". Тогда еще
одно свойство линка (primary|secondary). Если это packed record то 1 бит займет
(шучу, сейчас нет смысла экономить - оно при обработке все равно слово съест).



Alexey Khromov

[Dmitriy Romanov]

Приветики, Alexey!


Писал как-то Alexey Khromov к Dmitriy Romanov примерно 30 Авг 24 в 23:28
А я смотрю и фигею.

DR>> все-таки разница в несколько десятилетий, надо много кода править.
DR>> Тут
DR>> больше интересна логика. На текущий момент для каждого линка заводятся
DR>> одна или несколько записей "телефонной книги", где указаны способы
DR>> соединения - модем, ip различных протоколов, у каждой записи свое
DR>> время работы, некоторые можно галочкой отключить. Мне представляется,
AK> У каждого соединения есть свойства - тип, от типа пляшет
AK> адрес/телефон/е-мейл, и время.
Но таковых может однотипных оказаться несколько. Ну ладно, телефон только один,
но ip-адресов может быть несколько.

DR>> что при чтении нодлиста будут добавлены еще по несколько записей там
DR>> же. Непонятки возникают вот в каком моменте. Допустим, я вручную в
DR>> конфиге запретил один из способов исходящего соединения на линк,
DR>> который прочитался из нодлиста. Как при очередном чтении нодлиста их
DR>> идентифицировать в дальнейшем? Вот я запретил один. А на нем потом
AK> Либо запретить обновлять все соединения - замок на линк
AK> Либо запретить обновлять соединения определенного типа - замок на
AK> способ (вкладку) Либо запретить обновлять соединения определенного
AK> типа с тем же временем доступа (замок на строку) Любое соединение,
AK> обновленное с нодлиста не попавшее под запрет генерит лог-мессагу + в
AK> файл сисуведомлений. Файл сисуведомлений при открытии мейлера сисопом
AK> показывается в окошке сисопу и очищается. Ой, чот разбежался я.
Сисоп в конфиг мейлера может заглядывать раз в несколько лет. А штатной морды
мейлер не имеет, так как заточен работать
сервисом в винде (ну в перспективе - демоном в линуксе). Писать в лог - ну тоже
так себе затея. Я в лог смотрю только
тогда, когда замечаю, что что-то пошло не так.

DR>> поменялся айпишник к примеру. Получится, что старая запись удалится,
DR>> но появится новая, которая по умолчанию снова станет активной. Либо их
DR>> сразу по умолчанию делать неактивными, а включать вручную. Но
DR>> тогда теряется весь смысл автоматического чтения нодлиста - старый
DR>> способ связи станет неактуальным, а новый не
DR>> активируется автоматически.
AK> Вот куда замок поставишь - там голова и будет болеть.
AK> Еще мысля до кучи - галочка "основной способ связи обновлять всегда".
AK> Тогда еще одно свойство линка (primary|secondary). Если это packed
AK> record то 1 бит займет (шучу, сейчас нет смысла экономить - оно при
AK> обработке все равно слово съест).
Можно только галочку на линка - не активировать автоматически добавленные
способы связи.


Hа сем разрешите письмо закончить. Elec (RA2FDR)

[Nil A]

Hello, Dmitriy!

30 Aug 24 21:56, from Dmitriy Romanov -> Alexey Khromov:

DR> больше интересна логика. На текущий момент для каждого линка заводятся
DR> одна или несколько записей "телефонной книги", где указаны способы
DR> соединения - модем, ip различных протоколов, у каждой записи свое
DR> время работы, некоторые можно галочкой отключить. Мне представляется,
DR> что при чтении нодлиста будут добавлены еще по несколько записей там
DR> же. Непонятки возникают вот в каком моменте. Допустим, я вручную в
DR> конфиге запретил один из способов исходящего соединения на линк,
DR> который прочитался из нодлиста. Как при очередном чтении нодлиста их
DR> идентифицировать в дальнейшем? Вот я запретил один. А на нем потом
DR> поменялся айпишник к примеру. Получится, что старая запись удалится,
DR> но появится новая, которая по умолчанию снова станет активной. Либо их
DR> сразу по умолчанию делать неактивными, а включать вручную. Но
DR> тогда теряется весь смысл автоматического чтения нодлиста - старый
DR> способ связи станет неактуальным, а новый не
DR> активируется автоматически.

Если у тебя парсер нодлиста как вывод правит конфиг куда и как звонить, то это
не очень удобно. Парсер нодлиста создаёт в_памаяти/на_диске словарик, ключ
FTN-адрес, значение - список способов связи, с флажками, с временем работы и
пр.
При этом в конфиге звонилки ты прописываешь линк, например, как в бинке.

node 2:5080/***@fidonet binkd.node.grumbler.org;binkp.vashadmin.su;* PASSWORD
И на этого нода бинк будет звонить сначала по этим хостам, на стандартный порт,
а потом звёздочка, т.е. сходить в нодлист.

А вот тут наоборот, сначала в нодлистовыми контактами попытается
воспользоваться, а потом уже на указанный хост пойдёт.
node 2:5058/104 *;math.ydns.eu PASSWORD

Best Regards, Nil

[Dmitriy Romanov]

Приветики, Nil!


Писал как-то Nil A к Dmitriy Romanov примерно 31 Авг 24 в 21:20
А я смотрю и фигею.


DR>> больше интересна логика. На текущий момент для каждого линка
DR>> заводятся
DR>> одна или несколько записей "телефонной книги", где указаны способы
DR>> соединения - модем, ip различных протоколов, у каждой записи свое
DR>> время работы, некоторые можно галочкой отключить. Мне представляется,
DR>> что при чтении нодлиста будут добавлены еще по несколько записей там
DR>> же. Непонятки возникают вот в каком моменте. Допустим, я вручную в
DR>> конфиге запретил один из способов исходящего соединения на линк,
DR>> который прочитался из нодлиста. Как при очередном чтении нодлиста их
DR>> идентифицировать в дальнейшем? Вот я запретил один. А на нем потом
DR>> поменялся айпишник к примеру. Получится, что старая запись удалится,
DR>> но появится новая, которая по умолчанию снова станет активной. Либо их
DR>> сразу по умолчанию делать неактивными, а включать вручную. Но
DR>> тогда теряется весь смысл автоматического чтения нодлиста - старый
DR>> способ связи станет неактуальным, а новый не
DR>> активируется автоматически.

NA> Если у тебя парсер нодлиста как вывод правит конфиг куда и как звонить, то
NA> это не очень удобно.
Это может быть в отдельной части конфига. В гуе конфига мейлера такие записи
будут отражаться в списке контактов линка,
например, другим цветом или с каким-нибудь значком. Из конфига их нельзя будет
только отредактировать, но можно
включить-выключить.
NA> Парсер нодлиста создаёт в_памаяти/на_диске словарик,
NA> ключ FTN-адрес, значение - список способов связи, с флажками, с
NA> временем работы и пр. При этом в конфиге звонилки ты прописываешь
NA> линк, например, как в бинке.
А кто мешает создавать в том же месте, где и конфиг лежит? Только эти записи
будут помечены как сгенерированные из
нодлиста, обновляться автоматически при чтении нодлиста (и удаляться), и не
подлежать редактированию.

NA> node 2:5080/***@fidonet binkd.node.grumbler.org;binkp.vashadmin.su;*
NA> PASSWORD И на этого нода бинк будет звонить сначала по этим хостам, на
NA> стандартный порт, а потом звёздочка, т.е. сходить в нодлист.
NA> А вот тут наоборот, сначала в нодлистовыми контактами попытается
NA> воспользоваться, а потом уже на указанный хост пойдёт. node 2:5058/104
NA> *;math.ydns.eu PASSWORD
У меня приоритет контактов одного линка не организован. За вызов по каждому
протоколу отвечает отдельный поток. Кто
первым схватил линка на вызов - для остальных блокирует его до тех пор, пока не
отпустит.

Hа сем разрешите письмо закончить. Elec (RA2FDR)