>> Если у тебя это не так, чини ноду.
ahamai> я не могу починить референсную ii 0.3, которая является базовым и законченным стандартом ii, потому что она осталась в 2014 году

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

ahamai> ps. проблема не в /u/e

Да. Проблема в ii 0.3.

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

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

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

shaos> а revoltech по-видимому читает сразу всех и часто

Не так уж и часто. У меня фетч чисто в ручном режиме по кнопке на данный момент. Но порядок чтения уже написал.

AL> Всё там же, где он лежит уже чёрт знает сколько лет. Ты же с ним сюда и приходил. Если ты про стандарт ii, то за этим к Роме.

Да я уже запутался. Наверное, про стандарт ii. Короче, про то, что было до ребрендинга в IDEC и появления той доки на гитхабе.

AL> У него должен быть, ведь не может же быть такого, чтобы это великолепие да осталось без описания.

Ну надеюсь. А то если окажется, что вместо описания остался только кривой референсный код, то совсем печаль.

Рома, не нервничай. У меня 3й день подряд мигрень, но я решил немного пояснить ситуацию, не влезая в детали. Как ты предложил. Но по существу! Мой ответ частично обращён к твоим другим сообщениям.

# Про дизайн и простоту ii

Я прекрасно понимаю твои доводы о простоте и сам практикую решения проблем "не в лоб". Это действительно круто, когда проблему можно "обойти" не решая её вообще. Plan9, кстати, отличный пример этого подхода. Я пришёл к этому не сразу, но когда так понял - сразу начал с радостью практиковать. На работе и в быту. И про питон + падения некорректных данных я тоже нормально отношусь. Мы пишем "чистые (сейчас не в терминах ФП)" функции при этом. А контролируемое падение питона (да ещё в рамках веб-фреймворка, например) это, обычно, не является проблемой безопасности.

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

# Проблемы "базового" ii

Собственно это и есть краеугольный момент. Либо мы воспринимаем особенности ii проблемами либо нет. Я согласен, можно проявить аскетичность, смирение и "вложить" себя в базовый ii который предполагает:

- полный фетч;
- архивирование и "бегучесть" эх.

Но аскетика - дело добровольное. Если каким-то людям эти ограничения тесноваты - они вольны решать эти проблемы так, как они это способны делать. И даже, если они делают это по твоему мнению плохо и топорно, вправе ли ты их за это осуждать?

# Обсуждаемые изменения стандарта idec

Обсуждаемые изменения стандарта - в основном, реакция на взгляд со стороны о двусмысленных моментах. Андрей выкинул из текущего idec то, что посчитал лишним. Так что это упрощение. А то, что было неточно сформулировано - сформулировал. Речь вроде бы и не шла о "принципиально новом" стандарте. То-есть, мера хаоса была уменьшена, не революционно, но тем не менее. В этом и есть его ценность.

# Новый стандарт

Вот. А теперь самое интересное. Есть чистый стол. Есть ii. Есть упрощённый idec. И дальше развилка.

1) мне достаточно ii
2) мне достаточно idec
3) я могу сделать лучше

Ты можешь мне сказать где ты? Вроде бы ты на пп1, но при этом я вижу в твоих сообщения обсуждения решений тогоже sf, h которые вроде бы демонстрируют что то из пп3.

Ну так возьми и предложи, связанным текстом непротиворечивый стандарт, который по твоему мнению достаточен.

Я лично могу сформулировать несколько вариантов:

1) ii с полным фетчем но с надёжным механизмом проверки изменений в эхах узла (это то, что у тебя hash эх
2) ii с возможностью забирать n последних сообщений (это твой lim и/или sf)
3) ii с отдачей списка msgid в обратном порядке (моя идея)

Каждая из них мне не нравится по своим причинам:

1) Необходимостью хранить счетчики/хеши/что угодно - мой шкурный интерес. Я тоже иногда люблю экстремальную простоту. Приемлемо, но не прекрасно.

2) Невозможно "чётко" подобрать лимит такого захлёста. Сколько надо ставить чтобы и разброс порядка не влиял и интенсивность чата? 100? А если сисоп уехал в круиз а за пол года его отсутствия пришло 10000 пользователей? Нет, не надёжно.

3) Вроде всё четко технически (читаем и обрываем связь когда считаем нужным) но.. Есть элемент хака.

Текущий idec в терминах простоты мне тоже НЕ НРАВИТСЯ, но! Я НЕ МОГУ придумать лучше и так, чтобы были решены те недостатки, о которых я говорю. И вот слайсы, достаточно просты и их таки решают! И этот адаптивный фетч который ты называешь оверинженирингом, для меня это вынужденный шаг. Другого пути я просто не вижу. Если хочу избавиться от полного фетча и при этом иметь надёжность которая позволила бы мне бросить ноду и не следить за ней год (хотя бы и гипотетически)

В общем, давай конструктивно. Дружно. Корректно! (Мою ноду дети читают!) Предлагай решения если есть что предложить дополнительно или скажи, что тебя устраивает ii в чистом виде, но тогда и не нервничай. Дай нам двигаться своим путём.

AL>> Всё там же, где он лежит уже чёрт знает сколько лет. Ты же с ним сюда и приходил. Если ты про стандарт ii, то за этим к Роме.
revoltech> Да я уже запутался. Наверное, про стандарт ii. Короче, про то, что было до ребрендинга в IDEC и появления той доки на гитхабе.

Сначала был ii. Вещь хорошая, но недоделка. И даже стандарта не было - был только кривой референсный код. Потом Рома написал что-то типа стандарта. С кучей воды, неоднозначностями и вот это вот всё. Потом мы тут начали думать как ii довести до юзабельного состояния и родили слайсы. Конечно, это плохое решение, но все остальные ещё хуже. Были идеи и со счётчиками (они остались, но ими никто не пользуется, да и выкину я их), с хешем последнего сообщения (вообще максимально плохой вариант), с хешем всего индекса (тоже хреновый вариант, к тому же не позволяет определить откуда качать).

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

AL>> У него должен быть, ведь не может же быть такого, чтобы это великолепие да осталось без описания.
revoltech> Ну надеюсь. А то если окажется, что вместо описания остался только кривой референсный код, то совсем печаль.

Скорее всего, так и есть. Но надо спрашивать Рому.

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

Я там в revoltech.local (у Шаоса) пофантазировал на тему, как можно было бы весь протокол упростить, не будь необходимости держать обратную совместимость с ii/IDEC. Причём там и файлэхи тоже в общую структуру прекрасно ложились бы, например.

Но сначала актуальный стандарт IDEC реализую в ноде своей, а потом уж посмотрим. Так что там, 40 мессаг на запрос устаканили, больше дополнений к доке не будет, можно приступать к запилу?

revoltech> Я там в revoltech.local (у Шаоса) пофантазировал на тему, как можно было бы весь протокол упростить, не будь необходимости держать обратную совместимость с ii/IDEC. Причём там и файлэхи тоже в общую структуру прекрасно ложились бы, например.

Ну я Шаоса, вроде, не тяну. Если кто-то транзитом протащит, затащу к себе.

revoltech> Но сначала актуальный стандарт IDEC реализую в ноде своей, а потом уж посмотрим. Так что там, 40 мессаг на запрос устаканили, больше дополнений к доке не будет, можно приступать к запилу?

Ну... На самом деле, я ещё думаю, что есть смысл выкинуть e/ и m/ :)

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

AL> Ну... На самом деле, я ещё думаю, что есть смысл выкинуть e/ и m/ :)

m/ постоянно использую для отладки. Удобно. Про e/ сходу не могу вспомнить.

AL>> Ну... На самом деле, я ещё думаю, что есть смысл выкинуть e/ и m/ :)
hugeping> m/ постоянно использую для отладки. Удобно. Про e/ сходу не могу вспомнить.

Ну m/, по размышлению, мне тоже кажется полезным. Даже просто взять и получить сообщение с помощью curl это удобно. А вот e/ никогда не видел, чтобы использовали. Разве что на заре ещё ii был клиент на баше и dialog, который был онлайн-клиентом и использовал как раз e/ и m/, если мне не изменяет память. Хотя, по факту, разделить строчку и декодировать base64 на баше всё равно просто.

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

AL> Ну... На самом деле, я ещё думаю, что есть смысл выкинуть e/ и m/ :)

Согласен.

> Ну я Шаоса, вроде, не тяну.

Ну как не тяну? Тянешь, но по старому списку эх 2021 года и по старому адресу…

Подумал тут ещё... Хочу добавить. Может какой-то мозговой штурм начнётся. Но это все в рамках некоторого "потенциально нового" ii-подобного протокола. idec3 :)

Адаптивный фетч тоже не 100% надёжен. Но ненадёжен по-другому. Речь о той точке алгоритма, когда мы останавливаемся. Когда видим что такое сообщение у нас есть и начинаем фетч. Это лучше чем жёсткий лимит, но всё-ещё не абсолютно надёжно.

Поэтому мне кажется, что в "идеальном" протоколе нужно выбрать что-то принципиально иное.

1) Либо полный sync если хоть что то поменялось (но тогда стоит вернуться и к перекатыванию эх, потому что в этом решении нет масштабировании при бесконечном росте эхи. Короче - это "принятие" ii)

2) Выборка, основанная на времени.

Вроде бы Рома делал такое когда-то, может ошибаюсь. Запрос вида: дай мне сообщения которые пришли с такого-то времени (время - ну пусть секунды эпохи unix в utc).

Да, тогда мы немного завязаны на время, но это вроде бы окончательно решает всё. Или нет?

Что думаете?

hugeping> Но это все в рамках некоторого "потенциально нового" ii-подобного протокола. idec3 :)

Стоило прийти в idec, как его уже хоронят :)

tuple> Стоило прийти в idec, как его уже хоронят :)

Не надо вбросов! Давай по существу.

P.S. Ipv4 тоже хоронят давно, но что-то никак. :)

hugeping> Что думаете?

Продолжаю рассуждать. sf=hash становится надёжной, если только мы после последнего фетча запоминаем hash последнего сообщения которое зафетчили и сохранили. Возможно, о таком режиме Рома и говорил, но я до сих пор воспринимал sf=hash совсем по другому. Так что пишу это, если вы тоже воспринимали это по другому...

Так что sf=hash так же надёжна как и время, если мы после каждого фетча успешного записываем hash последнего взятого сообщения для этой ноды.

Мне, правда, не нравится необходимость хранить эти хеши для фетчей (причём для каждой ноды), поэтому идея с временем нравится больше. Но тем не менее.

TOP10 VISITORS:

[1] Facebook point=0 web=1027 up=22.9MB (33%)
[2] 176.109.111.x point=46 web=0 up=16.7MB (24%) <--- tavern (2/hr)
[3] 92.63.98.x point=70 web=0 up=5.9MB (8%) <--- tgi (3/hr)
[4] Google point=42 web=480 up=5.7MB (8%) <--- Google (2/hr)
[5] 145.224.100.x point=115 web=1 up=5.0MB (7%) <--- 145.224.100.x (5/hr)
[6] Amazon point=0 web=83 up=4.1MB (5%)
[7] 95.165.9.x point=135 web=2 up=3.3MB (4%) <--- ping (6/hr)
[8] 217.197.116.x point=150 web=0 up=2.7MB (3%) <--- blackcat (6/hr)
[9] 24.130.121.x point=35 web=58 up=2.0MB (2%) <--- spnet (1/hr)
[10] 172.56.42.x point=0 web=35 up=0.2MB (<1%)

TOTAL TRAFFIC: 68MB

Если сохранять хеш последнего принятого сообщения для КАЖДОЙ опрашиваемой ноды, то тогда да - имеет право на жизнь. По идее оно может собой заменить хеш списка сообщений для эхи (мой /x/h или /list.txt?h=1) т.к. список не может расти изнутри - только с конца...

Время ненадёжно т.к. сообщения приходят так как приходят из-за особенностей роутинга и последовательности фетчинга, а вовсе не в хронологическом порядке, и старое сообщение вполне может внезапно "всплыть" выше по списку чем более новые ответы на него (см. беседу revoltech с Ромой).

shaos> Если сохранять хеш последнего принятого сообщения для КАЖДОЙ опрашиваемой ноды, то тогда да - имеет право на жизнь. По идее оно может собой заменить хеш списка сообщений для эхи (мой /x/h или /list.txt?h=1) т.к. список не может расти изнутри - только с конца...

Он не то чтобы его заменяет, а решает бОльшую задачу - sync только новых сообщений. При этом /x/h не нужен, так как решена более общая задача. Но хеши надо хранить для всех эх всех нод с которых мы фетчим...

shaos> Время ненадёжно т.к. сообщения приходят так как приходят из-за особенностей роутинга и последовательности фетчинга, а вовсе не в хронологическом порядке, и старое сообщение вполне может внезапно "всплыть" выше по списку чем более новые ответы на него (см. беседу revoltech с Ромой).

Я имел в виду время принятия сообщения нодой, а не время создания сообщения, конечно.

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

А ну это сейчас вообще никем не фиксируется

shaos> А ну это сейчас вообще никем не фиксируется

Гм. Действительно, как-то я не подумал об этом. :)

Ну теоретически если кто хранит мессаги в MySQL или SQLite, то время добавления можно и сохранять, а если только в файлах, то по времени создания файла? Можно попробовать - всё равно ведь не всё перебирать надо, а только последние сообщения в эхе пока не найдём «прошлое»…

shaos> Ну теоретически если кто хранит мессаги в MySQL или SQLite, то время добавления можно и сохранять, а если только в файлах, то по времени создания файла? Можно попробовать - всё равно ведь не всё перебирать надо, а только последние сообщения в эхе пока не найдём «прошлое»…

Да не, ерунда это всё. Не могу я, в общем, ничего принципиально иного придумать. Ну, а о реверсной выдачи ID что думаешь?

Реверсная выдача это когда клиент качает список в обратном порядке пока не дойдёт до знакомых хешей? Это может работать только для отдельных эх (типа /e но в обратном порядке).

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

echo.1:msgid999
echo.2:msgid998
echo.1:msgid997
…

> Ну теоретически если кто хранит мессаги в MySQL или SQLite, то время добавления можно и сохранять

так было в босфор. я ща гляжу на него, прикольная была штука, только клиентов и фетчеров для него не было :)

> Он не то чтобы его заменяет, а решает бОльшую задачу - sync только новых сообщений. При этом /x/h не нужен, так как решена более общая задача. Но хеши надо хранить для всех эх всех нод с которых мы фетчим...

x/h единственный валидный триггер. он бывает в двух состояниях "эха изменилась" и "эха не изменилась". всё остальное не даёт полных гарантий.

> Собственно это и есть краеугольный момент. Либо мы воспринимаем особенности ii проблемами либо нет. Я согласен, можно проявить аскетичность, смирение и "вложить" себя в базовый ii который предполагает:

Это не проблема. Это основа. Хотел вчера ответить revoltech, но отвечу сразу здесь.

ii это социальная сеть малых сообществ. Так она всегда и называлась. Она не про технологии, она про любительское программирование, радиолюбительство, клуб юного техника и прочие порождения Дворца Пионеров. Чтобы каждый мог собрать свою ноду и общаться со своим хомячком. Потому что это просто. Весь протокол постоянно упрощался. Какие вообще слайсы?

Ещё мне там понравилось, что второй человек уже указывает, что в выводе /u/e может быть мусор. Они походу вообще не понимают сути. Ты синкаешься с доверенным узлом по предельно формализированному и простому формату. Единственный вариант, когда там может быть мусор - это СБОЙ. И как можно в этой ситуации поступать "ну давайте что-нибудь попробуем вычленить". Да ты можешь получить 800 дублей или ещё чего похуже. Вся история и фидо, и ii, говорят об этом.

> Ты можешь мне сказать где ты? Вроде бы ты на пп1, но при этом я вижу в твоих сообщения обсуждения решений тогоже sf, h которые вроде бы демонстрируют что то из пп3.

меня не интересует стандарт. ВООБЩЕ. у меня есть /u/e, который проживёт ещё 100 лет и переживёт всех модернизаторов.

я просто напоминал о 2014 году, когда делали стандарт. сейчас 2024 год и опять делают стандарт. на этом всё. умному - достаточно.

О. Третий. Гы-гы, проблемы проектирования... попытка решить болезни роста прежде чем они возникнут - погубило не одну сотню проектов. ii выжил, и именно благодаря своему проектированию и своему позиционированию. С технологией у текущей сети нет проблем, вообще. Есть проблемы с контентом.

> Изменения ради изменений. Ты бы классно вписался в современную IT-индустрию с такими подходами.

я вообще не трогаю технологию. она по мне изначально идеальна. я про внедрение проекта, новых пользователей, новый софт и прочая инфраструктура - ничего этого нет. при Стали^W мне каждую неделю новые клиенты выходили :) была куча юзеров, эх и прочего. сейчас всё глухо, несколько месяцев активность вообще была околонулевая. Даже shaos свой форум в эху не переформатировал. :) Я думаю, если бы жизненные обстоятельства мне не помешали, и сеть и технология сейчас были бы куда популярнее. Сейчас я тоже хочу заняться именно контентом, есть несколько идей, но жизненные обстоятельства сейчас куда хуже, к сожалению. Попробую. Ваши форматы меня не интересуют вообще, idec я прочитал только несколько дней назад, новый не читал.

Я ПРОСТО НАПОМИНАЛ 2014. Делали формат, который ПОЛНОСТЬЮ совместим с ii, но при этом экономит трафик. Итог:
1.
2.

Мне, старому фидошнику, непонятно, зачем фетчить сразу несколько станций. :) лично я качаю только с shaos

ты бы хотя бы посмотрел, что они выдают :) у тебя нет http, по нему нет никакой отдачи.

> 2) Невозможно "чётко" подобрать лимит такого захлёста. Сколько надо ставить чтобы и разброс порядка не влиял и интенсивность чата? 100? А если сисоп уехал в круиз а за пол года его отсутствия пришло 10000 пользователей? Нет, не надёжно.

полный фетч периодически необходим. и он решает все вопросы. вопросы "уехал в круиз на полгода" тоже решает полный фетч. а лимиты, как и любой другой k/v, можно легко добавить вообще не ломая совместимость с любой версией ii, просто меняя endpoint (что было заложено изначально, когда схема /z менялась на схему /u)

но вообще причина не особо понятна. я опрашиваю shaos каждые 5 минут, сейчас слайсами раньше полным фетчем. до h/x и с полным фетчем это 12 мб в сутки (при этом я тяну rss-эхи). после h/x и с полным фетчем 2-4 мб в сутки. (со слайсами, кстати, трафик почему-то нифига не уменьшился). в http есть gzip, который тоже экономит трафик.

По мне проблемы ровно три: отсутствие контента, отсутствие клиентов, отсутствие юзеров. Проблему внезапного лишнего трафика решает элементарное внедрение хэширования эх - оно сокращает трафик, и в отличие от адаптивных и ?sf даёт полную гарантию синхронности эх.

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

shaos> Для минимизации количества запросов можно все эхи разом опросить - для этого придётся городить новый вызов и новый формат ответа

Не вижу смысла минимизировать число запросов. До сих пор считаю это ложной целью. У меня и сейчас опрашивается в одном потоке одна эха и работает все быстро.

ahamai> Чтобы каждый мог собрать свою ноду и общаться со своим хомячком. Потому что это просто. Весь протокол постоянно упрощался. Какие вообще слайсы?

Дык я и начинаю собирать свою ноду. Слайсы мне в этом вообще не помешают. А ещё у меня там будет автопереключение транспортов — по одному и тому же порту можно будет запрашивать как HTTP, так и Nex/Gopher. И потом ещё после стандартной реализации IDEC будет сбоку приделан совсем несовместимый с ним протокол, ещё более простой и при этом решающий ровно те же задачи, но куда более красиво, компактно и всего пятью эндпоинтами.

ahamai> Ещё мне там понравилось, что второй человек уже указывает, что в выводе /u/e может быть мусор.

Не в выводе, а на входе. Это существенная разница.

ahamai> Они походу вообще не понимают сути. Ты синкаешься с доверенным узлом по предельно формализированному и простому формату.

А ты уверен, что ты сам-то суть понимаешь? Это не про доверенные узлы вообще. Для запроса /u/e пароль не нужен, тебе запрос с дичью вместо эхонеймов может прислать вообще кто угодно, когда угодно и в каком угодно количестве.

ahamai> Единственный вариант, когда там может быть мусор - это СБОЙ.

Или сознательная атака. Если твоя нода при этом будет падать от малейшего чиха, толку от неё мало. У меня вон VPS-ку всякие васяны постоянно по SSH брутить пытаются, судя по логам. И обламываются на корню.

Я попытался склеить твои сообщения фрагментные в одно и осознать. Но не смог. На моё сообщение ты как-то очень непрямо ответил. По кр. мере я не считаю что ты меня понял и ответил так, чтобы я понял в ответ. Почему уж это происходит так -- я не хочу разбираться. Давай я перестану тогда тебя беспокоить. Буду заниматься дальше своими делами.

> Дык я и начинаю собирать свою ноду. Слайсы мне в этом вообще не помешают.

ты программист, наверное. а речь про любителей.

> А ты уверен, что ты сам-то суть понимаешь? Это не про доверенные узлы вообще. Для запроса /u/e пароль не нужен, тебе запрос с дичью вместо эхонеймов может прислать вообще кто угодно, когда угодно и в каком угодно количестве.

ты. синкаешься. с доверенным. узлом. всё. а теперь сам перечитай свою же фразу.

ps. при запросе (запросе от тебя) система автоматом разбирается. если есть файлик, то это эха с данными, если всё остальное - то это пустая эха. и ты выдаёшь такой же полностью корректный бандл, где просто перечисляется куча пустых эх. вот тебе вход, список, чего угодно, любой ахинеи. вот тебе выход - ответ на твой запрос, что эха КРАКОЗЯБЛ1 и эха КРАКОЗЯБЛ2 пусты. это полностью корректный и абсолютно формализуемый бандл. бандл состоит только из двух вещей, msgid и эхи, и выдаёт такой бандл, что бы у тебя не запросили вообще.

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

> Или сознательная атака.

то есть, тебя собирается атаковать собственный аплинк. И ТЫ ПРИ ЭТОМ ПЫТАЕШЬСЯ ВАЛИДИРОВАТЬ какие-то данные? ты вообще сам понимаешь, что говоришь - тебе дают заведомо некорректные данные, а ты говоришь "нет, не отлуп давать, а пытаться хоть что-то свалидировать, ВДРУГ ТАМ ЧТО-ТО хорошее?"

+++ memo:absurd

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

а, ну ещё проблема в сути вопроса - нахрена, чтобы навредить, давать НЕКОРРЕКТНЫЙ БАНДЛ??? вот тут вообще непонятно. логичнее давать абсолютно корректный бандл, содержащий, например каждый раз тысячу разных msgid с некорректными данными или просто со случайным флудом

Речь была вроде не про мусор в выводе /u/e а про мусор в запросе /u/e - такой запрос кто угодно может сделать

> у тебя нет http, по нему нет никакой отдачи.

Есть :)

Порт 8085 ;)

> Не вижу смысла минимизировать число запросов.

ну, в 2014 это было проблемой, раз /e заменили на /u/e. а вообще запрос вещь дорогая, это и лишние tcp-фреймы, и лишняя нагрузка на сервер, и лишняя строка в логах :) упаковка в один запрос лучше в любом случае. иначе можно было бы на /m и /e остаться. и мы бы остались, если бы запросы не были столь дорогими, пришлось прикручивать изначально ненужные бандлы. я не знаю, в текущих реалиях можно было бы, если создавать сеть сейчас, остаться на /m и /e - это бы сильно всё упростило :)

> У меня и сейчас опрашивается в одном потоке одна эха и работает все быстро.

u/e для этого вообще не нужна, достаточно e/

> На моё сообщение ты как-то очень непрямо ответил.

я ровно в каждом сообщении пишу ровно одно и то же.

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

2. вспомните 2014 год. у меня каждое сообщение ровно про одно - вспомните 2014 год. всё. ни о чём другом я не пишу. и про технологии я пишу только в этом разрезе.

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