Судя по всему вы рассматриваете Centrifuge(o) только как решение для построения чатов – это не так, это скорее просто real-time транспорт с некоторыми вспомогательными примитивами вроде подписок на каналы, восстановления истории в канале после короткого дисконнекта, масштабирования на несколько инстансов. На основе Центрифуги можно написать много разных вещей, в том числе и чат, но для этого нужно поверх того что есть еще на бекенде реализовать много бизнес-логики конкретного приложения — в том числе unread count и т.д. В случае использования библиотеки вам, например, придется на бекенде реализовать методы подтверждения о прочтении сообщений, метод получения счетчика непрочитанных — и вызывать их когда нужно (можно через RPC-вызов через вебсокет, можно как-то иначе).
В общем расчет такой — если вам нужно писать сложное реал-тайм приложение (а не просто например пушить в страничку клиента изменяющиеся в реальном времени котировки акций), то вся бизнес-логика приложения отдается на откуп вам — а Центрифуга это только транспорт, способ быстро доставить какое-то сообщение клиенту или от клиента.
Ощущение, что вы намеренно обошли стороной все мои достаточно конкретные вопросы. Websocket — это протокол поверх TCP с минимальным оверхедом. Какие-то дополнительные затраты по сравнению с чистым TCP есть на начальный upgrade по HTTP — но далее это TCP-сессия. Ничего магического facebook и telegram не используют — точно также в качестве транспорта используют TCP.
В таком виде это достаточно голословное утверждение. Можете привести доказательства? О каких известных реализациях идет речь? Что на ваш взгляд нужно использовать вместо?
Редис будет в том же виде за исключением публикации новых сообщений через очередь в нем – эта возможность была не совсем верна в разрезе обработки ошибок при публикации и недетерминированной задержки перед отправкой клиентам, поэтому решил убрать – для публикации теперь HTTP или GRPC API. В библиотеке кстати вот так Redis можно использовать.
Меняется ли логика работы (токены и все такое)?
Меняется механизм генерации токена подключения и токена приватных подписок с ручной генерации токена (то есть использования вот такого кода) на JWT. В остальном все то же самое. JWT в том числе позволяет избавиться от болей связанных с тем как правильно info в виде JSON-строки прокинуть в Центрифугу через шаблонизаторы.
Нет ли желания делать лаунчер?
Пакеты для дистрибутивов Linux, которые используют systemd уже давно есть. Плюс docker-image тоже есть.
У библиотеки совсем мало описания и документации сейчас – еще буду дописывать. Ну и пример в README библиотеки согласен нужен.
Да, тогда join/leave на сервере единственный выход сейчас… Как вариант можно слушать Редис на предмет join/leave сообщений — но это внутренний протокол. Оба варианта не красивые. В теории вебхуки от Centrifugo бекенду могли бы помочь – но именно этого я старался избегать — появляется связность, много запросов, дополнительная логика отправки. Так что в целом когда нужно совершать действия при дисконнекте клиента лучше Centrifugo не использовать.
Спасибо:) А отправка AJAX запроса с async: false с клиента при закрытии таба (событие onbeforeunload) не подойдет ли случаем для этой цели? Это проще чем отлавливать событие выхода на серверной стороне?
Спасибо! На самом деле иногда все же нужно обновлять:) Например, в недавнем прошлом обнаружилось, что при нескольких подряд разрывах соединения с Redis-ом состояние подписок не восстанавливалось корректно –соответственно, сообщения могли перестать доходить до клиентов. Хорошо, что вы не столкнулись – по сути это воспроизводилось только в той инсталляции, о которой я написал в начале статьи (там очень большое количество активных каналов, на которые нужно переподписываться при реконнекте к Редису).
Ну это всегда trade-off, в общем случае, используя open-source решение (Centrifugo и т.д.) на своем бэкенде можно столкнуться с подобными же проблемами. Наверное, выбирая решение, нужно исходить из «а чего мне будет стоить от него отказаться в определенный момент».
В этом примере невозможна ситуация, когда close(done) выполнится перед тем как воркерами будут получены все данные из wq. Потому что канал wq небуферизованный, до close(done) управление дойдет только после того как последнее значение будет отправлено в канал wq и вычитано в воркере (потому что согласно go memory model: A receive from an unbuffered channel happens before the send on that channel completes).
Если у wq будет буффер — тогда поведение недетерминировано и воркеры могут завершиться до выполнения всей работы. В этом случае как-то по-другому нужно написать код.
Wadik привет! Упор на PUSH вытекает из концепта Центрифуги — логика приложения остается в приложении — проверка прав, сохранение данных и т.д. Это позволяет Центрифуге работать в связке с бекендом на любом языке.
Кмк выгоду от полнодуплексного общения с клиентом можно почувствовать, если обработка входящих сообщений от клиента происходит тут же в процессе, в котором находится хендлер вебсокет-соединения, то есть на самом бекенде, а не в Центрифуге. Вариант с промежуточной очередью сообщений от клиентов, из которой будет читать приложение, сводит на нет все эти преимущества. Если действительно нужно полнодуплексное общение — то, наверное, Центрифуга не лучший вариант и нужно смотреть в сторону фреймворков на том языке, на котором написан бекенд — для более тесной интеграции.
Redis используется для некоторых фич — таких как presence и кеш сообщений в каналах. По большому счету внутри Центрифуги жесткой привязки к Редису нет. Я сейчас делаю рефакторинг, который в теории позволит использовать любой PUB/SUB провайдер и любую бд для presence/history данных. Но это потребует написания кода, который все это будет имплементировать. Для Редиса этот код уже есть, соответственно.
Судя по всему вы рассматриваете Centrifuge(o) только как решение для построения чатов – это не так, это скорее просто real-time транспорт с некоторыми вспомогательными примитивами вроде подписок на каналы, восстановления истории в канале после короткого дисконнекта, масштабирования на несколько инстансов. На основе Центрифуги можно написать много разных вещей, в том числе и чат, но для этого нужно поверх того что есть еще на бекенде реализовать много бизнес-логики конкретного приложения — в том числе unread count и т.д. В случае использования библиотеки вам, например, придется на бекенде реализовать методы подтверждения о прочтении сообщений, метод получения счетчика непрочитанных — и вызывать их когда нужно (можно через RPC-вызов через вебсокет, можно как-то иначе).
В общем расчет такой — если вам нужно писать сложное реал-тайм приложение (а не просто например пушить в страничку клиента изменяющиеся в реальном времени котировки акций), то вся бизнес-логика приложения отдается на откуп вам — а Центрифуга это только транспорт, способ быстро доставить какое-то сообщение клиенту или от клиента.
Редис будет в том же виде за исключением публикации новых сообщений через очередь в нем – эта возможность была не совсем верна в разрезе обработки ошибок при публикации и недетерминированной задержки перед отправкой клиентам, поэтому решил убрать – для публикации теперь HTTP или GRPC API. В библиотеке кстати вот так Redis можно использовать.
Меняется механизм генерации токена подключения и токена приватных подписок с ручной генерации токена (то есть использования вот такого кода) на JWT. В остальном все то же самое. JWT в том числе позволяет избавиться от болей связанных с тем как правильно info в виде JSON-строки прокинуть в Центрифугу через шаблонизаторы.
Пакеты для дистрибутивов Linux, которые используют systemd уже давно есть. Плюс docker-image тоже есть.
У библиотеки совсем мало описания и документации сейчас – еще буду дописывать. Ну и пример в README библиотеки согласен нужен.
rewrite ^/centrifugo(.*) /$1 break;
– не хватало /, еще судя по всему мне нужно будет адреса статики поправить, чтобы веб-интерфейс работал без дополнительной конфигурации.
"port", через command-line аргументы вот такasync: falseс клиента при закрытии таба (событиеonbeforeunload) не подойдет ли случаем для этой цели? Это проще чем отлавливать событие выхода на серверной стороне?Если у wq будет буффер — тогда поведение недетерминировано и воркеры могут завершиться до выполнения всей работы. В этом случае как-то по-другому нужно написать код.
Кмк выгоду от полнодуплексного общения с клиентом можно почувствовать, если обработка входящих сообщений от клиента происходит тут же в процессе, в котором находится хендлер вебсокет-соединения, то есть на самом бекенде, а не в Центрифуге. Вариант с промежуточной очередью сообщений от клиентов, из которой будет читать приложение, сводит на нет все эти преимущества. Если действительно нужно полнодуплексное общение — то, наверное, Центрифуга не лучший вариант и нужно смотреть в сторону фреймворков на том языке, на котором написан бекенд — для более тесной интеграции.
Redis используется для некоторых фич — таких как presence и кеш сообщений в каналах. По большому счету внутри Центрифуги жесткой привязки к Редису нет. Я сейчас делаю рефакторинг, который в теории позволит использовать любой PUB/SUB провайдер и любую бд для presence/history данных. Но это потребует написания кода, который все это будет имплементировать. Для Редиса этот код уже есть, соответственно.