# Re: spnet проапгрейдился до iii-php v0.9
shaos (spnet, 2) → ahamai – 03:12:52 2024-11-03
Это не дата в заголовке сообщения, это дата когда сервер это сообщение принял либо по фетчу, либо по пушу, либо через поинтовый апи, либо путём копирования файлов извне (у меня сейчас - дата модификации файла сообщения). Ясно понятно, что 2001 год там быть не может. Да и в заголовке старая дата как бы не должна быть т.к. это timestamp проставляемый сервером при конвертировании ii сообщения из поинтового в сохранённое, чего никак не могло произойти раньше 2014 года...
shaos (spnet, 2) → ahamai – 03:12:52 2024-11-03
Это не дата в заголовке сообщения, это дата когда сервер это сообщение принял либо по фетчу, либо по пушу, либо через поинтовый апи, либо путём копирования файлов извне (у меня сейчас - дата модификации файла сообщения). Ясно понятно, что 2001 год там быть не может. Да и в заголовке старая дата как бы не должна быть т.к. это timestamp проставляемый сервером при конвертировании ii сообщения из поинтового в сохранённое, чего никак не могло произойти раньше 2014 года...
# Re: spnet проапгрейдился до iii-php v0.9
ahamai (blackcat, 2) → shaos – 02:36:03 2024-11-03
Теоретически кто может сконвертить фидошные, с оригинальной датой. Лучше убрать один порядок :)
ahamai (blackcat, 2) → shaos – 02:36:03 2024-11-03
Теоретически кто может сконвертить фидошные, с оригинальной датой. Лучше убрать один порядок :)
# Re: Стандарт
shaos (spnet, 2) → shaos – 02:36:32 2024-11-03
> Узел должен обеспечивать запрос 40 сообщений в одном запросе /u/m. Клиент может запрашивать меньше, но узел должен обеспечивать передачу именно 40 сообщений за запрос.
Может быть первое предложение подкорректировать?
Количество одновременно запрашиваемых сообщений в одном запросе /u/m не должно превышать 40. Клиент может запрашивать меньше, но узел должен обеспечивать передачу именно 40 сообщений за запрос.
shaos (spnet, 2) → shaos – 02:36:32 2024-11-03
> Узел должен обеспечивать запрос 40 сообщений в одном запросе /u/m. Клиент может запрашивать меньше, но узел должен обеспечивать передачу именно 40 сообщений за запрос.
Может быть первое предложение подкорректировать?
Количество одновременно запрашиваемых сообщений в одном запросе /u/m не должно превышать 40. Клиент может запрашивать меньше, но узел должен обеспечивать передачу именно 40 сообщений за запрос.
# Re: Стандарт
shaos (spnet, 2) → Andrew Lobanov – 02:25:48 2024-11-03
Заметил лишний пробел:
> Количество сообщений указывается от 0 до произвольного числа. Если количество равно нулю, индекс строится от смещения до конца. Если сумма смещения и количества превышает фактическу ю длину индекса на узле, отдаются все msgid от смещения до конца индекса.
фактическу_ю
shaos (spnet, 2) → Andrew Lobanov – 02:25:48 2024-11-03
Заметил лишний пробел:
> Количество сообщений указывается от 0 до произвольного числа. Если количество равно нулю, индекс строится от смещения до конца. Если сумма смещения и количества превышает фактическу ю длину индекса на узле, отдаются все msgid от смещения до конца индекса.
фактическу_ю
# Re: spnet проапгрейдился до iii-php v0.9
shaos (spnet, 2) → shaos – 02:20:39 2024-11-03
> Осталось N:0 исправить...
Исправил - заменяю количество 0 на 999999999 (один миллиард минус 1) т.к. вряд ли когда-нибудь в ii/IDEC будут эхи с количеством сообщений больше миллиарда - ограничение такое сделал ещё и из-за того, что у меня в /u/e/ теперь unixtime может пролетать и для простоты он у меня определяется как число >=1000000000 что соответствует Sun Sep 09 2001 01:46:40 GMT+0000 (не думаю, что в ii/IDEC когда-либо попадутся сообщения древнее сентября 2001 года)...
shaos (spnet, 2) → shaos – 02:20:39 2024-11-03
> Осталось N:0 исправить...
Исправил - заменяю количество 0 на 999999999 (один миллиард минус 1) т.к. вряд ли когда-нибудь в ii/IDEC будут эхи с количеством сообщений больше миллиарда - ограничение такое сделал ещё и из-за того, что у меня в /u/e/ теперь unixtime может пролетать и для простоты он у меня определяется как число >=1000000000 что соответствует Sun Sep 09 2001 01:46:40 GMT+0000 (не думаю, что в ii/IDEC когда-либо попадутся сообщения древнее сентября 2001 года)...
# Re: Новое лицо ii-go
shaos (spnet, 2) → ahamai – 02:00:59 2024-11-03
> 30 мин чё-то долго, я фетчу только тебя, но с интервалом 5 мин.
надо в iii-php фетчер под тебя подковырять, чтобы list.txt?h=1 спрашивал для понимания чего брать чего не брать - тогда буду почаще опрашивать
shaos (spnet, 2) → ahamai – 02:00:59 2024-11-03
> 30 мин чё-то долго, я фетчу только тебя, но с интервалом 5 мин.
надо в iii-php фетчер под тебя подковырять, чтобы list.txt?h=1 спрашивал для понимания чего брать чего не брать - тогда буду почаще опрашивать
# Re: Новое лицо ii-go
ahamai (blackcat, 2) → shaos – 22:32:50 2024-11-02
> Я забираю раз в 30 минут с каждого, но моменты забирания размазаны вдоль часа - поэтому если с тебя никто кроме меня не забирает, то будет полчаса. А если все фетчат всех, то так или иначе теми или иными путями оно должно минут за 10 добраться...
мне не нравится, когда все фетчат всех :) мне привычнее схема аплинков-даунлинков. а 30 мин чё-то долго, я фетчу только тебя, но с интервалом 5 мин.
ahamai (blackcat, 2) → shaos – 22:32:50 2024-11-02
> Я забираю раз в 30 минут с каждого, но моменты забирания размазаны вдоль часа - поэтому если с тебя никто кроме меня не забирает, то будет полчаса. А если все фетчат всех, то так или иначе теми или иными путями оно должно минут за 10 добраться...
мне не нравится, когда все фетчат всех :) мне привычнее схема аплинков-даунлинков. а 30 мин чё-то долго, я фетчу только тебя, но с интервалом 5 мин.
# Re: spnet проапгрейдился до iii-php v0.9
ahamai (blackcat, 2) → hugeping – 22:31:39 2024-11-02
> Я сегодня тоже баг в сплайсах у себя обнаружил. Не работали положительные индексы вообще :)
> Но никто не использовал их в таком режиме. Исправил.
я про это и говорил, что не смогу у себя реализовать такое правильно, потому что этого не понимаю
ahamai (blackcat, 2) → hugeping – 22:31:39 2024-11-02
> Я сегодня тоже баг в сплайсах у себя обнаружил. Не работали положительные индексы вообще :)
> Но никто не использовал их в таком режиме. Исправил.
я про это и говорил, что не смогу у себя реализовать такое правильно, потому что этого не понимаю
# Re: spnet проапгрейдился до iii-php v0.9
hugeping (ping,1) → shaos – 18:43:13 2024-11-02
shaos> Осталось N:0 исправить...
Я сегодня тоже баг в сплайсах у себя обнаружил. Не работали положительные индексы вообще :)
Но никто не использовал их в таком режиме. Исправил.
hugeping (ping,1) → shaos – 18:43:13 2024-11-02
shaos> Осталось N:0 исправить...
Я сегодня тоже баг в сплайсах у себя обнаружил. Не работали положительные индексы вообще :)
Но никто не использовал их в таком режиме. Исправил.
# Re: spnet проапгрейдился до iii-php v0.9
shaos (spnet, 2) → shaos – 16:22:08 2024-11-02
Проверил старый ii-point.php - он и по 0:0 возвращал 0 хешей :)
Так что я получается это уже частично исправил ;)
Осталось N:0 исправить...
shaos (spnet, 2) → shaos – 16:22:08 2024-11-02
Проверил старый ii-point.php - он и по 0:0 возвращал 0 хешей :)
Так что я получается это уже частично исправил ;)
Осталось N:0 исправить...
# Re: spnet проапгрейдился до iii-php v0.9
shaos (spnet, 2) → shaos – 16:05:53 2024-11-02
-1:0 не работает (точнее работает, но возвращает 0 хешей)
но я эту логику не трогал - видимо ii-php всегда так работал
исправлю
shaos (spnet, 2) → shaos – 16:05:53 2024-11-02
-1:0 не работает (точнее работает, но возвращает 0 хешей)
но я эту логику не трогал - видимо ii-php всегда так работал
исправлю
# Re: Адаптивный фетч с несколькими эхами сразу
shaos (spnet, 2) → hugeping – 16:02:57 2024-11-02
Всё равно наверное надо скажем раз в неделю делать полное забирание всего - чисто на всякий пожарный...
shaos (spnet, 2) → hugeping – 16:02:57 2024-11-02
Всё равно наверное надо скажем раз в неделю делать полное забирание всего - чисто на всякий пожарный...
# Re: spnet проапгрейдился до iii-php v0.9
shaos (spnet, 2) → ahamai – 16:01:44 2024-11-02
> Жесть. Ты теперь обязан жениться на u/e
Выходит что так :)
shaos (spnet, 2) → ahamai – 16:01:44 2024-11-02
> Жесть. Ты теперь обязан жениться на u/e
Выходит что так :)
# Re: Новое лицо ii-go
shaos (spnet, 2) → ahamai – 15:49:03 2024-11-02
> Моё сообщение, написанное в 8:04 пришло туда в 8:38, чёт долго :)
Я забираю раз в 30 минут с каждого, но моменты забирания размазаны вдоль часа - поэтому если с тебя никто кроме меня не забирает, то будет полчаса. А если все фетчат всех, то так или иначе теми или иными путями оно должно минут за 10 добраться...
shaos (spnet, 2) → ahamai – 15:49:03 2024-11-02
> Моё сообщение, написанное в 8:04 пришло туда в 8:38, чёт долго :)
Я забираю раз в 30 минут с каждого, но моменты забирания размазаны вдоль часа - поэтому если с тебя никто кроме меня не забирает, то будет полчаса. А если все фетчат всех, то так или иначе теми или иными путями оно должно минут за 10 добраться...
# Re: spnet проапгрейдился до iii-php v0.9
shaos (spnet, 2) → hugeping – 15:46:45 2024-11-02
> Просто на всякий случай. В слайсах, установка limit в 0 означает безлимит.
0:0 у меня таки сработает как all
а вот -1:0 надо посмотреть...
shaos (spnet, 2) → hugeping – 15:46:45 2024-11-02
> Просто на всякий случай. В слайсах, установка limit в 0 означает безлимит.
0:0 у меня таки сработает как all
а вот -1:0 надо посмотреть...
# Re: Адаптивный фетч с несколькими эхами сразу
ahamai (blackcat, 2) → hugeping – 13:21:02 2024-11-02
lim это не для фетча, это чисто для клиентов. а переполнение при постоянном фетче живых эх вообще практически 0. такое может быть, если где-то rss бот сломался а потом вдруг выдал всё (и то в rss по 100 сообщений обычно не отдают). ну и я в lor.gold вкидываю сразу всю серию, там может быть и 200. а в клиентских эхах, по своему опыту, если я в фидо давно не забирал почту и в какой-то эхе куча сообщений, я максимум прочту несколько десятков последних и потом помечу эху, как прочитанную.
ps. у меня такое ощущение, что с такой экономией копеечного на самом деле трафика вы скоро на аутбаунд перейдёте. :) который я считаю главным недостатком фидо, я ровно сегодня думал, что фидо даже с сегодняшней моделью ii и тогдашними модемами на 300 байт/с, вполне могло бы жить.
ahamai (blackcat, 2) → hugeping – 13:21:02 2024-11-02
lim это не для фетча, это чисто для клиентов. а переполнение при постоянном фетче живых эх вообще практически 0. такое может быть, если где-то rss бот сломался а потом вдруг выдал всё (и то в rss по 100 сообщений обычно не отдают). ну и я в lor.gold вкидываю сразу всю серию, там может быть и 200. а в клиентских эхах, по своему опыту, если я в фидо давно не забирал почту и в какой-то эхе куча сообщений, я максимум прочту несколько десятков последних и потом помечу эху, как прочитанную.
ps. у меня такое ощущение, что с такой экономией копеечного на самом деле трафика вы скоро на аутбаунд перейдёте. :) который я считаю главным недостатком фидо, я ровно сегодня думал, что фидо даже с сегодняшней моделью ii и тогдашними модемами на 300 байт/с, вполне могло бы жить.
# Re: Адаптивный фетч с несколькими эхами сразу
hugeping (ping,1) → hugeping – 12:46:12 2024-11-02
Да, ещё, чтобы не забыть.
Допустим, мы используем endpoint /lim/100 и всегда фетчим последние 100 сообщений. Чем это плохо? Плохо тем, что если за это время накопится 200 сообщений, то у нас старые сообщения придут когда-то потом, после того как админ заметит проблему и сделает полный фетч.
Поэтому этот режим я никогда не рассматривал как надёжный. Он даже опасный.
Адаптивный фетч пытается решить эту проблему. В самой частой ситуации он сработает как /lim, но если окажется что сообщений всё-таки накапало больше, сдвинется назад.
hugeping (ping,1) → hugeping – 12:46:12 2024-11-02
Да, ещё, чтобы не забыть.
Допустим, мы используем endpoint /lim/100 и всегда фетчим последние 100 сообщений. Чем это плохо? Плохо тем, что если за это время накопится 200 сообщений, то у нас старые сообщения придут когда-то потом, после того как админ заметит проблему и сделает полный фетч.
Поэтому этот режим я никогда не рассматривал как надёжный. Он даже опасный.
Адаптивный фетч пытается решить эту проблему. В самой частой ситуации он сработает как /lim, но если окажется что сообщений всё-таки накапало больше, сдвинется назад.
# Re: Адаптивный фетч с несколькими эхами сразу
ahamai (blackcat, 2) → hugeping – 12:47:09 2024-11-02
Алгоритмы хорошо, но есть ли реальные замеры. Тестируй разные варианты на shaos, он подробную статистику ведёт :)
ahamai (blackcat, 2) → hugeping – 12:47:09 2024-11-02
Алгоритмы хорошо, но есть ли реальные замеры. Тестируй разные варианты на shaos, он подробную статистику ведёт :)
# Адаптивный фетч с несколькими эхами сразу
hugeping (ping,1) → All – 12:30:42 2024-11-02
Я после всех этих обсуждений засомневался, а может быть и правда нам нужны множественные слайсы в 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
>> Читать далее
hugeping (ping,1) → All – 12:30:42 2024-11-02
Я после всех этих обсуждений засомневался, а может быть и правда нам нужны множественные слайсы в 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
>> Читать далее
# Re: я наверное тоже напишу спецификацию
ahamai (blackcat, 2) → revoltech – 11:51:55 2024-11-02
> А потому что нефиг завязываться на точку было. Сделали бы 1) что-то в духе /u/l (в моём новом несовместимом протоколе будет /r/l вместо list.txt), 2) в выводе /u/e после каждой эхи (для отличия от msgid) ставить двоеточие. И всё, никаких коллизий.
так это теперь фича. пишешь туда то, что не хочешь, чтобы высвечивалось в веб :) раньше была внутренняя сисопская эха, которую мы называли "дальний кордон", типа "смотри я тебе на дальний кордон отправил". а теперь будет тайная эха, или эха-которую-нельзя-называть, и можно так же что-то туда написать и туда же послать :)
ahamai (blackcat, 2) → revoltech – 11:51:55 2024-11-02
> А потому что нефиг завязываться на точку было. Сделали бы 1) что-то в духе /u/l (в моём новом несовместимом протоколе будет /r/l вместо list.txt), 2) в выводе /u/e после каждой эхи (для отличия от msgid) ставить двоеточие. И всё, никаких коллизий.
так это теперь фича. пишешь туда то, что не хочешь, чтобы высвечивалось в веб :) раньше была внутренняя сисопская эха, которую мы называли "дальний кордон", типа "смотри я тебе на дальний кордон отправил". а теперь будет тайная эха, или эха-которую-нельзя-называть, и можно так же что-то туда написать и туда же послать :)
# Re: Разбор idec №2
ahamai (blackcat, 2) → revoltech – 11:49:48 2024-11-02
> Без фильтрации айдишников — ой как сделает.
каким образом? у нас есть только два состояния - мы делим строку и получаем список эх. для каждого, что мы решили как эху:
1. у нас есть файл с такой эхой - отдаём этот файл
2. у нас нет файла с этой эхой, отдаём пустую эху
третьего не дано
ahamai (blackcat, 2) → revoltech – 11:49:48 2024-11-02
> Без фильтрации айдишников — ой как сделает.
каким образом? у нас есть только два состояния - мы делим строку и получаем список эх. для каждого, что мы решили как эху:
1. у нас есть файл с такой эхой - отдаём этот файл
2. у нас нет файла с этой эхой, отдаём пустую эху
третьего не дано
# Re: Shaos linux.14
ahamai (blackcat, 2) → ahamai – 11:48:12 2024-11-02
1. я снял срезы. они почему-то вообще трафик не экономят, как был 2-4 мб так и остался, хотя x/h сильно его экономит. не понимаю, я же тяжёлые лор-опеннет и хабр.рсс тащу.
2. я создал эху spnet.uplink и поставил её фетч на тебя. поставь её фетч на меня, будем там решать проблемы нашей связи :), проблем, эх для гейтования и прочего, думаю здесь этому не место.
ahamai (blackcat, 2) → ahamai – 11:48:12 2024-11-02
1. я снял срезы. они почему-то вообще трафик не экономят, как был 2-4 мб так и остался, хотя x/h сильно его экономит. не понимаю, я же тяжёлые лор-опеннет и хабр.рсс тащу.
2. я создал эху spnet.uplink и поставил её фетч на тебя. поставь её фетч на меня, будем там решать проблемы нашей связи :), проблем, эх для гейтования и прочего, думаю здесь этому не место.
# Re: Разбор idec №2
Andrew Lobanov (tavern,1) → shaos – 11:22:19 2024-11-02
shaos> Ну вон я же вчера приводил замеры - каждый HTTPS запрос добавляет 3.5КБ к полезной нагрузке - будет 1000 запросов, будет лишних 3.5 мега...
Если в каждой эхе у нас новых сообщений от 128 до 256 штук, то для 1000 запросов, с учётом того, что запрашиваем по одной эхе, нужно запросить 125 эх. Это раз
Далеко не обязательно при адаптивном фетче запрашивать по одной эхе. Можно запрашивать все, наращивать количество, выкидывая из запроса те, где уже определились с индексом, пока не кончатся эхи для запросов. Таким образом количество запросов для получения индекса сокращается до единиц.
Бандлы по 40 сообщений... Если мы возьмём те самые 125 эх, в которых у нас по 256 новых сообщений и начнём их выкачивать такими вот бандлами, у нас всё равно будет 800 запросов, что меньше заявленного тобой ужасного числа на 20%.
В реальности такой оверхед будет только для новых узлов и разово. Дальше, при фетчинге хотя бы пару раз в день, количество запросов будет от силы несколько десятков на сессию, что меньше 10% от заявленного.
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
Andrew Lobanov (tavern,1) → shaos – 11:22:19 2024-11-02
shaos> Ну вон я же вчера приводил замеры - каждый HTTPS запрос добавляет 3.5КБ к полезной нагрузке - будет 1000 запросов, будет лишних 3.5 мега...
Если в каждой эхе у нас новых сообщений от 128 до 256 штук, то для 1000 запросов, с учётом того, что запрашиваем по одной эхе, нужно запросить 125 эх. Это раз
Далеко не обязательно при адаптивном фетче запрашивать по одной эхе. Можно запрашивать все, наращивать количество, выкидывая из запроса те, где уже определились с индексом, пока не кончатся эхи для запросов. Таким образом количество запросов для получения индекса сокращается до единиц.
Бандлы по 40 сообщений... Если мы возьмём те самые 125 эх, в которых у нас по 256 новых сообщений и начнём их выкачивать такими вот бандлами, у нас всё равно будет 800 запросов, что меньше заявленного тобой ужасного числа на 20%.
В реальности такой оверхед будет только для новых узлов и разово. Дальше, при фетчинге хотя бы пару раз в день, количество запросов будет от силы несколько десятков на сессию, что меньше 10% от заявленного.
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
# Re: spnet проапгрейдился до iii-php v0.9
hugeping (ping,1) → shaos – 08:41:46 2024-11-02
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)
hugeping (ping,1) → shaos – 08:41:46 2024-11-02
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)