subject: Дополнения к стандарту
31.10.2024 08:14
revoltech (spnet, 4)
Предлагаю ввести общий слайсинг вида «ключ-значение», в котором вместо диапазона можно писать all или же msgid (в таком случае берётся содержимое эхо от него):
/u/e/echo.1/all/echo.2/some_msgid_blablabla/echo.3/-10:10
А ещё предлагаю ввести /u/mc, возвращающий число, чтобы клиент знал максимум сообщений, который нода может ему отдать за один GET-запрос /u/m.
--------------------------------------------------------------------------------
subject: Re: Дополнения к стандарту
31.10.2024 08:45
shaos (spnet, 2) => KmXTgt056WiPcGcdA9Mv
ну разве что если /x/e/...
--------------------------------------------------------------------------------
subject: Re: Дополнения к стандарту
31.10.2024 08:48
revoltech (spnet, 4) => H6OS1X5CMS9IAQOqsXMM
shaos> ну разве что если /x/e/...
Да пофигу, раз упростить алгоритмически всё равно ничего не получится, пусть будет так, как есть. Меня больше про /u/mc вопрос интересует.
--------------------------------------------------------------------------------
subject: Re: Дополнения к стандарту
31.10.2024 08:57
shaos (spnet, 2) => EeLfzfGKPa1LEAR3Nzbj
насколько длинный урл можно скормить вебсерверу это настройка вебсервера - сама нода может про это и не знать
--------------------------------------------------------------------------------
subject: Re: Дополнения к стандарту
31.10.2024 09:05
revoltech (spnet, 4) => EOo7DNnSghOYnQFqA38u
shaos> насколько длинный урл можно скормить вебсерверу это настройка вебсервера - сама нода может про это и не знать
Но её админ должен об этом знать. И выставить в урлу /u/mc. Иначе при перефетче придётся брутфорсить на стороне клиента: ага, 10000 айдишников — отлуп, 1000 айдишников — отлуп, 500 — отлуп, 389 — норм... Запишем, что в этой станции 389.
--------------------------------------------------------------------------------
subject: Re: Дополнения к стандарту
31.10.2024 09:12
shaos (spnet, 2) => QRaXIYzOJS7IuWzfZST8
> Но её админ должен об этом знать.
Ну я например не знал пока не загуглил :)
Потом пришлось свой анализатор логов переписывать, чтобы строки длинне 8К принимал ;)
--------------------------------------------------------------------------------
subject: Re: Дополнения к стандарту
31.10.2024 10:52
Andrew Lobanov (tavern,1) => KmXTgt056WiPcGcdA9Mv
revoltech> Предлагаю ввести общий слайсинг вида «ключ-значение», в котором вместо диапазона можно писать all или же msgid (в таком случае берётся содержимое эхо от него):
revoltech> /u/e/echo.1/all/echo.2/some_msgid_blablabla/echo.3/-10:10
Зачем? Усложнение ради усложнения? Так IDEC не про это, а про дубовую простоту.
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
--------------------------------------------------------------------------------
subject: Re: Дополнения к стандарту
31.10.2024 10:52
Andrew Lobanov (tavern,1) => EeLfzfGKPa1LEAR3Nzbj
shaos>> ну разве что если /x/e/...
revoltech> Да пофигу, раз упростить алгоритмически всё равно ничего не получится, пусть будет так, как есть. Меня больше про /u/mc вопрос интересует.
Не вижу в нём смысла.
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
--------------------------------------------------------------------------------
subject: Re: Дополнения к стандарту
31.10.2024 10:52
Andrew Lobanov (tavern,1) => QRaXIYzOJS7IuWzfZST8
shaos>> насколько длинный урл можно скормить вебсерверу это настройка вебсервера - сама нода может про это и не знать
revoltech> Но её админ должен об этом знать. И выставить в урлу /u/mc. Иначе при перефетче придётся брутфорсить на стороне клиента: ага, 10000 айдишников — отлуп, 1000 айдишников — отлуп, 500 — отлуп, 389 — норм... Запишем, что в этой станции 389.
А зачем?
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
--------------------------------------------------------------------------------
subject: Re: Дополнения к стандарту
31.10.2024 10:40
hugeping (ping,1) => KmXTgt056WiPcGcdA9Mv
Я тут несколько дней сдерживаюсь. К тому же, довольно сильно приболел.
Но сдерживаться мне всё тяжелее конечно...
Понимаю, что меня не воспримут, всё-таки напишу.
Подумайте, что за задачи вы решаете?
Например, в данном случае, в один запрос запиханы разные лимиты слайсов для разных эх. Зачем?
Видимо, предполагается что "умный" админ будет настраивать фетч таким образом под станцию, что задаст разные лимиты для эх разной наполненности? Зачем этот ужас? Придумайте, как в реальности вы будете это использовать?
Потом, Рома трясёт своим ?sf=hash - как замену слайсов. На самом деле этот sf=hash при своей красоте, всё-таки, хуже слайсов. Во первых, даже с хешем надо делать запрос внахлёст с запасом (не забываем про то, что порядок сообщений на ноде может не совпадать с нашим) и нам все равно придётся самим на своей станции находить n сообщение от конца в эхе и брать затем его хеш чтобы сформировать запрос. Те же слайсы, вид сбоку. Ну и во-вторых, sf решает одну конкретную задачу, а слайсы - универсальны. Слайсы делают возможным адаптивный фетч и онлайн просмотр.
Потом постоянные намёки на то, что нам нужно обязательно забрать всё одним запросом. Причём, неявно подразумевается что это благая цель которую все разделяют... ЗАЧЕМ?? У меня фетчер вообще забирает по 12 кажется msgid за раз, но он, наверное, самый быстрый из всех реализаций что я видел. Можете скачать ii-go и сделать полное клонирование моей станции и написать, сколько это заняло времени.
Про ограничение на запрос. В лучшем случае в стандарт можно добавить рекомендацию про 8кб "стандарт" запроса, который в большинстве случаев совпадает с фактическим положением дел. Но расширение, которое будет показывать этот параметр, который вообще говоря доступен только веб серверу? Сами же простоту и элегантность хотите, нет? По 16 msgid забирать чистоплюство не позволяет? Значит, страдайте! :)
В общем, попытки решить какие-то несуществующие проблемы и навязать какие-то свои оценки. Чего я боялся, то и происходит. Лебедь рак и щука.
Моё мнение -- надо замораживать вариант драфта Андрея. А дальше, пилить альтернативный стандарт - если он будет хорош - ну значит его поддержит. Кто-то. Но в таком хаосе и горячке я точно не участник. Мне не нравится русло в которое все свернуло. Но это - неизбежно. Поэтому коммьюнити не будет. Никогда.
--------------------------------------------------------------------------------
subject: Re: Дополнения к стандарту
31.10.2024 11:58
revoltech (spnet, 4) => Fz6ja06beCxp4N9AHShl
AL> Не вижу в нём смысла.
Как клиенту понять, сколько сообщений максимум можно забрать за один запрос?
--------------------------------------------------------------------------------
subject: Re: Дополнения к стандарту
31.10.2024 12:02
revoltech (spnet, 4) => NkzCRBAI4IOPrMnQNeGD
AL> Зачем? Усложнение ради усложнения? Так IDEC не про это, а про дубовую простоту.
Это как раз и было бы про дубовую простоту парсинга. Ключ-значение. Всё однозначно.
--------------------------------------------------------------------------------
subject: Re: Дополнения к стандарту
31.10.2024 12:09
revoltech (spnet, 4) => cUfxPLrLrjY9xxrVKPAb
hugeping> Например, в данном случае, в один запрос запиханы разные лимиты слайсов для разных эх. Зачем?
Чтобы не качать лишнее.
hugeping> Видимо, предполагается что "умный" админ будет настраивать фетч таким образом под станцию, что задаст разные лимиты для эх разной наполненности? Зачем этот ужас? Придумайте, как в реальности вы будете это использовать?
В реальности — точно так же, как и твой адаптивный фетч сейчас это делает, только без необходимости предварительно мурыжить каждую эху отдельно.
hugeping> По 16 msgid забирать чистоплюство не позволяет?
Накладные расходы не позволяют. Когда станция тормозит, это особо заметно.
Сейчас у меня в stations.txt напротив каждой ноды стоит число. Если непонятно, сколько сообщений нода позволяет забрать за раз, ставлю 12, ибо это случай с tgi и его ограничением 256 символов на гет. Андрей не озвучивал ограничение spline-online, поэтому там тоже стоит 12, и делать полный перефетч — это боль с такой-то скоростью отдачи. А бывает, что надо. Например, когда я внутренний формат базы поменял, добавив поле.
hugeping> Моё мнение -- надо замораживать вариант драфта Андрея.
Я-то не против, просто предлагаю вещи, которые облегчат жизнь, пока не поздно.
--------------------------------------------------------------------------------
subject: Re: Дополнения к стандарту
31.10.2024 13:43
Andrew Lobanov (tavern,1) => EzYy42f4YaA48cZTsl8q
AL>> Не вижу в нём смысла.
revoltech> Как клиенту понять, сколько сообщений максимум можно забрать за один запрос?
Зачем ему это понимать?
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
--------------------------------------------------------------------------------
subject: Re: Дополнения к стандарту
31.10.2024 13:43
Andrew Lobanov (tavern,1) => 6pksCiWX1RJhIuuPsbhb
AL>> Зачем? Усложнение ради усложнения? Так IDEC не про это, а про дубовую простоту.
revoltech> Это как раз и было бы про дубовую простоту парсинга. Ключ-значение. Всё однозначно.
Тут слайс, тут волшебное слово, тут хэш. Сиди, разбирай.
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
--------------------------------------------------------------------------------
subject: Re: Дополнения к стандарту
31.10.2024 13:43
Andrew Lobanov (tavern,1) => cUfxPLrLrjY9xxrVKPAb
hugeping> Я тут несколько дней сдерживаюсь. К тому же, довольно сильно приболел.
hugeping> Но сдерживаться мне всё тяжелее конечно...
hugeping> Понимаю, что меня не воспримут, всё-таки напишу.
hugeping> Подумайте, что за задачи вы решаете?
[skipped]
Подписываюсь под каждым словом.
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
--------------------------------------------------------------------------------
subject: Re: Дополнения к стандарту
31.10.2024 13:43
Andrew Lobanov (tavern,1) => wlQOMGtJlSURcKLpSNFF
hugeping>> Например, в данном случае, в один запрос запиханы разные лимиты слайсов для разных эх. Зачем?
revoltech> Чтобы не качать лишнее.
Чтобы что?
hugeping>> Видимо, предполагается что "умный" админ будет настраивать фетч таким образом под станцию, что задаст разные лимиты для эх разной наполненности? Зачем этот ужас? Придумайте, как в реальности вы будете это использовать?
revoltech> В реальности — точно так же, как и твой адаптивный фетч сейчас это делает, только без необходимости предварительно мурыжить каждую эху отдельно.
Лучше мурыжить все эхи пока все слайсы не уляжутся. И этот человек говорит мне о том, чтобы не качать лишнего. Будь последователен.
hugeping>> По 16 msgid забирать чистоплюство не позволяет?
revoltech> Накладные расходы не позволяют. Когда станция тормозит, это особо заметно.
revoltech> Сейчас у меня в stations.txt напротив каждой ноды стоит число. Если непонятно, сколько сообщений нода позволяет забрать за раз, ставлю 12, ибо это случай с tgi и его ограничением 256 символов на гет. Андрей не озвучивал ограничение spline-online, поэтому там тоже стоит 12, и делать полный перефетч — это боль с такой-то скоростью отдачи. А бывает, что надо. Например, когда я внутренний формат базы поменял, добавив поле.
hugeping>> Моё мнение -- надо замораживать вариант драфта Андрея.
revoltech> Я-то не против, просто предлагаю вещи, которые облегчат жизнь, пока не поздно.
Они ни облегчат, ни усложнят жизнь. Просто придётся делать бесполезную работу.
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
--------------------------------------------------------------------------------
subject: Re: Дополнения к стандарту
31.10.2024 13:53
revoltech (spnet, 4) => mqIfbEyfpxXgnyjraVqk
AL> Зачем ему это понимать?
Да блин. Моделируем ситуацию. Клиент пришёл в сеть. Без готовой базы сообщений, без ничего. Выкачивает список эх по /list.txt. Выкачивает по /u/e/[список_эх] айдишники сообщений. Их овердофига. Дальше как ему знать, по сколько айдишников группировать для посыла одного GET /u/m, если ни станция, ни стандарт об этом ничего не говорят? Он может сгруппировать по 16 и получить ошибку на tgi, каковы дальнейшие действия?
--------------------------------------------------------------------------------
subject: Re: Дополнения к стандарту
31.10.2024 14:26
Andrew Lobanov (tavern,1) => 9RYLX6uLoKfccZ0nh45I
AL>> Зачем ему это понимать?
revoltech> Да блин. Моделируем ситуацию. Клиент пришёл в сеть. Без готовой базы сообщений, без ничего. Выкачивает список эх по /list.txt. Выкачивает по /u/e/[список_эх] айдишники сообщений. Их овердофига. Дальше как ему знать, по сколько айдишников группировать для посыла одного GET /u/m, если ни станция, ни стандарт об этом ничего не говорят? Он может сгруппировать по 16 и получить ошибку на tgi, каковы дальнейшие действия?
Пинать сисопа своего аплинка. Потому что такие короткие урлы это издевательство.
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
--------------------------------------------------------------------------------
subject: Re: Дополнения к стандарту
31.10.2024 14:34
hugeping (ping,1) => 9RYLX6uLoKfccZ0nh45I
AL>> Зачем ему это понимать?
revoltech> Он может сгруппировать по 16 и получить ошибку на tgi, каковы дальнейшие действия?
Варианты:
1) tgstation считать аномалией и написать админу, чтобы он сделал "стандартные 8k" как рекомендовано в RFC: https://www.rfc-editor.org/rfc/rfc9110.html#section-4.1
It is RECOMMENDED that all senders and recipients support, at a minimum, URIs with lengths of 8000 octets in protocol elements.
2) Увидев это, задать параметр поменьше для фетча конкретно с tgi и оставить
3) Расширить станд.... ^W тьфу! :)
--------------------------------------------------------------------------------
subject: Re: Дополнения к стандарту
31.10.2024 14:37
tuple (ping,54) => kraoFGkG7nssWkalMFZ3
hugeping> tgstation считать аномалией
tgi же неоднократно просил считать владелец станцией экспериментов и не фетчиться с неё.
--------------------------------------------------------------------------------
subject: Re: Дополнения к стандарту
31.10.2024 15:03
revoltech (spnet, 4) => EDAPZhHKKwXmiihtlySH
AL> Пинать сисопа своего аплинка. Потому что такие короткие урлы это издевательство.
Хорошо. Какие — не издевательство? Сколько айдишников скачивать по умолчанию? Где проходит граница между «слишком жирно» и «пора пинать сисопа»?
Может, в стандарте хотя бы рекомендованное число указать в таком случае? Опытным путём вот выяснилось, что апачу 389 айдишников можно скормить в /u/m на дефолтных настройках. А на spline-online сколько, например?
--------------------------------------------------------------------------------
subject: Re: Дополнения к стандарту
31.10.2024 15:06
revoltech (spnet, 4) => kraoFGkG7nssWkalMFZ3
hugeping> It is RECOMMENDED that all senders and recipients support, at a minimum, URIs with lengths of 8000 octets in protocol elements.
Так, может, тогда и в стандарте прописать |(8000 - 5) / 21| = 380 айдишников рекомендованным максимумом для отдачи через /u/m?
--------------------------------------------------------------------------------
subject: Re: Дополнения к стандарту
31.10.2024 15:25
hugeping (ping,1) => cu5eKYo7Z1AuiTednoVJ
hugeping>> It is RECOMMENDED that all senders and recipients support, at a minimum, URIs with lengths of 8000 octets in protocol elements.
revoltech> Так, может, тогда и в стандарте прописать |(8000 - 5) / 21| = 380 айдишников рекомендованным максимумом для отдачи через /u/m?
Всё-таки, это не аксиома. Тут мы зависим от внешнего фактора. Так что я бы написал что-то вроде:
> При составных запросах следует учесть возможные ограничения сервера на максимальную длину. Поэтому в общем случае запросы следует разбивать на части ... итд
Главная мысль в том, что фетчер всё равно должен содержать в себе логику разбивки на запросы. А размер "пачки" -- дело второе. Я бы вообще > 16 или 32 не ставил бы никогда.
--------------------------------------------------------------------------------
subject: Re: Дополнения к стандарту
31.10.2024 15:39
revoltech (spnet, 4) => zwsHtRm37r9hyAeS4AQ9
hugeping> Всё-таки, это не аксиома. Тут мы зависим от внешнего фактора.
Не аксиома, но вполне разумное значение по умолчанию. Сисопа проще пнуть на документальном уровне и пусть объясняет, почему приём 380 айдишников в /u/m для него проблема.
hugeping> Я бы вообще > 16 или 32 не ставил бы никогда.
Ну вот для случая полного перефетча это как раз издевательство, но пусть, лишь бы нода и 380 поддерживала.
--------------------------------------------------------------------------------
subject: Re: Дополнения к стандарту
31.10.2024 15:53
hugeping (ping,1) => DhnvGPj4r6PyCTMrosg4
revoltech> Ну вот для случая полного перефетча это как раз издевательство, но пусть, лишь бы нода и 380 поддерживала.
Ну там выше tuple скинул сколько полный фетч занимает времени с моей станции. А ты видел на чём она работает? ;) И сколько там в одном запросе? Так что я по прежнему не вижу проблем. Но раз кому-то очень важно, чтобы в одном запросе шло 380 сообщений, ну пусть так. Но в стандарте я бы явно не фиксировал эти числа. Написал бы про общую проблему.
--------------------------------------------------------------------------------
subject: Re: Дополнения к стандарту
31.10.2024 19:46
shaos (spnet, 2) => HVKFdLZdlcoU3v2VUnAH
> tgi же неоднократно просил считать владелец станцией экспериментов и не фетчиться с неё.
Ну может кого и просил, но мы с ним в сентябре 2022 года по е-мейлу договорились взаимно фетчить idec.talks и zx.spectrum, а потом я ещё bot.habr.rss у него начал забирать.
--------------------------------------------------------------------------------
subject: Re: Дополнения к стандарту
31.10.2024 19:48
shaos (spnet, 2) => cu5eKYo7Z1AuiTednoVJ
Лучше написать не больше 380 т.к. вебсервер может такое не пережувать
И наверное надо метод POST добавить (я у себя добавлю)
--------------------------------------------------------------------------------
subject: Re: Дополнения к стандарту
31.10.2024 19:49
shaos (spnet, 2) => zwsHtRm37r9hyAeS4AQ9
Рекомендовать 32, но указать, что некоторые вебсервера могу принять до 380
--------------------------------------------------------------------------------
subject: Re: Дополнения к стандарту
31.10.2024 19:52
revoltech (spnet, 4) => Ta2K7mWp2CRuCyVlACVn
shaos> Лучше написать не больше 380 т.к. вебсервер может такое не пережувать
Ну я о том же, можно сказать, что 380 — максимум, который нужно поддерживать, а дальше уже на усмотрение владельца сервера.
shaos> И наверное надо метод POST добавить (я у себя добавлю)
Только за, но здесь почему-то нашлись принципиальные противники этой идеи.
--------------------------------------------------------------------------------
subject: Re: Дополнения к стандарту
31.10.2024 20:03
shaos (spnet, 2) => C6vnAGTkszxVzv9iqkQT
Рекомендовать 32 т.к. оно вообще не через http-сервер может идти, а через самописный (кстати bottle.py какое ограничение имеет?)
--------------------------------------------------------------------------------
subject: Re: Дополнения к стандарту
31.10.2024 20:05
revoltech (spnet, 4) => K8ShhPqB8mkwNl3y6H1i
shaos> Рекомендовать 32 т.к. оно вообще не через http-сервер может идти, а через самописный (кстати bottle.py какое ограничение имеет?)
Да у самописных вообще ограничений нет обычно.
--------------------------------------------------------------------------------
subject: Re: Дополнения к стандарту
31.10.2024 21:18
shaos (spnet, 2) => mckFZren6i0W8jQYI8el
Ну это как написать…
--------------------------------------------------------------------------------
subject: Re: Дополнения к стандарту
31.10.2024 21:26
ahamai (blackcat, 2) => AoMnqcRftBI2A64vTJLg
Большие запросы вообще не нужны. Во-первых, они не нужны в принципе, я вообще не вижу разницы между запросами по 10 и по 40 сообщений, я и так и так легко выкачиваю всю сеть. Во-вторых, это ставит колом однопоточные серверы. Я бы запросы более 40 мессаг за раз расценивал бы как XAB.
--------------------------------------------------------------------------------
subject: Re: Дополнения к стандарту
31.10.2024 21:36
Andrew Lobanov (tavern,1) => Fi3iApXWCHvOD7VhCCeR
AL>> Пинать сисопа своего аплинка. Потому что такие короткие урлы это издевательство.
revoltech> Хорошо. Какие — не издевательство? Сколько айдишников скачивать по умолчанию? Где проходит граница между «слишком жирно» и «пора пинать сисопа»?
10+ лет качаем по 40. Полёт нормальный. Зачем выдумывать себе трудности? Чтобы героически их преодолевать?
revoltech> Может, в стандарте хотя бы рекомендованное число указать в таком случае? Опытным путём вот выяснилось, что апачу 389 айдишников можно скормить в /u/m на дефолтных настройках. А на spline-online сколько, например?
Настройки веб-сервера выходят за рамки стандарта.
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
--------------------------------------------------------------------------------
subject: Re: Дополнения к стандарту
31.10.2024 21:36
Andrew Lobanov (tavern,1) => cu5eKYo7Z1AuiTednoVJ
hugeping>> It is RECOMMENDED that all senders and recipients support, at a minimum, URIs with lengths of 8000 octets in protocol elements.
revoltech> Так, может, тогда и в стандарте прописать |(8000 - 5) / 21| = 380 айдишников рекомендованным максимумом для отдачи через /u/m?
Это уже прописано в стандарте. Только почему это должно быть прописано в стандарте IDEC?
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
--------------------------------------------------------------------------------
subject: Re: Дополнения к стандарту
31.10.2024 21:36
Andrew Lobanov (tavern,1) => DhnvGPj4r6PyCTMrosg4
hugeping>> Всё-таки, это не аксиома. Тут мы зависим от внешнего фактора.
revoltech> Не аксиома, но вполне разумное значение по умолчанию. Сисопа проще пнуть на документальном уровне и пусть объясняет, почему приём 380 айдишников в /u/m для него проблема.
Хорошо. Я укажу в стандарте 40. Все, кто качает больше или предоставляют меньше, не соблюдают стандарт.
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
--------------------------------------------------------------------------------
subject: Re: Дополнения к стандарту
31.10.2024 21:38
Andrew Lobanov (tavern,1) => AoMnqcRftBI2A64vTJLg
shaos>> И наверное надо метод POST добавить (я у себя добавлю)
revoltech> Только за, но здесь почему-то нашлись принципиальные противники этой идеи.
Эта идея решает примерно - проблем. Так зачем?
Могу добавить, оставив упоминание про потолок в 40 айдишников на запрос.
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
--------------------------------------------------------------------------------
subject: Re: Дополнения к стандарту
31.10.2024 21:59
ahamai (blackcat, 2) => cUfxPLrLrjY9xxrVKPAb
> Например, в данном случае, в один запрос запиханы разные лимиты слайсов для разных эх. Зачем?
Так это была изначальная идея - для экономии трафика. я всегда думал, что оно именно так и сделано, там 100 rss сообщений за час их и забрали, там 1 за неделю. а так это какая-то полумера, ни туда ни сюда.
> Потом, Рома трясёт своим ?sf=hash - как замену слайсов.
Приехали. Я не использую ?sf. Я не собираюсь использовать ?sf. Оно создано ровно для одного случая, работы в условиях медленного интернета. Для чего, как заявлялось, и делался idec. И, в отличие от idec, он делает ровно то, что от него просят, даёт одним запросом ровно то, что нужно, минимальный объём сообщений.
> На самом деле этот sf=hash при своей красоте, всё-таки, хуже слайсов. Во первых, даже с хешем надо делать запрос внахлёст с запасом (не забываем про то, что порядок сообщений на ноде может не совпадать с нашим)
Не надо так делать. В 99% случаев запрос вернёт ровно то, что от него хотят. В остальных случаях, скорее всего, поможет только полный фетч.
> и нам все равно придётся самим на своей станции находить n сообщение от конца в эхе и брать затем его хеш чтобы сформировать запрос. Те же слайсы, вид сбоку.
Только все эхи опрашиваются одним запросом, и с нужным количеством сообщений.
> Ну и во-вторых, sf решает одну конкретную задачу, а слайсы - универсальны. Слайсы делают возможным адаптивный фетч и онлайн просмотр.
То, что называется слайсы, у меня называется lim. Сделано одной строчкой кода. Совместимо вообще со всем, не ломает /u/e/, и даже клиенты, которые понятия не имеют о lim, могут им пользоваться.
Адаптивный фетчинг это оверинжиниринг, программирование ради программирования, он вообще не даёт гарантий, в станциях где нет формальных эх а сортировка идёт по timestamp, могут быть вкинуты старые сообщения и такой фетчинг их не увидит. В нормальных условиях я вообще не вижу проблем гонять полные эхи, ибо только они дают полную гарантию. Для экономии трафка можно использовать ?h, его использование в гейтовании с shaos сократило дневной трафик с 12 мб до 2.
> В общем, попытки решить какие-то несуществующие проблемы и навязать какие-то свои оценки. Чего я боялся, то и происходит. Лебедь рак и щука.
Проблема была в проектировании. Некорректном дизайне. В сломе того, что просто работало и было простым, как три копейки, ради решения несуществующих проблем и каких-то непонятных смен стандарта, которые ничего не дают, кроме экономии трафика, которой тоже нет, потому что у тебя либо постоянные новые запросы, новые коннекции, новые строчки в логе сервера и так далее, да там tcp фреймы больше сожрут чем трафика сэкономится :)
Забавно, я посмотрел архив старых эх - я постоянно из протокола что-то выкидывал, пока не остались /e /m /u/e /u/m, и всё это не достигло предельной простоты. А щас только что-то добавляют. Да сколько угодно. Но не надо лезть в /u/e. Это база из баз, фейлбек из фейлбеков, он должен быть простым, примитивным, кодиться за три строчки кода на любом языке и быть единой везде. Расширяйте как хотите, но расширяйте отдельные методы, без x/feaures и прочего фиг пойми зачем, может нода работать по новому - запрашиваем, не может - фэлбэчимся на старое. Или это можно прописать в конфиге, например как здесь:
****
ii.about.2014
1396407760
51t
lenina,1
51t
Re: есть идея вообще всё нафиг переделать
ладно, эксперименты - потом. в принципе, я тут подумал, можно всё решить в рамках существующей реалзиации
1. сделать рядом с /z/ ещё одну (а не 8, как планировалось) реализацию, /u/ - без zlib и для обычного base64. /u/ должны будут поддерживать все серверы и все клиенты, всегда. /z/ - пока будет вотчина python, а там посмотрим.
2. так и сделать - вместо хттп://51t.ru/ писать хттп://51t.ru/z/. или хттп://51t.ru/u/. или даже хттп://мойсайт.ру/ii.php?q=/u/, по нему и определять, если на /z/ заканчивается - значит схема python, если на /u/ - значит плоская схема. для получения - всегда останутся /m/ и /e/
3. пока будет опциональным. пусть внедряется. :)
****
А стандарт обмена между станциями это стандарт обмена между станциями, пусть хоть на берёзовых бруньках обмениваются, это договорённости сисопов. Большие инконсистентные эхи - это проблема, которая была решена изначально, но потом заменена на другое решение, для которой и потребовались слайсы, чем больше изменений, тем больше новых сущностей. Это всё - плохой дизайн.
--------------------------------------------------------------------------------
subject: Re: Дополнения к стандарту
31.10.2024 22:21
revoltech (spnet, 4) => FzZ2XPleXm6ExGqoJHjj
AL> 10+ лет качаем по 40. Полёт нормальный.
Ну а мне откуда было это знать? Нигде о 40 не было написано. А tgi уже на 13 посылает куда подальше, например.
AL> Хорошо. Я укажу в стандарте 40. Все, кто качает больше или предоставляют меньше, не соблюдают стандарт.
Ну вот так бы сразу.
--------------------------------------------------------------------------------
subject: Re: Дополнения к стандарту
31.10.2024 22:23
ahamai (blackcat, 2) => AoMnqcRftBI2A64vTJLg
> Только за, но здесь почему-то нашлись принципиальные противники этой идеи.
потому что у больших запросов куча проблем и никакого смысла. поэтому в своё время и перешли от них к маленьким. я вообще не понял, какая проблема решается, первоначальный фетч всей текущей сети занимает небольшое время, большой запрос принципиально ничего не изменит. но нагрузка на серверы растёт, однопоточные серверы вообще поставит колом. я не говорю про проблемы обрыва связи. чанками разумного размера качать лучше, чем целым. оптимальным числом эмперическим путём было выбрано 40.
если ты предоставишь бенчмарки, что выгрузка всех сообщений единым блоком хотя бы в 2 раза быстрее, чем чанками по 20 сообщений, тогда это будет интересно. тогда мож и /get вернётся.
--------------------------------------------------------------------------------
subject: Re: Дополнения к стандарту
31.10.2024 22:45
revoltech (spnet, 4) => ZLXRALtnXaxCr9LOhb3s
ahamai> если ты предоставишь бенчмарки, что выгрузка всех сообщений единым блоком хотя бы в 2 раза быстрее, чем чанками по 20 сообщений, тогда это будет интересно. тогда мож и /get вернётся.
Это зависит от местоположения клиента и ноды. В стерильных тестовых условиях, может, и не вдвое быстрее будет. А вот в реальных время установки TCP/TLS-соединения тоже существенно добавляет к общей картине. Могу на днях замерять перефетч с shaos-а после уменьшения чанка с 389 сообщений до 40. Или с ping после уменьшения с 10000 до 40... Если интересно.
--------------------------------------------------------------------------------
subject: Re: Дополнения к стандарту
01.11.2024 06:43
Andrew Lobanov (tavern,1) => 9Rn6bz5hnKdf1umtWICd
>> Ну и во-вторых, sf решает одну конкретную задачу, а слайсы - универсальны. Слайсы делают возможным адаптивный фетч и онлайн просмотр.
ahamai> То, что называется слайсы, у меня называется lim. Сделано одной строчкой кода. Совместимо вообще со всем, не ломает /u/e/, и даже клиенты, которые понятия не имеют о lim, могут им пользоваться.
Только твой lim решает совершенно другую задачу. Ты попробуй прочитать хотя бы черновик стандарта. То, что ты видишь единственное применение слайсам, не означает, что существует только оно.
Ну или я не понимаю как работает твой lim. Как им получить индекс эхи с 20 сообщения по 30?
ahamai> Адаптивный фетчинг это оверинжиниринг, программирование ради программирования, он вообще не даёт гарантий, в станциях где нет формальных эх а сортировка идёт по timestamp, могут быть вкинуты старые сообщения и такой фетчинг их не увидит. В нормальных условиях я вообще не вижу проблем гонять полные эхи, ибо только они дают полную гарантию. Для экономии трафка можно использовать ?h, его использование в гейтовании с shaos сократило дневной трафик с 12 мб до 2.
Если узел отдаёт индекс с сортировкой по времени сообщений, то его надо снимать с фетчинга, потому что это как минимум хулиганство. Как отдача полного индекса решает проблему выкинутых сообщений вообще непонятно.
>> В общем, попытки решить какие-то несуществующие проблемы и навязать какие-то свои оценки. Чего я боялся, то и происходит. Лебедь рак и щука.
ahamai> Проблема была в проектировании. Некорректном дизайне. В сломе того, что просто работало и было простым, как три копейки, ради решения несуществующих проблем и каких-то непонятных смен стандарта, которые ничего не дают, кроме экономии трафика, которой тоже нет, потому что у тебя либо постоянные новые запросы, новые коннекции, новые строчки в логе сервера и так далее, да там tcp фреймы больше сожрут чем трафика сэкономится :)
Кто о чём, а Рома снова о том, что idec это не ii. Потому и не ii, что ii имел фундаментальные проблемы в дизайне.
ahamai> Забавно, я посмотрел архив старых эх - я постоянно из протокола что-то выкидывал, пока не остались /e /m /u/e /u/m, и всё это не достигло предельной простоты. А щас только что-то добавляют. Да сколько угодно. Но не надо лезть в /u/e.
В твой ii никто не лезет. Ты можешь взять хоть ii-0.3 и работать с idec. Но и ты в свою очередь не лезь в idec. Постоянно добавляют, это одни только слайсы. Если у тебя от них пригорает, просто не используй их. Нет, мы будем изобретать несовместимые со стандартом велосипеды.
Я даже больше скажу, никто не мешает фетчить ii в idec. Фетчер может не использовать слайсы вполне.
ahamai> Это база из баз, фейлбек из фейлбеков, он должен быть простым, примитивным, кодиться за три строчки кода на любом языке и быть единой везде.
Он никогда не кодился за три строчки даже на петухоне. Я твою референсную реализацию читал.
ahamai> Расширяйте как хотите, но расширяйте отдельные методы, без x/feaures и прочего фиг пойми зачем, может нода работать по новому - запрашиваем, не может - фэлбэчимся на старое.
Рома, закопай уже стюардессу. Сабжа не будет. По крайней мере в стандарте. В плане обмена мой черновик останется без изменений. Изменения будут только в сопроводительном тексте для устранения неоднозначностей.
Кто что для своих фантазий сделает у себя не имеет значения пока он соблюдает стандарт.
+++ Caesium/0.4 RC1
--------------------------------------------------------------------------------
subject: Re: Дополнения к стандарту
01.11.2024 06:43
Andrew Lobanov (tavern,1) => GTC7zmoM2SBCHwSfUJGU
AL>> 10+ лет качаем по 40. Полёт нормальный.
revoltech> Ну а мне откуда было это знать? Нигде о 40 не было написано. А tgi уже на 13 посылает куда подальше, например.
Готовый софт уже делал так. Всё на гитхабе есть - бери и смотри, раз уж начал своё писать.
AL>> Хорошо. Я укажу в стандарте 40. Все, кто качает больше или предоставляют меньше, не соблюдают стандарт.
revoltech> Ну вот так бы сразу.
Договорились.
+++ Caesium/0.4 RC1
--------------------------------------------------------------------------------