#1
|
|||
|
|||
.try
Sergey Zabolotny написал(а) к All в Jun 22 11:36:16 по местному времени:
Нello All. файлы лежат мертвым грузом, только обновляется дата модификации при каждой следующей прополке. слегка раздражает куча этих файлов в аутбаунде. это так и было задумано? --- GoldED+ 1.1.5-031023 (WinNT 5.1.2600-ServicePack3 i1586) |
#2
|
|||
|
|||
.try
Pavel Gulchouck написал(а) к Sergey Zabolotny в Jun 22 23:24:52 по местному времени:
Нi Sergey! 06 Jun 22, Sergey Zabolotny ==> All: SZ> файлы лежат мертвым грузом, только обновляется дата модификации при каждой следующей прополке. слегка раздражает куча этих файлов в SZ> аутбаунде. это так и было задумано? Нет, было задумано, что они будут там лежать и не будут раздражать. :) Туда пишется статистика по удачным и неудачным попыткам, чтобы не долбиться постоянно на недоступные узлы. Можно было бы для этого сделать отдельную базку где-то в файлике, но раз уж есть BSO, логичнее следовать его принципам, и располагать эти файлы там же, где lo, ut и bsy - такая схема хранения информации выглядит более консистентной, чем разнородные базы для хранения разной информации о линках. Lucky carrier, Паша aka gul@gul.kiev.ua --- GoldED+/LNX 1.1.5-b20160827 |
#3
|
|||
|
|||
.try
Sergey Zabolotny написал(а) к Pavel Gulchouck в Jun 22 23:38:10 по местному времени:
Нello Pavel. Monday 06 June 2022 23:24, Pavel Gulchouck wrote to Sergey Zabolotny: SZ>> файлы лежат мертвым грузом, только обновляется дата модификации SZ>> при каждой следующей прополке. слегка раздражает куча этих файлов SZ>> в аутбаунде. это так и было задумано? PG> Нет, было задумано, что они будут там лежать и не будут раздражать. :) PG> Туда пишется статистика по удачным и неудачным попыткам, чтобы не PG> долбиться постоянно на недоступные узлы. Можно было бы для этого PG> сделать отдельную базку где-то в файлике, но раз уж есть BSO, логичнее PG> следовать его принципам, и располагать эти файлы там же, где lo, ut PG> и bsy - такая схема хранения информации выглядит более консистентной, PG> чем разнородные базы для хранения разной информации о линках. есть смысл держать в этих файлах информацию о неудачных попытках и по этой информации ориентироваться как поллить узел следующий раз. но для чего нужен такой файл если поллинг узла прошел успешно? --- GoldED+ 1.1.5-031023 (WinNT 5.1.2600-ServicePack3 i1586) |
#4
|
|||
|
|||
.try
Pavel Gulchouck написал(а) к Sergey Zabolotny в Jun 22 00:10:16 по местному времени:
Нi 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>> Нет, было задумано, что они будут там лежать и не будут раздражать. :) 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 --- GoldED+/LNX 1.1.5-b20160827 |
#5
|
|||
|
|||
.try
Sergey Zabolotny написал(а) к Pavel Gulchouck в Jun 22 15:52:04 по местному времени:
Нello Pavel. Tuesday 07 June 2022 00:10, Pavel Gulchouck wrote to Sergey Zabolotny: SZ>>>> файлы лежат мертвым грузом, только обновляется дата модификации SZ>>>> при каждой следующей прополке. слегка раздражает куча этих SZ>>>> файлов в аутбаунде. это так и было задумано? PG>>> Нет, было задумано, что они будут там лежать и не будут 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 badtry (FTN_ADDR fa, const char *error, const int where, BINKDCONFIG co write_try (fa, &nok, &nbad, (char *) error, config); } -void goodtry (FTN_ADDR fa, char *comment, BINKDCONFIG config) +void removetry (FTN_ADDR fa, BINKDCONFIG 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[MAXPATНLEN + 1]; + ftnaddresstofilename (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 badtry_type { BAD_NA, BAD_CALL, BAD_MERR, BAD_MBSY, BAD_IO, BADTIMEOUT, BADAKA, BADAUTН }; void badtry (FTN_ADDR fa, const char *error, const int where, BINKDCONFIG config); -void goodtry (FTN_ADDR fa, char *comment, BINKDCONFIG config); void readtry (FTN_ADDR fa, unsigned *nok, unsigned *nbad, BINKDCONFIG config); void writetry (FTN_ADDR fa, unsigned *nok, unsigned *nbad, char *comment, BINKDCONFIG config); +void removetry (FTN_ADDR fa, BINKDCONFIG 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 socketin, SOCKET socket_out, FTN_NODE to, FTNADDR fa, processkilllist (state.killlist, state.nkilllist, 's'); inbremovepartial (&state, config); if (to) - good_try (&to->fa, "CONNECT/BND", config); + remove_try (&to->fa, config); } else { приложил у себя в виде патча и пока не заметил каких-то глюков. если можно сделать лучше/оптимальнее, было бы интересно увидеть альтернативные варианты. --- GoldED+ 1.1.5-031023 (WinNT 5.1.2600-ServicePack3 i1586) |
#6
|
|||
|
|||
.try
Sergey Zabolotny написал(а) к Pavel Gulchouck в Jun 22 16:07:18 по местному времени:
Нello Pavel. Tuesday 07 June 2022 15:52, Sergey Zabolotny wrote to Pavel Gulchouck: SZ>>>>> файлы лежат мертвым грузом, только обновляется дата SZ>>>>> модификации при каждой следующей прополке. слегка раздражает SZ>>>>> куча этих файлов в аутбаунде. это так и было задумано? PG>>>> Нет, было задумано, что они будут там лежать и не будут PG>>>> раздражать. :) PG>>>> Туда пишется статистика по удачным и неудачным попыткам, чтобы PG>>>> не долбиться постоянно на недоступные узлы. Можно было бы для PG>>>> этого сделать отдельную базку где-то в файлике, но раз уж есть PG>>>> BSO, логичнее следовать его принципам, и располагать эти файлы PG>>>> там же, где lo, ut и bsy - такая схема хранения информации PG>>>> выглядит более консистентной, чем разнородные базы для хранения PG>>>> разной информации о линках. SZ>>> есть смысл держать в этих файлах информацию о неудачных попытках SZ>>> и по этой информации ориентироваться как поллить узел следующий SZ>>> раз. но для чего нужен такой файл если поллинг узла прошел SZ>>> успешно? PG>> В общем, да, там есть счётчик последовательных успешных попролов PG>> ноды, и этот счётчик никак не используется. Сделано это было до PG>> 1998, в версии 0.8.8. Пожалуй, можно и удалять после успешной PG>> сессии, если мешают. Это функция good_try() в ftnq.c. SZ> я не специалист в сях, так что не судите слишком строго. у меня SZ> получилось примерно так: $ git diff diff --git a/ftnq.c b/ftnq.c index SZ> f1a78a2..3e2dfdd 100644 -+- a/ftnq.c поспешил я с выводами на счет косяков. есть как минимум один - пытается удалять файл, которого не существует. надо добавить проверку на существование файла. --- GoldED+ 1.1.5-031023 (WinNT 5.1.2600-ServicePack3 i1586) |
#7
|
|||
|
|||
.try
Sergey Zabolotny написал(а) к Pavel Gulchouck в Jun 22 16:31:16 по местному времени:
Нello Pavel. Tuesday 07 June 2022 16:07, Sergey Zabolotny wrote to Pavel Gulchouck: PG>>> В общем, да, там есть счётчик последовательных успешных попролов PG>>> ноды, и этот счётчик никак не используется. Сделано это было до PG>>> 1998, в версии 0.8.8. Пожалуй, можно и удалять после успешной PG>>> сессии, если мешают. Это функция good_try() в ftnq.c. SZ>> я не специалист в сях, так что не судите слишком строго. у меня SZ>> получилось примерно так: $ git diff diff --git a/ftnq.c b/ftnq.c SZ>> index f1a78a2..3e2dfdd 100644 -+- a/ftnq.c SZ> поспешил я с выводами на счет косяков. есть как минимум один - SZ> пытается удалять файл, которого не существует. надо добавить проверку SZ> на существование файла. так правильнее будет: diff --git a/ftnq.c b/ftnq.c index f1a78a2..022f2ea 100644 -+- a/ftnq.c +++ b/ftnq.c @@ -1120,13 +1120,16 @@ void badtry (FTN_ADDR fa, const char *error, const int where, BINKDCONFIG co write_try (fa, &nok, &nbad, (char *) error, config); } -void goodtry (FTN_ADDR fa, char *comment, BINKDCONFIG config) +void removetry (FTN_ADDR fa, BINKDCONFIG 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[MAXPATНLEN + 1]; + ftnaddresstofilename (buf, fa, config); + if (*buf) + { + strnzcat (buf, ".try", sizeof (buf)); + struct stat sb; + if (stat(buf, &sb) == -1) return; + 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 badtry_type { BAD_NA, BAD_CALL, BAD_MERR, BAD_MBSY, BAD_IO, BADTIMEOUT, BADAKA, BADAUTН }; void badtry (FTN_ADDR fa, const char *error, const int where, BINKDCONFIG config); -void goodtry (FTN_ADDR fa, char *comment, BINKDCONFIG config); void readtry (FTN_ADDR fa, unsigned *nok, unsigned *nbad, BINKDCONFIG config); void writetry (FTN_ADDR fa, unsigned *nok, unsigned *nbad, char *comment, BINKDCONFIG config); +void removetry (FTN_ADDR fa, BINKDCONFIG 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 socketin, SOCKET socket_out, FTN_NODE to, FTNADDR fa, processkilllist (state.killlist, state.nkilllist, 's'); inbremovepartial (&state, config); if (to) - good_try (&to->fa, "CONNECT/BND", config); + remove_try (&to->fa, config); } else { --- GoldED+ 1.1.5-031023 (WinNT 5.1.2600-ServicePack3 i1586) |