Does subscribing to multiple PubNub channels share an HTTP connection or create separate connections?
The reason for asking is that clients will receive notifications from a central hub.
We can use channels for routing the notification types. (Like REST).
We can have a single channel for events, with an event_type field. (Like SOAP).
The former is preferable in terms of implementation simplicity, so just checking if there are any drawbacks.
PubNub now offers Channel Groups and Wildcard Subscribe via the Stream Controller add-on
Channel Groups
PubNub now offers Channel Groups so that one client connection can subscribe to 20K channels at once (10 channel groups X 2000 channels in each channel group). See Channel Groups KBs for more details.
Wildcard Subscribe
Subscribe to a.b.* and publish to any channel that is prefixed by a.b. (a.b.c, a.b.d, a.b.aa, etc) and your a.b.* subscribe will get those messages. See Wildcard KBs for more details.
PubNub Connections Per Channel
PubNub SDK client connections utilize one TCP connection per SDK instance. The number of channels used will not increase the open TCP connection count. Multiple PubNub channels share a connection. PubNub uses Multiplexing allowing your channel messages to be received using only one TCP connection.
Related
We are using IoTHub Routes to direct messages to the ServiceBus queues. One of the queues is Session enabled for the sake of ordered message processing.
Is it possible to enrich messages for that particular endpoint and add SessionId to them right in IotHub before directing to the queue? The value for the SessionId is inside the JSON content of the message.
As of writing this, It's not possible to do so. Session enabled queues could be added as an endpoint to IoTHub but then stay Unreachable there.
Is it possible to use mqtt+mosquitto (or any broker like rabbitmq, redis) for the purpose of push notification instead of FCM ?
Let's assume we are using mqtt+mosquitto.
I am explaining my needed scenario:
An user A is sending a message to user B but the user B is now offline. Whenever user B will come online he should be notified about his pending message.
How to implement this scenario with broker
MQTT has a concept of "persistent sessions". There's a flag called "clean session" that the client sends to the broker in the connect packet when first connecting. By setting this flag to false, the client is asking the broker to "remember me".
Then if the client disconnects or loses it's connection, the broker will hold messages for the client until the next time it reconnects, and send them to the client in the order received.
In MQTT, each client is required to have a unique "ClientID". This is how the broker recognizes the client when it reconnects. The client uses subscriptions to tell the broker what messages that it wants the first time it connects, and then after that the broker remembers the list of subscriptions for that client and all the messages that match those subscriptions.
So, for your scenario, Client B would need to connect once with a persistent session, and then after that, the broker will hold messages for it whenever it disconnects.
I have a Progressive WebApp Chat application and I want to be able to be able to send or receive Push Notifications (on Mobile) and Web (Chrome) Notifications while on Desktop. Right now, I have a web client that is able to receive tickles i.e. data without payloads (payloads will then be fetched through an API call from my server)
I am using Pubnub to talk to GCM and APNS. I have working apps on Web, iOS(native) and Android(native) clients of my project. Right now, I am able to receive Push Notifications on my web app but without the payload.
No where is the server publishing anything. All publishes are done by the clients since its mainly a chat app.
From my Web/Android client, my pubnubPayload is:
var pubnubPayload = {
"text": "no payload!",
"pn_gcm": {
"data": {
"title": "shash",
"babe": "ya"
}
}
}
And then do a normal publish like this:
Pubnub.publish({
channel: myChannel,
message: pubnubPayload,
callback: someFunc
});
So, when I subscribe to a pubnub channel like this:
Pubnub.subscribe({
channel: selectedChannel,
message: function(m){
console.log(m)
},
error: function (error) {
// Handle error here
console.log(JSON.stringify(error));
}
});
I receive the message through Pubnub AND a push notification (but without the payload) on my webapp.
My question is:
How do I receive push notifications on web that have a payload? Is there someway pubnub lets you publish encrypted messages for webs client to be able to read the payload of the GCM push notification without using Pubnub's Access Manager?
Or is using PAM my only option and should fix the no payload issue?
PubNub Access Manager not required for Message Encryption
PubNub Access Manager and message encryption are not directly related and is not required to encrypt your messages, but all applications using PubNub should implement Access Manager to control who can do what on channels by granting permissions (read/write/delete) to auth-keys that your client apps will init PubNub with to use those channels as you intended.
Encrypt using Standard TLS (formerly known as SSL)
To encrypt messages, simply initialize PubNub with TLS enabled (ssl might be the name of the parameter but it is the latest TLS, not the old SSL that was deprecated). This will use standard TLS encryption from your server or client apps to the PubNub network.
Encrypt messages using Cipher Key for AES 256 Encryption
If you wish to have your messages encrypted from your server/client apps to PubNub and all throughout PubNub, just provide a cipher key when you initialize PubNub. The best part about this is that you hold the keys, not PubNub, so no one can read your messages except the holders of those cipher keys.
Custom Encryption using the encrypt/decrypt API
The question asked here includes mobile push notifications which means you can't encrypt the full message if you want the mobile push message to be sent by PubNub to the push services (APNS/FCM) and handled by those services properly. The realtime message will be sent as is - encrypted - to the client subscribers. But you can encrypt the important/confidential parts of the message and leave the parts that need to be ready by PubNub and the push services unencrypted using the encrypt and decrypt APIs. The article, Encryption for APNS, GCM, WMS with PubNub, is a bit old but should provide the required insights.
By WebRTC standard all connections should be encrypted via DTLS. This is great. However, unless application verifies authenticity of the peer, the connection is vulnerable to man in the middle (MITM) attack.
The question is how to do this with libWebRTC (http://www.webrtc.org/native-code) specifically in Objective C interface. Ideally, I would like to be able to specify my own certificate for WebRTC connection. In this case I will be able to verify it through my application-specific secure channel. If this is not possible, then what is the suggested approach? I will be grateful for any hints.
The WebRTC specification does not include the signaling layer, i.e., how the fingerprints, ICE candidates, etc are exchanged between peers. This means that in almost all WebRTC applications, there's a signaling socket to rapidly signal the connection with a service which exchanges the information between two peers.
Instead of supplying your own certificates or fingerprints, what you want to do is authenticate the signaling over which those are sent.
Your signaling server effectively is the man-in-the-middle, especially in cases of using an MCU or SFU. It should verify the identity of clients exchanging signaling information, and ensure the signaling information is exchanged between mutually agreeing peers (i.e., calling one another by address, or joining a common "room").
So the answer is: use secure websockets, and authenticate clients sending/receiving WebRTC offer/answer information. If you do that, there's no risk of man-in-the-middle attacks, beyond the risk of any other HTTPS+WSS application.
In the docs for the Google Channel API it says:
"A channel is a one-way communication path through which the server sends updates to a specific JavaScript client identified by its Client ID."
In their diagrams they show a client sending its state with a POST. This seems like it would be slow. Can the client communicate with the Channel API through a socket? Or must it send via POST?
POST is a message type indicator and message format.
Major edit after more research!
See Google API doc
Looks like messages from the browser to the server do indeed open new HTTP-level connections to send a POST message. Whether a new TCP/IP connection is needed or not depends on the browser's management of TCP connections--new browsers do a better job of this. See wikipedia HTTP persistent connection
Re: This seems like it would be slow. Usually the browser traffic is asymmetrical--with most of the data from the server to the browser. Comet will help that use case.
Re: Can the client communicate with the Channel API through a socket? Do you mean IP socket? Browsers don't have an api for that. Do you mean "web socket?" I'm 98% sure it wouldn't work to combine the two techniques. But you could try...