ramax495, дизайн Центрифуги таков, что она работает в отвязке от бизнес-логики приложения, по сути являясь лишь транспортом реал-тайм сообщений от бекенда клиенту. Но не в обратную сторону - так как в таком случае ваш бекенд не узнает о сообщении ничего (оно просто пройдет сквозь Центрифугу до других юзеров в канале). А что если вам нужно его валидировать, сохранить в базу данных, затроттлить? поэтому в большинстве случаев новое сообщение нужно сначала отправить на бекенд для выполнения всех действий необходимых приложению - и только потом разослать потенциальным получателям в канал. В теории можно было бы отправлять его по вебсокету в Центрифугу, которая потом делала запрос в бекенд по HTTP, например. Но на самом деле в такой схеме выгода не очевидна - сообщение проходит лишнее звено.
Александр Аксентьев, ну я иногда смотрю рефереров на Github:) По такой поверхностной информации конечно сложно судить, но есть предположение, что очень много join/leave эвентов посылается - по сути на каждый коннект и релоад странички сообщение в итоге отправляется всем – это может приводить к огромному количеству сообщений. Join/Leave события плохо масштабируются на каналы с большим кол-вом пользователей. Тут все же не лучшее место раскапывать дальше, если есть желание понять реальную причину, то можно поисследовать в Gitter чате. Вот тут описаны шаги которые могут помочь понять, что происходит - https://github.com/centrifugal/centrifugo/wiki/Inv...
Александр, 4-5k коннектов это очень мало - Centrifugo явно может больше, 50k соединений в проде на ноду без проблем должно быть. Возможно дело в специфичном характере нагрузки на Centrifugo в вашем случае? Можем попробовать понять в чем дело - напишите в gitter чат проекта (ссылка в ридми на гитхабе есть)
carroll: смотря какой механизм приватности используется. Я не вижу тут ни решетки, ни знака доллара в начале канала - то есть по большому счету на этот канал сможет любой подписаться. Расскажу, как у нас были организованы приватные чаты. Диалог был между 2-мя пользователями. Комната была сущностью в базе данных с уникальным длинным id, который невозможно подобрать за разумное время. Когда кто-то писал в чат комнаты, мы знали id комнаты. Этот id был в имени канала - что-то вроде room_cehfwif87wyf8wtf8t4f6n3468nf648ft843fnt438fn8 в итоге получалось. Соответственно передавали эти имена только тем клиентам которые могли на них подписаться, другие не знали. И когда кто-то писал новое сообщения в чатик - просто публиковали его в этот канал. Другие механизмы приватности я описывал выше - это каналы с решеткой (#) или приватные каналы (с $ в начале).
carroll: честно говоря вообще не понимаю за что отвечает данный код - можешь открыть issue на гитхабе в phpcent репозитории, потому что здесь все-таки не место как мне кажется для подобных вопросов? в issue нужно хотя бы описать что должен делать этот код, для чего он вообще. можно в гиттер-чатик если удобнее - https://gitter.im/centrifugal/centrifugo
carroll: неправильные настройки каналов/неймспейсов, в данном случае скорее всего не хватает publish: true в настройках, но вообще публиковать новые сообщения нужно с бекенда через API, а не напрямую с клиента - это только в демках с клиента проще публиковать. Еще я вижу presence not available - это потому что presence также не включена в настройках каналов. Вот эта глава очень важна для понимания настроек - https://fzambia.gitbooks.io/centrifugal/content/se...
привет, я автор Centrifugo - Центрифуга идеально ложится под описанные требования, большой плюс, что не нужно будет кардинальным образом менять работающий бэкенд. По поводу вопроса про user ID и чужие сообщения – если правильно организовать каналы, то, конечно, чужие сообщения прочитать будет нельзя. Центрифуга знает id юзера, так как он указывается при подключении. Причем он подтвержден токеном на основе секретного ключа, что исключает его подмену до тех пор пока не утек секретный ключик, естественно:) Соответственно если использовать канал с решеткой (напр. personal#1674 где 1674 – это id пользователя, подробнее в документации) – то только юзер с id 1674 сможет подписаться на этот канал. Соответственно сообщения юзеру нужно публиковать в него. Еще есть приватные каналы с дополнительным подтверждением AJAX-запросом через бэкенд приложения (начинаются с доллара $personal1674 – опять же подробнее в доке, аналогично приватным каналам сервиса pusher.com). Также некоторые используют трудно угадываемые имена каналов просто - на основе id юзера и какого-то алгоритма шифрования (то есть только бэкенд и пользователь знают имя этого канала в итоге) - подобрать такой оч сложно, и на практике некоторые именно так и поступают. То есть существует 3 разных способа так или иначе защитить канал от "прослушки". Какой лучше - решает каждый для себя.
Спасибо за ссылку:) Центрифуга сейчас в процессе миграции c Python на Go - будет быстрей и удобней, уже сейчас можно попробовать pre-release Go-версию, вот репа: https://github.com/centrifugal/centrifugo , там есть ссылки на релиз и на документацию, которая сейчас в процессе написания.
Написано
Войдите на сайт
Чтобы задать вопрос и получить на него квалифицированный ответ.