Фреки по-роутингу

Stas Mishchenkov написал(а) к Vladimir Donskoy в Oct 23 11:55:22 по местному времени:

Нi Vladimir!

27 Oct 23 19:57, Vladimir Donskoy -> Oleg Redut:

VD> Так эта самая автоматизация и есть "поддержка фреканья по роутингу"! И
VD> у узла, не понимающего такого - фрекать по роутингу не получится,
VD> максимум обычный фрек выйдет.

Вэтом месте мы подошли к тому, как же узнать, какой тип фрека поддерживает узел. Опять мотрим в нодлист.

Нave nice nights.
Stas Mishchenkov.

--- Каждый раз бухай как последний. Потому что однажды так и будет.

Oleg Redut написал(а) к Vladimir Donskoy в Oct 23 12:55:22 по местному времени:

Доброе (current) время суток, Vladimir!

VD>>> Все вы забываете в этом треде один момент: только из нетмайла,
VD>>> созданного на данном узле! И далее по тексту:

OR>> Я не забываю. Я только этот вариант и рассматриваю. :-)

VD> Согласно сабжу мы роутинг рассматриваем.

Фидошники сабжей не меняют.

VD>>> его атрибуты вы не имеете права. И обработка этого письма - дело
VD>>> того узла, которому оно предназначено (с которого фрекают)!

OR>> Логично. Но можно послать квиток.

VD> Если квиток запрошен соответствующим флагом в письме, иначе это
VD> спам...

С чего бы спам? Так любое письмо от ареафикса может считаться спамом. Спам - это массовая рассылка. И на извещения флаги не предусмотрены. Любой узел может на любой нетмайл настроить bounce, с извещением, что письмо, скажем, получено, но когда будет прочтено - неизвестно. Или отреагировать извещением на любой другой флаг/сабж/текст.

OR>> А вот это уже далеко не факт. Дистанционно фрекнутые файлы
OR>> узел адресата может тупо положить на холд. И ждать директной
OR>> прозвонки с любой стороны.

VD> Отсутствует роутинг фреков, раз на холде лежит! Итого - такая система
VD> не поддерживает роутинг фреков, нечего к ней обращаться.

Логики не вижу. Если фрек по роутингу дошёл до конечного узла и обраотался, с выкладываеним заказанного на холд - это не значит, что он не поддерживает фреки. Это уже значит, что он не поддерживает аттачи по роутингу. Вместо холда, узел может начать ломиться директом на узел отправивший файловый запрос. :-)
Давай разделим эти понятия:

OR>> Аттач - это активное действие по отправке файла.
OR>> Обработка фрека - пассивное: выкладывание запрощенного файла на
OR>> отправку и создание какой-либо лошки, согласно политики ноды.
OR>> Создание и отправка аттача по роутингу - это уже не относится к
OR>> процедуре фрека. Это уже отдельный наворот объединяющий два
OR>> понятия. Это как бы просто нетмайлом написали, отправь мне, плиз,
OR>> такой-то файл. И ему заттачили бы по роутингу. Просто можно,
OR>> конечно, это автоматизировать. Но это не будут фрек и аттач в
OR>> чистом виде этих понятий.

VD> Так эта самая автоматизация и есть "поддержка фреканья по роутингу"! И
VD> у узла, не понимающего такого - фрекать по роутингу не получится,
VD> максимум обычный фрек выйдет.

Фрек по роутингу: передача фрек-запроса транзитом до конечного узла.

Что я могу еще сказать?..
Oleg

... AKA oleg(&)redut.info AKA https://t.me/OVRnsk
--- GoldED+/W64-MSVC 1.1.5-b20180707 (пока работает)

Vladimir Donskoy написал(а) к Oleg Redut в Oct 23 21:18:16 по местному времени:

Нello Oleg!

30 окт 23 12:55, Oleg Redut wrote to Vladimir Donskoy:

VD>>>> Все вы забываете в этом треде один момент: только из нетмайла,
VD>>>> созданного на данном узле! И далее по тексту:

OR>>> Я не забываю. Я только этот вариант и рассматриваю. :-)

VD>> Согласно сабжу мы роутинг рассматриваем.

OR> Фидошники сабжей не меняют.

Фреки директом тривиальны, не предмет рассмотрения.
Тут рассматривается ситуация транзитного узла, на которое паришло письмо с фреком.
Ситуации узла, создавшего фрекписьмо - не рассматриваем, это дело его софта.
А узел, получивший фрекписьмо - должен его обработать своим софтом и как-то отреагировать, файлом и письмом-квитком.

VD>>>> его атрибуты вы не имеете права. И обработка этого письма -
VD>>>> дело того узла, которому оно предназначено (с которого
VD>>>> фрекают)!

OR>>> Логично. Но можно послать квиток.

VD>> Если квиток запрошен соответствующим флагом в письме, иначе это
VD>> спам...

OR> С чего бы спам? Так любое письмо от ареафикса может считаться
OR> спамом.

Повторюсь, рассматриваем транзитный узел! И делать квитки о прохождении транзитного письмо можно толькео если они запрошены этим письмом (соответствующим флагом), иначе:

OR> Спам - это массовая рассылка.

Нет, не "массовая", а "незапрошенная"! Даже единичное мусорное письмо является спамом.

OR> И на извещения флаги не
OR> предусмотрены. Любой узел может на любой нетмайл настроить bounce, с
OR> извещением, что письмо, скажем, получено, но когда будет прочтено -
OR> неизвестно. Или отреагировать извещением на любой другой
OR> флаг/сабж/текст.

Только на свои письма, но не на транзитные!

OR>>> А вот это уже далеко не факт. Дистанционно фрекнутые файлы
OR>>> узел адресата может тупо положить на холд. И ждать директной
OR>>> прозвонки с любой стороны.

VD>> Отсутствует роутинг фреков, раз на холде лежит! Итого - такая
VD>> система не поддерживает роутинг фреков, нечего к ней обращаться.

OR> Логики не вижу. Если фрек по роутингу дошёл до конечного узла и
OR> обраотался, с выкладываеним заказанного на холд - это не значит, что
OR> он не поддерживает фреки. Это уже значит, что он не поддерживает
OR> аттачи по роутингу. Вместо холда, узел может начать ломиться директом
OR> на узел отправивший файловый запрос. :-)

Это будет описано в письме-квитке фрека, либо оно имеет флаг аттача, либо содержит информацию о местонахождении и условиях получения файла (кто сказал что нельзя выложить файл на FTP/иной_сайт и прислать ссылку?).

OR> Давай разделим эти понятия:

OR>>> Аттач - это активное действие по отправке файла.
OR>>> Обработка фрека - пассивное: выкладывание запрощенного файла на
OR>>> отправку и создание какой-либо лошки, согласно политики ноды.
OR>>> Создание и отправка аттача по роутингу - это уже не относится к
OR>>> процедуре фрека. Это уже отдельный наворот объединяющий два
OR>>> понятия. Это как бы просто нетмайлом написали, отправь мне,
OR>>> плиз, такой-то файл. И ему заттачили бы по роутингу. Просто
OR>>> можно, конечно, это автоматизировать. Но это не будут фрек и
OR>>> аттач в чистом виде этих понятий.

VD>> Так эта самая автоматизация и есть "поддержка фреканья по
VD>> роутингу"! И у узла, не понимающего такого - фрекать по роутингу
VD>> не получится, максимум обычный фрек выйдет.

OR> Фрек по роутингу: передача фрек-запроса транзитом до конечного
OR> узла.

И получение некоего ответа, не требующего директной связи с узлом-хранителем файла. Всякие холды - в отказ: не поддерживается "фрек-роутинг".

С уважением, Vladimir Donskoy.

--- GoldED+/W64-MSVC 1.1.5-b20231025

Oleg Redut написал(а) к Vladimir Donskoy в Oct 23 11:03:40 по местному времени:

Доброе (current) время суток, Vladimir!

VD> Тут рассматривается ситуация транзитного узла, на которое паришло
VD> письмо с фреком.

Если отмотать тред, то там имеется такая фраза.

=== Вырезка из филе Windows Clipboard ===

NA>>> А, между прочим, если хаски из Req нетмейла делает .frq файл,

=== Кончилась врезка ===
frq - флаг нетмайла. .req - расширение файла запроса.
Поэтому я и спросил у автора: не перепутаны ли понятия. После чего ты начал что-то уточнять и увёл разговор в другую сторону.

VD> Ситуации узла, создавшего фрекписьмо - не
VD> рассматриваем, это дело его софта. А узел, получивший фрекписьмо -
VD> должен его обработать своим софтом и как-то отреагировать, файлом и
VD> письмом-квитком.

И фрекписьмом является нетмайл с флагом frq.

OR>>>> Логично. Но можно послать квиток.

VD>>> Если квиток запрошен соответствующим флагом в письме, иначе это
VD>>> спам...

Если мой узел получает письмо с флагом frq, то как ты выше утверждаешь: "должен его обработать своим софтом и как-то отреагировать".

OR>> С чего бы спам? Так любое письмо от ареафикса может считаться
OR>> спамом.

"письмом-квитком" - если такого файла нет или вообще узел ничего пр отранзиные фреки не знает.

VD> Повторюсь, рассматриваем транзитный узел! И делать квитки о
VD> прохождении транзитного письмо можно толькео если они запрошены этим
VD> письмом (соответствующим флагом), иначе:

OR>> Спам - это массовая рассылка.

VD> Нет, не "массовая", а "незапрошенная"! Даже единичное мусорное письмо
VD> является спамом.

Тогда и письмо от сисопа, который лично, а не скриптом сообщит, что письмо завёрнуто/необработано, тоже будет незапрошенным.
И вполне возможно предположение транзитнго узла, что если он пропустит письмо с фреком, то ему в ответ свалится аттач для транзита. :-\

VD>>> Отсутствует роутинг фреков, раз на холде лежит! Итого - такая
VD>>> система не поддерживает роутинг фреков, нечего к ней обращаться.

Ещё раз хочется определится с понятиями. Что такое роутинг фреков. Каков стандарт последовательности действий узлов задействованных в нём.
Для меня фрек - это запрос. Аттач - отправка. После прихода фрека - уже дело получателя, как ему аттачить файл. И аттачить ли вообще.

OR>> Давай разделим эти понятия:

OR>>>> Аттач - это активное действие по отправке файла.
OR>>>> Обработка фрека - пассивное: выкладывание запрощенного файла на
OR>>>> отправку и создание какой-либо лошки, согласно политики ноды.
OR>>>> Создание и отправка аттача по роутингу - это уже не относится к
OR>>>> процедуре фрека. Это уже отдельный наворот объединяющий два
OR>>>> понятия. Это как бы просто нетмайлом написали, отправь мне,
OR>>>> плиз, такой-то файл. И ему заттачили бы по роутингу. Просто
OR>>>> можно, конечно, это автоматизировать. Но это не будут фрек и
OR>>>> аттач в чистом виде этих понятий.

VD>>> Так эта самая автоматизация и есть "поддержка фреканья по
VD>>> роутингу"! И у узла, не понимающего такого - фрекать по роутингу
VD>>> не получится, максимум обычный фрек выйдет.

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

OR>> Фрек по роутингу: передача фрек-запроса транзитом до
OR>> конечного узла.

VD> И получение некоего ответа, не требующего директной связи с
VD> узлом-хранителем файла. Всякие холды - в отказ: не поддерживается
VD> "фрек-роутинг".

Предположительно "получение некоего ответа". Ибо не холд - это уже отдельная сущность: аттач по роутингу.

Что я могу еще сказать?..
Oleg

... AKA oleg(&)redut.info AKA https://t.me/OVRnsk
--- GoldED+/W64-MSVC 1.1.5-b20180707 (пока работает)

Andrei Mihailov написал(а) к Stas Mishchenkov в Oct 23 09:00:37 по местному времени:

Нello, Stas Mishchenkov.
On 22.10.2023 11:41 you wrote:

CO>>>> Это было главным, на чём я споткнулся. ет такого изобилия под
CO>>>> фидо, а то, что есть - оооочень непривычно и аскетично.:)
SM>>> binkd+hpt+golded есть подо всё и везде оно одинаково привычно.

Под Андроид и iOS их нет.

--
Best regards!
Posted using Нotdoged on Android
--- Нotdoged/2.13.5/Android

Stas Mishchenkov написал(а) к Oleg Redut в Oct 23 11:11:42 по местному времени:

Нi Oleg!

31 Oct 23 11:03, Oleg Redut -> Vladimir Donskoy:

OR> И вполне возможно предположение транзитнго узла, что если он
OR> пропустит письмо с фреком, то ему в ответ свалится аттач для транзита.
OR> :-\

Совсем не факт. Ответ вполне может пойти по другому пути.

Нave nice nights.
Stas Mishchenkov.

--- Снесла курочка яичко старику и выразительно посмотрела на модератора.

Stas Mishchenkov написал(а) к Andrei Mihailov в Oct 23 11:15:54 по местному времени:

Нi Andrei!

31 Oct 23 09:00, Andrei Mihailov -> Stas Mishchenkov:

CO>>>>> Это было главным, на чём я споткнулся. ет такого изобилия под
CO>>>>> фидо, а то, что есть - оооочень непривычно и аскетично.:)
SM>>>> binkd+hpt+golded есть подо всё и везде оно одинаково привычно.

AM> Под Андроид и iOS их нет.

Мобильныые платформы - отдельная пестня.

Нave nice nights.
Stas Mishchenkov.

--- Целуй медленно, прощай быстро, кастрюлю из-под гречки мой сразу.

Vladimir Donskoy написал(а) к Oleg Redut в Oct 23 22:33:59 по местному времени:

Нello Oleg!

31 окт 23 11:03, Oleg Redut wrote to Vladimir Donskoy:

VD>> Тут рассматривается ситуация транзитного узла, на которое паришло
VD>> письмо с фреком.

OR> Если отмотать тред, то там имеется такая фраза.

OR> === Вырезка из филе Windows Clipboard ===

NA>>>> А, между прочим, если хаски из Req нетмейла делает .frq файл,

OR> === Кончилась врезка ===
OR> frq - флаг нетмайла. .req - расширение файла запроса.
OR> Поэтому я и спросил у автора: не перепутаны ли понятия. После чего ты
OR> начал что-то уточнять и увёл разговор в другую сторону.

С какой стати хаски что-то делает с транзитными письмами, имеющими флаг frq? Его дело только отроутить письмо дальше, а не портить!

VD>> Ситуации узла, создавшего фрекписьмо - не
VD>> рассматриваем, это дело его софта. А узел, получивший фрекписьмо
VD>> - должен его обработать своим софтом и как-то отреагировать,
VD>> файлом и письмом-квитком.

OR> И фрекписьмом является нетмайл с флагом frq.

Да

OR>>>>> Логично. Но можно послать квиток.

VD>>>> Если квиток запрошен соответствующим флагом в письме, иначе это
VD>>>> спам...

OR> Если мой узел получает письмо с флагом frq, то как ты выше
OR> утверждаешь: "должен его обработать своим софтом и как-то
OR> отреагировать".

Если письмо адресовано тебе - да, транзитник - пропустить и не портить.

OR>>> С чего бы спам? Так любое письмо от ареафикса может
OR>>> считаться спамом.

OR> "письмом-квитком" - если такого файла нет или вообще узел ничего
OR> пр отранзиные фреки не знает.

Да.

VD>> Повторюсь, рассматриваем транзитный узел! И делать квитки о
VD>> прохождении транзитного письмо можно толькео если они запрошены
VD>> этим письмом (соответствующим флагом), иначе:

OR>>> Спам - это массовая рассылка.

VD>> Нет, не "массовая", а "незапрошенная"! Даже единичное мусорное
VD>> письмо является спамом.

OR> Тогда и письмо от сисопа, который лично, а не скриптом сообщит,
OR> что письмо завёрнуто/необработано, тоже будет незапрошенным.
OR> И вполне возможно предположение транзитнго узла, что если он
OR> пропустит письмо с фреком, то ему в ответ свалится аттач для транзита.
OR> :-\

Повторюсь: письмо от получателя фрекписьма - да, требует реакции. Транзитное письмо - не требует.

Если сисоп при установлении линка указал что по нему могут ходить файлы - он будет получать файлы, в том числе для транзита. Если линк только для писем - результат (аттач) пойдёт иным путём. Смотри например рнтрак или иные трекеры нетмайла, понимающие такую разницу в описаниях линков.

VD>>>> Отсутствует роутинг фреков, раз на холде лежит! Итого - такая
VD>>>> система не поддерживает роутинг фреков, нечего к ней
VD>>>> обращаться.

OR> Ещё раз хочется определится с понятиями. Что такое роутинг фреков.
OR> Каков стандарт последовательности действий узлов задействованных в
OR> нём.
OR> Для меня фрек - это запрос. Аттач - отправка. После прихода фрека
OR> - уже дело получателя, как ему аттачить файл. И аттачить ли вообще.

Если у получателя фрекписьма нет линка с отправителем, то холд становится бессмысленным: может не быть общих протоколов или времени работы! Потому запрос и шёл по роутингу...

OR>>> Давай разделим эти понятия:

OR>>>>> Аттач - это активное действие по отправке файла.
OR>>>>> Обработка фрека - пассивное: выкладывание запрощенного файла
OR>>>>> на отправку и создание какой-либо лошки, согласно политики
OR>>>>> ноды. Создание и отправка аттача по роутингу - это уже не
OR>>>>> относится к процедуре фрека. Это уже отдельный наворот
OR>>>>> объединяющий два понятия. Это как бы просто нетмайлом
OR>>>>> написали, отправь мне, плиз, такой-то файл. И ему заттачили бы
OR>>>>> по роутингу. Просто можно, конечно, это автоматизировать. Но
OR>>>>> это не будут фрек и аттач в чистом виде этих понятий.

VD>>>> Так эта самая автоматизация и есть "поддержка фреканья по
VD>>>> роутингу"! И у узла, не понимающего такого - фрекать по
VD>>>> роутингу не получится, максимум обычный фрек выйдет.

OR> Почему же? Получатель фрека по роутингу может зааттачить файл с
OR> директным креш-полом на отправителя.

Ага, Матюку на телефон с ИП-ноды... Или на узел без СМ-времени работы. Да мало ли причин было у того, кто слал письмо по роутингу!

OR>>> Фрек по роутингу: передача фрек-запроса транзитом до
OR>>> конечного узла.

VD>> И получение некоего ответа, не требующего директной связи с
VD>> узлом-хранителем файла. Всякие холды - в отказ: не поддерживается
VD>> "фрек-роутинг".

OR> Предположительно "получение некоего ответа". Ибо не холд - это уже
OR> отдельная сущность: аттач по роутингу.

Да, это "роутинг файлов", давным-давно известный в ФИДО и постоянно применяемый для передачи нод- и поинт-сегментов, например.

С уважением, Vladimir Donskoy.

--- GoldED+/W64-MSVC 1.1.5-b20231025

Oleg Redut написал(а) к Stas Mishchenkov в Nov 23 08:46:36 по местному времени:

Доброе (current) время суток, Stas!

OR>> И вполне возможно предположение транзитнго узла, что если он
OR>> пропустит письмо с фреком, то ему в ответ свалится аттач для
OR>> транзита.
OR>> :-\

SM> Совсем не факт. Ответ вполне может пойти по другому пути.

Как не факт, что он пойдёт по другому пути. Если роутинг через меня.

Что я могу еще сказать?..
Oleg

... AKA oleg(&)redut.info AKA https://t.me/OVRnsk
--- GoldED+/W64-MSVC 1.1.5-b20180707 (пока работает)

Oleg Redut написал(а) к Vladimir Donskoy в Nov 23 08:51:32 по местному времени:

Доброе (current) время суток, Vladimir!

OR>> Если отмотать тред, то там имеется такая фраза.

OR>> === Вырезка из филе Windows Clipboard ===

NA>>>>> А, между прочим, если хаски из Req нетмейла делает .frq файл,

OR>> === Кончилась врезка ===
OR>> frq - флаг нетмайла. .req - расширение файла запроса.
OR>> Поэтому я и спросил у автора: не перепутаны ли понятия. После
OR>> чего ты начал что-то уточнять и увёл разговор в другую сторону.

VD> С какой стати хаски что-то делает с транзитными письмами, имеющими
VD> флаг frq? Его дело только отроутить письмо дальше, а не портить!

А причём тут хаски и frq, если речь про "Req нетмейл"?

OR>> Предположительно "получение некоего ответа". Ибо не холд -
OR>> это уже отдельная сущность: аттач по роутингу.

VD> Да, это "роутинг файлов", давным-давно известный в ФИДО и постоянно
VD> применяемый для передачи нод- и поинт-сегментов, например.

Только это аттач по роутингу. Никак не связанный с фреками.

Что я могу еще сказать?..
Oleg

... AKA oleg(&)redut.info AKA https://t.me/OVRnsk
--- GoldED+/W64-MSVC 1.1.5-b20180707 (пока работает)