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




\/ . revoltech to Re: Мея видо? @ shaos 23/10/24 10:24

Да, так задумано, если о пустой строке между абзацами речь.

[forwarded from idec.test]

ScavLd... . ОТВЕТИТЬ





\/ . Andrew Lobanov to revoltech @ Re: Мея видо? 23/10/24 08:43

revoltech> Тестируем многострочный пост, как я бы его обычно писал в виме до того, как
revoltech> допилю GUI-клиента.
revoltech> Если всё нормально, то сегодня или на днях сделаю вообще длиннопост о том,
revoltech> что покамест думаю об этой сети и её перспективах.
revoltech> И да, спасибо shaos за доступ, будем тестить в idec.test дальше.

ВИД О. Только откуда-то лишние переводы строки лезут.

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

[forwarded from idec.test]

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





\/ . revoltech to All @ Мея видо? 23/10/24 06:13

Тестируем многострочный пост, как я бы его обычно писал в виме до того, как
допилю GUI-клиента.

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

И да, спасибо shaos за доступ, будем тестить в idec.test дальше.

[forwarded from idec.test]

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



\/ . ahamai to All @ idec.test 25/10/24 10:37

shaos, почему с тебя idec.test не фетчится?

ps. Ценность маленьких запросов понимаешь, когда фетчишь с spline :)

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





\/ . ahamai to revoltech @ Re: Полуневдимые эхи 25/10/24 10:18

Это понятно, но меня http полностью устраивает по ресурсоёмкости, распространённости везде и для всего, веб-фреймворков для него.

Ну и есть всякие плюшки типа минимальной гарантии доставки (content-len, или если что-то пошло не так, брякнулись с ошибкой и клиент понял что ошибка). Плюс опциональное gzip сжатие, существующее с лохматых годов. Правда, сейчас py3 фетчер не поддерживает gzip сжатие, py2 и ii-txt на py2 поддерживают. Сейчас глянул, у меня на сервере не включён gzip для text/plain, включил.

Это хорошо и замечательно, если будут другие транспорты. Но подразумевается, что протокол настолько простой то эти транспорты пишет тот, кто этим интересуется. Для меня простота - это возможность в несколько строк написать фетчер хоть на python, хоть на busybox, поэтому я буду поддерживать реализацию только через http. Но всегда интересно посмотреть на сторонние проекты.

pfhpzp... . ОТВЕТИТЬ



\/ . hugeping to revoltech @ Re: Полуневдимые эхи 25/10/24 10:10

revoltech> P.S. Да, ещё раз пардон, перепроверил — то у tgi только 12 сообщений за раз можно выгрести. У остальных 389, у тебя вообще лимит 10000 вроде хавает без проблем. Правда, spline-online не тестил, он и так еле живой сейчас.

Кстати, это соответствует "рекомендованному" буферу в 8к. Как раз ~380 id-шников. 12 сообщений это, конечно, маловато даже по меркам "обычного" веба.

80dk50... . ОТВЕТИТЬ



\/ . revoltech to hugeping @ Re: Полуневдимые эхи 25/10/24 09:54

hugeping> Каких метаданных и почему куча соединений?

Даже если отбросить всю низкоуровневую тряхомудию с установкой TLS-соединения и проверкой сертификатов при HTTPS, каждый HTTP-запрос — это статусы, заголовки Accept, Content-Type, Content-Encoding и т.д. Тут, как ни крути, оверхед будет существенным при большом количестве мелких запросов. Поэтому тело запроса укрупнять смысл имеет в любом случае.

P.S. Да, ещё раз пардон, перепроверил — то у tgi только 12 сообщений за раз можно выгрести. У остальных 389, у тебя вообще лимит 10000 вроде хавает без проблем. Правда, spline-online не тестил, он и так еле живой сейчас.

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



\/ . revoltech to hugeping @ Re: Полуневдимые эхи 25/10/24 09:46

hugeping> У меня нет веб сервера. Насчёт 12 сообщений, интересный вопрос. Это проверено? Я посмотрю, может быть это можно настроить в go библиотеке.

А, значит, с tgi перепутал. Пардон. Изначально тестил на обоих.

OE0R5G... . ОТВЕТИТЬ



\/ . hugeping to hugeping @ Re: Полуневдимые эхи 25/10/24 09:44

revoltech>> У пинга понятно, нжинкс и 12 сообщений на запрос максимум.

hugeping> У меня нет веб сервера. Насчёт 12 сообщений, интересный вопрос. Это проверено? Я посмотрю, может быть это можно настроить в go библиотеке.

В общем, откуда инфа про 12? Запрос ввёл сейчас раза в два больше - не вижу ограничений. Или это опять, поэтическое преувеличение?

z5oeWQ... . ОТВЕТИТЬ



\/ . hugeping to revoltech @ Re: Полуневдимые эхи 25/10/24 09:28

revoltech> У пинга понятно, нжинкс и 12 сообщений на запрос максимум.

У меня нет веб сервера. Насчёт 12 сообщений, интересный вопрос. Это проверено? Я посмотрю, может быть это можно настроить в go библиотеке.

zDTrsh... . ОТВЕТИТЬ



\/ . hugeping to revoltech @ Re: Полуневдимые эхи 25/10/24 09:26

revoltech> И там AL написал, что POST /u/m не решает ни одной проблемы. Как же не решает, если решает? Вот вам проблема: куча лишних соединений и метаданных

Каких метаданных и почему куча соединений? Если ты работаешь последовательно - то это несколько подряд идущих get запросов, а не куча параллельных соединений. Если же ты хочешь скорости, то да - потоки. Но это вообще говоря две независимые вещи. Например, запуск отдельных фетчеров на каждый узел. И да, многопоточность не связана с наличием свободных процессоров. Там нагрузки практически нет, вопрос не в утилизации мощности вычислительной, а в "съедании" времени ожидания TCP.

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



\/ . revoltech to ahamai @ Re: Полуневдимые эхи 25/10/24 09:03

ahamai> Идея в том, что есть и библиотеки, и средсва в системе, и можно с плмощью wget, cat и такой то матери в три строчки собрать простейший клиент.

Намёк был на то, что есть транспорты ещё проще, чем HTTP. Например, Nex/NPS можно вообще описать парой коротких предложений:

1. Скачивание (Nex): отправляем путь и LF на TCP-порт 1900, забираем данные.
2. Постинг (NPS): отправляем путь и LF, опционально строку авторизации и LF, сами данные, LF, точку (.) и LF на TCP-порт 1915, забираем ответ.

Всё, это оба протокола. Дальше в Nex расписано, что рекомендуется делать на клиенте, если путь заканчивается на /, но к ii это уже можно не применять. Вместо LF можно использовать CRLF, как минимум существующие сервера это понимают.

Суть именно в простоте, даже на оф.сайте указано сверху, как через nc выгрести Nex-ресурс:

echo nps/info/form.txt | nc nightfall.city 1900 | less

С гофером, кстати, точно так же, только порт по умолчанию 70. Но нет, давайте городить огород с ненужными для ii HTTP-хедерами, лимитами на гет-запросы и контент-тайпами.

Если что, не осуждаю существующие подходы, просто не понимаю, почему бы опционально не сделать ещё проще.

ahamai> Лимит на get у меня вроде тоже 8 кб

Это типа «640 кб хватит всем»? :D Ну ладно, поставил тоже 389 на запрос. Как-нибудь попробую перефетч. А у остальных как? У пинга понятно, нжинкс и 12 сообщений на запрос максимум. А у spline-online и tgistation что?

SO0bBc... . ОТВЕТИТЬ













\/ . ahamai to revoltech @ Re: Полуневдимые эхи 25/10/24 08:20

Идея в том, что есть и библиотеки, и средсва в системе, и можно с плмощью wget, cat и такой то матери в три строчки собрать простейший клиент.

Лимит на get у меня вроде тоже 8 кб

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







\/ . revoltech to ahamai @ Re: Полуневдимые эхи 25/10/24 07:46

ahamai> По хттп можно качать хоть с дискеты и вообще отовсюду, он есть везде.

А для некса с гофером вообще ничего, кроме нетката/телнета (голого TCP), не нужно.

ahamai> Сегментирование запросов было введено специально.

Чтобы создать новым поинтам затруднения с первым выкачиванием эх (а-ля блокчейн монеро)?

ahamai> И я не вижу проблемы, я щас всю rulinux14 скачал за несколько секунд.

Сколько сообщений можно выкачать за один запрос у тебя на станции?

Noq1sm... . ОТВЕТИТЬ







\/ . ahamai to revoltech @ Re: Полуневдимые эхи 25/10/24 07:29

> С тем же успехом можно на Gemini/Spartan перелезть полностью — там длина запроса 2048 символами ограничивается, если не ошибаюсь. В Nex и такого ограничения нет.

По хттп можно качать хоть с дискеты и вообще отовсюду, он есть везде.

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

Fb8hAH... . ОТВЕТИТЬ













\/ . ahamai to revoltech @ Re: Полуневдимые эхи 25/10/24 07:15

Кросспостинг был изначально, но я от него сразу отказался, он создаёт больше проблем, чем решает. Он тут не нужен

NXpuLv... . ОТВЕТИТЬ



\/ . revoltech to shaos @ Re: Полуневдимые эхи 25/10/24 07:05

shaos> Кстати вопрос про POST в /u/m периодически поднимался, например вот тут w6o5S9CleUqqm4Lgc8O9 (декабрь 2021) что так ни к чему и не привело - вот полное обсуждение

И там AL написал, что POST /u/m не решает ни одной проблемы. Как же не решает, если решает? Вот вам проблема: куча лишних соединений и метаданных, т.к. владельцы станций ограничивают длину GET-запросов, либо сознательно, либо оставляя дефолт на веб-сервере. С POST запрос будет всегда одним в идеале.

С тем же успехом можно на Gemini/Spartan перелезть полностью — там длина запроса 2048 символами ограничивается, если не ошибаюсь. В Nex и такого ограничения нет.

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



\/ . shaos to revoltech @ Re: Полуневдимые эхи 25/10/24 06:58



\/ . ahamai to revoltech @ Re: Полуневдимые эхи 25/10/24 07:02

Операция атомарна, поэтому надо чтобы в случае чего она была проведена без сбоев, а то заново придётся качать

За 10 лет не помню проблем с текущим фетчем

waPdSq... . ОТВЕТИТЬ







\/ . ahamai to shaos @ Re: Полуневдимые эхи 25/10/24 06:56

> если IDEC уже имеет все средства как часть стандарта, то зачем для него городить кастомные гейты?..

Без гейта ты нормально не отобразишь ничего ни на zx spectrum ни на msdos, ни на atari st. Сначала научи их utf8 :)

Хочется хоть одно реальное применение слайсов, кроме "забрать последние сообщения"

eQvqj5... . ОТВЕТИТЬ



\/ . shaos to ahamai @ Re: Полуневдимые эхи 25/10/24 06:40

> зачем тебе там список сообщений, если ты там и одно сообщение не отобразишь? :)

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

> для таких вещей вообще абсолютно кастомные гейты надо делать, а не стандартные средства

если IDEC уже имеет все средства как часть стандарта, то зачем для него городить кастомные гейты?...

bcGCVv... . ОТВЕТИТЬ



\/ . revoltech to shaos @ Re: Полуневдимые эхи 25/10/24 06:33

shaos> гугол говорит 8192

Да, в теории 389 айдишников туда поместятся. Всё равно маловато, но лучше, чем по 12 группировать.

Может, сделаю в stations.txt напротив каждой урлы поле, которое указывает максимальное количество адишников. Мол, если не знаем, ставим 12.

TUUvfJ... . ОТВЕТИТЬ









\/ . revoltech to hugeping @ Re: Полуневдимые эхи 25/10/24 06:11

hugeping> Нет.

Вполне достаточный ответ.

hugeping> А слайсы решают проблему больших индексов.

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

Мой юзкейс — зашёл утром, запустил tiifetch.tcl или нажал на кнопочку Fetch all echos в tiix, клиент докачает изменения всех эх за ночь и в течение дня дофетчиваю только новое содержимое конкретно интересующих эх, вручную жмякая на Fetch this echo при необходимости. За это время в них может собраться куда больше 100 сообщений, и в случае слайсинга ещё на серверной части до клиента они уже не дойдут никогда.

Поэтому придерживаться базового протокола мне пока кажется более разумным, только вот с выгребанием по /u/m надо что-то решать. 12 айдишников на запрос — слишком мало, а многопоточность всё равно не решает проблему с кучей TCP-соединений и HTTP-метаданных.

w1w2Mv... . ОТВЕТИТЬ



\/ . ahamai to shaos @ Re: Полуневдимые эхи 25/10/24 06:17

> Например ZX Spectrum с сетевой карточкой Spectranet - у этого компа 48КБ ОЗУ только, но т.к. Spectranet использует бейсик (который в ПЗУ прошит в первых 16КБ) у которого есть свои переменные и ещё экран занимает 6912 байт ОЗУ т.е. под буфера останется 32КБ или даже меньше...

зачем тебе там список сообщений, если ты там и одно сообщение не отобразишь? :)

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

ps. блин, опять потерялся текст про спектрум в коробке из под обуви, интересно в какую эху я его запульнул в итоге... в рухуморе14 нет

namIvk... . ОТВЕТИТЬ





\/ . shaos to revoltech @ Re: Полуневдимые эхи 25/10/24 06:01

> Эх, лучше бы поддержали POST /u/m, тогда не пришлось бы по куче мелких запросов при перефетче делать.

это тоже можно

eIrJj4... . ОТВЕТИТЬ



\/ . shaos to ahamai @ Re: Полуневдимые эхи 25/10/24 05:59

> Вообще не понимаю, можно какой-то конкретный пример.

Например ZX Spectrum с сетевой карточкой Spectranet - у этого компа 48КБ ОЗУ только, но т.к. Spectranet использует бейсик (который в ПЗУ прошит в первых 16КБ) у которого есть свои переменные и ещё экран занимает 6912 байт ОЗУ т.е. под буфера останется 32КБ или даже меньше...

> у меня и постраничного вида нет

ну может у кого-то есть, ну или будет ;)

Azrimy... . ОТВЕТИТЬ



\/ . revoltech to shaos @ Re: Полуневдимые эхи 25/10/24 05:57

shaos> ну и GET /list.txt?h=1 заодно тоже можно поддержать ;)

Эх, лучше бы поддержали POST /u/m, тогда не пришлось бы по куче мелких запросов при перефетче делать.

А то тут предложили многопоточность, но я ориентируюсь в том числе и на одноядерное железо. И, конечно, вопроса оптимизации (а оптимизация ≠ скорость) многопоточность при выгребании сообщений не решает — всё равно при полном перефетче будет гоняться куча метаданных и создаваться куча TCP-соединений неизвестно с какой целью.

2p1RnD... . ОТВЕТИТЬ



\/ . shaos to ahamai @ Re: Полуневдимые эхи 25/10/24 05:30

да - хэш надёжнее, но действительно придётся хранить хеши для каждого узла

вобчем я наверное сделаю у себя вызов GET /x/h/echo.1/echo.2 по аналогии с GET /x/c/echo.1/echo.2

ну и GET /list.txt?h=1 заодно тоже можно поддержать ;)

====
idec.talks:1699:hsh/wHerzeypz8j1d8tviSRh
blcat.local:6:hsh/kAIYYMMc5DWK0FJhsW64
retro.talks:62:hsh/bahvlLwAzK2ArGHvXWat
bot.habr.rss:157:hsh/dwqigyrvKJQURxn88dwq
lor.opennet:127:hsh/12hqQwDfGoRXxD5ILIfj
ru.humor.14:817:hsh/4GxIyw2R69G75LlwnG0r
lor.gold:47:hsh/f4BQcuDnC7LTwzQHZ42k
linux.14:919:hsh/k8AiOJGrmMm1Q30W0Stz
====


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



\/ . shaos to ahamai @ Re: Полуневдимые эхи 25/10/24 05:22

Действительно:

====
a45cdfa3 (user            2014-04-01 19:19:03 +1100  9) @route('/list.txt')
a45cdfa3 (user            2014-04-01 19:19:03 +1100 10) def list_txt():
a45cdfa3 (user            2014-04-01 19:19:03 +1100 11)     response.set_header ('content-type','text/plain; charset=utf-8')
08c516db (user            2014-04-06 00:06:51 +1100 12)     lst = api.load_echo(False)[1:]
08c516db (user            2014-04-06 00:06:51 +1100 13)     if request.query.n:
08c516db (user            2014-04-06 00:06:51 +1100 14)         return '\n'.join([t[0] for t in lst])
08c516db (user            2014-04-06 00:06:51 +1100 15)     else:
08c516db (user            2014-04-06 00:06:51 +1100 16)         return '\n'.join(['%s:%s:%s' % t for t in lst])
08c516db (user            2014-04-06 00:06:51 +1100 17)
====


M36xgS... . ОТВЕТИТЬ





\/ . ahamai to shaos @ Re: Полуневдимые эхи 25/10/24 05:08

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

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



\/ . ahamai to shaos @ Re: Полуневдимые эхи 25/10/24 05:04

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

Вообще не понимаю, можно какой-то конкретный пример. Зачем брать кусками список? И мегабайт хэшей - это 49000 сообщений. Вообще не могу представить юзкейс.

> допустим надо взять последние 5 хешей из retro.talks:
> /u/e/retro.talks/-5:5
> в данном случае смещение отрицательное - значит считаем с конца ну и после двоеточия количество

я всё равно не могу понять, зачем это может быть нужно кроме юзкейса "запросить n последних сообщений". Я в слайсах не разбираюсь, там вечно массив 20 может быть или 19, или 20, или 21, у меня и постраничного вида нет, потому что у меня и реверс и разбирать это я с ума сойду. Вот это я сделать не смогу, мне слишком нудно разбираться. Достаточно было одного крайнего случая "н последних сообщений", это гораздо проще кодить и на клиенте, и на сервере. Мой lim прозрачен для вообще любых клиентов, какие существовали в истории, если кто-то не хочет тянуть 49000 файлов. А по факту в txt клиенте у меня уже ограничение на запрос только 100 последних мессаг. Средств для больших эх никогда не задумывалось потому что изначально, и это была часть концепции, не должно было быть больших эх.

> по идее "жобавляется" всегда в конец, а из середины только удаляется (блеклистается) и если брать частями, то наверное надо брать с перехлёстом на 1, чтобы точно ничего не удалилось на границах блоков пока ты их вычитываешь...

ну если бы я делал фетчер, я бы ещё штук 5 сверху проверял, на всякий случай. и раз в день полная проверка списка.

KqmUkC... . ОТВЕТИТЬ



\/ . ahamai to shaos @ Re: Полуневдимые эхи 25/10/24 04:57

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

bCUznG... . ОТВЕТИТЬ



\/ . shaos to iiii @ Re: Полуневдимые эхи 25/10/24 04:40

> при запросе /u/e/ с ключом ?sf=хэш он при запросе будет выдавать только хэши после указанного

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

Zk4mNN... . ОТВЕТИТЬ



\/ . shaos to iiii @ Re: Полуневдимые эхи 25/10/24 04:31

По идее хеши можно было бы в IDEC протокол добавить для GET /x/c/echo.1/echo.2 которое сейчас возвращает количество сообщений (видимо предполагалось, что сообщения никогда не удаляются). Кто-то вообще пользуется /x/c/... сейчас? Ну или завести новый вызов /x/h/... для возврата списка с хешами списков хешей...

90NVGj... . ОТВЕТИТЬ



\/ . shaos to iiii @ Re: Полуневдимые эхи 25/10/24 04:21

> я не знаю как запросить последние n сообщений

допустим надо взять последние 5 хешей из retro.talks:

/u/e/retro.talks/-5:5

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

> и я не понимаю, зачем мне запрашивать кусок эхи не до конца, а посредине.

например для ретроклиентов, которые по собственной ограниченности не могут принять многомегабайтный список хешей в один присест - идём кусочками от начала до конца

> Количество сообщений я считаю ненадёжным источником, можно удалить 1 и жобавить 1 и эха вроде не изменится.

по идее "жобавляется" всегда в конец, а из середины только удаляется (блеклистается) и если брать частями, то наверное надо брать с перехлёстом на 1, чтобы точно ничего не удалилось на границах блоков пока ты их вычитываешь...

aCdkdL... . ОТВЕТИТЬ





\/ . shaos to iiii @ Re: Полуневдимые эхи 25/10/24 04:08

> а что за расширение list.txt?

Видимо имелось ввиду что

GET /list.txt

появился только в IDEC - спецификация перечисляет это в расширениях

или оно в ранних версиях ii тоже было?

RHL8N4... . ОТВЕТИТЬ















\/ . iiii to shaos @ Re: Полуневдимые эхи 24/10/24 23:45

Я не понимаю, как это работает, я не знаю как запросить последние n сообщений и я не понимаю, зачем мне запрашивать кусок эхи не до конца, а посредине. Количество сообщений я считаю ненадёжным источником, можно удалить 1 и жобавить 1 и эха вроде не изменится. , в отличие от хэша. Я вообще при делании срезов не понимаю, что входит а что не входит. Поэтому у меня на станции нет постраничного вывода :)

А lim совместим со всем, хоть с ii txt 0.1, меняется только строка в конфиге.

FkvDFV... . ОТВЕТИТЬ





\/ . iiii to revoltech @ Re: Полуневдимые эхи 24/10/24 23:14

> Да вот не знаю, кстати, мне пока что только расширение с list.txt полезным показалось.

а что за расширение list.txt? не слышал. щас у себя посмотрел, el поддерживает ключи ?h=, ?n=, и ?el= :) сидел соображал. что к чему. не сообразил.

TezUbF... . ОТВЕТИТЬ



\/ . iiii to revoltech @ Re: Полуневдимые эхи 24/10/24 23:02

Расширения idec я не поддерживаю, но конкретно в моей реализации есть две минифичи, естественно это никакой не стандарт:

при запросе list.txt с ключом ?h=1, он вместо описаний эх показывает хэши файлов эх, чтобы можно было забирать только изменившиеся эхи.

при запросе /u/e/ с ключом ?sf=хэш он при запросе будет выдавать только хэши после указанного (если указанного в списке нет, выдаст все). но запрашивать так можно по одной эхе. это нигде и никогда не использовалась, но такая возможность в моей реализации есть, каждая заняла по 2 строчки кода в коде сервера, поэтому добавил.

ещё раньше была возможность задавать количество скачаного с помощью url, типа запрос /lim/200/u/e вместо /u/e отдавал только последние 200 хэшей из эхи - то есть, вообще не надо менять клиентский софт или фетчеры, просто менять строку в конфиге. в следующей версии nastene, когда я перепишу её на picnic, я её верну

zNxVGj... . ОТВЕТИТЬ



\/ . iiii to shaos @ Re: ловите теперь спам и набеги :) 24/10/24 22:55

А, это bosfor. С более развитым ip и прозрачным гейтом в ii, эхи там определялись не по точке, а по символу : спереди.

Не помню, был ли там список эх, но там была команда discover, показывающая все эхи на станции, скрытых эх нету. У меня, кстати, в gemini транслируются тоже все эхи, в том числе скрытые :)

ofLw6y... . ОТВЕТИТЬ



\/ . hugeping to shaos @ Re: Ответ на всё сразу 24/10/24 20:02

shaos> Фуф, а я уж думал выяснится, что Лобанов - квадробер :)

Так-так-так... С этого места поподробнее!

+++ отключает фетч с spline-online и настраивает iptables

x9ZKES... . ОТВЕТИТЬ





\/ . hugeping to revoltech @ Re: Полуневдимые эхи 24/10/24 14:08

revoltech> Так всё-таки есть стандартный и поддерживаемый вариант, чтобы полный перефетч эхи делался не кучей мелких запросов

Нет. Несколько потоков решают проблему быстрого фетча. А слайсы решают проблему больших индексов.

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





\/ . revoltech to shaos @ Re: Полуневдимые эхи 24/10/24 13:52

shaos> Это да :)

Так всё-таки есть стандартный и поддерживаемый вариант, чтобы полный перефетч эхи делался не кучей мелких запросов по 12 айдишников из-за ограничений хттпшного гета на сервере, а чем-то более вменяемым? Или нет? В доках ничего, кроме GET /u/m, по этому поводу не нарыл.

47WbOW... . ОТВЕТИТЬ



\/ . hugeping to revoltech @ Re: Полуневдимые эхи 24/10/24 13:54

revoltech> Длина ID сообщения — 21 байт (20 на сам ID и один на перевод строки). Это погоды не делает.

Почему не делает? Если каждые 5 минут делать фетч из эх, которые содержат по 10 тысяч сообщений, то как раз делает. Конечно, по современным меркам ~60мб в сутки на 10000 сообщений это вроде бы мелочи, но... Как-то меня такое не вдохновляет. Допустим, сообщений на ноде не 10тыс а 100тыс... Почему нет?

revoltech> В результате при фетче с нуля приходится разбивать каждый список на группы по 12 и выгребать сообщения отдельными запросами. А это не оптимально ни разу.

revoltech> Теперь понятнее?

Мне то понятнее, поэтому я и говорю - посмотри как сделано в ii-go. Там быстрый многопоточный фетчер.

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



\/ . revoltech to hugeping @ Re: Полуневдимые эхи 24/10/24 13:41

hugeping> Там есть полезная вещь, возможность забирать не все сообщения, а только часть. Например, последние n сообщений. Это позволяет делать фетчинг который не гоняет по интернету всегда полный индекс. Очень сильно снижает количество трафика.

Длина ID сообщения — 21 байт (20 на сам ID и один на перевод строки). Это погоды не делает. Определить, какие айдишники ещё не сфетчены, можно и на клиенте. Погоду делает то, что этих самых айдишников в GET /u/m можно поместить всего 12 штук, а дальше твой (вроде бы, не помню уже) нжинкс начнёт ругаться на слишком длинную строку запроса.

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

Теперь понятнее?

z1DKjB... . ОТВЕТИТЬ



\/ . revoltech to shaos @ Re: Полуневдимые эхи 24/10/24 13:37

shaos> При наличии групп эх наверное можно таки дать возможность пользователям (с высокой кармой?) создавать новые публичные эхи в группе unsorted - эдакий crowd sourcing получится, но по умолчанию такие эхи должны будут быть скрыты от веба (хоть и будут перечислены в list.txt)..,

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

FtFvcA... . ОТВЕТИТЬ



\/ . shaos to hugeping @ Re: Полуневдимые эхи 24/10/24 13:35

> Очень сильно снижает количество трафика.

Это да :)

TOP10 VISITORS:

[1] 145.224.100.x point=136 web=31 up=53.3MB (45%) <--- 145.224.100.x (6/hr)
[2] Google point=8 web=1298 up=20.8MB (17%) <--- Google
[3] 176.109.111.x point=48 web=0 up=16.8MB (14%) <--- tavern (2/hr)
[4] 217.197.116.x point=142 web=0 up=12.1MB (10%) <--- blackcat (6/hr)
[5] 92.63.98.x point=72 web=0 up=5.2MB (4%) <--- tgi (3/hr)
[6] 95.165.9.x point=145 web=4 up=3.3MB (2%) <--- ping (6/hr)
[7] 185.220.101.x point=4 web=0 up=1.0MB (<1%) <--- 185.220.101.x
[8] 24.130.121.x point=3 web=62 up=0.8MB (<1%) <--- spnet
[9] Facebook point=0 web=51 up=0.5MB (<1%)
[10] 179.43.159.x point=1 web=0 up=0.4MB (<1%) <--- 179.43.159.x

TOTAL TRAFFIC: 116MB

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



\/ . hugeping to revoltech @ Re: Полуневдимые эхи 24/10/24 13:18

shaos>> И кстати зачем родили IDEC если ii был такой уютненький и самодостаточный? ;)

revoltech> Да вот не знаю, кстати, мне пока что только расширение с list.txt полезным показалось.

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

qIm4tv... . ОТВЕТИТЬ



\/ . shaos to Andrew Lobanov @ Re: Полуневдимые эхи 24/10/24 13:03

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

Ну например можно выкинуть «вообще вредный» код файлэх, который сейчас чуть ли не половину всего кода ii-php занимает :)

GHtyya... . ОТВЕТИТЬ



\/ . shaos to Reprise @ Re: Полуневдимые эхи 24/10/24 12:55

Ну это издевательство над здравым смыслом когда одной рукой вы разрешаете декларировать поддерживаемые фичи через features, а другой запрещаете эти фичи расширять…

pQftmi... . ОТВЕТИТЬ







\/ . shaos to doesnm @ Re: Полуневдимые эхи 24/10/24 12:49

Это был риторический вопрос :)

Всё в этом мире должно развиваться и обрастать фичами ;)

Благо IDEC позволяет декларировать расширения узла через публичный список фич…

AILSMi... . ОТВЕТИТЬ



\/ . Reprise to shaos @ Re: Полуневдимые эхи 24/10/24 12:26

shaos> И кстати зачем родили IDEC если ii был такой уютненький и самодостаточный? ;)

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

+++ Caesium/0.4 RC1

X6WhBL... . ОТВЕТИТЬ



\/ . Reprise to shaos @ Re: Полуневдимые эхи 24/10/24 12:26

shaos> Ну phpbb у меня есть с 2003 года :)
shaos> http://forum.nedopc.org
shaos> И оно сугубо централизованное, а мне нужно распределённое и многоузловое….
shaos> И потом не надо культивировать мнение, что IDEC такойr простой - он уже не такой простой как ii…

То, что он чуть сложнее ii, не значит, что нужно делать из него монстра с непонятными с точки зрения юзабилити фичами.

+++ Caesium/0.4 RC1

D8bkzP... . ОТВЕТИТЬ



\/ . Reprise to tuple @ Re: Ответ на всё сразу 24/10/24 12:26

tuple> Приветствуем!
>> (и спасибо за такой тёплый, хоть и, хм, своеобразный приём)
tuple> Раз уж вы любитель тора, анонимности и подобного, то должны понимать, что данные технологии привлекают не только энтузиастов, но и вредителей, которых привлекает политическая позиция держателя таверны.

Интересно было бы услышать какая у меня политическая позиция :)

+++ Caesium/0.4 RC1

aHjPNw... . ОТВЕТИТЬ



\/ . shaos to revoltech @ Re: Полуневдимые эхи 24/10/24 12:44

При наличии групп эх наверное можно таки дать возможность пользователям (с высокой кармой?) создавать новые публичные эхи в группе unsorted - эдакий crowd sourcing получится, но по умолчанию такие эхи должны будут быть скрыты от веба (хоть и будут перечислены в list.txt)..,

QB5IzB... . ОТВЕТИТЬ



\/ . revoltech to shaos @ Re: Полуневдимые эхи 24/10/24 12:18

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

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

jd7jrs... . ОТВЕТИТЬ



\/ . shaos to Andrew Lobanov @ Re: Полуневдимые эхи 24/10/24 12:17

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

hWeoLL... . ОТВЕТИТЬ



\/ . shaos to revoltech @ Re: Полуневдимые эхи 24/10/24 12:11

Надо будет фичу выпилить ;)

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

Ну и чисто административный момент - даже если сисоп временно потерял физический доступ к узлу (уехал в отпуск) у него должна оставаться возможность видеть что там происходит пользуясь открытыми апи (напрямую либо через ботов)…

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



\/ . revoltech to shaos @ Re: Полуневдимые эхи 24/10/24 12:07

shaos> И кстати зачем родили IDEC если ii был такой уютненький и самодостаточный? ;)

Да вот не знаю, кстати, мне пока что только расширение с list.txt полезным показалось.

zsnW8A... . ОТВЕТИТЬ





\/ . doesnm to shaos @ Re: Полуневдимые эхи 24/10/24 12:09

shaos> Да не маленький он уже…
shaos> И кстати зачем родили IDEC если ii был такой уютненький и самодостаточный? ;)

А кто заставляет вас его использовать? ii и IDEC полностью совместимы
Хотя бесполезного трафика станет больше
Да и можно ли сравнить ii/IDEC с SMTP? Тоже простой протокол, но пришлось навешать кучу костылей начиная от авторизации и заканчивая всякими DKIM/DMARC/SPF

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

I4893Z... . ОТВЕТИТЬ





shaos to Andrew Lobanov @ Re: Полуневдимые эхи 24/10/24 11:49

Ну phpbb у меня есть с 2003 года :)

http://forum.nedopc.org

И оно сугубо централизованное, а мне нужно распределённое и многоузловое….

И потом не надо культивировать мнение, что IDEC такойr простой - он уже не такой простой как ii…

ls77RJ... . ОТВЕТИТЬ


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