Заливка сегмента нодлиста

Dmitriy Romanov написал(а) к Alexey Khromov в Oct 24 17:49:08 по местному времени:

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


Писал как-то Alexey Khromov к Dmitriy Romanov примерно 12 Окт 24 в 17:07
А я смотрю и фигею.

DR>> А зачем их скрывать? Вызывающий сам должен разобраться, с каким
DR>> адресом он будет работать. Или предъявление "несуществующего" ака
DR>> (помимо основного адреса) тянет на какое-то преступление?
AK> Да, предъявление "несуществующего" FTN-адреса никак не преступление.
AK> Однако меня самого удивляет факт наличия в настройках bforce опций
AK> hideAka, которые работают для EMSI-сессий, но не работают для binkp.
AK> Хорошая возможность привести все к единому знаменателю.
При имеющейся реализации вполне понятно, почему она не работает. Мне больше другой вопрос интересен. А нужна ли такая
опция? Если да, то хотелось бы конкретный пример из жизни, где это действительно могло бы понадобиться.

На сем разрешите письмо закончить. Elec (RA2FDR)
--- NoSFeRaTU's GoldED+/W32-MINGW 1.1.5-b20090603

Dmitriy Romanov написал(а) к Alexey Fayans в Oct 24 17:50:32 по местному времени:

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


Писал как-то Alexey Fayans к Dmitriy Romanov примерно 12 Окт 24 в 17:12
А я смотрю и фигею.
AF>>> Возможно, ты прав. Но хотелось бы увидеть софт, который сможет
AF>>> успешно провести сессию с каким-нибудь binkd 1.0 в качестве
AF>>> вызывающей стороны, отправив ему свои адреса после того, как он
AF>>> предъявит свои.
DR>> Такой точно есть. У кого-то из моих линков был, когда я свой мейлер
DR>> тогда писал и тестировал. Уже точно не помню у кого и какой. Ну и
DR>> наверняка с binkd он прекрасно договаривался.
AF> Я очень в этом сомневаюсь. В общем, нужно тестировать.
Если бы это было не так, то наверняка этот мейлер бы не использовали, так как у большинства все-таки binkd.

На сем разрешите письмо закончить. Elec (RA2FDR)
--- NoSFeRaTU's GoldED+/W32-MINGW 1.1.5-b20090603

Alexey Fayans написал(а) к Dmitriy Romanov в Oct 24 21:16:59 по местному времени:

Нello Dmitriy!

On Sun, 13 Oct 2024 17:50 +0200, you wrote to me:

DR>>> Такой точно есть. У кого-то из моих линков был, когда я свой
DR>>> мейлер тогда писал и тестировал. Уже точно не помню у кого и
DR>>> какой. Ну и наверняка с binkd он прекрасно договаривался.
AF>> Я очень в этом сомневаюсь. В общем, нужно тестировать.
DR> Если бы это было не так, то наверняка этот мейлер бы не использовали,
DR> так как у большинства все-таки binkd.

Нет тела - нет дела, как говорится. Нужны пруфы. Пока что, если руководствоваться логикой, можно с большой уверенностью сказать, что такой мейлер соединится с binkd только в качестве вызывыающего, но не наоборот.


... Music Station BBS | https://bbs.bsrealm.net | telnet://bbs.bsrealm.net
--- GoldED+/W32-MSVC 1.1.5-b20180707

Nil A написал(а) к Dmitriy Romanov в Oct 24 01:25:10 по местному времени:

Нello, Dmitriy!

13 Oct 24 17:49, from Dmitriy Romanov -> Alexey Khromov:

AK>> Да, предъявление "несуществующего" FTN-адреса никак не
AK>> преступление. Однако меня самого удивляет факт наличия в
AK>> настройках bforce опций hideAka, которые работают для
AK>> EMSI-сессий, но не работают для binkp. Хорошая возможность
AK>> привести все к единому знаменателю.

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

Скрыть принадлежность к каким-то зашкварным левонетам. Но хотя, в этом случае проще левонетовые линки на отдельном просто порту хостить, отдельным конфигом. Хотя, может не весь софт понимает, что можно ходить на нестандартный порт.

Best Regards, Nil
--- GoldED+/LNX 1.1.5-b20240306

Nil A написал(а) к Dmitriy Romanov в Oct 24 02:35:24 по местному времени:

Нello, Dmitriy!

12 Oct 24 14:57, from Dmitriy Romanov -> Nil A:

NA>> проверяет уровень выше, со своими дуполовками. Но всё равно,
NA>> можно решить многое и на уровне пересылке бандлов.

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

Именно такой сценарий.

DR> Настолько маловероятная и труднопопадаемая ситуация, что можно
DR> исправление этой ошибки переложить и на вышестоящий уровень.

Несколько раз в год дупы у меня так получаются. Смотрю по логам, и один и тот же бандл пришёл дважды.
Так то да, уровень дуполовки отрабатывает, но приходится смотреть почему, чтобы какую-то возможно другую важную причину не пропустить.

Best Regards, Nil
--- GoldED+/LNX 1.1.5-b20240306

Alexey Fayans написал(а) к Nil A в Oct 24 08:41:07 по местному времени:

Нello Nil!

On Mon, 14 Oct 2024 02:35 +0300, you wrote to Dmitriy Romanov:

NA> Несколько раз в год дупы у меня так получаются. Смотрю по логам, и
NA> один и тот же бандл пришёл дважды.

=== Start of Windows Clipboard ===
# * `-nd' means "No Dupe Mode", this works only on outbound calls with
# another binkd 0.9.3 or higher. The option solves problem with
# duplicating files while losts carrier but link is a bit slower
# then with "-nr" option
=== End of Windows Clipboard ===

Нужно чтобы и у тебя, и у линка было включено. В логе сессии должна быть строчка:

=== Start of Windows Clipboard ===
- 14 Oct 08:42:00 [1264] remote is in ND mode
=== End of Windows Clipboard ===


... Music Station BBS | https://bbs.bsrealm.net | telnet://bbs.bsrealm.net
--- GoldED+/W32-MSVC 1.1.5-b20180707

Stas Mishchenkov написал(а) к Alexey Fayans в Oct 24 09:42:06 по местному времени:

Нi Alexey!

13 Oct 24 17:41, Alexey Fayans -> Stas Mishchenkov:

AF>>> Возможно, ты прав. Но хотелось бы увидеть софт, который сможет
AF>>> успешно провести сессию с каким-нибудь binkd 1.0 в качестве
AF>>> вызывающей стороны, отправив ему свои адреса после того, как он
AF>>> предъявит свои.
SM>> https://brorabbit.g0x.ru/files/perl/callip.pl в качестве вызывающей
SM>> стороны работает с любым вариантом...

AF> Отлично, но как я и написал, нужно тестировать binkd 1.0 в качестве
AF> вызывающей стороны, потому что именно он, скорее всего, будет ждать до
AF> последнего, пока вызываемая сторона не представится. В результате либо
AF> сессия отвалится по таймауту, либо binkd 1.0 буде думать, что соединился с
AF> каким-нибудь 0:0/0.

Сори. Не внимательно прочитал. Здесь реализован binkp 1.0 таким образом, что он не ждёт, когда вызываемая сторона представится, а сразу представляется сам.

Нave nice nights.
Stas Mishchenkov.

--- Вечеринка - это как утренник, только ты не зайчик, а свинья.

Alexey Fayans написал(а) к Stas Mishchenkov в Oct 24 12:14:43 по местному времени:

Нello Stas!

On Mon, 14 Oct 2024 09:42 +0300, you wrote to me:

AF>> Отлично, но как я и написал, нужно тестировать binkd 1.0 в
AF>> качестве вызывающей стороны, потому что именно он, скорее всего,
AF>> будет ждать до последнего, пока вызываемая сторона не
AF>> представится. В результате либо сессия отвалится по таймауту,
AF>> либо binkd 1.0 буде думать, что соединился с каким-нибудь 0:0/0.
SM> Сори. Не внимательно прочитал. Здесь реализован binkp 1.0 таким
SM> образом, что он не ждёт, когда вызываемая сторона представится, а
SM> сразу представляется сам.

Как и везде. И речь в этом треде идёт о том, что будет, если вызываемая сторона представится не полностью и будет ждать адрес вызывающей перед тем, как выдать свой. И я говорю о binkd 1.0, а не binkp 1.0, потому что, вероятно, в какой-нибудь современной версии binkd такой хендшейк и прокатит, а в старой - крайне маловероятно.


... Music Station BBS | https://bbs.bsrealm.net | telnet://bbs.bsrealm.net
--- GoldED+/W32-MSVC 1.1.5-b20180707

Vitaliy Aksyonov написал(а) к Alexey Fayans в Oct 24 23:27:30 по местному времени:

Привет, Alexey!

10 Oct 24 09:14, ты писал(а) Dmitriy Romanov:

AF>>> В спецификации binkp написано, что вызываемая сторона должна
AF>>> начать хендшейк. Поэтму любой софт, реализующий протокол binkp,
AF>>> будет работать именно так и никак иначе. Если кто-то сделает
AF>>> по-другому, то ни один стандартный клиент не будет с такой
AF>>> реализцией работать.
DR>> классический binkd не дожидается, пока вызывающий представится.

AF> Я именно об этом и пишу. Потому что в классическом (и единственном)
AF> binkp представляется ВЫЗЫВАЕМВЫЙ, а не вызывающий. И пока вызываемый
AF> не представится (не начнёт хендшейк), сессия не начнётся.

А вот стандарт с тобой не согласен. fts-1026.001 говорит, что, цитата:

6.1.1 Originating Side
----------------------

Originating side sends MADR and MPWD frames, waits for successful
authentication acknowledgement from the Answering side (M_OK frame)
and goes to file transfer stage; or receive M_ERR frame and close
connection. Originating side MUST NOT wait before sending M_ADR
frame, i.e. this frame should be send just after setting up a
connection on underlying layer. Originating side MUST NOT wait
before sending MPWD except after reception of MADR frame. The
term wait in this paragraph means do not send anything while
expecting data from remote.

То есть сразу поле коннекта шлёт свои адреса и пароли.

6.1.2 Answering Side
--------------------

Originating side sends MADR and waits for M_ADR and MPWD frames
from remote. Upon receptions of these frames, it decides whether
the password really matches the list of presented addresses, and
either acknowledges it by sending M_OK frame (and goes to file
transfer stage) or rejects by sending M_ERR frame (and
disconnects). The term wait in this paragraph means do not send
anything while expecting data from remote.

То есть реальные мейлеры могут слать адреса одновременно! Протокол ведь полнодуплексный.

Best regards,
Vitaliy Aksyonov.

... Куй железо, если не можешь ковать золото.
--- GoldED+/LNX 1.1.5-b20240309

Vitaliy Aksyonov написал(а) к Alexey Fayans в Oct 24 23:37:18 по местному времени:

Привет, Alexey!

14 Oct 24 12:14, ты писал(а) Stas Mishchenkov:

AF>>> Отлично, но как я и написал, нужно тестировать binkd 1.0 в
AF>>> качестве вызывающей стороны, потому что именно он, скорее всего,
AF>>> будет ждать до последнего, пока вызываемая сторона не
AF>>> представится. В результате либо сессия отвалится по таймауту,
AF>>> либо binkd 1.0 буде думать, что соединился с каким-нибудь 0:0/0.
SM>> Сори. Не внимательно прочитал. Здесь реализован binkp 1.0 таким
SM>> образом, что он не ждёт, когда вызываемая сторона представится, а
SM>> сразу представляется сам.

AF> Как и везде. И речь в этом треде идёт о том, что будет, если
AF> вызываемая сторона представится не полностью и будет ждать адрес
AF> вызывающей перед тем, как выдать свой. И я говорю о binkd 1.0, а не
AF> binkp 1.0, потому что, вероятно, в какой-нибудь современной версии
AF> binkd такой хендшейк и прокатит, а в старой - крайне маловероятно.

Если одна из сторон не пришлёт адрес/пароль, то сессия просто не установится и отвалится по таймауту. Но что-то мне подсказывает, что это так не работает. Ведь в самой первой версии стандарта нет никакого ожидание адресов прежде чем слать свои адреса.

Best regards,
Vitaliy Aksyonov.

... Что нам, кабанам?
--- GoldED+/LNX 1.1.5-b20240309