Ответ 1
Нет ни одного способа решения проблем, с которыми вы столкнулись. Наши клиенты использовали широкий спектр шаблонов проектирования для решения этих проблем. Я сам столкнулся с такими вещами, которые создают приложения PubNub, и я помогу вам как можно больше.
Pubnub говорит, что неплохо создавать более двух каналов на одного клиента. Итак, в моем приложении у меня есть требование создать более двух каналов для прослушивания уведомлений, происходящих повсюду на моем веб-сайте, но я поеду с двумя каналами для каждого зарегистрированного пользователя, как предполагал Pubnub.
Записанные пользователи прослушивают Channel1-Public Записанные пользователи прослушивают приватные UsersOwnDynamic-Channel для получения уведомлений, связанных и предназначенных только для него.
Это хороший способ сделать это, и то, как это делают многие наши массовые клиенты. Глобальный канал и частный, пользовательский канал.
A.
Мне всегда нужно создавать новое имя частного динамического канала каждый раз, когда я заходил на сайт.
Не обязательно, хотя это хороший способ. Вы можете использовать PUBNUB.uuid()
в JavaScript на стороне клиента для этого. Или, сгенерируйте его на стороне сервера, используя PHP, и отнесите его клиенту. Возможно, вы можете установить его как файл cookie, чтобы клиент всегда имел к нему доступ.
Если да, то каким другим пользователям будет известно, как отправить уведомление на мой частный канал.
Они могут получить идентификатор с сервера PHP; либо через глобальный канал, либо на собственный личный канал пользователя, который они прослушивают.
Или мне просто нужно иметь только одно статическое имя канала, хранящееся в таблице базы данных, так что другие проверенные подлинности пользователи будут запрашивать таблицу и получать имя моего личного канала для отправки мне уведомлений.
Вы тоже могли бы сделать это. У вас может быть глобальный канал, который пользователи могут отправлять, чтобы быть другим, чем глобальный канал, который они прослушивают. Только сервер имеет , который подписаться. Таким образом, аутентифицированные пользователи отправляют на сервер сообщение с сообщением "Мне нужны соответствующие пользовательские ключи", затем сервер выполняет запрос и отправляет сообщение обратно на этот частный канал пользователей.
Если это так, разве вы не думаете, сможет ли хакер получить какое-то имя частного канала для определенных пользователей, они смогут прослушать этот канал?
Если вы удерживаете ключ подписки на глобальном канале отправки, только сервер может видеть болтовню на этом канале.
В.
Я использую PHP и mysql, поэтому я до сих пор не могу придумать способ или придумать решение для отправки сообщений на частные каналы другого пользователя. Давайте рассмотрим пример простой системы запросов друзей. - UserA отправляет запрос другу в UserB. - UserB слушает его собственное имя динамического частного канала под названием DynamicPrivateChannelB (как UserA найдет имя канала для UserB, которое является приватным? Im думает, что единственный способ для этого состоит в том, что частный канал UserB должен храниться в таблице базы данных для каждого пользователя loggedin для запроса. Я думаю, что правильный путь?)
Это очень похоже на ваш предыдущий вопрос. Нет никакого способа сделать это, но шаблон дизайна, который я изложил выше, должен работать. Чтобы повторить этот шаблон дизайна:
Серверная сторона
- Прослушивает глобальный пользовательский канал отправки сообщений пользователя. Сервер является единственным объектом, у которого есть этот ключ подписки.
- Может запросить db, чтобы получить идентификаторы пользователя, а затем отправить на различные идентификаторы по желанию.
- Также можно отправлять по каналу Global-user-receive, который все клиенты прослушивают. Сервер является единственным объектом, который имеет этот ключ публикации.
Клиентская сторона
- Прослушивает канал Global-user-receive-channel. Вот как он получает массовые трансляции серверов. Не удается отправить на этот канал (есть только подписной ключ)
- Отправляет сообщения сервера по каналу Global-user-send. Не удается получить на этом канале (только имеет ключ публикации)
- Прослушивает частный канал пользователя. Так пользователь получает личные сообщения. Он также может использовать это для взаимодействия клиент-клиент.
- Предотвращение злоупотреблений путем добавления всех личных сообщений с закрытым ключом для каждого пользователя, хранящимся на сервере, и предоставляемым во время начальной загрузки страницы. Таким образом, клиент знает, является ли сообщение, утверждающее, что оно с сервера, является законным.
С.
Если мы всегда генерируем имена динамических частных каналов, сохраняем в таблице базы данных, обновляя каждый раз, когда генерируются новые имена динамических каналов. Я думаю, что это вызовет проблему, потому что некоторое сообщение не будет доставлено, поскольку новые имена динамических частных каналов заменяют старые.
Если вы будете осторожны при создании новых имен каналов, это не должно быть проблемой. Имейте в виду, клиент всегда может сказать по каналу Global-user-send-channel "эй, я здесь! это мой идентификатор. держи меня в курсе'. Обычно я разрабатываю свои приложения, чтобы клиенты автоматически кричали об этом каждые 30 секунд или около того.
D.
Итак, у меня есть много уведомлений для отправки на один канал, например, New Friends, New Private messages, New Gifts и многие другие. Как я отправил все эти данные на канал и как узнать и проанализировать входящие новые данные уведомлений. Я знаю, что JSON - это формат отправки, но я не уверен относительно формата отправки.
JSON хорош для отправки и получения. То, как я это делаю, - это свойство, называемое "имя", которое определяет тип сообщения. Например:
{
"id" : "blah_blah_unique_id", // sender_client_id
"name" : "friend_request", // type of message
"data" : { // the data itself
"requested_friend_id" : "blah_blah_some_other_unique_id"
}
}
Вы можете использовать любой формат, который хотите, но мы обернем его в JSON (обычно это означает, что он просто завернут в кавычки), когда он попадает через PubNub.
Надеюсь, это поможет!
Новые вопросы
Согласно эта ссылка, один канал Pubnub может содержать только до 100 сообщений. Означает ли это, что если 200 сообщений поступают сразу в один канал, первые 100 доставляются, а остальные остаются в очереди? Как насчет того, если сразу поступит 10 000 сообщений на один канал? Все оставшиеся сообщения остаются в очереди? если да, то как он доставляется абоненту в реальном времени?
Ограничение 100 сообщений относится к PubNub.history. Если кто-то подписался и заходит 200 сообщений, они получат все 200 сообщений.
(Теперь только userA должен получить уведомление на своем личном канале о новом личном сообщении, как пользователь или система узнают имя канала UserAx732dsw3efsdfsdfsdf, потому что это частный канал, сгенерированный динамически пользователем A, ни System, ни userB к которому он обратился. То же самое происходит и для userB, если пользователь должен быть уведомлен каким-либо другим сущностью или системой снова, должен быть способ узнать имя динамического канала userB.
В этом вопросе нет решения для одноразового использования, но я бы сделал, чтобы сервер сгенерировал этот уникальный id при загрузке страницы и передал его клиенту по вашему первоначальному HTTP-запросу.
Другая проблема заключается в том, что если пользователь динамически генерирует имя канала каждый раз, когда он/она вошел в систему на веб-сайт. Что произойдет со всеми сообщениями, которые были отправлены на динамический канал? Выпускаете ли pubnub все созданные имена каналов на своем сервере?
Вам не нужно динамически генерировать каждый раз. Вы могли бы... но вы также установили cookie с этим уникальным идентификатором или вытащили его из базы данных и отнесите его клиенту на загрузку страницы (что бы я сделал). Мы не сохраняем имена каналов.
Есть ли способ, которым система или пользователь может узнать, является ли имя канала еще собственностью и, по крайней мере, один пользователь слушает канал?.
Не из коробки, но вы можете легко реализовать это. Просто отправьте свой сервер на пинг и настройте своих клиентов, чтобы они всегда отвечали на пинги, если они слушают.
Теперь UserA выходит из веб-сайта в 1:30 утра, что произойдет со многими другими пользователями, которые все еще выталкивают уведомление в свой dynamicChannelA, потому что в следующий раз, когда UserA войдет на сайт, UserA будет слушать к другому имени динамического канала. UserA не будет слушать его предыдущий канал dynamicChannelA.
Как вы можете предотвратить это периодическое (каждые 30 секунд?) пинги с сервера, которые могут отслеживать, если пользователи все еще там. В ближайшие месяцы мы будем запускать API присутствия, чтобы сделать это автоматически, btw.
Im думает использовать метод извлечения имени канала конкретного пользователя из таблицы базы данных. Есть ли способ или способ предотвратить несанкционированную подписку на канал? Потому что любой может подписаться на имя канала, если у них есть ключ подписки и имя канала независимо от того, как долго имя канала. Мне просто интересно, потому что вся подписка происходит на стороне клиента, и вид подписки и названия каналов видны
Основным способом является стратегическое размещение ключей публикации/подписки. Вы правы, что любой, у кого есть правильные детали, может слушать - это большая проблема только для клиентских систем. В настоящее время вам придется придумать творческие способы обойти это.