shaos> Рекомендовать 32 т.к. оно вообще не через http-сервер может идти, а через самописный (кстати bottle.py какое ограничение имеет?)Да у самописных вообще ограничений нет обычно.
shaos> Лучше написать не больше 380 т.к. вебсервер может такое не пережуватьНу я о том же, можно сказать, что 380 — максимум, который нужно поддерживать, а дальше уже на усмотрение владельца сервера.
shaos> И наверное надо метод POST добавить (я у себя добавлю)Только за, но здесь почему-то нашлись принципиальные противники этой идеи.
> tgi же неоднократно просил считать владелец станцией экспериментов и не фетчиться с неё.Ну может кого и просил, но мы с ним в сентябре 2022 года по е-мейлу договорились взаимно фетчить idec.talks и zx.spectrum, а потом я ещё bot.habr.rss у него начал забирать.
revoltech> Ну вот для случая полного перефетча это как раз издевательство, но пусть, лишь бы нода и 380 поддерживала.Ну там выше tuple скинул сколько полный фетч занимает времени с моей станции. А ты видел на чём она работает? ;) И сколько там в одном запросе? Так что я по прежнему не вижу проблем. Но раз кому-то очень важно, чтобы в одном запросе шло 380 сообщений, ну пусть так. Но в стандарте я бы явно не фиксировал эти числа. Написал бы про общую проблему.
hugeping> Всё-таки, это не аксиома. Тут мы зависим от внешнего фактора.Не аксиома, но вполне разумное значение по умолчанию. Сисопа проще пнуть на документальном уровне и пусть объясняет, почему приём 380 айдишников в /u/m для него проблема.
hugeping> Я бы вообще > 16 или 32 не ставил бы никогда.Ну вот для случая полного перефетча это как раз издевательство, но пусть, лишь бы нода и 380 поддерживала.
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 не ставил бы никогда.
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?
AL> Пинать сисопа своего аплинка. Потому что такие короткие урлы это издевательство.Хорошо. Какие — не издевательство? Сколько айдишников скачивать по умолчанию? Где проходит граница между «слишком жирно» и «пора пинать сисопа»?
hugeping> tgstation считать аномалиейtgi же неоднократно просил считать владелец станцией экспериментов и не фетчиться с неё.
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 тьфу! :)
AL>> Зачем ему это понимать?Пинать сисопа своего аплинка. Потому что такие короткие урлы это издевательство.
revoltech> Да блин. Моделируем ситуацию. Клиент пришёл в сеть. Без готовой базы сообщений, без ничего. Выкачивает список эх по /list.txt. Выкачивает по /u/e/[список_эх] айдишники сообщений. Их овердофига. Дальше как ему знать, по сколько айдишников группировать для посыла одного GET /u/m, если ни станция, ни стандарт об этом ничего не говорят? Он может сгруппировать по 16 и получить ошибку на tgi, каковы дальнейшие действия?
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
AL> Зачем ему это понимать?Да блин. Моделируем ситуацию. Клиент пришёл в сеть. Без готовой базы сообщений, без ничего. Выкачивает список эх по /list.txt. Выкачивает по /u/e/[список_эх] айдишники сообщений. Их овердофига. Дальше как ему знать, по сколько айдишников группировать для посыла одного GET /u/m, если ни станция, ни стандарт об этом ничего не говорят? Он может сгруппировать по 16 и получить ошибку на tgi, каковы дальнейшие действия?
shaos>> Неа - опять не сработало…По идее, это без разницы. $ -- это в любом случае конец строки.
hugeping> Возможно, потому что в сообщении нет последнего перевода строки ( см: http://shaos.net:8085/ii-point.php?q=/m/DpizUAp7CfgxVznSUul4 )
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
hugeping>> Например, в данном случае, в один запрос запиханы разные лимиты слайсов для разных эх. Зачем?Чтобы что?
revoltech> Чтобы не качать лишнее.
hugeping>> Видимо, предполагается что "умный" админ будет настраивать фетч таким образом под станцию, что задаст разные лимиты для эх разной наполненности? Зачем этот ужас? Придумайте, как в реальности вы будете это использовать?Лучше мурыжить все эхи пока все слайсы не уляжутся. И этот человек говорит мне о том, чтобы не качать лишнего. Будь последователен.
revoltech> В реальности — точно так же, как и твой адаптивный фетч сейчас это делает, только без необходимости предварительно мурыжить каждую эху отдельно.
hugeping>> По 16 msgid забирать чистоплюство не позволяет?Они ни облегчат, ни усложнят жизнь. Просто придётся делать бесполезную работу.
revoltech> Накладные расходы не позволяют. Когда станция тормозит, это особо заметно.
revoltech> Сейчас у меня в stations.txt напротив каждой ноды стоит число. Если непонятно, сколько сообщений нода позволяет забрать за раз, ставлю 12, ибо это случай с tgi и его ограничением 256 символов на гет. Андрей не озвучивал ограничение spline-online, поэтому там тоже стоит 12, и делать полный перефетч — это боль с такой-то скоростью отдачи. А бывает, что надо. Например, когда я внутренний формат базы поменял, добавив поле.
hugeping>> Моё мнение -- надо замораживать вариант драфта Андрея.
revoltech> Я-то не против, просто предлагаю вещи, которые облегчат жизнь, пока не поздно.
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
hugeping> Я тут несколько дней сдерживаюсь. К тому же, довольно сильно приболел.[skipped]
hugeping> Но сдерживаться мне всё тяжелее конечно...
hugeping> Понимаю, что меня не воспримут, всё-таки напишу.
hugeping> Подумайте, что за задачи вы решаете?
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
shaos> Ну проблему нелогичности решает, на которую некоторые указывают :)Нелогичность пока недоказана :)
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
shaos> Нету пробелов после ====А может, это от тех деятелей, которые \n\r шлют вместо \n? Попробуй поэкспериментировать с этим.
shaos> Он просто иногда работает, но чаще не работает
shaos> ====
shaos> here?
shaos> ====
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
shaos> Вот почему в предыдущем сообщении оно только на последний ==== среагировало? Пустую строку надо до?Вангую, что это потому, что не было пустой строки в конце сообщения. Попробуй добавить и оно сломается совсем :)
shaos> ====
shaos> again?
shaos> ====
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
AL>> Зачем? Усложнение ради усложнения? Так IDEC не про это, а про дубовую простоту.Тут слайс, тут волшебное слово, тут хэш. Сиди, разбирай.
revoltech> Это как раз и было бы про дубовую простоту парсинга. Ключ-значение. Всё однозначно.
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
AL>> Не вижу в нём смысла.Зачем ему это понимать?
revoltech> Как клиенту понять, сколько сообщений максимум можно забрать за один запрос?
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
>> ahamai просто не помнит свой же стандарт. Надеюсь, у него всё хорошо.Ещё пустая строка.
ahamai> В бандле только эхи и msgid.
ahamai> Эхи с точками, всё осталное msgid. Если там что то ещё, падай а не игнорируйОткуда оно там возьмётся?
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
hugeping> Да нет, вру. Там проверяется на корректность ID всего лишь. Странно. Проверю.У этих сообщений repto не соответствует формату. Не 20 символов. Таки сообщения я стал дропать на приёме, после того случая недавнего. Но старые сообщения остались, видимо, битые.
hugeping> Возможно, это не очень хорошо. Судя по коду, DecodBundle отбрасывает сообщение если в нём неверный repto. То-есть дело не в веб морде даже. Потом подумаю, что лучше с этим сделать. Пока так.Да нет, вру. Там проверяется на корректность ID всего лишь. Странно. Проверю.
tuple> Как я понял: эти сообщения существуют, но сообщения, которые записаны в их repto, не существуют. Поэтому их веб-морда показать не может, а они есть. Потеряшки?Возможно, это не очень хорошо. Судя по коду, DecodBundle отбрасывает сообщение если в нём неверный repto. То-есть дело не в веб морде даже. Потом подумаю, что лучше с этим сделать. Пока так.
hugeping> Можете скачать ii-go и сделать полное клонирование моей станции и написать, сколько это заняло времени.Активного участия в дискуссиях не принимал, но решил попробовать:
$ time ./ii-tool fetch https://club.hugeping.ru INFO: 2024/10/31 12:20:50 Start fetcher(s) for https://club.hugeping.ru INFO: 2024/10/31 12:20:50 Get https://club.hugeping.ru/u/e/pipe.2032 INFO: 2024/10/31 12:20:50 Get https://club.hugeping.ru/u/e/std.rein ... real 0m30,322s user 0m9,286s sys 0m4,117sПри фетче были ошибки на некоторые сообщения, у которых обнаружили "wrong repto format":