Сабж задумался. Определение смещения для расширенной схемы u/e мы можем хранить как константу (или передавать как константу в качестве параметра), а можем вычислять из результата работы схемы x/c. И всё это просто замечательно пока мы работаем с одной единственной нодой. Но если ноды две и более, то порядок сообщений в индексе у них скорее всего разный и мы можем потерять сообщения при фетчинге одной и той же эхи с разных узлов.

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

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

Что думаете на этот счёт?

2vit01: Да я могу взять твой навороченный фетчер, но мне он показался достаточно сложным (не в духе нашей сетки, так сказать). Хочется максимальной простоты а-ля изначальный ii, но с шахматами и гимназистками.

vit01>> 3. Расширенный /u/e используется и там, и там. Различие лишь в том, что оптимальное значение на клиенте - это 50-100, а на сервере - немного больше. Mira station фетчит каждого аплинка со смещением 200. Уже как очень долгое время.

AL> Эту практику я считаю приемлемой, если нас не интересует гарантированное получение всех новых сообщений.

Без обид, но у тебя плохая память :)
В моём фетчере эта проблема уже решена. Передаёшь параметр pervasive_ue=True, и ни одного сообщения потеряно не будет.

Алгоритм:
Запрашиваем последние -N. Если все из них новые, то запрашиваем -2N:N и так далее, подсовывая в начало.

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

AL> 2vit01: Да я могу взять твой навороченный фетчер, но мне он показался достаточно сложным (не в духе нашей сетки, так сказать). Хочется максимальной простоты а-ля изначальный ii, но с шахматами и гимназистками.

Тогда пиши сам, какой считаешь идеальным и юниксвейным :)
Главное, чтобы он свои задачи выполнял и не тормозил на большом количестве эх.

vit01>> Запрашиваем последние -N. Если все из них новые, то запрашиваем -2N:N и так далее, подсовывая в начало.

AL> У меня на данный момент так же точно происходит (по крайней мере при построении индекса). Фигня случается, когда одна и та же эха забирается с разных узлов. В таком случае этот подход приводит к потере сообщений из-за разного порядка сообщений на разных нодах.

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

Есть нода1 и нода2. У клиента стоит /u/e, предположим, на 50 сообщений.
В течение 10 минут на ноде1 появляются сразу 50 сообщений. В то же самое время на ноде2 появляются 10 сообщений. После этого нода2 гейтует ноду1, забирая те 50 сообщений.

Итого на ноде1 - 50 новых, а на ноде2 - 60 новых.

В этот самый момент подключается клиент и начинает фетчить сначала первую, затем вторую.
Так как у него лимит стоит 50, то с первой ноды он забирает 100 записей индекса и успокаивается. На второй ноде он обнаруживает 50 сообщений, которые у него уже есть в базе, и не трогает её дальше.

Да, действительно, потери. Но тебе не кажется, что такой интенсивный трафик в одной единственной эхе за такое короткое время - это _слишком_ маловероятно?

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

Дальше нода1 гейтует ноду2, забирая у неё недостающие 10 сообщений (мы же не забыли, что сервера оптимизации не используют, да?). Клиент фетчит ноду1, и недостающие 10 сообщений также к нему приходят. Всё разрешилось само собой.

vit01> Для начала не надо мешать мух с котлетами, то есть сервера с клиентами.

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

vit01> 1. Вычисление смещения из результата /x/c - это порочная практика. Её никто никогда не предлагал и не реализовывал.

Вот я и начинаю предлагать =)

vit01> 2. На сервере /x/c не нужен. Более того, ни один серверный фетчер его не поддерживает. Эта схема необходима только для того, чтобы клиенту не фетчить creepy.14, mlp.15 и прочие питоны, в которые пишут не больше раза в неделю. Самая частая работа /x/c - это выдать на экран надпись "новых сообщений нет".

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

vit01> 3. Расширенный /u/e используется и там, и там. Различие лишь в том, что оптимальное значение на клиенте - это 50-100, а на сервере - немного больше. Mira station фетчит каждого аплинка со смещением 200. Уже как очень долгое время.

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

vit01> Так и надо. Для гейтоскриптов вообще можно и не использовать кучу оптимизаций.

Гейты да. Можно хоть от 0.3 фетчер оторвать и оно будет оправдано =)

vit01> Чтобы все были счастливы, надо

vit01> 1. Делать ровно один запрос /u/e вместо того, чтобы опрашивать каждую эху

В процессе. Пока не пишу в апстрим свои эксперименты потому как лучше плохая работа, чем поломатый клиент.

vit01> 2. Добавить в Цезий поддержку /x/c, чтобы не фетчить все 40 эх из подписок, когда новые сообщения только в пайпе или в новостях (или когда их вообще нет).

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

vit01> Этих двух пунктов достаточно и для скорости, и для комфорта.

И для потенциальной потери сообщений. Вот именно это мне покоя не даёт.

vit01> Дальше нода1 гейтует ноду2, забирая у неё недостающие 10 сообщений (мы же не забыли, что сервера оптимизации не используют, да?). Клиент фетчит ноду1, и недостающие 10 сообщений также к нему приходят. Всё разрешилось само собой.

Я хочу оптимизацию на серверах применять %) Отсюда и наступление на грабли.

vit01> Без обид, но у тебя плохая память :)

Я знаю. Очень плохая =)

vit01> В моём фетчере эта проблема уже решена. Передаёшь параметр pervasive_ue=True, и ни одного сообщения потеряно не будет.

vit01> Алгоритм:
vit01> Запрашиваем последние -N. Если все из них новые, то запрашиваем -2N:N и так далее, подсовывая в начало.

У меня на данный момент так же точно происходит (по крайней мере при построении индекса). Фигня случается, когда одна и та же эха забирается с разных узлов. В таком случае этот подход приводит к потере сообщений из-за разного порядка сообщений на разных нодах.

vit01> А насчёт максимального приращения новых сообщений идея нравится. Но большой погоды она вряд ли сделает. В любом случае, рад буду посмотреть на рабочее решение.

Самое главное, что она решит вышеозвученную проблему. Но пока я её не реализовал.

vit01> Тогда пиши сам, какой считаешь идеальным и юниксвейным :)

Мой девиз "Велосипедостроительство и отвага" =)

AL> Определение смещения для расширенной схемы u/e мы можем хранить как константу (или передавать как константу в качестве параметра), а можем вычислять из результата работы схемы x/c.

AL> На стороне клиента ещё возможны костыли вида каждому аплинку по базе (хотя мне эта затея и не нравится), но на ноде мы уже так делать не можем.

Для начала не надо мешать мух с котлетами, то есть сервера с клиентами.

1. Вычисление смещения из результата /x/c - это порочная практика. Её никто никогда не предлагал и не реализовывал.

2. На сервере /x/c не нужен. Более того, ни один серверный фетчер его не поддерживает. Эта схема необходима только для того, чтобы клиенту не фетчить creepy.14, mlp.15 и прочие питоны, в которые пишут не больше раза в неделю. Самая частая работа /x/c - это выдать на экран надпись "новых сообщений нет".

3. Расширенный /u/e используется и там, и там. Различие лишь в том, что оптимальное значение на клиенте - это 50-100, а на сервере - немного больше. Mira station фетчит каждого аплинка со смещением 200. Уже как очень долгое время.

AL> Пока лучше достаточно большой минимальной длины запрашиваемого индекса я не придумал. Но это всё равно достаточно мороченный вариант. Может действительно имеет смысл просто забирать индекс фиксированной длины и не заморачиваться на лютую оптимизацию трафика (что такое +- несколько десятков килобайт в наши дни?).

Так и надо. Для гейтоскриптов вообще можно и не использовать кучу оптимизаций.

Чтобы все были счастливы, надо

1. Делать ровно один запрос /u/e вместо того, чтобы опрашивать каждую эху
2. Добавить в Цезий поддержку /x/c, чтобы не фетчить все 40 эх из подписок, когда новые сообщения только в пайпе или в новостях (или когда их вообще нет).

Этих двух пунктов достаточно и для скорости, и для комфорта.

vit01> И она работать пока отказывается.
vit01> https://ii-net.tk/ii/files/I7D9Pr9GzoFkojC1mSix.png

Что очень странно, так как я ей сейчас как раз и пользуюсь. Ошибка странная. С какой нодой возникает? Кинь caesium.cfg без auth.

vit01> Тогда ничего против не имею. Надо как-то лучше друг друга понимать учиться :)

Ну с формулировками у меня всю дорогу проблему. Именно поэтому по юности в фидо я молчал =)

vit01> Реализую-ка у себя тоже этот хак с /x/c, чтобы от прогресса не отставать.

Я уже написал. Осталось только запоминание x/c для разных нод реализовать, но уже сейчас фетчер просто молниеносный.

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

Ещё хочу добавить возможность формировать строку вызова фетчера в конфиге. Тогда останется только чтобы фетчер умел принимать через аргументы адрес ноды, список эх для фетча и список эх для клонирования (последнее опционально).

AL> Сейчас допишу поддержку нескольких нод и подсуну этот фетчер в цезий дабы погоняю немного. Если всё нормально будет, то внедрю в апстрим.

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

Ещё надо чтобы необновлённые эхи в запрос не попадали, но это вечером или завтра.

vit01> Реализую-ка у себя тоже этот хак с /x/c, чтобы от прогресса не отставать.

На пробу можно взять мою версию (непричёсана и как всегда с дублирующим кодом пока) тут http://spline-online.tk/stuff/fetcher.py можно просто подложить её цезию и она будет работать.

В первый коннект с нодой забирает индекс со смещением 200 (можно изменить значение в конфиге или через параметр). Если подписаться на новую эху, то тоже берёт смещение 200. В остальных случаях юзает этот финт с x/c.

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

AL> На пробу можно взять мою версию (непричёсана и как всегда с дублирующим кодом пока) тут http://spline-online.tk/stuff/fetcher.py можно просто подложить её цезию и она будет работать.

И она работать пока отказывается.
https://ii-net.tk/ii/files/I7D9Pr9GzoFkojC1mSix.png

vit01> Реализую-ка у себя тоже этот хак с /x/c, чтобы от прогресса не отставать.

Это оказалось значительно проще, чем себе представлял. Коммитить пока не буду. Лучше недельку потестирую сначала.

vit01>> Дальше нода1 гейтует ноду2, забирая у неё недостающие 10 сообщений (мы же не забыли, что сервера оптимизации не используют, да?). Клиент фетчит ноду1, и недостающие 10 сообщений также к нему приходят. Всё разрешилось само собой.

AL> Я хочу оптимизацию на серверах применять %) Отсюда и наступление на грабли.

Тогда ничего против не имею. Надо как-то лучше друг друга понимать учиться :)

Реализую-ка у себя тоже этот хак с /x/c, чтобы от прогресса не отставать.

vit01> Видимо, с самой первой, mira station. От изменения подписок ошибка не уходит. Скинул конфиг на email

Ошибку исправил. Забыл проверку на пустые строки сделать. И ещё дебаг опцию надо отключить. Лежит так же. Коммитить не буду пока. потестирую немного сперва.

vit01> Это оказалось значительно проще, чем себе представлял.

Вот да.