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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ты бы хотя бы посмотрел, что они выдают :) у тебя нет http, по нему нет никакой отдачи.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

+++ memo:absurd

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

> у тебя нет http, по нему нет никакой отдачи.

Есть :)

Порт 8085 ;)

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

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

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

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

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

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

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

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

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

list.txt кэшировать на сервере, чтобы уменьшить нагрузку на него

поменял list.txt

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

мемо забыл проставить. ну хоть так, метамемо поставлю

+++ memo:iiiiii

А, ещё. Хочу использовать два первых символа хэша для указания года (только не решил, будет ли memo иметь приоритет или нет, наверное будет, это будут именованные сообщения)

пишу тут: http://ii.blcat.ru/naste.ne.notes

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

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

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

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

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

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

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

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

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

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

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

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

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

Тока он наоборот, lim/n/u/e

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

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

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

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

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

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

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

Или мы про фильтрацию эх уже говорим. Не важно, я в ответе к shaos всё расписал

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

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

Смотрим если вдруг вылезут косяки с веб-интерфейсом либо пинтовым апи. Новый поинтовый апи доступен всё так же по 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

> Тока он наоборот, lim/n/u/e

Не - так не получится :)

Тогда оно просто дублирует слайсы, смысл именно в том что оно впереди парохода

Так. Я могу задать срез последней, я могу задать каждой. А если я задам не каждой, а некоторым, что будет тогда?

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

ahamai> мемо забыл проставить. ну хоть так, метамемо поставлю

Что такое memo

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

http://ii.blcat.ru/memo00

Очень желательно сделать на станции отличие одной страницы от другой в title вкладки. А то в истории браузера сохраняется просто как:
- ping
- ping
- ping
- ...

А хотелось бы что-то вроде:
- [ping] echo/all // общая лента
- [ping] Re: разборки с IDEC // для тредов
- [ping] Жертвы разборок
- [ping] Новый протокол - VINI: VINI is not IDEC

Сделал

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

Сделал хак для поддержки /lim/N/u/e/...

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

работает также как и

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

ahamai> Да и пойнт тебе с u/e ничё не сделает.

Без фильтрации айдишников — ой как сделает.

> Так. Я могу задать срез последней, я могу задать каждой. А если я задам не каждой, а некоторым, что будет тогда?

Когда ты задаёшь "срез" в конце, то он распространяется на весь список

Если надо чтобы что-то из списка брало по своему, то там надо указать свой "срез" либо волшебное слово all либо волшебное слово last

типа /u/e/echo.1/echo.2/all/echo.3/last вернёт всё для echo.1 и echo.2, но только хеш последнего сообщения для echo.3

ну ещё lim можно воткнуть в середину - вот такая запись сделает тоже самое:

/u/e/echo.1/echo.2/lim/1/echo.3

короче полная гибкость и свобода выбора :)

ну конечно оно в каком-то смысле дублирует слайсы :)

короче с хаком теперь работает, но только применительно к /u/e т.е. например /lim/3/list.txt у меня не пройдёт ;)

Хак:

elseif (($opts[0] == 'u' and $opts[1] == 'e') ||
        ($opts[0] == 'lim' and $opts[2] == 'u' and $opts[3] == 'e')) {
	$work_options=array_slice($opts, 2);
	// lim/N/u/e hack
	if($opts[0] == 'lim') {
		$work_options[0] = 'lim';
		$work_options[1] = $opts[1];
	}

Жесть. Ты теперь обязан жениться на u/e

По ходу пьесы удалил около 500 строк отвечающих за файлэхи - это было порядка 20% всего кода ii-php (сейчас осталось чуть больше 2000 строк), а чтобы поддержать в /u/e/ слайсы где попало, lim/N, выдача по хешу, выдача по времени сохранения плюс хак /lim/N/e/u потребовалось добавить меньше 50 строк...

> сейчас осталось чуть больше 2000 строк

там ведь ещё есть неиспользуемый сейчас транспорт MySQL - я пока думаю стоит туда вообще залезать или остаться в рамках файлового представления

наверное надо пересаживаться на MySQL хотя бы для хранения метаданных типа цепочек тредов, таблиц поиска и т.д.

tuple> Очень желательно сделать на станции отличие одной страницы от другой в title вкладки. А то в истории браузера сохраняется просто как:

Посмотри сейчас, лучше стало? Правда наверное не все случаи предусмотрел.

hugeping> Посмотри сейчас, лучше стало? Правда наверное не все случаи предусмотрел.

Да, классно теперь. Только https://club.hugeping.ru/echo/all/ отображается как "club.hugeping.ru/echo/all".

hugeping>> Посмотри сейчас, лучше стало? Правда наверное не все случаи предусмотрел.

tuple> Да, классно теперь. Только https://club.hugeping.ru/echo/all/ отображается как "club.hugeping.ru/echo/all".

Ага, ещё несколько случаев добавил. Если что, пиши. Для меня web ii-go сейчас близок к идеалу. Но иногда что-то меняю по мелочи.

Зашёл на станцию hugeping а там уже будущее :)

Моё сообщение, написанное в 8:04 пришло туда в 8:38, чёт долго :)

Не могу понять, но от тебя периодически перестаёт ходить эха linux.14. Вот только эта эха. Проблему понять не могу

shaos> Если надо чтобы что-то из списка брало по своему, то там надо указать свой "срез" либо волшебное слово all либо волшебное слово last

Просто на всякий случай. В слайсах, установка limit в 0 означает безлимит.

https://hugeping.tk/u/e/idec.talks/0:0 - всё
https://hugeping.tk/u/e/idec.talks/-1:0 - последнее (ну или -1:1)

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

Если в каждой эхе у нас новых сообщений от 128 до 256 штук, то для 1000 запросов, с учётом того, что запрашиваем по одной эхе, нужно запросить 125 эх. Это раз

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

Бандлы по 40 сообщений... Если мы возьмём те самые 125 эх, в которых у нас по 256 новых сообщений и начнём их выкачивать такими вот бандлами, у нас всё равно будет 800 запросов, что меньше заявленного тобой ужасного числа на 20%.

В реальности такой оверхед будет только для новых узлов и разово. Дальше, при фетчинге хотя бы пару раз в день, количество запросов будет от силы несколько десятков на сессию, что меньше 10% от заявленного.

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

1. я снял срезы. они почему-то вообще трафик не экономят, как был 2-4 мб так и остался, хотя x/h сильно его экономит. не понимаю, я же тяжёлые лор-опеннет и хабр.рсс тащу.

2. я создал эху spnet.uplink и поставил её фетч на тебя. поставь её фетч на меня, будем там решать проблемы нашей связи :), проблем, эх для гейтования и прочего, думаю здесь этому не место.

> Без фильтрации айдишников — ой как сделает.

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

1. у нас есть файл с такой эхой - отдаём этот файл
2. у нас нет файла с этой эхой, отдаём пустую эху

третьего не дано

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

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

Я после всех этих обсуждений засомневался, а может быть и правда нам нужны множественные слайсы в u/e? Может быть это нужно для адаптивного фетча? Поговорил с Андреем и стало понятно что вроде бы не нужны.

# Идея

Идея, на самом деле, простая. Мы сканируем последние сообщения станции но ровно до тех пор, пока сами не решим - хватит или нет. А решение принимаем на основе анализа полученных msgid (есть они в базе у нас или нет?). В этом отличие от просто фетча последних n сообщений.

# Алгоритм

1. Выбрали N=16, LIM=16
2. Выбрали набор эх elist: echo.1, echo.2, ... echo.i
3. Сделали запрос /u/e/echo.1...echo.i/-N:LIM
4. Для каждой эхи в ответе:
- Все отсутствующие msgid добавляем в список, который добавляем в голову msgids
- Если таких сообщений нет или ответ содержит меньше записей чем N (выгребли всё)
удаляем эху из набора elist
5. Набор elist пуст? Да! иди на 10
6. LIM=N, N = N * 2
7. N > 1024 ? Если да, бросаем это дело и начинаем полный фетч
8. Перейти на 3
10. Делаем запрос(ы) /u/m для всех id из списка msgids

Числа 16 и 1024 тоже эвристические. 1024 - просто способ закончить фетч если мы видим, что адаптивный фетч всё никак не дойдёт до "дна".

# Можно ли проще?

Моя станция работает по-другому. Основное отличие в том, что я делаю запросы -N:1 а не -N:LIM и просто проверяю -- а есть ли у меня это сообщение или нет? Если есть, потом я делаю фетч на -N:N.

1. Выбрали N=16
2. Выбрали эху
3. Сделали запрос /u/e/echo/-N:1
4. Сообщение есть? Или такое же как в прошлый раз? На 10
5. N = N*2
7. N > 1024 ? Если да, бросаем это дело и начинаем полный фетч
8. Перейти на 3
10. Делаем запрос /u/e/echo/-N:N
11. Делаем запрос /u/m для всех id из ответа пп.10 которых у нас нет

Это немного упрощает алгоритм и, возможно?, делает ситуацию безопасней, если во время сканирования добавились новые сообщения, но я работаю только с одной эхой. Если такую штуку делать со многими эхами сразу то:
a) понадобятся множественные slice
b) алгоритм станет сложнее, а не проще

Но, конечно, можно брать просто максимальный N для всех эх а потом делать один общий фетч.

1. Выбрали N=16
2. Выбрали набор эх elist: echo.1, echo.2, ... echo.i
3. Сделали запрос /u/e/echo.1...echo.i/-N:1
4. Для каждой эхи в ответе:
- Если сообщение есть или получили тот же id что в прошлый раз, удаляем эху из набора
5. Набор elist пуст? Да! иди на 10
6. N = N * 2
7. N > 1024 ? Если да, бросаем это дело и начинаем полный фетч
8. Перейти на 3
10. Делаем запрос(ы) /u/e/все эхи/-N:N
11. Делаем запрос(ы) /u/m для всех id из ответа пп10

Написал просто, чтобы не забыть.

Алгоритмы хорошо, но есть ли реальные замеры. Тестируй разные варианты на shaos, он подробную статистику ведёт :)

Да, ещё, чтобы не забыть.

Допустим, мы используем endpoint /lim/100 и всегда фетчим последние 100 сообщений. Чем это плохо? Плохо тем, что если за это время накопится 200 сообщений, то у нас старые сообщения придут когда-то потом, после того как админ заметит проблему и сделает полный фетч.

Поэтому этот режим я никогда не рассматривал как надёжный. Он даже опасный.

Адаптивный фетч пытается решить эту проблему. В самой частой ситуации он сработает как /lim, но если окажется что сообщений всё-таки накапало больше, сдвинется назад.

lim это не для фетча, это чисто для клиентов. а переполнение при постоянном фетче живых эх вообще практически 0. такое может быть, если где-то rss бот сломался а потом вдруг выдал всё (и то в rss по 100 сообщений обычно не отдают). ну и я в lor.gold вкидываю сразу всю серию, там может быть и 200. а в клиентских эхах, по своему опыту, если я в фидо давно не забирал почту и в какой-то эхе куча сообщений, я максимум прочту несколько десятков последних и потом помечу эху, как прочитанную.

ps. у меня такое ощущение, что с такой экономией копеечного на самом деле трафика вы скоро на аутбаунд перейдёте. :) который я считаю главным недостатком фидо, я ровно сегодня думал, что фидо даже с сегодняшней моделью ii и тогдашними модемами на 300 байт/с, вполне могло бы жить.

> Просто на всякий случай. В слайсах, установка limit в 0 означает безлимит.

0:0 у меня таки сработает как all
а вот -1:0 надо посмотреть...

> Моё сообщение, написанное в 8:04 пришло туда в 8:38, чёт долго :)

Я забираю раз в 30 минут с каждого, но моменты забирания размазаны вдоль часа - поэтому если с тебя никто кроме меня не забирает, то будет полчаса. А если все фетчат всех, то так или иначе теми или иными путями оно должно минут за 10 добраться...

2. сделал spnet.uplink

> Жесть. Ты теперь обязан жениться на u/e

Выходит что так :)

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

-1:0 не работает (точнее работает, но возвращает 0 хешей)
но я эту логику не трогал - видимо ii-php всегда так работал
исправлю

Проверил старый ii-point.php - он и по 0:0 возвращал 0 хешей :)
Так что я получается это уже частично исправил ;)
Осталось N:0 исправить...

shaos> Осталось N:0 исправить...

Я сегодня тоже баг в сплайсах у себя обнаружил. Не работали положительные индексы вообще :)
Но никто не использовал их в таком режиме. Исправил.

> Я сегодня тоже баг в сплайсах у себя обнаружил. Не работали положительные индексы вообще :)
> Но никто не использовал их в таком режиме. Исправил.

я про это и говорил, что не смогу у себя реализовать такое правильно, потому что этого не понимаю

> Я забираю раз в 30 минут с каждого, но моменты забирания размазаны вдоль часа - поэтому если с тебя никто кроме меня не забирает, то будет полчаса. А если все фетчат всех, то так или иначе теми или иными путями оно должно минут за 10 добраться...

мне не нравится, когда все фетчат всех :) мне привычнее схема аплинков-даунлинков. а 30 мин чё-то долго, я фетчу только тебя, но с интервалом 5 мин.

> 30 мин чё-то долго, я фетчу только тебя, но с интервалом 5 мин.

надо в iii-php фетчер под тебя подковырять, чтобы list.txt?h=1 спрашивал для понимания чего брать чего не брать - тогда буду почаще опрашивать

> Осталось N:0 исправить...

Исправил - заменяю количество 0 на 999999999 (один миллиард минус 1) т.к. вряд ли когда-нибудь в ii/IDEC будут эхи с количеством сообщений больше миллиарда - ограничение такое сделал ещё и из-за того, что у меня в /u/e/ теперь unixtime может пролетать и для простоты он у меня определяется как число >=1000000000 что соответствует Sun Sep 09 2001 01:46:40 GMT+0000 (не думаю, что в ii/IDEC когда-либо попадутся сообщения древнее сентября 2001 года)...

Заметил лишний пробел:

> Количество сообщений указывается от 0 до произвольного числа. Если количество равно нулю, индекс строится от смещения до конца. Если сумма смещения и количества превышает фактическу ю длину индекса на узле, отдаются все msgid от смещения до конца индекса.

фактическу_ю

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

> Узел должен обеспечивать запрос 40 сообщений в одном запросе /u/m. Клиент может запрашивать меньше, но узел должен обеспечивать передачу именно 40 сообщений за запрос.

Может быть первое предложение подкорректировать?

Количество одновременно запрашиваемых сообщений в одном запросе /u/m не должно превышать 40. Клиент может запрашивать меньше, но узел должен обеспечивать передачу именно 40 сообщений за запрос.