Блин, мне всё равно кажется, что нужны именно очереди, без них никуда

Куда ж без изобретения колеса и велосипеда

напиши в @android_ru

Но 200 в минуту это как-то маловато, особенно если пользователя нет долго в сети, нет?

Там ща лимит 1000 на пользователя в ОЧЕРЕДИ

тебе этого пиздец как достаточно

Разве в телеграме на пушах? Точно не на сокетах? Надо чекнуть исходники.

Разве в телеграме на пушах? Точно не на сокетах? Надо чекнуть исходники.

Хотя не, они же могут и то и другое

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

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

Я тоже так хотел сделать

Разве в телеграме на пушах? Точно не на сокетах? Надо чекнуть исходники.

А как по твоему блокировку тг обходил, умник

Блин, зачем меняешь сообщение, теперь разговора нить сломана

А как по твоему блокировку тг обходил, умник

Но можно и не хамить.

А как по твоему блокировку тг обходил, умник

А вот это аргумент

Но можно и не хамить.

Сорян =)

Там ща лимит 1000 на пользователя в ОЧЕРЕДИ

Я же могу теоретически отправить пользователю больше 1000 сообщений пока он офлайн, верно? И впринципе это не так сложно

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

Я же могу теоретически отправить пользователю больше 1000 сообщений пока он офлайн, верно? И впринципе это не так сложно

Да и тут 2 проблемы, первые сообщения чистятся, когда отправляешь дальше

И надо на мобиле отхендлить перебор

И надо на мобиле отхендлить перебор

?

В принципе апи для отлова этого ада есть

Даже в доках написано

А если заплатить, то очередь увеличат?

?

Ну 1000 пушей в мобилу вывалилось, охоенеешь хендлить, подависнет все если в мейнтреде такое делать

А если заплатить, то очередь увеличат?

Нет

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

Жёстко

А юзал RabbitMQ?

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

Скорее рестом, пуши к слову на сокетах под капотом

А если заплатить, то очередь увеличат?

Плакала половина тредпула

А юзал RabbitMQ?

Это серверное счастье же, зачем оно на ведре

Плакала половина тредпула

Там в одном потоке ж все

Это серверное счастье же, зачем оно на ведре

Я предполагал сделать так: реализовать очередь на сервере, а Android клиенты будут подписываться на обновление очереди, так можно сделать?

Так что плакала половина популяции пользователей

Я предполагал сделать так: реализовать очередь на сервере, а Android клиенты будут подписываться на обновление очереди, так можно сделать?

Можно, но overkill

Пуши используются, не потому что никто не может свой аналог навернуть

А просто чтоб аккум не посадить за полчаса

Сжалься над юзверями

А просто чтоб аккум не посадить за полчаса

Вооот, я это и учитываю) Когда приложение работает используется RabbitMQ, когда закрыто - пуши

Ну или павербанк в комплекте с приложением выдавай

Вооот, я это и учитываю) Когда приложение работает используется RabbitMQ, когда закрыто - пуши

А крол тогда зачем вообще?

Ну или павербанк в комплекте с приложением выдавай

Я так и хожу в последнее время

Я так и хожу в последнее время

Я и не сомневался

Кстати

Я и не сомневался

Но только пока что ничего из МОИХ приложений в фоне не работает

Как ты такой треш на 8 ведре пустишь?

Форграундным сервисом?

А в чём сложность?

Какой треш?

Ограничения на бекграундную работу же

Так что у пользователя будет нотификация сверху, о том, что их аккум жрешь лично ты

Либо нихрена пахать не будет

Работа с Rabbit в сервисе будет, а ограничения касаются только когда приложение выкинуто из Task'a, разве нет?

Работа с Rabbit в сервисе будет, а ограничения касаются только когда приложение выкинуто из Task'a, разве нет?

Ну так да

Только двойная работа же

Получается обработку пушей и так и так делать

И плюс крол еще

Тут тебе уже себя не жалко

Я тут ещё боюсь, что могут закидать сообщениями и сервер вырубится, бывают же всякие DDOS атаки

Я тут ещё боюсь, что могут закидать сообщениями и сервер вырубится, бывают же всякие DDOS атаки

Защиту от дудоса и так делать отдельно

А кролик обеспечивает надёжность в таких ситуациях

Если не сложно прочитайте маленькую статейку) Какие аргументы могут быть против RabbitMQ? https://smartum.pro/ru/blog-ru/ispolzovanie-rabbitmq-v-messengere/

Если не сложно прочитайте маленькую статейку) Какие аргументы могут быть против RabbitMQ? https://smartum.pro/ru/blog-ru/ispolzovanie-rabbitmq-v-messengere/

Ты не developer advocate часом? "У вас есть минутка поговорить о либе нашей - rabbitMQ"

XD

Короче может и работает, но только с форграундным сервисом, т.е. с 8 андроида без него пахать не будет

Разве что навернуть враппер поверх пушей для него

ERROR: S client not available

Ну и весит 500кб, что довольно много для андроида, учитывая адское количество методов

А чем обычные сокеты + брокер типа RabbitMq не угодил?

как только получил сообщениее в сокет - ответил на сервер и ack-нул

Ещё раз, работу с выключенным приложением как делать будешь?

если проблема с транспортом или ответом - nack

Спасибо я в курсе как tcp умеет

Проблема то не в этом

а че там когда консьюмера нету - в очередь ничего не летит?

щас аж доку гляну...

а че там когда консьюмера нету - в очередь ничего не летит?

Летит, но Андрей имеет ввиду, что пока приложение включено читать ничего оно не будет, и придётся уже реализовать Push уведомления

Ребята, давайте завойтим вот этого вот ежа https://youtrack.jetbrains.com/issue/CPP-4141

Чем отличается чат реального времени от другого чата?

Летит, но Андрей имеет ввиду, что пока приложение включено читать ничего оно не будет, и придётся уже реализовать Push уведомления

Выключено*

По мне так любой чат в реальном времени

Выключено*

Да, опечатка, спасибо)

Летит, но Андрей имеет ввиду, что пока приложение включено читать ничего оно не будет, и придётся уже реализовать Push уведомления

не силен в аднроид, но реализововал приблизительно подобное для фронта, как только клиент присоединяется на сокет, шлет свой идентификатор, и инициирует получение сообщение из очередей адресованных емк. У WS есть ping/pong для этих целей, чтобы понимать живой ли клиент или нет.

если живой клиент - продолжаем слать ему оставшиеся сообщеня, нет ответа, не шлем

как-то так

просто браузер ping по умолчанию шлет

как-то так

Я тоже сначала думал так сделать, но было похоже на костыль, потом встретил такую схему

И понял, что это то что нужно

Я тоже сначала думал так сделать, но было похоже на костыль, потом встретил такую схему

есть рабочее приложение, правда пока хайлоада там не было и нагрузочное не делали...а в остальном работает)

клиент сам в шину лезет??

А если у меня 1000 пользователей, это получается 1000 очередей будет?

клиент сам в шину лезет??

Да

Мне кажется это логичнее

да, а в чем проблема с очередями?

да, а в чем проблема с очередями?

Может работать будет как черепашка

не надо так. обычно message broker спрятан в инфраструктуре а клиенты общаются через api gateway (просто общее название). там сильно удобней скейлить и проч.

Может работать будет как черепашка

не думаю, многие вообще как транспорт юзают шину...и-то как-то работает