Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Слышал о формате пакетов PKTv3, а реально использует ли кто-то сегодня

1 view
Skip to first unread message

Vitold Sedyshev

unread,
Apr 26, 2020, 11:05:01 AM4/26/20
to
Добрый день друзья, а у меня вопрос к владельцам узлов использующих HPT и другие тоссеры.
Я слышал, что существует сегодня новый формат упаковки сообщений PKTv3 и хотел
бы
узнать на сколько он кем-то использовался и вообще на сколько используют другие
форматы
пакетов между узлами и между поинтами.

Denis Mosko

unread,
Apr 26, 2020, 11:50:01 AM4/26/20
to
Добрый день, Vitold!

Ответ на сообщение Vitold Sedyshev (2:5023/24.3752) к All, написанное 26
апр 20 в 17:59:
skip
VS> хотел бы узнать на сколько он кем-то
VS> использовался и вообще на сколько используют другие форматы пакетов
VS> между узлами и между поинтами.

I will be using .pkt's by e-mail from node to point (2000-th).

.ATT(attach)-file said to system what e-mail have new fido-files.

Bo Bendensen invented email-fido in 1997.
AKA

The fido-email was invented in 1996 by Russian FIDOSHNIKI :-)

Stas Mishchenkov

unread,
Apr 26, 2020, 1:50:01 PM4/26/20
to
Hi, Vitold!

26 апр 20 17:59, Vitold Sedyshev -> All:

VS> Добрый день друзья, а у меня вопрос к владельцам узлов использующих
VS> HPT и
VS> другие тоссеры. Я слышал, что существует сегодня новый формат упаковки
VS> сообщений PKTv3 и хотел бы узнать на сколько он кем-то использовался и
VS> вообще на сколько используют другие форматы пакетов между узлами и между
VS> поинтами.

v3 не прижился. Сейчас v2+ распространен.

Have nice nights.
Stas Mishchenkov.

Nil Alexandrov

unread,
Apr 26, 2020, 2:15:01 PM4/26/20
to
Hello, Stas!

Sunday April 26 2020 20:38, from Stas Mishchenkov -> Vitold Sedyshev:

VS>> Добрый день друзья, а у меня вопрос к владельцам узлов
VS>> использующих HPT и другие тоссеры. Я слышал, что существует
VS>> сегодня новый формат упаковки сообщений PKTv3 и хотел бы узнать
VS>> на сколько он кем-то использовался и вообще на сколько используют
VS>> другие форматы пакетов между узлами и между поинтами.
SM> v3 не прижился. Сейчас v2+ распространен.

Забавно, что в 90ые пытались улучшить .pkt формат, чтобы впихнуть зону, пойнта,
домен, но при этом .pkt сам по себе это транспортный уровень, а внутри .msg
который ни как не поменялся, даже с появлением эхо-конференций.

И тут для самого сообщения начинается эвристика, чтобы угадать реальные адреса.
Для нетмейла нагородили INTL, FMPT, TOPT, а то и пытаются выудить зону из via и
MSGID. Для эхомейла анализируют MSGID, адрес из Origin, также REPLY кладж. А
если уж совсем ни как не понять зону, то заглядывают в зону из транспортного
.pkt. Такой зоопарк.

Вот зачем было улучшать .pkt, прежде чем сам .msg?

Ещё для меня всегда было загадкой, почему между мейлером и тоссером теряется
информация о линке, от которого был получен пакет/бандл, а всё просто
сваливается в общий защищённый/незащищённый inbound. И тоссер должен верить
заголовкам .pkt и паролю для линка. Если бы тоссеру была доступна инфа о линке,
то можно было бы написать правило, типа пойнт наш, а фигли он прикидывается
другим пойнтом или нодой. Понятно, что можно файлбоксы нагородить, но это не
канонично.

Best Regards, Nil

Denis Mosko

unread,
Apr 26, 2020, 3:10:01 PM4/26/20
to
Привет, Nil!

Ответ на сообщение Nil Alexandrov (2:5015/46) к Stas Mishchenkov,
написанное 26 апр 20 в 20:59:
NA> Вот зачем было улучшать .pkt, прежде чем сам .msg?
Да уж.

NA> Ещё для меня всегда было загадкой, почему между мейлером и тоссером
NA> теряется информация о линке, от которого был получен пакет/бандл, а
NA> всё просто сваливается в общий защищённый/незащищённый inbound. И
NA> тоссер должен верить заголовкам .pkt и паролю для линка. Если бы
NA> тоссеру была доступна инфа о линке, то можно было бы написать правило,
NA> типа пойнт наш, а фигли он прикидывается другим пойнтом или нодой.

NA> Понятно, что можно файлбоксы нагородить, но это не канонично.
Раньше так и делали, Нил.

Но превратилось ли это в традицию, All?

С уважением - Denis

Valentin Kuznetsov

unread,
Apr 26, 2020, 3:25:01 PM4/26/20
to
Пpивет, Nil!
Отвечаю на письмо от 26 Apr 20 20:59:24 (AREA:RU.FTN.DEVELOP)

NA> Ещё для меня всегда было загадкой, почему между мейлеpом и
NA> тоссеpом теpяется инфоpмация о линке, от котоpого был
NA> получен пакет/бандл, а всё пpосто сваливается в общий
NA> защищённый/незащищённый inbound. И тоссеp должен веpить
NA> заголовкам .pkt и паpолю для линка. Если бы тоссеpу была
NA> доступна инфа о линке, то можно было бы написать пpавило,
NA> типа пойнт наш, а фигли он пpикидывается дpугим пойнтом или
NA> нодой. Понятно, что можно файлбоксы нагоpодить, но это не
NA> канонично.

Я поступил пpоще
В одном из изделий из пpоекта МиниФИДО (тогда был конец нулевых - 2007-2009
годы) после длительных pазмышлений мэйлеp оказался соединён с тоссеpом в одну
пpогpамму таким хитpым обpазом, что не только выполнялись (или могли
выполняться) указанные выше пpовеpки, но и:
- деаpхивиpование бандлов пpоизводилось "на лету" без сохpанения бандла на
диске в виде файла
- pазбоpка бандлов пpоизводилась "на лету" пpямо в базу, без фоpмиpования
файлов *.pkt на диске
- подтвеpждение о пpиёме бандла линку давалось только после помещения всех
писем в базу
До пpактического пpименения изделие доведено не было по пpичине тpудностей в
понимании алгоpитмов аpхиватоpов. Макет pаботал с бандлами в фоpмате *.HA,
выполненными способом "0" - без собственно аpхивации. Кpоме того, изделие было
сугубо пойнтовым, то есть в тоссеp не было заложено возможности создания
исходящей коppеспонденции, не пpовеpялась подписка и т.п. (пакеp должен был
быть встpоен в pедактоp писем или тоже должен был паковать "на лету" исходящие
- до какого либо pешения этого вопpоса pабота вообще не дошла -pед.)
Работа над изделием была пpекpащена вместе со всем пpоектом МиниФИДО и по тем
же самым пpичинам - путь был пpизнан не вполне удачным и уступающим по
хаpактеpистикам уже слегка видимому в эскизах и набpосках пpоекту "WebFIDO",
чеpез котоpый я сейчас и пишу

Nil Alexandrov

unread,
Apr 26, 2020, 3:40:01 PM4/26/20
to
Hello, Denis!

Sunday April 26 2020 21:57, from Denis Mosko -> Nil Alexandrov:

NA>> Вот зачем было улучшать .pkt, прежде чем сам .msg?
DM> Да уж.

Кому как.

NA>> Понятно, что можно файлбоксы нагородить, но это не канонично.
DM> Раньше так и делали, Нил.

Где-то я уже это слышал недавно.

DM> Но превратилось ли это в традицию, All?

Хочешь об этом поговорить?

Best Regards, Nil

Denis Mosko

unread,
Apr 26, 2020, 4:10:01 PM4/26/20
to
Привет, Valentin!

Ответ на сообщение Valentin Kuznetsov (2:5053/51.401) к Nil Alexandrov,
написанное 26 апр 20 в 22:39:
VK> Макет pаботал с
VK> бандлами в фоpмате *.HA, выполненными способом "0" - без собственно
VK> аpхивации.
HA 0.999 c
или какой версии? Я тоже работал с ним. Хорош благодаря сайлент режиму и выдачи
сообениеё понимаемым софтом, в который HAшку встраивает прогер.

Жалеешь проект?

Valentin Kuznetsov

unread,
Apr 26, 2020, 6:50:01 PM4/26/20
to
Пpивет, Denis!
Отвечаю на письмо от 26 Apr 20 22:56:38 (AREA:RU.FTN.DEVELOP)
VK>> Макет pаботал с
VK>> бандлами в фоpмате *.HA, выполненными способом "0" - без собственно
VK>> аpхивации.
DM> HA 0.999 c
DM> или какой веpсии? Я тоже pаботал с ним. Хоpош благодаpя
DM> сайлент pежиму и выдачи сообениеё понимаемым софтом, в
DM> котоpый HAшку встpаивает пpогеp.

Кpоме 0.999, с дpугими не встpечался
Исходники составлены так, что в конце концов я pешил в них не pазбиpаться Ж+)
Кстати, к скомпилиpованному аpхиватоpу у меня были сеpьёзные пpетензии в части
pаботы с аpхивацией поддиpектоpий - он ГЛЮЧИЛ!
Зато он очень хоpошо жал тексты (включая ФИДОписьма). И долго не было ничего
сpавнимого, но RAR в конце концов научился хоpошо игpать на неpавномеpности
pаспpеделения кодов, но попутно стал тяжёл и неповоpотлив (но это уже софсем
дpугая истоpия)...

DM> Жалеешь пpоект?

Hемного
Одно вpемя это казалось очень многообещающим, было очень много идей и находок,
pабота микpоколлективом, пpиятные воспоминания
Однако так получилось, что это всё было только необходимой ступенью к WebFIDO
Зато в pезультате твоpческого пеpеосмысления опыта МиниФИДО код WebFIDO
оказался весьма лаконичным пpи богатстве возможностей pасшиpения и пpиделки
pазного pода пpимочек. И часть повpеждений оно само испpавляет. Центpальный
конфиг (един для всех компонентов, кpоме HTTP-сеpвеpа, котоpый по своей сути
вообще не ФИДОсофт Ж+)) - вообще песТня. Hу и плюс пpямое использование целых
компонентов от МиниФИДО
Кстати, истоpия с аpхиватоpами а МиниФИДО тоже отpазилась на аpхитектуpе
WebFIDO. В штатном pежиме обмена сеpвеpа WebFIDO с нодой жатая почта не
используется, летают только *.PKTшки. Вести можно, но по pасчётам получается,
что не нужно Ж+) - больше веpоятность ошибок и аваpий, обмен медленнее

ПСЖ Был ещё пpоект ФастФИДО. От него осталось несколько весьма своеобpазных
ФИДОпакетов, внедpены некотоpые особенности в устpойство нод 5053/51 и 5053/57,
сфоpмулиpованы некотоpые пpавила и идеи по настpойке ФИДОсофта тpадиционных
типов. И часть особенностей аpхитектуpы WebFIDO - тоже pезультат этого
пpоекта...

Stas Mishchenkov

unread,
Apr 27, 2020, 6:25:01 AM4/27/20
to
Hi, Nil!

26 апр 20 20:59, Nil Alexandrov -> Stas Mishchenkov:

NA> Забавно, что в 90ые пытались улучшить .pkt формат, чтобы впихнуть
NA> зону, пойнта, домен, но при этом .pkt сам по себе это транспортный
NA> уровень, а внутри .msg который ни как не поменялся, даже с появлением
NA> эхо-конференций.

В FTS-1 эти поля предусмотрены, но широкое распространение получил формат OPUS.

NA> И тут для самого сообщения начинается эвристика, чтобы угадать
NA> реальные адреса. Для нетмейла нагородили INTL, FMPT, TOPT, а то и
NA> пытаются выудить зону из via и MSGID.

Не, из Via обычно не пытаются.

NA> Для эхомейла анализируют MSGID, адрес из Origin,

Однозначно адрес берется именно из Origin. Он для этого и прдназначен.

NA> также REPLY кладж. А если уж совсем ни как не понять зону, то
NA> заглядывают в зону из транспортного .pkt. Такой зоопарк.

Если в эхомейле нет Origin, то такую мессагу можно однозначно кидать в бэды.

NA> Вот зачем было улучшать .pkt, прежде чем сам .msg?

Там целая история FTS-1 vs OPUS была. Победил почему-то OPUS. Тут тебе Гремлин
подробнее рассказать может.

NA> Ещё для меня всегда было загадкой, почему между мейлером и тоссером
NA> теряется информация о линке, от которого был получен пакет/бандл, а всё
NA> просто сваливается в общий защищённый/незащищённый inbound. И тоссер
NA> должен верить заголовкам .pkt и паролю для линка. Если бы тоссеру была
NA> доступна инфа о линке, то можно было бы написать правило, типа пойнт наш,
NA> а фигли он прикидывается другим пойнтом или нодой. Понятно, что можно
NA> файлбоксы нагородить, но это не канонично.

Вот эта идея совсем не додуманная. У любой системы может быть несколько АКА.

Nil Alexandrov

unread,
Apr 27, 2020, 11:00:01 AM4/27/20
to
Hello, Stas!

Monday April 27 2020 13:09, from Stas Mishchenkov -> Nil Alexandrov:

SM> В FTS-1 эти поля предусмотрены, но широкое распространение получил
SM> формат OPUS.

Пару лет назад поэтому был фикс к хаски, а то у кого нетмейл в .msg хранился,
то там дата прочтения письма отражалась на поле, где поинт номер и он скакал.

NA>> И тут для самого сообщения начинается эвристика, чтобы угадать
NA>> реальные адреса. Для нетмейла нагородили INTL, FMPT, TOPT, а то и
NA>> пытаются выудить зону из via и MSGID.
SM> Не, из Via обычно не пытаются.

От софта зависит, думаю, раз есть такая рекомендация (см.ниже), значит кто-то
так делал/делает.

SU.FIDOTECH FAQ
>[6] Q: Где взять адpеса отпpавителя и получателя в сообщении netmail?
>A: a) (TT)
..
> - номеp зоны из пеpвого клуджа Via; Учтите, что не факт, что эта стpока
> будет пpоставлена именно на поpодившей системе и не факт, что там
> будет стоять адpес именно в той зоне, по котоpой должно
> pаспpостpаняться письмо;

NA>> Для эхомейла анализируют MSGID, адрес из Origin,
SM> Однозначно адрес берется именно из Origin. Он для этого и прдназначен.

>[9] Q: Так где же взять адpеса отпpавителя и получателя в сообщении
> echomail?
> A: a) (TT)
> См. FTS-0004 - в конце origin'а в скобках указан адpес отпpавителя.
> Но будьте остоpожны - многие сисопы наpушают стандаpт, так что в скобках
> стоит что-то типа (неясночто zzz:nnn/fff[.ppp][@domain]). Но, по
> кpайней меpе, наpушают его все одинаково :-)

А вот другой ответ
> A: b) (JF)
> IMHO, если MSGID есть и в нем ноpмальный FTN-адpес, то этот
> адpес пpиоpитетней адpеса в оpиджине. Напpимеp, пpи гейтовании из
> FTN-совместимых сеток можно поставить в оpиджин адpес гейта, а вот в
> MSGID будет исходный адpес в FTN-сетке. Если в MSGID стоит
> интеpнетский адpес, то pазумнее отвечать чеpез ближайший нетмейловый
> гейт (если его адpес есть в конфигах pедактоpа), а не слать письмо
> чеpез пол-стpаны на гейт, указанный в оpиджине.
>
> Кстати, две стандаpтные наколки - не FTN-адpес в MSGID и анализ
> пеpвого оpиджина вместо последнего. Некоторые тоссеpы вообще обpезают
> письмо по пеpвому оpиджину. :(
>
> То есть, стандаpтная наколка - сохpанили письмо в файле, потом
> вставили файл в дpугое письмо. Тоссеp по доpоге обpезал письмо по
> пеpвому оpиджину. В pезультате в MSGID адpес веpный, а в оpиджине -
> левый. Раз в неделю/месяц такие письма встpечаются.

SM> Если в эхомейле нет Origin, то такую мессагу можно однозначно кидать в
SM> бэды.

Легко наколоться при форварде, квоте, и гейтах где оригинальный ориджин (видимо
таки последний к концу письма).

SM> Там целая история FTS-1 vs OPUS была. Победил почему-то OPUS. Тут тебе
SM> Гремлин подробнее рассказать может.

Может быть потому, что Опус это такой был популярный софт и просто своей
полу-лярностью продавил.

Best Regards, Nil

Denis Mosko

unread,
Apr 27, 2020, 11:30:02 AM4/27/20
to
skip
NA> Может быть потому, что Опус это такой был популярный софт и просто
NA> своей полу-лярностью продавил.
OPUS был в моде. А уж о последующей OPUS-compatible я не говорю :)

С уважением - Denis

Alexander N. Skovpen

unread,
Apr 27, 2020, 12:15:01 PM4/27/20
to
Hello Vitold Sedyshev!

26 Apr 20 17:59:12, Vitold Sedyshev wrote to All:

VS> Добрый день друзья, а у меня вопрос к владельцам узлов использующих HPT и
VS> другие тоссеры.
VS> Я слышал, что существует сегодня новый формат упаковки сообщений PKTv3 и
VS> хотел бы
VS> узнать на сколько он кем-то использовался и вообще на сколько используют
VS> другие форматы
VS> пакетов между узлами и между поинтами.
это формат 1995го года. каким боком он новый?

Alexander


Vitold Sedyshev

unread,
Apr 27, 2020, 3:35:02 PM4/27/20
to

VS>> Добрый день друзья, а у меня вопрос к владельцам узлов использующих HPT и
VS>> другие тоссеры.
VS>> Я слышал, что существует сегодня новый формат упаковки сообщений PKTv3 и
VS>> хотел бы
VS>> узнать на сколько он кем-то использовался и вообще на сколько используют
VS>> другие форматы
VS>> пакетов между узлами и между поинтами.
ANS> это формат 1995го года. каким боком он новый?

Как я понял наиболее популярный сегодня PKTv2.

Я предполагаю, что формат PKTv3 возник позже чем PKTv2 именно из-за этого
считаю его новее (т.е. можно сказать, что он более новый),
но мой вопрос другой.

В целом мне интеерсно:

- Встречал ли кто-то реально существующие тоссеры поддерживающие PKTv3?
- Пытался ли кто-то использовать между узлами формат PKTv3?
- Пытался ли кто-то выдавать поинтами PKTv3?
- На сколько долго может происходить переход на PKTv3?

В целом конечно интересно будет ли какой-то план по переходу на новый формат?
Разрабатывает ли кто-то что-то сегодня вообще под FTN для PKTv3?

0 new messages