ru.binkd

Hi Nil! 24 May 22, Nil A ==> Evgeny Chevtaev: EC>> # Remove old .bsy/.csy files (If some are left after a system crash). EC>> It would # be wise to set this to 12h on almost any system. (Note that EC>> binkd always # touches .bsy's/.csy's for active sessions) # # EC>> kill-old-bsy is OFF by default. # kill-old-bsy 12h EC>> Это разве не оно? В binkd.conf параметр имеется, значит всё давно EC>> придумано. NA> Точно, почти оно. Только 12 часов залипания - это по сегодняшним меркам уже народ занервничает, хоть и фидо, хоть и "любительская сеть" NA> ;-) NA> А можно было бы и без времени сделать, если смотреть на PID внутри. NA> Только вопрос, все ли туда PID пишут, но хаски и бинк пишут. Софт должен ориентироваться на стандарт (в данном случае BSO), а не на фактическое поведение другого софта. Потому что поведение софта может меняться в пределах стандарта, софта может быть много разного, и это путь к граблям. По стандарту BSO внутри bsy пида может не быть. И это естестенно, ведь трудно атомарно создать бзишку с пидом. Кроме того, отсутствие процесса с прочитанным пидом не означает, что бзишку можно удалять. Ведь процесс, создавший бзишку, может быть на другом сервере (или на другой виртуалке - например, в докере) с другим пространством пидов. BSO на сетевом диске, мейлер и тоссер на разных компах - не такая уж редкая конфигурация. И кроме того, между событиями "прочитали пид из бзишки" и "удалили бзишку" могут быть другие события - например: - мы прочитали пид из бзишки; - процесс, установивший бзишку, успешно завершился, удалив за собой эту бзишку; - мы проверили существование процесса с указанным pid - его нет, считаем бзишку залипшей; - новый процесс запустился и установил свою бзищку на этот же адрес; - мы удалили эту новую бзишку и начали что-то делать с почтой параллельно с новым процессом. В результате могут получиться коллизии и потеря почты. В некоторых системах вообще нельзя открывать чужую бзишку на чтение, потому что владелец в это время не сможет удалить открытый кем-то файл. Было бы хорошо лочить бзишку на время сессии. Это можно сделать аккуратно и правильно почти на всех системах, но нужна гарантия, что так себя ведёт весь используемый софт, т.е. это получится уже не BSO, а немного другой тип outbound. В нынешних условиях вряд ли реально. В каком-то софте вместо бзишек использовались named mutex semaphores (TheBrake! Mailer, если не ошибаюсь). Интересно, но не взлетело. NA> Стоп, а что они туда пишут под виндой? ;-) Lucky carrier, Паша aka gul@gul.kiev.ua

Michiel, 17 May 22 23:28, you wrote to Sergey Zabolotny: MV>>> The IPv6 connectio fails. The most common problem is an incorrect MV>>> configured firewall. SZ>> i did some experimemnts with ipv6 configurations, thats why incoming SZ>> v6 connections to my system were failed. now it should work as SZ>> expected. MV> Not yet: MV> + 23:27 [3520] call to 2:469/122@fidonet MV> 23:27 [3520] trying fidonet.zuram.net MV> [2001:470:71:77b:f1d0:2:469:122]... ? 23:27 [3520] connection to MV> 2:469/122@fidonet failed: {W32 API error 10060} Connection timed out Works for me: $ nc -v6 2001:470:71:77b:f1d0:2:469:122 24554 Connection to 2001:470:71:77b:f1d0:2:469:122 24554 port [tcp/binkp] succeeded! ─.OPT CRAM-MD5-482b9c1d4cb89e8720881f4019f6b0ee─SYS UnderWorld─ZYZ Sergey Zabolotny─LOC Kishinev, Moldova─NDL 115200,TCP,BINKP─%TIME Wed, 18 May 2022 02:28:26 +0300─#VER binkd/1.1a-113/Linux binkp/1.1─ 2:469/122@fidonet

Hello *Alexander.* Wednesday 18 May 2022 15:52, Alexander Kruglikov wrote to Sergey Zabolotny: DS>>> у меня с того же места с добавлением --with-af-force без прочих DS>>> излишеств перестало ругаться на -64 в опшинах. А у тебя как раз DS>>> его не хватает, но есть --with-af-soft. SZ>> это я лошара опцию кривую написал. с --with-af-force перестало SZ>> ругаться на -64 спасибо AK> Общими усилиями разобрались. Пойду запушу изменённый конфиг чтоли Паше AK> в гит.. ага. не забудь только указать, что это работает с включенным --with-af-force. ;-)

Hello *Dmitriy.* Wednesday 18 May 2022 16:34, Dmitriy Smirnov wrote to Sergey Zabolotny: DS> у меня с того же места с добавлением --with-af-force без прочих DS> излишеств перестало ругаться на -64 в опшинах. А у тебя как раз его не DS> хватает, но есть --with-af-soft. это я лошара опцию кривую написал. с --with-af-force перестало ругаться на -64 спасибо

Hello Sergey, Tuesday May 17 2022 11:07, I wrote to you: SZ>> Binkd 1.1a-113 (May 9 2022 14:46:21/Linux) SZ>> Compilation flags: gcc, zlib, bzlib2, perl. SZ>> Facilities: fts5004 ipv6 MV> So your binkd supports IPv6. However: [..] MV> You are welcome to join the IPv6 echo... BTW, can you make outgoing binkd connections? You are welcome to try to connect to my system for testing... Cheers, Michiel

Hello *Pavel.* Tuesday 07 June 2022 00:10, Pavel Gulchouck wrote to Sergey Zabolotny: SZ>>>> файлы лежат мертвым грузом, только обновляется дата модификации SZ>>>> при каждой следующей прополке. слегка раздражает куча этих SZ>>>> файлов в аутбаунде. это так и было задумано? PG>>> Hет, было задумано, что они будут там лежать и не будут PG>>> раздражать. :) PG>>> Туда пишется статистика по удачным и неудачным попыткам, чтобы PG>>> не долбиться постоянно на недоступные узлы. Можно было бы для PG>>> этого сделать отдельную базку где-то в файлике, но раз уж есть PG>>> BSO, логичнее следовать его принципам, и располагать эти файлы PG>>> там же, где *lo, *ut и bsy - такая схема хранения информации PG>>> выглядит более консистентной, чем разнородные базы для хранения PG>>> разной информации о линках. SZ>> есть смысл держать в этих файлах информацию о неудачных попытках SZ>> и по этой информации ориентироваться как поллить узел следующий SZ>> раз. но для чего нужен такой файл если поллинг узла прошел SZ>> успешно? PG> В общем, да, там есть счётчик последовательных успешных попролов ноды, PG> и этот счётчик никак не используется. Сделано это было до 1998, в PG> версии 0.8.8. Пожалуй, можно и удалять после успешной сессии, если PG> мешают. Это функция good_try() в ftnq.c. я не специалист в сях, так что не судите слишком строго. у меня получилось примерно так: $ git diff diff --git a/ftnq.c b/ftnq.c index f1a78a2..3e2dfdd 100644 -+- a/ftnq.c +++ b/ftnq.c @@ -1120,13 +1120,14 @@ void bad_try (FTN_ADDR *fa, const char *error, const int where, BINKD_CONFIG *co write_try (fa, &nok, &nbad, (char *) error, config); } -void good_try (FTN_ADDR *fa, char *comment, BINKD_CONFIG *config) +void remove_try (FTN_ADDR *fa, BINKD_CONFIG *config) { - unsigned nok, nbad; - if (config->tries == 0) return; - read_try (fa, &nok, &nbad, config); - nbad = 0; - ++nok; - write_try (fa, &nok, &nbad, comment, config); + char buf[MAXPATHLEN + 1]; + ftnaddress_to_filename (buf, fa, config); + if (*buf) + { + strnzcat (buf, ".try", sizeof (buf)); + delete (buf); + } } diff --git a/ftnq.h b/ftnq.h index e399d91..cceb77d 100644 -+- a/ftnq.h +++ b/ftnq.h @@ -110,8 +110,8 @@ enum bad_try_type { BAD_NA, BAD_CALL, BAD_MERR, BAD_MBSY, BAD_IO, BAD_TIMEOUT, BAD_AKA, BAD_AUTH }; void bad_try (FTN_ADDR *fa, const char *error, const int where, BINKD_CONFIG *config); -void good_try (FTN_ADDR *fa, char *comment, BINKD_CONFIG *config); void read_try (FTN_ADDR *fa, unsigned *nok, unsigned *nbad, BINKD_CONFIG *config); void write_try (FTN_ADDR *fa, unsigned *nok, unsigned *nbad, char *comment, BINKD_CONFIG *config); +void remove_try (FTN_ADDR *fa, BINKD_CONFIG *config); #endif diff --git a/protocol.c b/protocol.c index 677cb44..6d40bea 100644 -+- a/protocol.c +++ b/protocol.c @@ -3440,7 +3440,7 @@ void protocol (SOCKET socket_in, SOCKET socket_out, FTN_NODE *to, FTN_ADDR *fa, process_killlist (state.killlist, state.n_killlist, 's'); inb_remove_partial (&state, config); if (to) - good_try (&to->fa, "CONNECT/BND", config); + remove_try (&to->fa, config); } else { приложил у себя в виде патча и пока не заметил каких-то глюков. если можно сделать лучше/оптимальнее, было бы интересно увидеть альтернативные варианты.

Привет, Evgeny! 12 июл 22 09:46, Evgeny Chevtaev писал(а) к All: EC> А для defnode, я так понимаю, "-64" не прокатывает? Присылай патч (ц) С наилучшими пожеланиями, Alexander.

hi, Alexander! 18 May 22 15:50, Alexander Kruglikov wrote to Sergey Zabolotny: DS>>>> чит кроется в --with-af-force =) AK>>> Я, кстати, так и не понял, что это за Enable soft AF force AK>>> feature =( SZ>> я тоже не понял, но включение этой опции сборки мне почему-то не SZ>> помогло. AK> Так ты её и не включил. у тебя --with-af-soft а надо --with-af-force AK> =) AK> З.Ы. (Замечу Ышо): --with-af-soft я вообще не нашёл в ./configure AK> --help это, поди, еще один волшебный чит ))) wbr, Dmitriy.

Hi Sergey! 06 Jun 22, Sergey Zabolotny ==> Pavel Gulchouck: SZ> Monday 06 June 2022 23:24, Pavel Gulchouck wrote to Sergey Zabolotny: SZ>>> файлы лежат мертвым грузом, только обновляется дата модификации SZ>>> при каждой следующей прополке. слегка раздражает куча этих файлов SZ>>> в аутбаунде. это так и было задумано? PG>> Hет, было задумано, что они будут там лежать и не будут раздражать. :) PG>> Туда пишется статистика по удачным и неудачным попыткам, чтобы не PG>> долбиться постоянно на недоступные узлы. Можно было бы для этого PG>> сделать отдельную базку где-то в файлике, но раз уж есть BSO, логичнее PG>> следовать его принципам, и располагать эти файлы там же, где *lo, *ut PG>> и bsy - такая схема хранения информации выглядит более консистентной, PG>> чем разнородные базы для хранения разной информации о линках. SZ> есть смысл держать в этих файлах информацию о неудачных попытках и по этой информации ориентироваться как поллить узел следующий раз. SZ> но для чего нужен такой файл если поллинг узла прошел успешно? В общем, да, там есть счётчик последовательных успешных попролов ноды, и этот счётчик никак не используется. Сделано это было до 1998, в версии 0.8.8. Пожалуй, можно и удалять после успешной сессии, если мешают. Это функция good_try() в ftnq.c. Lucky carrier, Паша aka gul@gul.kiev.ua

Hello *Pavel.* Monday 06 June 2022 23:24, Pavel Gulchouck wrote to Sergey Zabolotny: SZ>> файлы лежат мертвым грузом, только обновляется дата модификации SZ>> при каждой следующей прополке. слегка раздражает куча этих файлов SZ>> в аутбаунде. это так и было задумано? PG> Hет, было задумано, что они будут там лежать и не будут раздражать. :) PG> Туда пишется статистика по удачным и неудачным попыткам, чтобы не PG> долбиться постоянно на недоступные узлы. Можно было бы для этого PG> сделать отдельную базку где-то в файлике, но раз уж есть BSO, логичнее PG> следовать его принципам, и располагать эти файлы там же, где *lo, *ut PG> и bsy - такая схема хранения информации выглядит более консистентной, PG> чем разнородные базы для хранения разной информации о линках. есть смысл держать в этих файлах информацию о неудачных попытках и по этой информации ориентироваться как поллить узел следующий раз. но для чего нужен такой файл если поллинг узла прошел успешно?