Добро пожаловать, Гость. Пожалуйста авторизуйтесь здесь.
FGHIGate на GaNJa NeTWoRK ST@Ti0N - Просмотр сообщения в эхоконференции RU.FTN.DEVELOP
Введите FGHI ссылку:


Присутствуют сообщения из эхоконференции RU.FTN.DEVELOP с датами от 12 Jul 13 20:52:30 до 18 Sep 24 20:30:55, всего сообщений: 2600
Ответить на сообщение К списку сообщений Предыдущее сообщение Следующее сообщение
= Сообщение: 2586 из 2600 =================================== RU.FTN.DEVELOP =
От   : Dmitriy Romanov                  2:6078/1           31 Aug 24 21:19:58
Кому : Nil A                                               31 Aug 24 21:19:58
Тема : Nodelist INA:xxx.binkp.net
FGHI : area://RU.FTN.DEVELOP?msgid=2:6078/1+66d36e45
На   : area://RU.FTN.DEVELOP?msgid=2:5015/46+66d36076
= Кодировка сообщения определена как: CP866 ==================================
==============================================================================
Приветики, 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/102@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)
--- NoSFeRaTU's GoldED+/W32-MINGW 1.1.5-b20090603
* Origin: В свинарнике не стыдно быть свиньей (2:6078/1)

К главной странице гейта
Powered by NoSFeRaTU`s FGHIGate
Открытие страницы: 0.222394 секунды