разговоры про технологию nn/ii, idec






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

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

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



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

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

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

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



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

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

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

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

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



\/ . 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... . ОТВЕТИТЬ



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

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

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

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



\/ . 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: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... . ОТВЕТИТЬ





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

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

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

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





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

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

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

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

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



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

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

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

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



\/ . 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 revoltech @ Re: Полуневдимые эхи 24/10/24 23:14

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

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

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



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

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

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

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















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

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

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

GET /list.txt

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

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

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



\/ . 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:31

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

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



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

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

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

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





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

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

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



\/ . 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... . ОТВЕТИТЬ



\/ . 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... . ОТВЕТИТЬ



\/ . 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 05:08

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

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





\/ . 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:59

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

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

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

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

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



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

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

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

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





\/ . 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... . ОТВЕТИТЬ



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

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

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

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

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



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

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

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

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

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

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



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



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

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

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

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

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







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

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

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

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



\/ . 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... . ОТВЕТИТЬ







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

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

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









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

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

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

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

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





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

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

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

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

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

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

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

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











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

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

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

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











\/ . 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... . ОТВЕТИТЬ



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

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

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

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



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

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

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

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



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

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

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

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



\/ . 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... . ОТВЕТИТЬ



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

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

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

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

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



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

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

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

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



\/ . 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... . ОТВЕТИТЬ





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

ahamai> Ну и есть всякие плюшки типа минимальной гарантии доставки

А TCP для чего вообще создавался, если не для минимальной гарантии доставки? Зачем дублировать то же самое на уровень выше, но с обязательными метаданными?

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

Мысль понял, никого не заставляю, но nc и awk имеются и в busybox (как, впрочем, и декодер base64).

udAO2u... . ОТВЕТИТЬ



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

ahamai> увеличил буферы в nginx. скормил url на 89 кбайт - сожрало

Так и оставил? Я могу быть уверенным, что выгребу 4238 сообщений за один запрос?

YxUZjS... . ОТВЕТИТЬ



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

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

Можно. Но вред файлэх в чём? Вред твоей идеи понятен -- ты хочешь ограничивать своих пользователей в фичах и свободе общения.

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

knVHGT... . ОТВЕТИТЬ



\/ . Andrew Lobanov to revoltech @ Re: Ответ на всё сразу 25/10/24 10:58

>> Точно был способ в документации. Посмотрите подробней.
revoltech> Да уже всё перерыл, никак не нахожу, как именно клиентом выкачать все сообщения из указанных в /u/e за один HTTP-запрос.
revoltech> Так-то у меня и так выкачиваются только те сообщения, ID которых ещё нет в базе. Но проблемы с ограничением длины GET-строки на сервере это не решает.
revoltech> Самым очевидным решением было бы, наверное, разрешить ещё и HTTP POST /u/m с тем же синтаксисом.

У тебя трафик платный и тарифицируется по количеству HTTP-запросов?

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

yqov1V... . ОТВЕТИТЬ



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

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

Никуда не девается эта возможность. Скрытые эхи работают точно так же, как и те, что в list.txt.

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

Навернуть расширение для себя было бы лучше, чем ломать удобные фичи.

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

zHZr4j... . ОТВЕТИТЬ



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

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

Опять какие-то костыли :)

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

sX2EfA... . ОТВЕТИТЬ



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

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

Вот. Товарищ дело говорит!

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

ChsQAH... . ОТВЕТИТЬ



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

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

Божечки! Уже и карма. Куда катецо федо!

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

y9Vvf2... . ОТВЕТИТЬ



\/ . Andrew Lobanov to shaos @ Re: Ответ на всё сразу 25/10/24 10:59

shaos> А может не будем про политику?…

Ну раз уж начали, то давайте. Чего уж там?

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

k7wvAo... . ОТВЕТИТЬ



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

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

Я ничего никому не запрещаю и не разрешаю. Просто считаю отламывание фундаментальных фич вредительством.

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

YkdBsW... . ОТВЕТИТЬ



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

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

Потому что только GET и есть.

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

rAmepS... . ОТВЕТИТЬ



\/ . Andrew Lobanov to shaos @ Re: Ответ на всё сразу 25/10/24 10:59

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

Я сам думал уже кто же я. Квадробер, зацепер, видеоблоггер или, извиняюсь, рэпер. Но пронесло :)

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

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



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

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

====
/u/e/idec.talks/-100:100
====



заберёт последние 100 сообщений.

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

При этом будет работать и /lim/200/u/m и /lim/200/u/point?

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

vQTtqx... . ОТВЕТИТЬ



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

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

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

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



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

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

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

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

[forwarded from idec.test]

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





\/ . 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 Re: Мея видо? @ shaos 23/10/24 10:24

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

[forwarded from idec.test]

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




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 32