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.
Related
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.
Socket.IO timeout (disconnect) occurs if there are no activity present in the socket, but how is detected that are no activity? I dont find information about that. How works the detection process? For example:
If user closes the website tab, occurs disconnect?
There is any way user loses connection and disconnect will not be executed?
Is possible cache information informs that Im online even if I leave the website?
If you open your browser's developer tools in the network panel, you can filter your requests to ws requests (web socket requests), in there you can see your active web sockets connections. If you choose one connection, you can see the headers, the frames, the cookies and timing. If you choose the frames option you can see what's being sent and received, between your browser and your web socket server.
The next image will make it clear for you, it's chrome's developer tools:
Now in there you can see there are some numbers, basically your browser and your server are doing ping pong. You can read more about these numbers in this answer SocketIO Chrome Inspector Frames
This ping pong is what keeps the socket alive so we know that there are no timeouts. As for the disconnect and the connect I advise you to read more about the WebSockets API, in there you can see there are event listeners for onclose, onerror, onmessage and onopen.
So answering this question:
For example: If user closes the website tab, occurs disconnect? There
is any way user loses connection and disconnect will not be executed?
No, the onclose event will be fired, but even if any cosmic reason the onclose isn't fired you will eventually disconnect due to timeout.
As for your other question:
Is possible cache information informs that Im online even if I leave
the website?
Yes, that's not up to sockets, that's up to you and your implementation. You can keep a list of online users and only update that list from time to time, let's say 10 minutes. You can keep the online users lists and between the time you update your online users list, some of them are already disconnected.
I'm building MEAN application with socket.io. When page is just loaded, socket connection is established and kept live while user navigates to various pages, thanks to single-page nature of the app.
The user information is available in my socket connection thanks to passport.socketio.
However, when user logs in or out, I want the connection to be re-initialized, since otherwise socket will contain obsolete data about the user. Currently, I tried to implement it in this way: when user logs in / out, server disconnects this particular client's socket by calling socket.disconnect();.
On the client side, I listen for disconnect event, and try to re-establish the connection, like this:
_socket.on('disconnect', function(reason) {
_socket.connect();
});
Ok, now, when user logs out or in, server disconnects the client, this client connects back, and user information in the socket is up-to date. So far, so good.
But, consider different case when connection is broken: server is restarted. Previously, it "just worked": when I stop my server, connection is broken, but when I start server again, connection is automatically re-established. But after I've added my _socket.connect(); call, it doesn't work anymore: connection is still down until I refresh the page in the browser.
I've checked that when server calls disconnect();, the reason given to disconnect handler is: io server disconnect. And when server stops, the reason is: transport close.
Ok, then, I've implemented my disconnect handler as follows:
_socket.on('disconnect', function(reason) {
if (reason === 'transport close'){
// don't do anything special
} else {
_socket.connect();
}
});
Now it works. But, all of it seems as absolute dirty hack. At the very least, the reasons given (io server disconnect and transport close) seem to be just human-readable strings, so they might change in the future, and this will cause my code to stop working. And, well, there should be better way to do this; I must miss something essential, but unfortunately I can't find any good documentation on socket.io.
So, the question is: what is the correct way for the server to reconnect some particular client?
Additionally, if you have any recommendations on resources to learn about socket.io, I'd appreciate it very much as well.
How is it possible to add a 'disconnect' event whenever I leave a page that is intercepted by my single page application engine?
I have certain events set up (kind of like streaming events on YouTube) and each requires its own socket connection. I now set up a single-page engine on Angular that allows switching between these events.
I used to rely on the 'disconnect' event to let me know when someone has left the event, but they don't work anymore - the socket never shuts off if I leave via my single-page navigation.
Is there any way to configure the socket to still disconnect?
My less-than-ideal approach was to create a new instance of the socket connection on a controller of every page to which I can navigate from the event page, and forbid multiple connections.
If anybody has a better idea, I would love to hear it.
Thanks a lot.
You may call it manually since you are in control of page navigation - whenever client is navigating away from one page, call
socket.disconnect();
socket.close();
This will ensure that when client is navigating away from one page the socket gets disconnected before that.
I have a web based multiplayer game. It happens from time to time that someone is kicked out because server did not get expected message from client. It seems from my logs that client did not disconnect, just did not send message or server did not receive it. My question here is "Does this things happen normally from time to time?" Should i use some kind of callback mechanism to ensure message is delivered and if not send it again or is there some issue that i am not aware?
socket.io already provides ACKs and message ID tracking, on top of TCP.
Also, socket.io uses pings to check the connection. So, if you say that the client is not disconnected, and the server tells that the client is not disconnected, then the connection is still there.
The problem must be situated elsewhere.
Are you sure there is not a bug in either part of the implementation? Showing some code snippets could help, as well as the environment you are using.