Comments 40
Спасибо большое! Центрифуга — огонь как полезна, если будет (легко) встраиваемая, то вообще красота.
Вопросы: redis будет? Раньше был, в статье ни слова, а тег стоит.
Меняется ли логика работы (токены и все такое)? Например, чтобы делать рассылки вообще всем, всем из некой группы, одному клиенту — вот такие кейсы переигрываются или остаются? JWT понял — но он отменяет всё или дополняет?
Нет ли желания делать лаунчер? Чтобы запускать не ./centrigugo в screen/tmux, а как то поумнее? Например service centrifugo start или ./centrifugo run.
На странице проекта centrifuge в README нет какого нибудь минимального main.go (видимо, этот гист gist.github.com/FZambia/2f1a38ae2dcb21e2c5937328253c29bf и нужен).
Вопросы: redis будет? Раньше был, в статье ни слова, а тег стоит.
Меняется ли логика работы (токены и все такое)? Например, чтобы делать рассылки вообще всем, всем из некой группы, одному клиенту — вот такие кейсы переигрываются или остаются? JWT понял — но он отменяет всё или дополняет?
Нет ли желания делать лаунчер? Чтобы запускать не ./centrigugo в screen/tmux, а как то поумнее? Например service centrifugo start или ./centrifugo run.
На странице проекта centrifuge в README нет какого нибудь минимального main.go (видимо, этот гист gist.github.com/FZambia/2f1a38ae2dcb21e2c5937328253c29bf и нужен).
Спасибо:)
Редис будет в том же виде за исключением публикации новых сообщений через очередь в нем – эта возможность была не совсем верна в разрезе обработки ошибок при публикации и недетерминированной задержки перед отправкой клиентам, поэтому решил убрать – для публикации теперь HTTP или GRPC API. В библиотеке кстати вот так Redis можно использовать.
У библиотеки совсем мало описания и документации сейчас – еще буду дописывать. Ну и пример в README библиотеки согласен нужен.
Редис будет в том же виде за исключением публикации новых сообщений через очередь в нем – эта возможность была не совсем верна в разрезе обработки ошибок при публикации и недетерминированной задержки перед отправкой клиентам, поэтому решил убрать – для публикации теперь HTTP или GRPC API. В библиотеке кстати вот так Redis можно использовать.
Меняется ли логика работы (токены и все такое)?Меняется механизм генерации токена подключения и токена приватных подписок с ручной генерации токена (то есть использования вот такого кода) на JWT. В остальном все то же самое. JWT в том числе позволяет избавиться от болей связанных с тем как правильно info в виде JSON-строки прокинуть в Центрифугу через шаблонизаторы.
Нет ли желания делать лаунчер?Пакеты для дистрибутивов Linux, которые используют systemd уже давно есть. Плюс docker-image тоже есть.
У библиотеки совсем мало описания и документации сейчас – еще буду дописывать. Ну и пример в README библиотеки согласен нужен.
Для полного счастья не хватает нативных библиотек под iOS и Android
Мне кажется переносить websocket на мобильне девайсы не очень хорошая идея. Большинство известных реализаций неэкономичны в смысле расзода батареи. Я думаю если у клиента в отчете по расходу батареи приложение будет попадать на первые места то шанс на то что это приложение не будет удалено очень маленький.
Доакзательство — отчет на смартфоне по расходу батареи. От реализаций конкретных скорее всего мало что зависит т.к. websocket по сути это тот же модернизирванный longpooling. И это уже недостаток самого протокола. Использовать я бы стал на мобидных девайсах то что ейчас уже все практически использует (facebook, telegram etc.)
Ощущение, что вы намеренно обошли стороной все мои достаточно конкретные вопросы. Websocket — это протокол поверх TCP с минимальным оверхедом. Какие-то дополнительные затраты по сравнению с чистым TCP есть на начальный upgrade по HTTP — но далее это TCP-сессия. Ничего магического facebook и telegram не используют — точно также в качестве транспорта используют TCP.
websocket по сути это тот же модернизирванный longpooling.
нет от слова совсем. Это обычный tcp сокет, поверх которого прикрутили понятие сообщения, его заголовка и всё. Ничего более. Ах да, если вас пугает http соединение в начале, так это тоже просто tcp соединение с небольшим количеством текста там. Можете рассматривать это как приветственный хендшейк в любом tcp соединении которым (нендшейком) обменялись стороны обмена данными.
См. stackoverflow.com/questions/29282070/websockets-energy-consumption
Оверхед выражаеттся в проверке и повторном открытии соединения что не уитывают приведенные источники
Оверхед выражаеттся в проверке и повторном открытии соединения что не уитывают приведенные источники
Ждем на Вики добавление по 2-й версии или статью на хабре. Особенно интересует про JWT.
Добрый день! Не очень понял, что за Вики? И что именно про JWT интересует?
Вики имею ввиду: fzambia.gitbooks.io/centrifugal/content/server/tokens_and_signatures.html
Насколько понимаю теперь вместо HMAC авторизации используется JWT стандарт?
Насколько понимаю теперь вместо HMAC авторизации используется JWT стандарт?
Возможно ли проверять библиотекой, токены выданные Centrifuge(o)?
Насколько понимаю теперь вместо HMAC авторизации используется JWT стандарт?
Да, все так. JWT так же под капотом использует HMAC (на самом деле JWT умеет на основе других алгоритмов генерировать подписи, напр. AES, но мы пока HMAC SHA-256 поддерживаем только). Благодаря тому, что библиотеки JWT есть для большинства языков — вся генерация токенов скрыта от пользователя, хотя под капотом там очень похожий механизм.
Документация будет новая — уже есть прототип, который еще будет доработываться, но вот например описание JWT там — centrifugal.github.io/centrifugo/server/authentication
Не понял вопрос про проверку библиотекой токены выданные Centrifuge(o).
Не смог понять функционал по описанию(
Допустим есть канал, правильно ли я понял:
— если емкость канала равна 50 сообщениям, в канале будут храниться 50 последних сообщений, упорядоченных по времени
— хранится ли где ть uid последнего прочитанного сообщения подписчиком, можно ли его получить и есть ли возможность считать unread count
— Как помечать сообщения как прочитанные на клиенте, есть ли какой то апи метод для этого
— Хранится ли эта инфа на сервере или отдается на откуп клиенту/бекенду
По описанию, понятно что есть вебсокеты для рилтайм режима и события/уведомления о подключении/отключении и новом сообщении. Но совершенно не понял что происходит между сессиями и какие возможности дает библиотека. Простите если глупые вопросы.
Допустим есть канал, правильно ли я понял:
— если емкость канала равна 50 сообщениям, в канале будут храниться 50 последних сообщений, упорядоченных по времени
— хранится ли где ть uid последнего прочитанного сообщения подписчиком, можно ли его получить и есть ли возможность считать unread count
— Как помечать сообщения как прочитанные на клиенте, есть ли какой то апи метод для этого
— Хранится ли эта инфа на сервере или отдается на откуп клиенту/бекенду
По описанию, понятно что есть вебсокеты для рилтайм режима и события/уведомления о подключении/отключении и новом сообщении. Но совершенно не понял что происходит между сессиями и какие возможности дает библиотека. Простите если глупые вопросы.
Добрый день!
Судя по всему вы рассматриваете Centrifuge(o) только как решение для построения чатов – это не так, это скорее просто real-time транспорт с некоторыми вспомогательными примитивами вроде подписок на каналы, восстановления истории в канале после короткого дисконнекта, масштабирования на несколько инстансов. На основе Центрифуги можно написать много разных вещей, в том числе и чат, но для этого нужно поверх того что есть еще на бекенде реализовать много бизнес-логики конкретного приложения — в том числе unread count и т.д. В случае использования библиотеки вам, например, придется на бекенде реализовать методы подтверждения о прочтении сообщений, метод получения счетчика непрочитанных — и вызывать их когда нужно (можно через RPC-вызов через вебсокет, можно как-то иначе).
В общем расчет такой — если вам нужно писать сложное реал-тайм приложение (а не просто например пушить в страничку клиента изменяющиеся в реальном времени котировки акций), то вся бизнес-логика приложения отдается на откуп вам — а Центрифуга это только транспорт, способ быстро доставить какое-то сообщение клиенту или от клиента.
Судя по всему вы рассматриваете Centrifuge(o) только как решение для построения чатов – это не так, это скорее просто real-time транспорт с некоторыми вспомогательными примитивами вроде подписок на каналы, восстановления истории в канале после короткого дисконнекта, масштабирования на несколько инстансов. На основе Центрифуги можно написать много разных вещей, в том числе и чат, но для этого нужно поверх того что есть еще на бекенде реализовать много бизнес-логики конкретного приложения — в том числе unread count и т.д. В случае использования библиотеки вам, например, придется на бекенде реализовать методы подтверждения о прочтении сообщений, метод получения счетчика непрочитанных — и вызывать их когда нужно (можно через RPC-вызов через вебсокет, можно как-то иначе).
В общем расчет такой — если вам нужно писать сложное реал-тайм приложение (а не просто например пушить в страничку клиента изменяющиеся в реальном времени котировки акций), то вся бизнес-логика приложения отдается на откуп вам — а Центрифуга это только транспорт, способ быстро доставить какое-то сообщение клиенту или от клиента.
а почему вы не дали никаких методов в апи для построения на базе центрифуги чего то большего чем рилтайм транспорт доставки? Это принципиальная позиция или просто не было подобных запросов?
Вот смотрите, внутри центрифуги есть последний прочитанный уид в разрезе канал/клиент, как я понимаю
— но вы не дали метода его считать
— вы его не персистите для разрывов пока клиент зашел в метро как я понял, например
— вы не дали ни метода считать историю начиная с непрочитанного сообщения, по партициям/страницам, ни количества непрочитанных сообщений
Весь это функционал как бы есть (для кратковременных дисконектов, кстати насколько кратковременных? Секунда, сутки, это как то параметризируется?), но в апи — скрыт
Почему так? Это просто как то очень странно. Может быть я могу как то помочь реализовать это или описать тз или еще как то. Или вам это неинтересно?
Вот смотрите, внутри центрифуги есть последний прочитанный уид в разрезе канал/клиент, как я понимаю
— но вы не дали метода его считать
— вы его не персистите для разрывов пока клиент зашел в метро как я понял, например
— вы не дали ни метода считать историю начиная с непрочитанного сообщения, по партициям/страницам, ни количества непрочитанных сообщений
Весь это функционал как бы есть (для кратковременных дисконектов, кстати насколько кратковременных? Секунда, сутки, это как то параметризируется?), но в апи — скрыт
Почему так? Это просто как то очень странно. Может быть я могу как то помочь реализовать это или описать тз или еще как то. Или вам это неинтересно?
Я завел ишью на github с конструктивным описанием функционала, думаю там удобнее будет обсудить целесообразность и возможность реализации метода для чтения истории непрочитанных сообщений: github.com/centrifugal/centrifugo/issues/228
Просто по факту — вы говорите что я могу реализовать это сбоку, но в данный момент это невозможно. Я могу это реализовать только параллельно центрифуге. Без возможности синхронизации с ней( А хотелось бы просто уметь читать историю сообщений из кеша центрифуги.
Просто по факту — вы говорите что я могу реализовать это сбоку, но в данный момент это невозможно. Я могу это реализовать только параллельно центрифуге. Без возможности синхронизации с ней( А хотелось бы просто уметь читать историю сообщений из кеша центрифуги.
Позиция тут достаточно принципиальная в данный момент – если нужны методы восстановления истории для дисконнектов больше чем время жизни кеша, то это должно быть вне библиотеки.
История спроектирована именно под короткие дисконнекты на N секунд. Центрифуга держит кеш сообщений в памяти или в Redis – это информация, которая может быть потеряна (например если используется in-memory движок и нода перезагружается, в случае Redis история конечно сохранится, но семантика та же). В протоколе заложена возможность восстановить историю с бекенда в таком случае, так как Центрифуга дает клиенту понять были ли восстановлены сообщения.
Имхо под такой функционал история должна храниться персистентно и индексироваться — я не против это обсуждать, но перспектив особых не вижу в данный момент.
Параметризуется на уровне канала — godoc.org/github.com/centrifugal/centrifuge#ChannelOptions
История спроектирована именно под короткие дисконнекты на N секунд. Центрифуга держит кеш сообщений в памяти или в Redis – это информация, которая может быть потеряна (например если используется in-memory движок и нода перезагружается, в случае Redis история конечно сохранится, но семантика та же). В протоколе заложена возможность восстановить историю с бекенда в таком случае, так как Центрифуга дает клиенту понять были ли восстановлены сообщения.
Имхо под такой функционал история должна храниться персистентно и индексироваться — я не против это обсуждать, но перспектив особых не вижу в данный момент.
Весь это функционал как бы есть (для кратковременных дисконектов, кстати насколько кратковременных? Секунда, сутки, это как то параметризируется?)
Параметризуется на уровне канала — godoc.org/github.com/centrifugal/centrifuge#ChannelOptions
Я пони. Тем не менее сделать это кмк просто. Конечно речь не идет о том, чтобы хранить всю историю. Но так как она уже хранится за некий период возмоность ее чтения ничем не навредит. Тем более как Вы справедливо заметили в том же редисе сообщения персистятся.
Пожелание: было бы здорово выделить библиотеку в отдельный репозиторий и навести порядок. Какая то полная каша с зависимостями, именованиями и бренчами центрифуг( Просто непонятно какие бренчи каких проектов клонировать в каой последовательности github.com/centrifugal/centrifuge/issues/8
Пожелание: было бы здорово выделить библиотеку в отдельный репозиторий и навести порядок. Какая то полная каша с зависимостями, именованиями и бренчами центрифуг( Просто непонятно какие бренчи каких проектов клонировать в каой последовательности github.com/centrifugal/centrifuge/issues/8
Я бы тоже проголосовал зато чтобы иметь доступ не ко всей истории, а только к количеству, которое прописано в конфиге: «history_size»
Смотрю код, отличная работа!
Но если Вы хотите получить грант от Мозилы — надо научиться работать с комьюнити. Нельзя просто выкладывать код и ждать когда его начнут развивать
Люди — ленивы. Если вы юзаете dep -надо написать что вы его юзаете где его качать и как собирать. Если уж заюзали его — в toml файлы надо прописывать все зависимости, включая интернал с нужными путями. Либо выделять либы в отдельные репы. Если это либа и она не юзает прометеус какой ть — не надо заставлять его качать. Если вы в бренче работаете — надо написать в каком. Если вы хотите чтобы вам слали PR — встаньте на место того, кто захочет его слать. Клонируйте сами свою репу и попробуйте послать себе PR. Поймете что сделано не так. Не обижайтесь на критику я добра вам желаю и развития. Но пока это выглядит как пет проект не до конца доделанный (я про версию 2) Кругом путаница
Просто посмотрите на другие популярные проекты, полно шаблонов и рекомендаций как организовать репозиторий и как все надо описывать. Пока, к сожалению — удобней спулить ваш код, разобраться и собрать под себя нужное — не вернув вам PR
Удачи!
Но если Вы хотите получить грант от Мозилы — надо научиться работать с комьюнити. Нельзя просто выкладывать код и ждать когда его начнут развивать
Люди — ленивы. Если вы юзаете dep -надо написать что вы его юзаете где его качать и как собирать. Если уж заюзали его — в toml файлы надо прописывать все зависимости, включая интернал с нужными путями. Либо выделять либы в отдельные репы. Если это либа и она не юзает прометеус какой ть — не надо заставлять его качать. Если вы в бренче работаете — надо написать в каком. Если вы хотите чтобы вам слали PR — встаньте на место того, кто захочет его слать. Клонируйте сами свою репу и попробуйте послать себе PR. Поймете что сделано не так. Не обижайтесь на критику я добра вам желаю и развития. Но пока это выглядит как пет проект не до конца доделанный (я про версию 2) Кругом путаница
Просто посмотрите на другие популярные проекты, полно шаблонов и рекомендаций как организовать репозиторий и как все надо описывать. Пока, к сожалению — удобней спулить ваш код, разобраться и собрать под себя нужное — не вернув вам PR
Удачи!
Спасибо за фидбек, путаница есть из-за того, что я пишу про то, что еще не добралось до релиза – мне было важно собрать фидбек. Замечания постараюсь учесть.
Toml-файлы генерятся автоматически dep-ом, ничего туда руками прописывать не нужно — этот момент не понял.
Toml-файлы генерятся автоматически dep-ом, ничего туда руками прописывать не нужно — этот момент не понял.
Если склонировать репозиторий то все internal зависимости, не прописанные в toml — не подтянутся, если я правильно понимаю dep. Но я не фанат dep, могу неправильно им пользоваться. Хорошей идеей как мне кажется было бы просто пройти этот путь и описать, как собирать, какой бренч девовский, какой рабочий c2/master/c2-published и тп Ну я думаю как до релиза доберетесь — рассосется. Только после релиза обычно уже поздно — и новый релиз, а процесс описывать лень и так по кругу)
с помощью Centrifugo работает красивейший дашборд на ресепшн в московском офисе Badoo
Не только московском, но и лондонском. Спасибо за работу над Центрифугой!
Люблю Центрифугу. Хорошо работает. И чат норм на ней работает, и риалтаймовые оповещения по сайту, и любые изменения/апдейты контента тоже.
Привет! В v2 будет api для подключения других engine? Или как в 1 версии будет только два движка из коробки?
Привет, пока Engine интерфейс скрыт внутри библиотеки, но мой план его в конечном итоге открыть. Не хочется делать это раньше времени (чтобы потом не менять внешнее API engine-а) пока кто-то не придет с реальным юзкейсом, какой-то реализацией и обоснованием преимуществ нового engine-a для юзкейса. Из коробки — те же два остаются, да.
Чтобы другие могли написать другой Engine — обычно дают интерфейс, а не ждут чего то
Вот, смотрите пример как это делается: github.com/ipfs/go-datastore
Или в эфириум движке пример. У вас очень странный подход к разработке, я уже понял
Вот, смотрите пример как это делается: github.com/ipfs/go-datastore
Или в эфириум движке пример. У вас очень странный подход к разработке, я уже понял
Проекту 5 лет, он давно развивается — в разработке принимали участие ребята, которые сейчас работают в Hashicorp, плюс один из очень уважаемых разработчиков в Go-сообществе Klaus Post внес свой вклад. Это на случай если вы считаете, что я один все это делал. Дизайнерские решения по возможностям были приняты давно. Вы пришли — вбросили не разобравшись issue, не смогли склонировать библиотеку правильно — и учите меня Go.
Мой подход к разработке — не делать что-то без реальной необходимости со стороны пользователей и стараться как можно меньше ломать API даже на такой ранней стадии. Не считаю это странным, вы можете думать как угодно.
Мой подход к разработке — не делать что-то без реальной необходимости со стороны пользователей и стараться как можно меньше ломать API даже на такой ранней стадии. Не считаю это странным, вы можете думать как угодно.
… без реальной необходимости со стороны пользователей…
В том то и проблема — потребность есть. Я, например, уже два раза просто тихо отказался от центрифуги, потому что нет простого способа жить не с редисом.
Респект! Но возможности:
прочитать сообщения из хистори — начиная от заданного — нет
персистить сообщения — в свою бд — нет
апи — не продумано — ибо нет реальной необходимости со стороны пользователей
А я тогда кто? В чем вообще цель поста если вы на фидбек так реагируете? Похвастаться пришли? Ну молодец!
прочитать сообщения из хистори — начиная от заданного — нет
персистить сообщения — в свою бд — нет
апи — не продумано — ибо нет реальной необходимости со стороны пользователей
А я тогда кто? В чем вообще цель поста если вы на фидбек так реагируете? Похвастаться пришли? Ну молодец!
Кейс такой, что нет желания обслуживать еще одну БД, а хочется использовать ту базу или брокера, который уже есть на проекте.
Мне кажется, кейс более, чем реальный, потому что сейчас получается, что если тебе нужно больше одного сервера центрифуги, то ты обязан тащить редис, хотя его функции может выполнять очень много кто
Мне кажется, кейс более, чем реальный, потому что сейчас получается, что если тебе нужно больше одного сервера центрифуги, то ты обязан тащить редис, хотя его функции может выполнять очень много кто
Согласен, что если в стеке не используется Redis — тащить его далеко не идеальный вариант. Ну как я сказал — я не против попробовать это поддержать в будущем, но есть достаточно много моментов, которые на первый взгляд не видны и обеспечиваются текущей реализацией.
Если вы готовы помочь с этим — пишите мне в ЛС, или в Gitter-чат gitter.im/centrifugal/centrifugo — можно обсудить, я расскажу подробнее.
Если вы готовы помочь с этим — пишите мне в ЛС, или в Gitter-чат gitter.im/centrifugal/centrifugo — можно обсудить, я расскажу подробнее.
чем не угодил mqtt?
Не то что бы он чем-то не угодил, проект родился достаточно давно — MQTT не был достаточно распространен и я о нем не знал до определенного момента. За это время собственный протокол оброс некоторыми фичами, которых нет в спецификации MQTT. Протокол гораздо проще. Нет разных QOS (по сути Centrifugo — это только QOS 0) – это конечно не плюс, но на практике работает, и позволяет серверной реализации быть простой. Recovery в Центрифуге используется только при реконнектах, PUBREC аналога нет. Нет wildcard-подписок, что с одной стороны минус, а с другой очень сильно упрощает реализацию сервера и позволяет безболезненно шардировать каналы в Redis-ах. В общих чертах протоколы похожи — MQTT может предложить больше, но за счет радикального усложнения серверной части. Так как Центрифуга успешно используется в достаточном кол-ве проектов, могу сделать вывод, что протокол справляется с большим количеством практических задач.
Sign up to leave a comment.
Centrifugo v2 — будущее сервера real-time сообщений и библиотека для Go