# Re: Протокол IDEC
vit01 (mira, 1) → Andrew Lobanov – 14:18:49 2018-10-12
vit01>>>> Всё просто, поле по-хорошему increment only. А ещё клиентская часть обычно подстраховывается и скачивает индекс с запасом.
vit01>> Надо поправить в документации, чтобы не заводить путаницу. Но в первом приближении это обычно и есть количество сообщений. Можно timestamp новейшего сообщения в эхе подставлять, наши клиенты этот вариант съедят даже без переписывания кода.
AL> Ваши съедят, а мои подавятся. На базе x/c мои фетчеры вычисляют размер слайса.
Действительно, тут я ошибся. IDEC Mobile тоже подсчитывает слайсы по ним (хоть и более хитро), а ещё уведомления выдаёт :)
Важно, что поле только возрастает, и что на сервере после удаления сообщений значение /x/c не должно уменьшаться.
+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM
vit01 (mira, 1) → Andrew Lobanov – 14:18:49 2018-10-12
vit01>>>> Всё просто, поле по-хорошему increment only. А ещё клиентская часть обычно подстраховывается и скачивает индекс с запасом.
vit01>> Надо поправить в документации, чтобы не заводить путаницу. Но в первом приближении это обычно и есть количество сообщений. Можно timestamp новейшего сообщения в эхе подставлять, наши клиенты этот вариант съедят даже без переписывания кода.
AL> Ваши съедят, а мои подавятся. На базе x/c мои фетчеры вычисляют размер слайса.
Действительно, тут я ошибся. IDEC Mobile тоже подсчитывает слайсы по ним (хоть и более хитро), а ещё уведомления выдаёт :)
Важно, что поле только возрастает, и что на сервере после удаления сообщений значение /x/c не должно уменьшаться.
+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM
# Re: Протокол IDEC
Andrew Lobanov (tavern,1) → vit01 – 11:06:30 2018-10-12
vit01>>> Всё просто, поле по-хорошему increment only. А ещё клиентская часть обычно подстраховывается и скачивает индекс с запасом.
mirage>> Тогда это уже не количество сообщений будет, а что-то другое.
vit01> Надо поправить в документации, чтобы не заводить путаницу. Но в первом приближении это обычно и есть количество сообщений. Можно timestamp новейшего сообщения в эхе подставлять, наши клиенты этот вариант съедят даже без переписывания кода.
Ваши съедят, а мои подавятся. На базе x/c мои фетчеры вычисляют размер слайса.
mirage>> Ну я сейчас запустил iitxt и он неслолько минут запросы слал по несколько сообщений, а мог бы и быстрее отработать.
vit01> Дефолт для клиентов - скачивать по 20 сообщений за раз (можно увеличить в настройках), а индекс получать пачками.
vit01> iitxt медленный, потому что он хитро парсит сообщения и что-то пересчитывает, это к автору клиента вопрос.
mirage>> Эха содержит список id сообщений. Если новые id добавляются только в конец,
mirage>> то фетчер может хранить id последнего полученного сообщения и запрашивать от него.
mirage>> Только возникнет проблема если это сообщение будет удалено.
vit01> Проблема не только в удалении, но и в том, что сообщения могут не сохранять порядок в индексе базы. То есть они могут быть перепутаны хронологически.
Да все эти варианты мы уже рассматривали и обсуждали. Начиная с лета 2014 и заканчивая обсуждением расширенной u/e. Пройденный этап, откинутые варианты. Нет смысла к ним возвращаться. К тому же до сих пор не было озвучено предполагаемых преимуществ перед текущим вариантом.
>> Читать далее
Andrew Lobanov (tavern,1) → vit01 – 11:06:30 2018-10-12
vit01>>> Всё просто, поле по-хорошему increment only. А ещё клиентская часть обычно подстраховывается и скачивает индекс с запасом.
mirage>> Тогда это уже не количество сообщений будет, а что-то другое.
vit01> Надо поправить в документации, чтобы не заводить путаницу. Но в первом приближении это обычно и есть количество сообщений. Можно timestamp новейшего сообщения в эхе подставлять, наши клиенты этот вариант съедят даже без переписывания кода.
Ваши съедят, а мои подавятся. На базе x/c мои фетчеры вычисляют размер слайса.
mirage>> Ну я сейчас запустил iitxt и он неслолько минут запросы слал по несколько сообщений, а мог бы и быстрее отработать.
vit01> Дефолт для клиентов - скачивать по 20 сообщений за раз (можно увеличить в настройках), а индекс получать пачками.
vit01> iitxt медленный, потому что он хитро парсит сообщения и что-то пересчитывает, это к автору клиента вопрос.
mirage>> Эха содержит список id сообщений. Если новые id добавляются только в конец,
mirage>> то фетчер может хранить id последнего полученного сообщения и запрашивать от него.
mirage>> Только возникнет проблема если это сообщение будет удалено.
vit01> Проблема не только в удалении, но и в том, что сообщения могут не сохранять порядок в индексе базы. То есть они могут быть перепутаны хронологически.
Да все эти варианты мы уже рассматривали и обсуждали. Начиная с лета 2014 и заканчивая обсуждением расширенной u/e. Пройденный этап, откинутые варианты. Нет смысла к ним возвращаться. К тому же до сих пор не было озвучено предполагаемых преимуществ перед текущим вариантом.
>> Читать далее
# Re: Протокол IDEC
vit01 (mira, 1) → mirage – 17:44:25 2018-10-11
vit01>> Всё просто, поле по-хорошему increment only. А ещё клиентская часть обычно подстраховывается и скачивает индекс с запасом.
mirage> Тогда это уже не количество сообщений будет, а что-то другое.
Надо поправить в документации, чтобы не заводить путаницу. Но в первом приближении это обычно и есть количество сообщений. Можно timestamp новейшего сообщения в эхе подставлять, наши клиенты этот вариант съедят даже без переписывания кода.
mirage> Ну я сейчас запустил iitxt и он неслолько минут запросы слал по несколько сообщений, а мог бы и быстрее отработать.
Дефолт для клиентов - скачивать по 20 сообщений за раз (можно увеличить в настройках), а индекс получать пачками.
iitxt медленный, потому что он хитро парсит сообщения и что-то пересчитывает, это к автору клиента вопрос.
mirage> Эха содержит список id сообщений. Если новые id добавляются только в конец,
mirage> то фетчер может хранить id последнего полученного сообщения и запрашивать от него.
mirage> Только возникнет проблема если это сообщение будет удалено.
>> Читать далее
vit01 (mira, 1) → mirage – 17:44:25 2018-10-11
vit01>> Всё просто, поле по-хорошему increment only. А ещё клиентская часть обычно подстраховывается и скачивает индекс с запасом.
mirage> Тогда это уже не количество сообщений будет, а что-то другое.
Надо поправить в документации, чтобы не заводить путаницу. Но в первом приближении это обычно и есть количество сообщений. Можно timestamp новейшего сообщения в эхе подставлять, наши клиенты этот вариант съедят даже без переписывания кода.
mirage> Ну я сейчас запустил iitxt и он неслолько минут запросы слал по несколько сообщений, а мог бы и быстрее отработать.
Дефолт для клиентов - скачивать по 20 сообщений за раз (можно увеличить в настройках), а индекс получать пачками.
iitxt медленный, потому что он хитро парсит сообщения и что-то пересчитывает, это к автору клиента вопрос.
mirage> Эха содержит список id сообщений. Если новые id добавляются только в конец,
mirage> то фетчер может хранить id последнего полученного сообщения и запрашивать от него.
mirage> Только возникнет проблема если это сообщение будет удалено.
>> Читать далее
# Re: Кто какой софт для ноды использует?
Andrew Lobanov (tavern,1) → mirage – 17:21:55 2018-10-11
mirage> Сабж.
В данный момент это iing, но в планах переход на новый софт, который у меня подвис в процессе и будет релизнут, видимо, уже только в следующем году. Он готов, но ещё не доделан вебинтерфейс. На этот раз на golang =)
+++ Caesium/0.4 RC1
Andrew Lobanov (tavern,1) → mirage – 17:21:55 2018-10-11
mirage> Сабж.
В данный момент это iing, но в планах переход на новый софт, который у меня подвис в процессе и будет релизнут, видимо, уже только в следующем году. Он готов, но ещё не доделан вебинтерфейс. На этот раз на golang =)
+++ Caesium/0.4 RC1
# Re: Кто какой софт для ноды использует?
vit01 (mira, 1) → mirage – 17:28:17 2018-10-11
Андрей пользует собственный iing
Пётр - патченный iing
У меня своя нода ii-php
У Дениса своя реализация на базе elasticsearch
По сути единой эталонной серверной части у нас нет, каждый пишет её себе сам. Во-первых, свой код проще писать, чем читать чужой. Во-вторых, простота протокола позволяет такую роскошь как "а лучше свою напишу"
+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM
vit01 (mira, 1) → mirage – 17:28:17 2018-10-11
Андрей пользует собственный iing
Пётр - патченный iing
У меня своя нода ii-php
У Дениса своя реализация на базе elasticsearch
По сути единой эталонной серверной части у нас нет, каждый пишет её себе сам. Во-первых, свой код проще писать, чем читать чужой. Во-вторых, простота протокола позволяет такую роскошь как "а лучше свою напишу"
+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM
# Re: Кто какой софт для ноды использует?
Peter (syscall,1) → mirage – 15:12:55 2018-10-11
> Кто какой софт для ноды использует?
Я на https://github.com/gl00my/iing
Это запатченный на мои нужды iing.
Peter (syscall,1) → mirage – 15:12:55 2018-10-11
> Кто какой софт для ноды использует?
Я на https://github.com/gl00my/iing
Это запатченный на мои нужды iing.
# Кто какой софт для ноды использует?
mirage (syscall,44) → All – 14:14:58 2018-10-11
Сабж.
+++ Caesium/0.4 RC1
mirage (syscall,44) → All – 14:14:58 2018-10-11
Сабж.
+++ Caesium/0.4 RC1
# Re: Протокол IDEC
Andrew Lobanov (tavern,1) → mirage – 07:51:38 2018-10-10
mirage> Этот x/c нужен же для u/e?
Нет.
mirage> Смотрю в описание u/e: смещение указывается одно для всех эх в запросе?
mirage> Получается не оптимально. Ведь в разных эхах разное количество апдейтов.
Да, но зато никакой дополнительной нагрузки на ноду.
mirage> А вот например эхаA:idA/эхаB:idB/.... будет оптимальнее.
Несколько килобайт (это в худшем случае) лишней информации без переписывания ноды. И узлу не придётся шерстить толстые инндексы на каждый чих.
+++ Caesium/0.4 RC1
+++ Лично я вижу в этом перст судьбы — шли по лесу и встретили программиста.
Andrew Lobanov (tavern,1) → mirage – 07:51:38 2018-10-10
mirage> Этот x/c нужен же для u/e?
Нет.
mirage> Смотрю в описание u/e: смещение указывается одно для всех эх в запросе?
mirage> Получается не оптимально. Ведь в разных эхах разное количество апдейтов.
Да, но зато никакой дополнительной нагрузки на ноду.
mirage> А вот например эхаA:idA/эхаB:idB/.... будет оптимальнее.
Несколько килобайт (это в худшем случае) лишней информации без переписывания ноды. И узлу не придётся шерстить толстые инндексы на каждый чих.
+++ Caesium/0.4 RC1
+++ Лично я вижу в этом перст судьбы — шли по лесу и встретили программиста.
# Re: Протокол IDEC
Andrew Lobanov (tavern,1) → mirage – 07:51:37 2018-10-10
mirage> Решаемая задача: скачать обновление индекса.
mirage> Предложеное решение: запросить все что после конкретного ID.
mirage> Я не понял зачем ты спросил в этом случае про слайсы, они тут не нужны.
mirage> Я подумал слайсы нужны что бы скачивать обновление индекса по частям, если например есть опасения в слишком большом обновлении индекса.
mirage> Получается, если надо качать все обновление индекса за раз, то один запрос.
Можешь предложить красивое решение?
Вот, например, я подписан на несколько эх. Тогда я просто отправляю запрос x/c/bash.rss/pipe.2032/idec.talks и потом делаю u/e/bash.rss/pipe.2032/idec.talks/-50:50. Передавать что-то типа x/e/bash.rss/<id1>/pipe.2032/<id2>/idec.talks/<id3>?
Я ничего не вижу плохого в более других вариантах, если это будет нужно кому-то. Но пока я не вижу кому и зачем может быть нужно то, что ты предлагаешь. Какую практическую проблему ты пыташься решить?
+++ Caesium/0.4 RC1
+++ Лично я вижу в этом перст судьбы — шли по лесу и встретили программиста.
Andrew Lobanov (tavern,1) → mirage – 07:51:37 2018-10-10
mirage> Решаемая задача: скачать обновление индекса.
mirage> Предложеное решение: запросить все что после конкретного ID.
mirage> Я не понял зачем ты спросил в этом случае про слайсы, они тут не нужны.
mirage> Я подумал слайсы нужны что бы скачивать обновление индекса по частям, если например есть опасения в слишком большом обновлении индекса.
mirage> Получается, если надо качать все обновление индекса за раз, то один запрос.
Можешь предложить красивое решение?
Вот, например, я подписан на несколько эх. Тогда я просто отправляю запрос x/c/bash.rss/pipe.2032/idec.talks и потом делаю u/e/bash.rss/pipe.2032/idec.talks/-50:50. Передавать что-то типа x/e/bash.rss/<id1>/pipe.2032/<id2>/idec.talks/<id3>?
Я ничего не вижу плохого в более других вариантах, если это будет нужно кому-то. Но пока я не вижу кому и зачем может быть нужно то, что ты предлагаешь. Какую практическую проблему ты пыташься решить?
+++ Caesium/0.4 RC1
+++ Лично я вижу в этом перст судьбы — шли по лесу и встретили программиста.
# Re: Протокол IDEC
mirage (syscall,44) → Andrew Lobanov – 07:19:48 2018-10-10
AL>>> Тоже кривое решение как мне видится. Если порыться в архивах, то можно найти конкретные примеры потерь сообщений.
mirage>> Тут много вопросов о том кто какое время берет и с каким сравнивает, как влияет на это разница во времени на нодах и время обработки запроса. С ID проще, строже.
AL> Ещё проще так, как есть. Потому что оно уже есть и оно простое.
AL> Берём x/c по конференциям в подписке, сраниваем со старыми значениями с прошлой сессии, считаем максимальную разницу и одним запросом забираем индекс одним запросом. То есть два запроса на определение индекса при любом объёме новых сообщений.
Этот x/c нужен же для u/e?
Смотрю в описание u/e: смещение указывается одно для всех эх в запросе?
Получается не оптимально. Ведь в разных эхах разное количество апдейтов.
А вот например эхаA:idA/эхаB:idB/.... будет оптимальнее.
+++ Caesium/0.4 RC1
mirage (syscall,44) → Andrew Lobanov – 07:19:48 2018-10-10
AL>>> Тоже кривое решение как мне видится. Если порыться в архивах, то можно найти конкретные примеры потерь сообщений.
mirage>> Тут много вопросов о том кто какое время берет и с каким сравнивает, как влияет на это разница во времени на нодах и время обработки запроса. С ID проще, строже.
AL> Ещё проще так, как есть. Потому что оно уже есть и оно простое.
AL> Берём x/c по конференциям в подписке, сраниваем со старыми значениями с прошлой сессии, считаем максимальную разницу и одним запросом забираем индекс одним запросом. То есть два запроса на определение индекса при любом объёме новых сообщений.
Этот x/c нужен же для u/e?
Смотрю в описание u/e: смещение указывается одно для всех эх в запросе?
Получается не оптимально. Ведь в разных эхах разное количество апдейтов.
А вот например эхаA:idA/эхаB:idB/.... будет оптимальнее.
+++ Caesium/0.4 RC1
# Re: Протокол IDEC
mirage (syscall,44) → Andrew Lobanov – 07:08:56 2018-10-10
AL>>> Тоже кривое решение как мне видится. Если порыться в архивах, то можно найти конкретные примеры потерь сообщений.
mirage>> Тут много вопросов о том кто какое время берет и с каким сравнивает, как влияет на это разница во времени на нодах и время обработки запроса. С ID проще, строже.
AL> Ещё проще так, как есть. Потому что оно уже есть и оно простое.
AL> Берём x/c по конференциям в подписке, сраниваем со старыми значениями с прошлой сессии, считаем максимальную разницу и одним запросом забираем индекс одним запросом. То есть два запроса на определение индекса при любом объёме новых сообщений.
Решаемая задача: скачать обновление индекса.
Предложеное решение: запросить все что после конкретного ID.
Я не понял зачем ты спросил в этом случае про слайсы, они тут не нужны.
Я подумал слайсы нужны что бы скачивать обновление индекса по частям, если например есть опасения в слишком большом обновлении индекса.
Получается, если надо качать все обновление индекса за раз, то один запрос.
+++ Caesium/0.4 RC1
mirage (syscall,44) → Andrew Lobanov – 07:08:56 2018-10-10
AL>>> Тоже кривое решение как мне видится. Если порыться в архивах, то можно найти конкретные примеры потерь сообщений.
mirage>> Тут много вопросов о том кто какое время берет и с каким сравнивает, как влияет на это разница во времени на нодах и время обработки запроса. С ID проще, строже.
AL> Ещё проще так, как есть. Потому что оно уже есть и оно простое.
AL> Берём x/c по конференциям в подписке, сраниваем со старыми значениями с прошлой сессии, считаем максимальную разницу и одним запросом забираем индекс одним запросом. То есть два запроса на определение индекса при любом объёме новых сообщений.
Решаемая задача: скачать обновление индекса.
Предложеное решение: запросить все что после конкретного ID.
Я не понял зачем ты спросил в этом случае про слайсы, они тут не нужны.
Я подумал слайсы нужны что бы скачивать обновление индекса по частям, если например есть опасения в слишком большом обновлении индекса.
Получается, если надо качать все обновление индекса за раз, то один запрос.
+++ Caesium/0.4 RC1
# Re: Протокол IDEC
mirage (syscall,44) → Andrew Lobanov – 06:15:44 2018-10-10
AL> Это будет уже совсем другой набор договорённостей. Можно придумать что угодно, но есть такая вещь, как совместимость. В любом случае, преимуществ такого подхода пока не видно. Куда нужнее личная переписка КМК.
По нетмайлу готов proposal. Просто чтобы внимание не распылять по одной теме пишу :)
+++ Caesium/0.4 RC1
mirage (syscall,44) → Andrew Lobanov – 06:15:44 2018-10-10
AL> Это будет уже совсем другой набор договорённостей. Можно придумать что угодно, но есть такая вещь, как совместимость. В любом случае, преимуществ такого подхода пока не видно. Куда нужнее личная переписка КМК.
По нетмайлу готов proposal. Просто чтобы внимание не распылять по одной теме пишу :)
+++ Caesium/0.4 RC1
# Re: Caesium и файлэхи
Andrew Lobanov (tavern,1) → mirage – 06:23:34 2018-10-10
Peter>>> Фехи не поддерживаются этой нодой (syscall) :)
mirage>> Я знаю, поэтому пытаюсь качать с http://idec.spline-online.tk/
mirage> Кажется я доменом ошибся. В одной доке .tk в другой .ml
mirage> В итоге в клиенте одно, в браузере другое :)
Да. tk я проморгал =(
+++ Caesium/0.4 RC1
+++ Лично я вижу в этом перст судьбы — шли по лесу и встретили программиста.
Andrew Lobanov (tavern,1) → mirage – 06:23:34 2018-10-10
Peter>>> Фехи не поддерживаются этой нодой (syscall) :)
mirage>> Я знаю, поэтому пытаюсь качать с http://idec.spline-online.tk/
mirage> Кажется я доменом ошибся. В одной доке .tk в другой .ml
mirage> В итоге в клиенте одно, в браузере другое :)
Да. tk я проморгал =(
+++ Caesium/0.4 RC1
+++ Лично я вижу в этом перст судьбы — шли по лесу и встретили программиста.
# Re: Протокол IDEC
Andrew Lobanov (tavern,1) → mirage – 06:23:33 2018-10-10
AL>> Тоже кривое решение как мне видится. Если порыться в архивах, то можно найти конкретные примеры потерь сообщений.
mirage> Тут много вопросов о том кто какое время берет и с каким сравнивает, как влияет на это разница во времени на нодах и время обработки запроса. С ID проще, строже.
Ещё проще так, как есть. Потому что оно уже есть и оно простое.
Берём x/c по конференциям в подписке, сраниваем со старыми значениями с прошлой сессии, считаем максимальную разницу и одним запросом забираем индекс одним запросом. То есть два запроса на определение индекса при любом объёме новых сообщений.
+++ Caesium/0.4 RC1
+++ Лично я вижу в этом перст судьбы — шли по лесу и встретили программиста.
Andrew Lobanov (tavern,1) → mirage – 06:23:33 2018-10-10
AL>> Тоже кривое решение как мне видится. Если порыться в архивах, то можно найти конкретные примеры потерь сообщений.
mirage> Тут много вопросов о том кто какое время берет и с каким сравнивает, как влияет на это разница во времени на нодах и время обработки запроса. С ID проще, строже.
Ещё проще так, как есть. Потому что оно уже есть и оно простое.
Берём x/c по конференциям в подписке, сраниваем со старыми значениями с прошлой сессии, считаем максимальную разницу и одним запросом забираем индекс одним запросом. То есть два запроса на определение индекса при любом объёме новых сообщений.
+++ Caesium/0.4 RC1
+++ Лично я вижу в этом перст судьбы — шли по лесу и встретили программиста.
# Re: Протокол IDEC
Andrew Lobanov (tavern,1) → mirage – 06:23:33 2018-10-10
mirage> Фетчер знает сколько ему надо максимум запросить чтобы не подавиться, по каким-либо причинам.
Сколько угодно =)
mirage> Допустим это 100 idшников.
mirage> Он запрашивает 100 записей от последнего id. В итоге будет 2 случая:
mirage> 1. Придет меньше 100 id - запоминаем последний, конец.
mirage> 2. Придет 100 id - запоминаем последний и запрашиваем снова 100 от него.
Этот вариант мы тоже рассматривали. Но пока думали как это сделать так, чтобы не плодить сущностей и не сломать совместимость с ii (ты до сих пор можешь взять ii-client-03 и пользоваться им), соорудили эту штуку на том, что было. Получилось просто и без излишеств.
AL>> Это будет уже совсем другой набор договорённостей. Можно придумать что угодно, но есть такая вещь, как совместимость. В любом случае, преимуществ такого подхода пока не видно. Куда нужнее личная переписка КМК.
mirage> Это было предложение на вопрос в дискуссии о не совсем ясном числе в ответе API. Ну и это может быть расширением.
Я понимаю, что предложение, но не понимаю в чём будет выигрыш? Можно и аутбаунды сделать а-ля FTN, но пользы нет.
>> Читать далее
Andrew Lobanov (tavern,1) → mirage – 06:23:33 2018-10-10
mirage> Фетчер знает сколько ему надо максимум запросить чтобы не подавиться, по каким-либо причинам.
Сколько угодно =)
mirage> Допустим это 100 idшников.
mirage> Он запрашивает 100 записей от последнего id. В итоге будет 2 случая:
mirage> 1. Придет меньше 100 id - запоминаем последний, конец.
mirage> 2. Придет 100 id - запоминаем последний и запрашиваем снова 100 от него.
Этот вариант мы тоже рассматривали. Но пока думали как это сделать так, чтобы не плодить сущностей и не сломать совместимость с ii (ты до сих пор можешь взять ii-client-03 и пользоваться им), соорудили эту штуку на том, что было. Получилось просто и без излишеств.
AL>> Это будет уже совсем другой набор договорённостей. Можно придумать что угодно, но есть такая вещь, как совместимость. В любом случае, преимуществ такого подхода пока не видно. Куда нужнее личная переписка КМК.
mirage> Это было предложение на вопрос в дискуссии о не совсем ясном числе в ответе API. Ну и это может быть расширением.
Я понимаю, что предложение, но не понимаю в чём будет выигрыш? Можно и аутбаунды сделать а-ля FTN, но пользы нет.
>> Читать далее
# Re: Протокол IDEC
mirage (syscall,44) → Andrew Lobanov – 06:01:49 2018-10-10
>>> В следующий раз фетчер спрашивает у ноды: дай все что после ID3.
Peter>> Согласен. У Ромы в его gk11 (было такое развитие ii с его стороны) был запрос по времени. Типа, дай всё что было после такого-то времени. И это лучше, конечно. Но так уж получилось.
AL> Тоже кривое решение как мне видится. Если порыться в архивах, то можно найти конкретные примеры потерь сообщений.
Тут много вопросов о том кто какое время берет и с каким сравнивает, как влияет на это разница во времени на нодах
и время обработки запроса. С ID проще, строже.
+++ Caesium/0.4 RC1
mirage (syscall,44) → Andrew Lobanov – 06:01:49 2018-10-10
>>> В следующий раз фетчер спрашивает у ноды: дай все что после ID3.
Peter>> Согласен. У Ромы в его gk11 (было такое развитие ii с его стороны) был запрос по времени. Типа, дай всё что было после такого-то времени. И это лучше, конечно. Но так уж получилось.
AL> Тоже кривое решение как мне видится. Если порыться в архивах, то можно найти конкретные примеры потерь сообщений.
Тут много вопросов о том кто какое время берет и с каким сравнивает, как влияет на это разница во времени на нодах
и время обработки запроса. С ID проще, строже.
+++ Caesium/0.4 RC1
# Re: Протокол IDEC
mirage (syscall,44) → Andrew Lobanov – 06:01:48 2018-10-10
AL>>> А если между запросами пришло не одно сообщение, а несколько десятков? Снова тянуть весь индекс, который может весить мегабайты? Так я точно знаю насколько изменилась длина индекса с прошлой сессии и могу скачать соответствующий слайс индекса.
mirage>> Несколько десятков ID и получит. Только новое.
AL> Каким образом фетчер узнает по одному ID сколько ему сообщений зпрашивать в слайсе? Вот он запомнил, что поледним получил сообщение mzu2V8Iz3VIAVeDg0TOi. Как он узнает сколько именно тянуть?
Фетчер знает сколько ему надо максимум запросить чтобы не подавиться, по каким-либо причинам.
Допустим это 100 idшников.
Он запрашивает 100 записей от последнего id. В итоге будет 2 случая:
1. Придет меньше 100 id - запоминаем последний, конец.
2. Придет 100 id - запоминаем последний и запрашиваем снова 100 от него.
mirage>> Вот есть на ноде в эхе сообщения: ID1 ID2 ID3.
mirage>> Фетчер качает их и запоминает что последнее скачаное для этой ноды-эхи - ID3.
mirage>> На ноду еще приходят сообщения: ID4 ID5 ID6.
mirage>> В следующий раз фетчер спрашивает у ноды: дай все что после ID3.
mirage>> И получает ID4 ID5 ID6 и запоминает ID6.
>> Читать далее
mirage (syscall,44) → Andrew Lobanov – 06:01:48 2018-10-10
AL>>> А если между запросами пришло не одно сообщение, а несколько десятков? Снова тянуть весь индекс, который может весить мегабайты? Так я точно знаю насколько изменилась длина индекса с прошлой сессии и могу скачать соответствующий слайс индекса.
mirage>> Несколько десятков ID и получит. Только новое.
AL> Каким образом фетчер узнает по одному ID сколько ему сообщений зпрашивать в слайсе? Вот он запомнил, что поледним получил сообщение mzu2V8Iz3VIAVeDg0TOi. Как он узнает сколько именно тянуть?
Фетчер знает сколько ему надо максимум запросить чтобы не подавиться, по каким-либо причинам.
Допустим это 100 idшников.
Он запрашивает 100 записей от последнего id. В итоге будет 2 случая:
1. Придет меньше 100 id - запоминаем последний, конец.
2. Придет 100 id - запоминаем последний и запрашиваем снова 100 от него.
mirage>> Вот есть на ноде в эхе сообщения: ID1 ID2 ID3.
mirage>> Фетчер качает их и запоминает что последнее скачаное для этой ноды-эхи - ID3.
mirage>> На ноду еще приходят сообщения: ID4 ID5 ID6.
mirage>> В следующий раз фетчер спрашивает у ноды: дай все что после ID3.
mirage>> И получает ID4 ID5 ID6 и запоминает ID6.
>> Читать далее
# Re: Caesium и файлэхи
mirage (syscall,44) → mirage – 05:48:47 2018-10-10
Peter>> Фехи не поддерживаются этой нодой (syscall) :)
mirage> Я знаю, поэтому пытаюсь качать с http://idec.spline-online.tk/
Кажется я доменом ошибся. В одной доке .tk в другой .ml
В итоге в клиенте одно, в браузере другое :)
+++ Caesium/0.4 RC1
mirage (syscall,44) → mirage – 05:48:47 2018-10-10
Peter>> Фехи не поддерживаются этой нодой (syscall) :)
mirage> Я знаю, поэтому пытаюсь качать с http://idec.spline-online.tk/
Кажется я доменом ошибся. В одной доке .tk в другой .ml
В итоге в клиенте одно, в браузере другое :)
+++ Caesium/0.4 RC1
# Re: Протокол IDEC
Andrew Lobanov (tavern,1) → Peter – 05:43:50 2018-10-10
>> В следующий раз фетчер спрашивает у ноды: дай все что после ID3.
Peter> Согласен. У Ромы в его gk11 (было такое развитие ii с его стороны) был запрос по времени. Типа, дай всё что было после такого-то времени. И это лучше, конечно. Но так уж получилось.
Тоже кривое решение как мне видится. Если порыться в архивах, то можно найти конкретные примеры потерь сообщений.
+++ Caesium/0.4 RC1
+++ Лично я вижу в этом перст судьбы — шли по лесу и встретили программиста.
Andrew Lobanov (tavern,1) → Peter – 05:43:50 2018-10-10
>> В следующий раз фетчер спрашивает у ноды: дай все что после ID3.
Peter> Согласен. У Ромы в его gk11 (было такое развитие ii с его стороны) был запрос по времени. Типа, дай всё что было после такого-то времени. И это лучше, конечно. Но так уж получилось.
Тоже кривое решение как мне видится. Если порыться в архивах, то можно найти конкретные примеры потерь сообщений.
+++ Caesium/0.4 RC1
+++ Лично я вижу в этом перст судьбы — шли по лесу и встретили программиста.