Im using PubNub, Phonegap, Backbone.js and Require.js to build twiiter-style chat rooms. Currently I'm testing on a desktop with chrome.
I have a Chat.js view and in the initialize() function, I subscribe to the channel with:
that.pubnub.subscribe({
channel: chatChannel,
message: that.handleSingleMessage,
});
This works fine and I can see with Chrome inspector that ajax requests are sent off. At the top of the app there is a "back" button. In here I call unsubscribe to unsubscribe the user:
that.pubnub.unsubscribe({
channel: chatChannel
});
However, I still see with Chrome inspector that ajax requests to PubNub are still being sent off, even though the user should be unsubscribed and is on a different part of the app. 2 ajax requests are repeatedly sent. They look like:
http://ps13.pubnub.com/time/0?uuid=tomsmith&auth=&pnsdk=PubNub%2DTS%2DWeb%2F3%2Y5%2E1
and
http://ps11.pubnub.com/time/0?uuid=4ea9bd1c%2D7652%2D410c%2Da2ba%2D17c5d263085d&auth=&pnsdk=PubNub%2DTS%2DWeb%2F3%2Y5%2E1
Any idea what's going on?
http://ps13.pubnub.com/time/0?uuid=tomsmith&auth=&pnsdk=PubNub%2DTS%2DWeb%2F3%2Y5%2E1
Are just 'time' calls. They are used to monitor the online/offline status of the client, and do not mean that you are still subscribed. Think of them just as "PubNub Pings"
If you still saw a URL with 'subscribe' in it, then that would mean you are still subscribed, for example:
http://ps2.pubnub.com/subscribe/demo/demoapp1%2Cdemoapp1-pnpres/0/13825545216910725?uuid=2f62d1c1-69c8-423c-9492-74e29f46a877&pnsdk=PubNub-JS-Web%2F3.5.47
but it looks like from your example, its just performing heartbeat logic here, after you've un-subbed.
geremy
Make sure that you're not re-subscribing to the same channel after you unsubscribe to it. PubNub automatically tries to re-connect to a channel if it looses the connection. You can see how I switch and unsubscribe to channels here: http://plnkr.co/edit/7JyS4H
Related
I have used socket io and apollo subscription before, now I am looking for an alternative solution. I need something similar to subscriptions-transport-ws that allows client browser to subscribe events or channels from the server.
Simple example.
Let's say on the server-side is some kind of pub/sub broker. Now user opens an article and the comment section is updated in real-time. So when a user opens an article, he starts listening for events from that channel. It should work like on Twitter to display every new like and comment.
I am trying to implement private messaging with socket.io for my mobile applications which have a direct messaging feature like Instagram. Right now, I am using Node.js and React Native. I am kinda new to socket.io. I saw many examples of that. However, one thing is not clear in my mind.
User clicks "send message" button. Then I create a socket connection and the user joins a room with socket id. Then user sends a message to that room.
The problem here is, how other user will get the message? Because at this point, I don't think other user knows the room id. Of course if there is a better solution for that, I am open to every suggestion.
One thing you can do is create a room for each person. When the person logs into your app and connects with socket.io, you'll want to have them automatically join the room with their user id.
Then when someone wants to send them a message, they can just send the message to the room for the receiving user.
However, I think if you are building a messaging app, socket.io is not the right way to go. As far as I know you can't listen on sockets while the app is in the background (and even if you could, it would drain your users' battery life). You should use push notifications instead and use the data field (e.g. zo0r/react-native-push-notification and firebase).
I am looking for a solution to my problem. I have Node.js server serving my web application where user can log in. I want to handle a situation where one user A performs specific action and user B associated with this action gets real life notification. Is there a module that would help me or there is some other solution?
What you are describing is "server push" where the server proactively notifies a user on their site of some activity or event. In the web browser world these days, there are basically two underlying technology options:
webSocket (or some use socket.io, a more feature rich library built on top of webSocket)
server sent events (SSE).
For webSocket or socket.io, the basic idea is that the web page connects back to the server with a webSocket or socket.io connection. That connection stays live (unlike a typical http connection that would connect, send a request, receive a response, then close the connection). So, with that live connection, the server is free to send the client (which is the web page in a user's browser), notifications at any time. The Javascript in the web page then listens for incoming data on the connection and, based on what data it receives, then uses Javascript to update the currently displayed web page to show something to the user.
For server sent events, you open an event source on the client-side and that also creates a lasting connection to the server, but this connection is one-way only (the server can send events to the client) and it's completely built on HTTP. This is a newer technology than webSocket, but is more limited in purpose.
In both of these cases, the server has to keep track of which connection belongs to which user so when something interesting happens on the server, it can know which connection to notify of the event.
Another solution occasionally used is client-side polling. In this case, the web page just regularly sends an ajax call to the server asking if there are any new events. Anything new yet? Anything new yet? Anything new yet? While this is conceptually a bit simpler, it's typically far less efficient unless the polling intervals are spaced far apart, say 10 or 15 minutes which limits the timeliness of any notifications. This is because most polling requests (particularly when done rapidly) return no data and are just wasted cycles on your server.
If you want to notify userB, when both of you are simultaneously online during the action, then use websockets to pass message to a two-way channel to notify userB.
If you want to notify them whenever, regardless of online status, use a message queue.
I'm very new to node.js and sokcet.io that's why I need to ask you about the plan I have to see if it makes sense or is plain stupid. I need ongoing server/client communication for two reasons: sending real-time notifications to the user when they have one, and two, for chat between users.
Here is my plan for managing notifications:
PHP script finds out user X has a new notification.
Using Elephant.io send a message to server with user X's id as the data.
On the server side, upon receiving the message, if user X is connected emit him a message telling they have a notification.
user X's brower, Upon recieving the message, uses AJAX to poll the database and receive the text for the notification.
For chat, this is my plan (messages should be save on DB):
When user X submits a chat message to user Y, use ajax to send the text to a PHP script and save it on DB. On success, use elephant.io to send a message to user Y telling them that they have a new chat message.
User Y's browser, after receiving the server message, uses AJAX to poll a php script to receive the new text.
Do you think these plans are superior to short polling using AJAX? I appreciate any comments to improve them.
Finally,I'm curious to know how reliable these technologies (node.js, socket.io, elephant.io) are. Do they work well when the server becomes busy? How do they handle exceptions and errors ,etc.
will my server be notified about disconnect on the client side?
I assume the answer is yes if the disconnect happens explictly like below.
pusher.disconnect()
however what happens if the user simply closes the browser?
Another thing is there a way to notify the server that a certain channel has not been in use by the client(s) for some while?
The connection states documentation shows how to bind to connection state changes.
however what happens if the user simply closes the browser?
This really depends on if the browser calls webSocketInstance.onclose so the Pusher JavaScript library is informed before the browser is closed. You could always detect this yourself using window.onbeforeunload, window.onunload or the addEventListener versions.
Another thing is there a way to notify the server that a certain channel has not been in use by the client(s) for some while?
You can use WebHooks so that when a channel becomes vacated your app server will be informed.