разговоры об ii/IDEC






\/ . shaos to shaos @ Re: Разбор idec №2 02/11/24 07:22

По идее можно попробовать и /lim/N/u/e/ поддержать, но через хак - оно будет смотреть если это /lim/N/u/e/ то само будет переупорядочивать в /u/e/lim/N/

4ff64z... . ОТВЕТИТЬ









\/ . shaos to All @ spnet проапгрейдился до iii-php v0.9 02/11/24 06:51

Смотрим если вдруг вылезут косяки с веб-интерфейсом либо пинтовым апи. Новый поинтовый апи доступен всё так же по https://sprinternet.io/iii/ (что через rewrite вызывает iii-point.php?q=/ и если кто-то напрямую дёргает ii-point.php, то с него надо будет слазить т.к. там старый код). Основное нововведение, это насильственные действия в отношении /u/e/ в особо извращённой форме :)
Я вчера показывал свой шедевральный код, который я сегодня ещё более усугубил - ща объясню.

Всё также можно делать запросы в стародавнем стиле ii:

https://sprinternet.io/iii/u/e/retro.talks/english.talks

Всё также можно делать запросы со "слайсами" в стиле IDEC (когда диапазон указанный в конце распространяется на все перечисленные эхи):

> curl -XGET https://sprinternet.io/iii/u/e/retro.talks/english.talks/-1:1
retro.talks
XOjs0DTBN77YYkJT2drY
english.talks
HOYW7nXXHb3HPKAFLz1w

Но теперь появляется возможность писать диапазоны не только в конце, но и в середине списка эх (как я уже вчера докладывал):

> curl -XGET https://sprinternet.io/iii/u/e/retro.talks/-2:2/english.talks/-1:1
retro.talks
5B3Tra1DRJEcymDcA6Gi
XOjs0DTBN77YYkJT2drY
english.talks
HOYW7nXXHb3HPKAFLz1w

Причём вместо -1:1 можно написать волшебное слово last:

> curl -XGET https://sprinternet.io/iii/u/e/retro.talks/zx.spectrum/-2:2/english.talks/last
retro.talks
5B3Tra1DRJEcymDcA6Gi
XOjs0DTBN77YYkJT2drY
zx.spectrum
1cKGi833VgPtcN7D7uDs
ZryriIaG5IJqKHX3C6kl
english.talks
HOYW7nXXHb3HPKAFLz1w

Также в середине списка можно указать волшебное слово all если вдруг какую-то среднюю эху надо выкачать целиком:

> curl -XGET https://sprinternet.io/iii/u/e/retro.talks/-3:3/english.talks/all/zx.spectrum/last
retro.talks
yceDK3BmBJnfAZQlktjd
5B3Tra1DRJEcymDcA6Gi
XOjs0DTBN77YYkJT2drY
english.talks
Nw9ofK5x70iFMTrHzjHp
HOYW7nXXHb3HPKAFLz1w
zx.spectrum
ZryriIaG5IJqKHX3C6kl

И это уже похоже на то, что revoltech предлагал вот тут El8TC509rAzTVxpWWAaa

А сегодня я даже сделал возможным указывать хеш, начиная с которого надо возвращать список хешей как revoltech предлагал вот тут KmXTgt056WiPcGcdA9Mv т.е.

> curl -XGET https://sprinternet.io/iii/u/e/retro.talks/5B3Tra1DRJEcymDcA6Gi/english.talks/all/zx.spectrum/last
retro.talks
5B3Tra1DRJEcymDcA6Gi
XOjs0DTBN77YYkJT2drY
english.talks
Nw9ofK5x70iFMTrHzjHp
HOYW7nXXHb3HPKAFLz1w
zx.spectrum
ZryriIaG5IJqKHX3C6kl

Более того - можно указывать только первые символы хеша ;)

> curl -XGET https://sprinternet.io/iii/u/e/retro.talks/5B3T/english.talks/all/zx.spectrum/last
retro.talks
5B3Tra1DRJEcymDcA6Gi
XOjs0DTBN77YYkJT2drY
english.talks
Nw9ofK5x70iFMTrHzjHp
HOYW7nXXHb3HPKAFLz1w
zx.spectrum
ZryriIaG5IJqKHX3C6kl

Главное чтобы оно было не цифрой, иначе оно будет ругаться.

Ну и конечно же анонсированный вчера /u/e/lim/N/... :)

> curl -XGET https://sprinternet.io/iii/u/e/lim/3/retro.talks/english.talks/zx.spectrum
retro.talks
yceDK3BmBJnfAZQlktjd
5B3Tra1DRJEcymDcA6Gi
XOjs0DTBN77YYkJT2drY
english.talks
Nw9ofK5x70iFMTrHzjHp
HOYW7nXXHb3HPKAFLz1w
zx.spectrum
MPaCqYswUePWAAfiioBL
1cKGi833VgPtcN7D7uDs
ZryriIaG5IJqKHX3C6kl

Я вчера написал, что lim нельзя использовать вместе со слайсами, а сегодня понял, что можно, но только если lim указывается правее слайсов :)

> curl -XGET https://sprinternet.io/iii/u/e/retro.talks/-4:4/lim/3/english.talks/zx.spectrum
retro.talks
H50pJyclcYjeJbXBAi8k
yceDK3BmBJnfAZQlktjd
5B3Tra1DRJEcymDcA6Gi
XOjs0DTBN77YYkJT2drY
english.talks
Nw9ofK5x70iFMTrHzjHp
HOYW7nXXHb3HPKAFLz1w
zx.spectrum
MPaCqYswUePWAAfiioBL
1cKGi833VgPtcN7D7uDs
ZryriIaG5IJqKHX3C6kl

т.е. [-]N:M действует влево (как и all, last и hash), а lim действует вправо!

Ну и напоследок - выдача сообщений сохранённых позже какого-то времени :)

> curl -XGET https://sprinternet.io/iii/u/e/retro.talks/english.talks/zx.spectrum/1730472839
retro.talks
english.talks
HOYW7nXXHb3HPKAFLz1w
zx.spectrum

(если время совпадает, то такое сообщение тоже возвращается)

Кода это заняло не так много ( чуть больше, чем я вчера показывал ) - я больше кода выкинул, когда довыпиливал файлэхи :)

Кому интересно, то можно посмотреть на коммиты тут https://gitlab.com/shaos/iii-php

2SuPPA... . цепочка . ОТВЕТИТЬ



\/ . revoltech to ahamai @ Re: я наверное тоже напишу спецификацию 02/11/24 06:25

ahamai> кстати, к народному фольклору. какую эху можно посмотреть клиентом но нельзя в большинстве веб-интерфейсов? эху list.txt

А потому что нефиг завязываться на точку было. Сделали бы 1) что-то в духе /u/l (в моём новом несовместимом протоколе будет /r/l вместо list.txt), 2) в выводе /u/e после каждой эхи (для отличия от msgid) ставить двоеточие. И всё, никаких коллизий.

ZK7ooP... . ОТВЕТИТЬ





\/ . ahamai to revoltech @ Re: Разбор idec №2 02/11/24 06:27

Какой пойнт, если мы говорим про чистоту бандла u/e. С пойнта ты ничего не получишь по u/e

Да и пойнт тебе с u/e ничё не сделает. Он может легально с u/point спаму нагнать

8EGpBa... . ОТВЕТИТЬ



\/ . revoltech to ahamai @ Re: Разбор idec №2 02/11/24 06:21

ahamai> то есть, тебя собирается атаковать собственный аплинк.

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

Hkq2kd... . ОТВЕТИТЬ



\/ . Andrew Lobanov to Andrew Lobanov @ Re: Стандарт 02/11/24 06:03

Очередные правки. URL тот же: http://s.spline-online.ru/idec.html

Добавил явное указание запросов бандлов по 40 сообщений. Прояснил про строку аутентификации для пушей.

+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.

pKGfea... . ОТВЕТИТЬ





\/ . Andrew Lobanov to shaos @ Re: Разбор idec №2 02/11/24 05:50

shaos> Ну вон я же вчера приводил замеры - каждый HTTPS запрос добавляет 3.5КБ к полезной нагрузке - будет 1000 запросов, будет лишних 3.5 мега...

Бесплатного HTTPS не бывает. Если хочется HTTPS, всё равно будут накладные расходы.

+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.

nyuCZV... . ОТВЕТИТЬ



\/ . shaos to ahamai @ Re: Разбор idec №2 02/11/24 06:01

Я считаю тупо по апачи-логам - сколько там байт написано в ответе, столько и приплюсовываю

Сегодня кстати у меня появится /u/e/lim/N/... ;)

6v7A4C... . ОТВЕТИТЬ



\/ . shaos to hugeping @ Re: Разбор idec №2 02/11/24 06:00

Вроде сделал по времени сохранения - тормозов не заметил даже на больших эхах

Ща ещё немного погоняю и выложу

I3kjng... . ОТВЕТИТЬ



\/ . ahamai to shaos @ Re: Разбор idec №2 02/11/24 05:27

Мне интересно почему срезы у нас трафик не уменьшили? До них было 2 мб в сутки, щас то 4.5 то 2.7. У тебя трафик в обе стороны считается или только входящий?

wbB8VH... . ОТВЕТИТЬ



\/ . ahamai to shaos @ Re: Разбор idec №2 02/11/24 05:24

Еще tcp фреймы, хендшейк и прочее. Если бы всё было так просто, все бы жили на /m и /e и были бы счастливы

Tl2DVr... . ОТВЕТИТЬ



\/ . shaos to Andrew Lobanov @ Re: Разбор idec №2 02/11/24 05:12

Ну вон я же вчера приводил замеры - каждый HTTPS запрос добавляет 3.5КБ к полезной нагрузке - будет 1000 запросов, будет лишних 3.5 мега...

3YWnsz... . ОТВЕТИТЬ



\/ . Andrew Lobanov to hugeping @ Re: Разбор idec №2 02/11/24 04:37

shaos>> Для минимизации количества запросов можно все эхи разом опросить - для этого придётся городить новый вызов и новый формат ответа
hugeping> Не вижу смысла минимизировать число запросов. До сих пор считаю это ложной целью.

Два чаю этому джентельмену.

+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.

os9lB5... . ОТВЕТИТЬ









\/ . ahamai to ahamai @ Re: я наверное тоже напишу спецификацию 01/11/24 23:46

поменял list.txt

кстати, к народному фольклору. какую эху можно посмотреть клиентом но нельзя в большинстве веб-интерфейсов? эху list.txt. потому что раньше postfix обязан был быть цифрой, а теперь получили такую забавную коллизию. это можно даже как-то использовать, в духе "пиши в эху list.txt, там никто не увидит" :)

W7CCsl... . ОТВЕТИТЬ





\/ . ahamai to ahamai @ Re: я наверное тоже напишу спецификацию 01/11/24 23:31

Проблемы экономии трафика я не вижу, я каждый раз нажимая F5 в браузере потребляю трафика больше, чем в ii клиенте потратил бы за день. Но для этого всё равно есть list.txt, который можно даже кэшировать. lim только для новоподключившимся к большим эхам. стандарта на годовые эхи не будет, но для себя, если эха разрастётся, то поедет в эха.25 и так далее. это не вопрос спецификации, это вопрос реализации на конкретной станции.

29PRbW... . ОТВЕТИТЬ



\/ . ahamai to All @ я наверное тоже напишу спецификацию 01/11/24 23:26

Текущую проблему (одну из трёх) я вижу в том, что не пишут софта. Сейчас ровно один человек пишет клиент, и он программист. Раньше софт писали любители. Я сам любитель и смотрю с точки зрения любителей

> вообще. я заметил, когда вопрос политики и проектирования уходит к программистам, они решают это с какой-то особой, программисткой точки зрения. поэтому решают вообще не ту проблему: вопрос "ты грепаешь миллион телефонных номеров но семь не подходят под фильтр" меня убил, типа лучше сделать идеальный фильтр, чем за две минуты удалить эти номера вручную, и это единственно верный способ. собственно, этот ответ объясняет вообще всё

и чем проще формат и чем меньше непонятных букв, тем больше может возникнуть желание написать клиент. для принятия решения нужно 100% пунктов, какие ты можешь выполнить. хоть одно непонятное слово может сразу подавить желание заниматься этим. желания спонтанны, но чем больше погружаешься в скуку, тем больше это тебя демотивирует. А просто меняться списками легко и приятно.

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

Там будут u/ e/ u/e u/m и u/point.

Всё. Будут ещё серверная рекомендация k/v, сейчас там только lim/XXX. это не влияет на написателей клиентов, так как это строчка в конфиге, endpoint в любом случае прописывают при начале работы в сети. это не влияет на писателей серверов, так как они делают базовую реализацию, а потом могут навешивать любые ендпоинты, и просто писать на своей станции "конфиг при подключении к станции такой-то такой-то"

И, думаю, я просто изменю list.txt, который всегда будет выдавать после описания хэш эхи, кто из клиентов-фетчеров захочет этим пользоваться. пусть пользуется, кто не захочет - и не надо.

Вот такая у меня будет спецификация, абсолютно не ломающая совместимость со старым ii. Но это будет только тогда, когда будут контент и юзеры, чтобы были хотя бы потенциальные желающие писать клиент.

YsPrWH... . цепочка . ОТВЕТИТЬ





\/ . ahamai to shaos @ Re: Разбор idec №2 01/11/24 23:02

речь была о мусоре в /u/e который нужно игнорировать

а какая разница в запросе??? бандл он нужен только для одного, получить информацию. если тебе нужна информация, ты делаешь конкретный запрос. а так, ты сделал некорректный запрос, ну тебе выдался список пустых эх. И ЧТО.

u/e работает только так. даунлинк запрашивает список эх. аплинк выдаёт бандл. всё. тут нет ничего больше, всё взаимодействие u/e именно такое. ничего другого там нет. список эх -> корректный с точки зрения формата бандл. какая разница кто какой запрос делает, на любой запрос u/e делает только одно, выдаёт запрошенный бандл. всё примитивно. как три копейки, ничего другого там просто нет.

валидация урл на инъекции и прочее это вообще не про ii, это задача другого уровня, задача веб-сервера, url и прочее, это применимо к любому запросу к любому серверу. ii же работает абсолютно топорно - вот тебе список эх, вот тебе бандл, ничего другого в принципе там быть не может. на вход может быть подано вообще что угодно, для станции это список эх. станция смотрит, если есть такая эха, выдаёт контент, если нет, выдаёт пустую эху. ничего другого корректная станция выдать не может. и эту станцию ты сам прописываешь в конфиге.

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

T9DHHv... . ОТВЕТИТЬ



\/ . shaos to ahamai @ Re: Разбор idec №2 01/11/24 22:52

Речь была вроде не про мусор в выводе /u/e а про мусор в запросе /u/e - такой запрос кто угодно может сделать

rcxriB... . ОТВЕТИТЬ



\/ . ahamai to hugeping @ Re: Разбор idec №2 01/11/24 22:48

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

C2QS4s... . ОТВЕТИТЬ



\/ . ahamai to hugeping @ Re: Разбор idec №2 01/11/24 22:47

> На моё сообщение ты как-то очень непрямо ответил.

я ровно в каждом сообщении пишу ровно одно и то же.

1. меня не интересуют стандарты и технологии. как я могу ответить вопрос про стандарты и технологии, если мне это неинтересно, и для меня это вообще не проблема, какой бы стандарт в итоге не приняли.

2. вспомните 2014 год. у меня каждое сообщение ровно про одно - вспомните 2014 год. всё. ни о чём другом я не пишу. и про технологии я пишу только в этом разрезе.

bGnzDX... . ОТВЕТИТЬ



\/ . hugeping to ahamai @ Re: Разбор idec №2 01/11/24 22:22

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

Tq4QG9... . ОТВЕТИТЬ



\/ . ahamai to hugeping @ Re: Разбор idec №2 01/11/24 22:36

> У меня и сейчас опрашивается в одном потоке одна эха и работает все быстро.

u/e для этого вообще не нужна, достаточно e/

UUnbdC... . ОТВЕТИТЬ



\/ . ahamai to hugeping @ Re: Разбор idec №2 01/11/24 22:35

> Не вижу смысла минимизировать число запросов.

ну, в 2014 это было проблемой, раз /e заменили на /u/e. а вообще запрос вещь дорогая, это и лишние tcp-фреймы, и лишняя нагрузка на сервер, и лишняя строка в логах :) упаковка в один запрос лучше в любом случае. иначе можно было бы на /m и /e остаться. и мы бы остались, если бы запросы не были столь дорогими, пришлось прикручивать изначально ненужные бандлы. я не знаю, в текущих реалиях можно было бы, если создавать сеть сейчас, остаться на /m и /e - это бы сильно всё упростило :)

NjUdhF... . ОТВЕТИТЬ



\/ . hugeping to shaos @ Re: Разбор idec №2 01/11/24 22:13

shaos> Для минимизации количества запросов можно все эхи разом опросить - для этого придётся городить новый вызов и новый формат ответа

Не вижу смысла минимизировать число запросов. До сих пор считаю это ложной целью. У меня и сейчас опрашивается в одном потоке одна эха и работает все быстро.

uDzNXj... . ОТВЕТИТЬ



\/ . ahamai to ahamai @ Re: Разбор idec №2 01/11/24 22:31

а, ну ещё проблема в сути вопроса - нахрена, чтобы навредить, давать НЕКОРРЕКТНЫЙ БАНДЛ??? вот тут вообще непонятно. логичнее давать абсолютно корректный бандл, содержащий, например каждый раз тысячу разных msgid с некорректными данными или просто со случайным флудом

mtTGtg... . ОТВЕТИТЬ



\/ . ahamai to ahamai @ Re: Разбор idec №2 01/11/24 22:28

если тебе дают некорректные данные - ты должен падать - это основа безопасности. как и кому в голову может прийти идея их валидировать

XS2q1j... . ОТВЕТИТЬ



\/ . ahamai to revoltech @ Re: Разбор idec №2 01/11/24 22:23

> Дык я и начинаю собирать свою ноду. Слайсы мне в этом вообще не помешают.

ты программист, наверное. а речь про любителей.

> А ты уверен, что ты сам-то суть понимаешь? Это не про доверенные узлы вообще. Для запроса /u/e пароль не нужен, тебе запрос с дичью вместо эхонеймов может прислать вообще кто угодно, когда угодно и в каком угодно количестве.

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

ps. при запросе (запросе от тебя) система автоматом разбирается. если есть файлик, то это эха с данными, если всё остальное - то это пустая эха. и ты выдаёшь такой же полностью корректный бандл, где просто перечисляется куча пустых эх. вот тебе вход, список, чего угодно, любой ахинеи. вот тебе выход - ответ на твой запрос, что эха КРАКОЗЯБЛ1 и эха КРАКОЗЯБЛ2 пусты. это полностью корректный и абсолютно формализуемый бандл. бандл состоит только из двух вещей, msgid и эхи, и выдаёт такой бандл, что бы у тебя не запросили вообще.

две стороны. одна даёт список эх, не важно, реальный или абстрактный мусорный. вторая по этому списку выдаёт абсолютно корректный бандл по всем этим эхам, какие бы они не были. всё. не может быть другого варианта, в принципе. список эх -> бандл.

> Или сознательная атака.

то есть, тебя собирается атаковать собственный аплинк. И ТЫ ПРИ ЭТОМ ПЫТАЕШЬСЯ ВАЛИДИРОВАТЬ какие-то данные? ты вообще сам понимаешь, что говоришь - тебе дают заведомо некорректные данные, а ты говоришь "нет, не отлуп давать, а пытаться хоть что-то свалидировать, ВДРУГ ТАМ ЧТО-ТО хорошее?"

+++ memo:absurd

absurd... . ОТВЕТИТЬ



\/ . revoltech to ahamai @ Re: Разбор idec №2 01/11/24 22:08

ahamai> Чтобы каждый мог собрать свою ноду и общаться со своим хомячком. Потому что это просто. Весь протокол постоянно упрощался. Какие вообще слайсы?

Дык я и начинаю собирать свою ноду. Слайсы мне в этом вообще не помешают. А ещё у меня там будет автопереключение транспортов — по одному и тому же порту можно будет запрашивать как HTTP, так и Nex/Gopher. И потом ещё после стандартной реализации IDEC будет сбоку приделан совсем несовместимый с ним протокол, ещё более простой и при этом решающий ровно те же задачи, но куда более красиво, компактно и всего пятью эндпоинтами.

ahamai> Ещё мне там понравилось, что второй человек уже указывает, что в выводе /u/e может быть мусор.

Не в выводе, а на входе. Это существенная разница.

ahamai> Они походу вообще не понимают сути. Ты синкаешься с доверенным узлом по предельно формализированному и простому формату.

А ты уверен, что ты сам-то суть понимаешь? Это не про доверенные узлы вообще. Для запроса /u/e пароль не нужен, тебе запрос с дичью вместо эхонеймов может прислать вообще кто угодно, когда угодно и в каком угодно количестве.

ahamai> Единственный вариант, когда там может быть мусор - это СБОЙ.

Или сознательная атака. Если твоя нода при этом будет падать от малейшего чиха, толку от неё мало. У меня вон VPS-ку всякие васяны постоянно по SSH брутить пытаются, судя по логам. И обламываются на корню.

3659AV... . ОТВЕТИТЬ



\/ . ahamai to hugeping @ Re: Разбор idec №2 01/11/24 21:37

По мне проблемы ровно три: отсутствие контента, отсутствие клиентов, отсутствие юзеров. Проблему внезапного лишнего трафика решает элементарное внедрение хэширования эх - оно сокращает трафик, и в отличие от адаптивных и ?sf даёт полную гарантию синхронности эх.

Мне вообще эта движуха напоминает создание очередной левонетки, где на серьёзных щах пишут полиси и прочее, раздают эхи, раздают на них модераторов и комодераторов, прочая движуха, а потом остаются с тремя юзерами (зато все модераторы друг друга). Ну или один год, про который я где-то чё-то говорил.

nAwAZK... . ОТВЕТИТЬ



\/ . ahamai to hugeping @ Re: Разбор idec №2 01/11/24 21:32

но вообще причина не особо понятна. я опрашиваю shaos каждые 5 минут, сейчас слайсами раньше полным фетчем. до h/x и с полным фетчем это 12 мб в сутки (при этом я тяну rss-эхи). после h/x и с полным фетчем 2-4 мб в сутки. (со слайсами, кстати, трафик почему-то нифига не уменьшился). в http есть gzip, который тоже экономит трафик.

8pymT4... . ОТВЕТИТЬ



\/ . ahamai to hugeping @ Re: Разбор idec №2 01/11/24 21:29

> 2) Невозможно "чётко" подобрать лимит такого захлёста. Сколько надо ставить чтобы и разброс порядка не влиял и интенсивность чата? 100? А если сисоп уехал в круиз а за пол года его отсутствия пришло 10000 пользователей? Нет, не надёжно.

полный фетч периодически необходим. и он решает все вопросы. вопросы "уехал в круиз на полгода" тоже решает полный фетч. а лимиты, как и любой другой k/v, можно легко добавить вообще не ломая совместимость с любой версией ii, просто меняя endpoint (что было заложено изначально, когда схема /z менялась на схему /u)

F8mHea... . ОТВЕТИТЬ





\/ . ahamai to revoltech @ Re: Разбор idec №2 01/11/24 21:22

Мне, старому фидошнику, непонятно, зачем фетчить сразу несколько станций. :) лично я качаю только с shaos

0x5CGw... . ОТВЕТИТЬ



\/ . ahamai to Andrew Lobanov @ Re: Рома порвался 01/11/24 21:20

> Изменения ради изменений. Ты бы классно вписался в современную IT-индустрию с такими подходами.

я вообще не трогаю технологию. она по мне изначально идеальна. я про внедрение проекта, новых пользователей, новый софт и прочая инфраструктура - ничего этого нет. при Стали^W мне каждую неделю новые клиенты выходили :) была куча юзеров, эх и прочего. сейчас всё глухо, несколько месяцев активность вообще была околонулевая. Даже shaos свой форум в эху не переформатировал. :) Я думаю, если бы жизненные обстоятельства мне не помешали, и сеть и технология сейчас были бы куда популярнее. Сейчас я тоже хочу заняться именно контентом, есть несколько идей, но жизненные обстоятельства сейчас куда хуже, к сожалению. Попробую. Ваши форматы меня не интересуют вообще, idec я прочитал только несколько дней назад, новый не читал.

Я ПРОСТО НАПОМИНАЛ 2014. Делали формат, который ПОЛНОСТЬЮ совместим с ii, но при этом экономит трафик. Итог:
1.
2.

kDJmvH... . ОТВЕТИТЬ



\/ . ahamai to Andrew Lobanov @ Re: Рома порвался 01/11/24 21:10

О. Третий. Гы-гы, проблемы проектирования... попытка решить болезни роста прежде чем они возникнут - погубило не одну сотню проектов. ii выжил, и именно благодаря своему проектированию и своему позиционированию. С технологией у текущей сети нет проблем, вообще. Есть проблемы с контентом.

6hsaUU... . ОТВЕТИТЬ



\/ . ahamai to hugeping @ Re: Разбор idec №2 01/11/24 21:04

> Ты можешь мне сказать где ты? Вроде бы ты на пп1, но при этом я вижу в твоих сообщения обсуждения решений тогоже sf, h которые вроде бы демонстрируют что то из пп3.

меня не интересует стандарт. ВООБЩЕ. у меня есть /u/e, который проживёт ещё 100 лет и переживёт всех модернизаторов.

я просто напоминал о 2014 году, когда делали стандарт. сейчас 2024 год и опять делают стандарт. на этом всё. умному - достаточно.

5W9D3A... . ОТВЕТИТЬ



\/ . ahamai to hugeping @ Re: Разбор idec №2 01/11/24 21:02

> Собственно это и есть краеугольный момент. Либо мы воспринимаем особенности ii проблемами либо нет. Я согласен, можно проявить аскетичность, смирение и "вложить" себя в базовый ii который предполагает:

Это не проблема. Это основа. Хотел вчера ответить revoltech, но отвечу сразу здесь.

ii это социальная сеть малых сообществ. Так она всегда и называлась. Она не про технологии, она про любительское программирование, радиолюбительство, клуб юного техника и прочие порождения Дворца Пионеров. Чтобы каждый мог собрать свою ноду и общаться со своим хомячком. Потому что это просто. Весь протокол постоянно упрощался. Какие вообще слайсы?

Ещё мне там понравилось, что второй человек уже указывает, что в выводе /u/e может быть мусор. Они походу вообще не понимают сути. Ты синкаешься с доверенным узлом по предельно формализированному и простому формату. Единственный вариант, когда там может быть мусор - это СБОЙ. И как можно в этой ситуации поступать "ну давайте что-нибудь попробуем вычленить". Да ты можешь получить 800 дублей или ещё чего похуже. Вся история и фидо, и ii, говорят об этом.

BAZMzD... . ОТВЕТИТЬ



\/ . ahamai to hugeping @ Re: Разбор idec №2 01/11/24 20:52

> Он не то чтобы его заменяет, а решает бОльшую задачу - sync только новых сообщений. При этом /x/h не нужен, так как решена более общая задача. Но хеши надо хранить для всех эх всех нод с которых мы фетчим...

x/h единственный валидный триггер. он бывает в двух состояниях "эха изменилась" и "эха не изменилась". всё остальное не даёт полных гарантий.

7Ac0Ne... . ОТВЕТИТЬ



\/ . ahamai to shaos @ Re: Разбор idec №2 01/11/24 20:50

> Ну теоретически если кто хранит мессаги в MySQL или SQLite, то время добавления можно и сохранять

так было в босфор. я ща гляжу на него, прикольная была штука, только клиентов и фетчеров для него не было :)

LwnmsB... . ОТВЕТИТЬ



\/ . shaos to hugeping @ Re: Разбор idec №2 01/11/24 20:29

Реверсная выдача это когда клиент качает список в обратном порядке пока не дойдёт до знакомых хешей? Это может работать только для отдельных эх (типа /e но в обратном порядке).

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

echo.1:msgid999
echo.2:msgid998
echo.1:msgid997
…

PeWoiW... . ОТВЕТИТЬ



\/ . hugeping to shaos @ Re: Разбор idec №2 01/11/24 18:25

shaos> Ну теоретически если кто хранит мессаги в MySQL или SQLite, то время добавления можно и сохранять, а если только в файлах, то по времени создания файла? Можно попробовать - всё равно ведь не всё перебирать надо, а только последние сообщения в эхе пока не найдём «прошлое»…

Да не, ерунда это всё. Не могу я, в общем, ничего принципиально иного придумать. Ну, а о реверсной выдачи ID что думаешь?

3S4NgN... . ОТВЕТИТЬ



\/ . shaos to hugeping @ Re: Разбор idec №2 01/11/24 17:46

Ну теоретически если кто хранит мессаги в MySQL или SQLite, то время добавления можно и сохранять, а если только в файлах, то по времени создания файла? Можно попробовать - всё равно ведь не всё перебирать надо, а только последние сообщения в эхе пока не найдём «прошлое»…

jX2tAG... . ОТВЕТИТЬ



\/ . hugeping to shaos @ Re: Разбор idec №2 01/11/24 17:28

shaos> А ну это сейчас вообще никем не фиксируется

Гм. Действительно, как-то я не подумал об этом. :)

1QCpSR... . ОТВЕТИТЬ





\/ . hugeping to shaos @ Re: Разбор idec №2 01/11/24 15:48

shaos> Время ненадёжно т.к. сообщения приходят так как приходят из-за особенностей роутинга и последовательности фетчинга, а вовсе не в хронологическом порядке, и старое сообщение вполне может внезапно "всплыть" выше по списку чем более новые ответы на него (см. беседу revoltech с Ромой).

Я имел в виду время принятия сообщения нодой, а не время создания сообщения, конечно.

EKXCW5... . ОТВЕТИТЬ



\/ . hugeping to shaos @ Re: Разбор idec №2 01/11/24 15:48

shaos> Если сохранять хеш последнего принятого сообщения для КАЖДОЙ опрашиваемой ноды, то тогда да - имеет право на жизнь. По идее оно может собой заменить хеш списка сообщений для эхи (мой /x/h или /list.txt?h=1) т.к. список не может расти изнутри - только с конца...

Он не то чтобы его заменяет, а решает бОльшую задачу - sync только новых сообщений. При этом /x/h не нужен, так как решена более общая задача. Но хеши надо хранить для всех эх всех нод с которых мы фетчим...

Hb7Zz0... . ОТВЕТИТЬ



\/ . shaos to shaos @ Re: Разбор idec №2 01/11/24 15:46

Выше по списку в ленте сообщений где сверху показаны последние сообщения, а в списке хешей эхи оно естественно будет ниже по списку...

z0NKSA... . ОТВЕТИТЬ



\/ . shaos to hugeping @ Re: Разбор idec №2 01/11/24 15:37

Время ненадёжно т.к. сообщения приходят так как приходят из-за особенностей роутинга и последовательности фетчинга, а вовсе не в хронологическом порядке, и старое сообщение вполне может внезапно "всплыть" выше по списку чем более новые ответы на него (см. беседу revoltech с Ромой).

FfcpM8... . ОТВЕТИТЬ



\/ . shaos to hugeping @ Re: Разбор idec №2 01/11/24 15:34

Если сохранять хеш последнего принятого сообщения для КАЖДОЙ опрашиваемой ноды, то тогда да - имеет право на жизнь. По идее оно может собой заменить хеш списка сообщений для эхи (мой /x/h или /list.txt?h=1) т.к. список не может расти изнутри - только с конца...

w1Y45E... . ОТВЕТИТЬ



\/ . hugeping to hugeping @ Re: Разбор idec №2 01/11/24 14:50

hugeping> Что думаете?

Продолжаю рассуждать. sf=hash становится надёжной, если только мы после последнего фетча запоминаем hash последнего сообщения которое зафетчили и сохранили. Возможно, о таком режиме Рома и говорил, но я до сих пор воспринимал sf=hash совсем по другому. Так что пишу это, если вы тоже воспринимали это по другому...

Так что sf=hash так же надёжна как и время, если мы после каждого фетча успешного записываем hash последнего взятого сообщения для этой ноды.

Мне, правда, не нравится необходимость хранить эти хеши для фетчей (причём для каждой ноды), поэтому идея с временем нравится больше. Но тем не менее.

HyD52Y... . ОТВЕТИТЬ



\/ . hugeping to tuple @ Re: Разбор idec №2 01/11/24 14:42

tuple> Стоило прийти в idec, как его уже хоронят :)

Не надо вбросов! Давай по существу.

P.S. Ipv4 тоже хоронят давно, но что-то никак. :)

T0kx0h... . ОТВЕТИТЬ



\/ . tuple to hugeping @ Re: Разбор idec №2 01/11/24 14:41

hugeping> Но это все в рамках некоторого "потенциально нового" ii-подобного протокола. idec3 :)

Стоило прийти в idec, как его уже хоронят :)

TcA3cJ... . ОТВЕТИТЬ



\/ . hugeping to hugeping @ Re: Разбор idec №2 01/11/24 14:35

Подумал тут ещё... Хочу добавить. Может какой-то мозговой штурм начнётся. Но это все в рамках некоторого "потенциально нового" ii-подобного протокола. idec3 :)

Адаптивный фетч тоже не 100% надёжен. Но ненадёжен по-другому. Речь о той точке алгоритма, когда мы останавливаемся. Когда видим что такое сообщение у нас есть и начинаем фетч. Это лучше чем жёсткий лимит, но всё-ещё не абсолютно надёжно.

Поэтому мне кажется, что в "идеальном" протоколе нужно выбрать что-то принципиально иное.

1) Либо полный sync если хоть что то поменялось (но тогда стоит вернуться и к перекатыванию эх, потому что в этом решении нет масштабировании при бесконечном росте эхи. Короче - это "принятие" ii)

2) Выборка, основанная на времени.

Вроде бы Рома делал такое когда-то, может ошибаюсь. Запрос вида: дай мне сообщения которые пришли с такого-то времени (время - ну пусть секунды эпохи unix в utc).

Да, тогда мы немного завязаны на время, но это вроде бы окончательно решает всё. Или нет?

Что думаете?

OXDsX5... . ОТВЕТИТЬ



\/ . shaos to shaos @ Re: Рома порвался 01/11/24 14:35

TOP10 VISITORS:

[1] Facebook point=0 web=1027 up=22.9MB (33%)
[2] 176.109.111.x point=46 web=0 up=16.7MB (24%) <--- tavern (2/hr)
[3] 92.63.98.x point=70 web=0 up=5.9MB (8%) <--- tgi (3/hr)
[4] Google point=42 web=480 up=5.7MB (8%) <--- Google (2/hr)
[5] 145.224.100.x point=115 web=1 up=5.0MB (7%) <--- 145.224.100.x (5/hr)
[6] Amazon point=0 web=83 up=4.1MB (5%)
[7] 95.165.9.x point=135 web=2 up=3.3MB (4%) <--- ping (6/hr)
[8] 217.197.116.x point=150 web=0 up=2.7MB (3%) <--- blackcat (6/hr)
[9] 24.130.121.x point=35 web=58 up=2.0MB (2%) <--- spnet (1/hr)
[10] 172.56.42.x point=0 web=35 up=0.2MB (<1%)

TOTAL TRAFFIC: 68MB

IhSBUV... . ОТВЕТИТЬ



\/ . shaos to Andrew Lobanov @ Re: Рома порвался 01/11/24 14:02

> Ну я Шаоса, вроде, не тяну.

Ну как не тяну? Тянешь, но по старому списку эх 2021 года и по старому адресу…

tqZ25q... . ОТВЕТИТЬ





\/ . Andrew Lobanov to hugeping @ Re: Рома порвался 01/11/24 11:45

AL>> Ну... На самом деле, я ещё думаю, что есть смысл выкинуть e/ и m/ :)
hugeping> m/ постоянно использую для отладки. Удобно. Про e/ сходу не могу вспомнить.

Ну m/, по размышлению, мне тоже кажется полезным. Даже просто взять и получить сообщение с помощью curl это удобно. А вот e/ никогда не видел, чтобы использовали. Разве что на заре ещё ii был клиент на баше и dialog, который был онлайн-клиентом и использовал как раз e/ и m/, если мне не изменяет память. Хотя, по факту, разделить строчку и декодировать base64 на баше всё равно просто.

+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.

vzmybi... . ОТВЕТИТЬ



\/ . hugeping to Andrew Lobanov @ Re: Рома порвался 01/11/24 11:11

AL> Ну... На самом деле, я ещё думаю, что есть смысл выкинуть e/ и m/ :)

m/ постоянно использую для отладки. Удобно. Про e/ сходу не могу вспомнить.

Dnp1zy... . ОТВЕТИТЬ



\/ . Andrew Lobanov to revoltech @ Re: Рома порвался 01/11/24 11:02

revoltech> Я там в revoltech.local (у Шаоса) пофантазировал на тему, как можно было бы весь протокол упростить, не будь необходимости держать обратную совместимость с ii/IDEC. Причём там и файлэхи тоже в общую структуру прекрасно ложились бы, например.

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

revoltech> Но сначала актуальный стандарт IDEC реализую в ноде своей, а потом уж посмотрим. Так что там, 40 мессаг на запрос устаканили, больше дополнений к доке не будет, можно приступать к запилу?

Ну... На самом деле, я ещё думаю, что есть смысл выкинуть e/ и m/ :)

+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.

e7pDR4... . ОТВЕТИТЬ



\/ . revoltech to Andrew Lobanov @ Re: Рома порвался 01/11/24 10:34

Я там в revoltech.local (у Шаоса) пофантазировал на тему, как можно было бы весь протокол упростить, не будь необходимости держать обратную совместимость с ii/IDEC. Причём там и файлэхи тоже в общую структуру прекрасно ложились бы, например.

Но сначала актуальный стандарт IDEC реализую в ноде своей, а потом уж посмотрим. Так что там, 40 мессаг на запрос устаканили, больше дополнений к доке не будет, можно приступать к запилу?

eoQxBz... . ОТВЕТИТЬ



\/ . Andrew Lobanov to revoltech @ Re: Рома порвался 01/11/24 09:58

AL>> Всё там же, где он лежит уже чёрт знает сколько лет. Ты же с ним сюда и приходил. Если ты про стандарт ii, то за этим к Роме.
revoltech> Да я уже запутался. Наверное, про стандарт ii. Короче, про то, что было до ребрендинга в IDEC и появления той доки на гитхабе.

Сначала был ii. Вещь хорошая, но недоделка. И даже стандарта не было - был только кривой референсный код. Потом Рома написал что-то типа стандарта. С кучей воды, неоднозначностями и вот это вот всё. Потом мы тут начали думать как ii довести до юзабельного состояния и родили слайсы. Конечно, это плохое решение, но все остальные ещё хуже. Были идеи и со счётчиками (они остались, но ими никто не пользуется, да и выкину я их), с хешем последнего сообщения (вообще максимально плохой вариант), с хешем всего индекса (тоже хреновый вариант, к тому же не позволяет определить откуда качать).

Идея указывать слайс для каждой эхи тоже была. Но была отметена. Уже и не помню почему. Единственное, что страдает с общим слайсом, это чувство прекрасного. Технологически он работает. А адаптивный фетчинг близок к красивому решению.

AL>> У него должен быть, ведь не может же быть такого, чтобы это великолепие да осталось без описания.
revoltech> Ну надеюсь. А то если окажется, что вместо описания остался только кривой референсный код, то совсем печаль.

Скорее всего, так и есть. Но надо спрашивать Рому.

+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.

H5KlO0... . ОТВЕТИТЬ



\/ . hugeping to ahamai @ Re: Разбор idec №2 01/11/24 09:45

Рома, не нервничай. У меня 3й день подряд мигрень, но я решил немного пояснить ситуацию, не влезая в детали. Как ты предложил. Но по существу! Мой ответ частично обращён к твоим другим сообщениям.

# Про дизайн и простоту ii

Я прекрасно понимаю твои доводы о простоте и сам практикую решения проблем "не в лоб". Это действительно круто, когда проблему можно "обойти" не решая её вообще. Plan9, кстати, отличный пример этого подхода. Я пришёл к этому не сразу, но когда так понял - сразу начал с радостью практиковать. На работе и в быту. И про питон + падения некорректных данных я тоже нормально отношусь. Мы пишем "чистые (сейчас не в терминах ФП)" функции при этом. А контролируемое падение питона (да ещё в рамках веб-фреймворка, например) это, обычно, не является проблемой безопасности.

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

# Проблемы "базового" ii

Собственно это и есть краеугольный момент. Либо мы воспринимаем особенности ii проблемами либо нет. Я согласен, можно проявить аскетичность, смирение и "вложить" себя в базовый ii который предполагает:

- полный фетч;
- архивирование и "бегучесть" эх.

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

# Обсуждаемые изменения стандарта idec

Обсуждаемые изменения стандарта - в основном, реакция на взгляд со стороны о двусмысленных моментах. Андрей выкинул из текущего idec то, что посчитал лишним. Так что это упрощение. А то, что было неточно сформулировано - сформулировал. Речь вроде бы и не шла о "принципиально новом" стандарте. То-есть, мера хаоса была уменьшена, не революционно, но тем не менее. В этом и есть его ценность.

# Новый стандарт

Вот. А теперь самое интересное. Есть чистый стол. Есть ii. Есть упрощённый idec. И дальше развилка.

1) мне достаточно ii
2) мне достаточно idec
3) я могу сделать лучше

Ты можешь мне сказать где ты? Вроде бы ты на пп1, но при этом я вижу в твоих сообщения обсуждения решений тогоже sf, h которые вроде бы демонстрируют что то из пп3.

Ну так возьми и предложи, связанным текстом непротиворечивый стандарт, который по твоему мнению достаточен.

Я лично могу сформулировать несколько вариантов:

1) ii с полным фетчем но с надёжным механизмом проверки изменений в эхах узла (это то, что у тебя hash эх
2) ii с возможностью забирать n последних сообщений (это твой lim и/или sf)
3) ii с отдачей списка msgid в обратном порядке (моя идея)

Каждая из них мне не нравится по своим причинам:

1) Необходимостью хранить счетчики/хеши/что угодно - мой шкурный интерес. Я тоже иногда люблю экстремальную простоту. Приемлемо, но не прекрасно.

2) Невозможно "чётко" подобрать лимит такого захлёста. Сколько надо ставить чтобы и разброс порядка не влиял и интенсивность чата? 100? А если сисоп уехал в круиз а за пол года его отсутствия пришло 10000 пользователей? Нет, не надёжно.

3) Вроде всё четко технически (читаем и обрываем связь когда считаем нужным) но.. Есть элемент хака.

Текущий idec в терминах простоты мне тоже НЕ НРАВИТСЯ, но! Я НЕ МОГУ придумать лучше и так, чтобы были решены те недостатки, о которых я говорю. И вот слайсы, достаточно просты и их таки решают! И этот адаптивный фетч который ты называешь оверинженирингом, для меня это вынужденный шаг. Другого пути я просто не вижу. Если хочу избавиться от полного фетча и при этом иметь надёжность которая позволила бы мне бросить ноду и не следить за ней год (хотя бы и гипотетически)

В общем, давай конструктивно. Дружно. Корректно! (Мою ноду дети читают!) Предлагай решения если есть что предложить дополнительно или скажи, что тебя устраивает ii в чистом виде, но тогда и не нервничай. Дай нам двигаться своим путём.

wZtICH... . ОТВЕТИТЬ



\/ . revoltech to Andrew Lobanov @ Re: Рома порвался 01/11/24 09:21

AL> Всё там же, где он лежит уже чёрт знает сколько лет. Ты же с ним сюда и приходил. Если ты про стандарт ii, то за этим к Роме.

Да я уже запутался. Наверное, про стандарт ii. Короче, про то, что было до ребрендинга в IDEC и появления той доки на гитхабе.

AL> У него должен быть, ведь не может же быть такого, чтобы это великолепие да осталось без описания.

Ну надеюсь. А то если окажется, что вместо описания остался только кривой референсный код, то совсем печаль.

C93ksX... . ОТВЕТИТЬ



\/ . Andrew Lobanov to All @ Извините 01/11/24 08:31

Сабж. Почитал и понял, что проще везде Рому в твит добавить, чем читать эту галиматью. Превратил эху в помойку и рад. Видимо, воссоздаёт привычную среду.

+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.

yGXpt4... . цепочка . ОТВЕТИТЬ



\/ . Andrew Lobanov to ahamai @ Re: Рома порвался 01/11/24 08:31

>> Если у тебя это не так, чини ноду.
ahamai> я не могу починить референсную ii 0.3, которая является базовым и законченным стандартом ii, потому что она осталась в 2014 году

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

ahamai> ps. проблема не в /u/e

Да. Проблема в ii 0.3.

+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.

CPRdEO... . ОТВЕТИТЬ



\/ . Andrew Lobanov to ahamai @ Re: Рома порвался 01/11/24 08:31

ahamai> Потому что вы не делали Дизайна проекта, принимая много решений "как поступить"

То есть, ты принимал много решений чтобы сделать ii с его родовыми травмами? Ну что я могу сказать... Тут ты больше себя очерняешь, чем нас.

ahamai> Разговор на ту тему, что мне интересно, вас вытянуть не удалось, вы сразу переходите на совсем другую, мне неинтересную, и которая вообще ничё не даёт. Впрочем, в текущем статусе стандарт вообще ничего не даёт.

Тебе интересно ii. Но это не эхотаг.

+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.

s6l2XH... . ОТВЕТИТЬ



\/ . Andrew Lobanov to revoltech @ Re: Рома порвался 01/11/24 08:31

ahamai>> Потому что вы не делали Дизайна проекта, принимая много решений "как поступить", а базируетесь на уже готовой реализации, когда те решения, которые есть, кажутся уже сами собой разумеющимися.
revoltech> С моей колокольни стороннего наблюдателя и имплементатора мне важны чётко документированные элементы протокола и как бы всё. С точки же зрения дизайна здесь, как говорится, есть два стула: либо ломаем вообще всю обратную совместимость и радикально упрощаем протокол (а упрощать и правда есть куда даже после выпиливания кучи эндпоинтов из стандарта), либо же проще оставить как есть, т.к. любые оптимизации ПРИ сохранении обратной совместимости приведут только к усложнению.

Мне начинает казаться, что Рома и правда подспудно хочет, чтобы его позорище в виде ii забыли и сделали нормально. Хотя, чтобы ii стал полезным, фактически, достаточно было добавить слайсы.

revoltech> А почему так криво задизайнили в 2014 — это уж точно вопрос не ко мне. Но сейчас это приходится принимать как данность. Или же ломать совместимость полностью и делать как следует. Но тогда это уже будет другая сеть.

Будет. И Рома снова придёт со своим нытьём про ii.

+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.

EOLd0x... . ОТВЕТИТЬ



\/ . Andrew Lobanov to revoltech @ Re: Рома порвался 01/11/24 08:31

ahamai>> Зато у вас новый стандарт будет. Ура!
revoltech> А старый (до IDEC) где почитать-то? Или опять в ИМХОдники будут тыкать?

Всё там же, где он лежит уже чёрт знает сколько лет. Ты же с ним сюда и приходил. Если ты про стандарт ii, то за этим к Роме. У него должен быть, ведь не может же быть такого, чтобы это великолепие да осталось без описания.

+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.

LHIwMb... . ОТВЕТИТЬ



\/ . Andrew Lobanov to ahamai @ Re: Рома порвался 01/11/24 08:31

Не везде твит поставил. Нечаянно прочитал.

ahamai> За 10 лет каких то продвижений и изменений нет.

Изменения ради изменений. Ты бы классно вписался в современную IT-индустрию с такими подходами.

ahamai> И да, я 100% уверен, что я хотел сказать.

Я не сомневаюсь в том, что ты сказал то, что ты хотел сказать. Правда ты противоречишь сам себе, игнорируешь объективную реальность и скатываешься в истерику. Но зато делаешь это всё уверенно.

ahamai> Ибо умные люди притчами говорят, а глупые в них за частности цепляются, не видя целого.

Умные люди не путают причину и следствие. Если умные человек говорит притчами, это совсем не означает, что тот, кто говорит притчами, умён.

ahamai> Зато у вас новый стандарт будет. Ура!

Да. Выкинули хлам. И новый хлам затаскивать не будем. /lim тот же вещь совершенно глупая. Об этом я тебе и 10 лет назад писал, и сейчас писал, но ты слишком умён, чтобы понять. Про хешики для каких-то там разных индексов вообще говорить не хочется. Это сломается моментально. Но кто я такой, чтобы что-то объяснять такому могучему мудрецу?

+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.

ykWjya... . ОТВЕТИТЬ



\/ . Andrew Lobanov to doesnm @ Re: Test emoji 01/11/24 07:51

tuple>>> 🙄😬🧒👩‍🚀🙆‍♀️👩‍👦‍👦👩‍👦👒🤷‍♀️👩‍❤️‍💋‍👩🧛‍♀️☝️👻💂‍♀️🤫🍉🍰🥣🥡🍨🍢🏣
revoltech>> А почему не в idec.test?
doesnm> Его на ping-е нет

Так создай :)

+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.

BZIkGi... . ОТВЕТИТЬ



\/ . Andrew Lobanov to revoltech @ Re: Разбор idec №2 01/11/24 07:51

doesnm>> Отдачу сделать по CGI (читерство), а вместо nc взять /dev/tcp (фича баша)
revoltech> Да что ж везде одни теоретики... /dev/tcp только для клиентских соединений работает. Сервер сугубо на нём не сделаешь.

Перечитай на что отвечаешь. Серверная часть на CGI, клиентская на /dev/tcp. Как раз то, что ты пишешь, и выходит. Ну блин.

+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.

oTd6Jx... . ОТВЕТИТЬ



\/ . tuple to shaos @ Re: Test emoji 01/11/24 07:44

shaos> Надо игру какую-нить заварганить пошаговую...

⬜️⬛️⬛️⬛️
⬜️⬜️⬜️⬛️
⬛️⬛️⬜️⬛️
⬛️⬛️⬜️⬛️
⬛️⬜️⬜️⬛️
⬛️🧑‍🏭⬛️⬛️
⬛️⬜️⬛️⬛️

Напишите ваше дальнейшее движение. :P

Вспомнил такую игрушку как https://rogule.com/

rdQcuH... . ОТВЕТИТЬ



\/ . revoltech to shaos @ Re: Разбор idec №2 01/11/24 08:02

shaos> а revoltech по-видимому читает сразу всех и часто

Не так уж и часто. У меня фетч чисто в ручном режиме по кнопке на данный момент. Но порядок чтения уже написал.

R2MgOo... . ОТВЕТИТЬ



\/ . revoltech to shaos @ Re: Разбор idec №2 01/11/24 07:58



\/ . Andrew Lobanov to revoltech @ Re: Разбор idec №2 01/11/24 07:45

shaos>> а вот от msgid и далее делать неохота ибо оно криво будет работать т.к. порядок может быть чуть разный на разных нодах...
revoltech> Такого, кстати, быть не должно.

Такое, кстати, является вполне штатной ситуацией. Сообщения в индексе располагаются в порядке получения нодой. Все ноды получают сообщения в разном порядке.

+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.

9R2KJp... . ОТВЕТИТЬ



\/ . shaos to tuple @ Re: Тест скорости фетча (+потеряшки) 01/11/24 07:46

Если кому интересно вот разница в траффике между HTTPS и HTTP ответами на один и тот же запрос с моей ноды:

HTTPS:
24.130.121.38 - - [01/Nov/2024:00:36:38 -0700] "GET /iii/x/h/bot.habr.rss/lor.opennet HTTP/1.1" 200 3977 "-" "curl/7.64.0"

HTTP:
24.130.121.38 - - [01/Nov/2024:00:38:43 -0700] "GET /iii/x/h/bot.habr.rss/lor.opennet HTTP/1.1" 200 216 "-" "curl/7.64.0"

Как можно видеть HTTPS лишние 3.5КБ передаёт соответственно для HTTPS лучше большие и редкие запросы делать, а вот для HTTP наверное лучше много мелких, чтобы сервер быстрее отрабатывал.

nT0fA6... . ОТВЕТИТЬ



\/ . doesnm to revoltech @ Re: Test emoji 01/11/24 07:26

tuple>> 🙄😬🧒👩‍🚀🙆‍♀️👩‍👦‍👦👩‍👦👒🤷‍♀️👩‍❤️‍💋‍👩🧛‍♀️☝️👻💂‍♀️🤫🍉🍰🥣🥡🍨🍢🏣
revoltech> А почему не в idec.test?

Его на ping-е нет

+++ Никто не знает, как правильно. Так зачем же выдумывать правила?

1R7pBZ... . ОТВЕТИТЬ



\/ . doesnm to revoltech @ Re: Разбор idec №2 01/11/24 07:25

doesnm>> Отдачу сделать по CGI (читерство), а вместо nc взять /dev/tcp (фича баша)
revoltech> Да что ж везде одни теоретики... /dev/tcp только для клиентских соединений работает. Сервер сугубо на нём не сделаешь.

Я же сказал что сервер по CGI

+++ Никто не знает, как правильно. Так зачем же выдумывать правила?

uZ8F2u... . ОТВЕТИТЬ





\/ . shaos to shaos @ Re: Разбор idec №2 01/11/24 07:27

На http://ii.blcat.ru/idec.talks правильный порядок - значит blcat берёт сообщения с меня чаще, чеми я с него, а revoltech по-видимому читает сразу всех и часто - я просто вижу его ответы раньше т.к. он мой поинт и отвечает через меня...

11HUBD... . ОТВЕТИТЬ



\/ . tuple to All @ Test emoji 01/11/24 07:07

🙄😬🧒👩‍🚀🙆‍♀️👩‍👦‍👦👩‍👦👒🤷‍♀️👩‍❤️‍💋‍👩🧛‍♀️☝️👻💂‍♀️🤫🍉🍰🥣🥡🍨🍢🏣

qGxNSs... . цепочка . ОТВЕТИТЬ





\/ . shaos to doesnm @ Re: Разбор idec №2 01/11/24 07:19

Возможно revoltech берёт сообщения Ромы прямо с blcat.ru и отвечает на них через меня, а я опрашиваю blcat.ru уже после, соответствено у меня ответы появляются раньше вопросов и затем это распространяется везде, кто берёт idec.talks с меня...

y7oqvE... . ОТВЕТИТЬ



\/ . revoltech to tuple @ Re: Test emoji 01/11/24 07:14

tuple> 🙄😬🧒👩‍🚀🙆‍♀️👩‍👦‍👦👩‍👦👒🤷‍♀️👩‍❤️‍💋‍👩🧛‍♀️☝️👻💂‍♀️🤫🍉🍰🥣🥡🍨🍢🏣

А почему не в idec.test?

Vf8ARx... . ОТВЕТИТЬ



\/ . revoltech to doesnm @ Re: Разбор idec №2 01/11/24 07:13

doesnm> Отдачу сделать по CGI (читерство), а вместо nc взять /dev/tcp (фича баша)

Да что ж везде одни теоретики... /dev/tcp только для клиентских соединений работает. Сервер сугубо на нём не сделаешь.

G4Ix9W... . ОТВЕТИТЬ



\/ . doesnm to shaos @ Re: Разбор idec №2 01/11/24 07:03

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

Кстати у меня тоже самое. Я думал это прикол ping

+++ Никто не знает, как правильно. Так зачем же выдумывать правила?

yAk5eh... . ОТВЕТИТЬ



\/ . doesnm to revoltech @ Re: Разбор idec №2 01/11/24 06:56

revoltech> Если брать продвинутый шелл вроде bash или oksh, всё можно сделать непосредственно в нём, кроме самой отдачи по TCP. Я, блин, гофер-клиента на чистом баше не так давно делал (Bopher-NG), вопрос только, что это решает.

Отдачу сделать по CGI (читерство), а вместо nc взять /dev/tcp (фича баша)

+++ Никто не знает, как правильно. Так зачем же выдумывать правила?

rW6SWj... . ОТВЕТИТЬ



shaos to revoltech @ Re: Разбор idec №2 01/11/24 06:54

> это как раз тот уровень сложности, от которого я стараюсь держаться подальше.

Это сложность по твоему? Это наоборот лёгкость и непринуждённость :)

> Такого, кстати, быть не должно.

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

3WvTiR... . ОТВЕТИТЬ


1 2 3 4 5 6 .7. 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31