This question already has answers here:
Sharing websocket across browser tabs?
(9 answers)
Closed 11 months ago.
Some people already have asked this questions in some other places, Im just not sure if it exists here. Anyways, Im using Primus.io with engine.io as it's transformer. Im wondering if it's possible to have shared websocket connection on the browser(client). Like if I connected one client and connect another one on the other tab. Ideally they should get same connection that if I send something through the socket both tabs should be able to get the message.
Other's have mentioned about using the localStorage as a way to share/communicate the same data across different tabs, But I just don't find it neat.
Your help is greatly appreciated.
Best,
Each tab will have a separate connection to the server and has a unique socket id.
If you want to emit a message to every socket for a user id or session id you need to have something to map a user or session to its multiple socket connections.
In Socket.IO, they have a concept of a "room".
On connection you can add the socket to a room. This example uses a passport.js authed username for the grouping.
io.on('connection', function(socket){
socket.join(socket.request.user.username);
});
Then you can send a message to all sockets for that room.
io.to(username).emit('some event'):
Socket.IO cleans up the room on disconnect for you.
https://github.com/cayasso/engine.io-rooms is an implementation of rooms for engine.io that might be useful.
In simple terms
On connection, you want to add the new socket to a list of sockets for a user.
On disconnect, you want to delete the socket from the list of sockets for a user.
On emit, you want to emit a message to all sockets in the list for a user.
If the code in your two tabs cooperate, it is possible to share data from webSocket connection in one tab with the other tab. When a tab opens, it would have to find out if any other tab was already open with an existing webSocket connection and it would have to then ask that tab to share its data with the new tab. This is not a trivial operation as browser windows don't have an easy way to find out about other browser windows unless the new window was opened by the prior window's script, not opened by the user.
But, if each of your windows just attempts to make a webSocket connection to the server, they will each get their own webSocket connection. There is no automatic sharing of webSocket connections between tabs.
FYI, the usual behavior here is that each window just gets its own webSocket connection to the server and then the server just separately communicates with each browser window. If some information from one window needs to be kept in sync with the other window, then you can code your server to keep both up-to-date in that way.
Related
I've been implementing a WebSocket with JavaScript and I have this one problem:
The endpoint that my web-application is connected to doesn't send back a close control frame when I'm sending it one.
This isn't that bad because browsers close the WebSocket connection after a while.
But a few things to notice are:
Browsers do only allow a specific amount of WebSockets to be connected at the same time.
When refreshing the web-application a new WebSocket is created
This causes the problem on IE:
When refreshing the web-application more than 6 times, a WebSocket connection cannot be made.
It seems like IE doesn't "delete" the WebSockets if they haven't been closed cleanly. And what's odd is that the amount of web sockets never seems to decrease by refreshing or just by waiting.
Only by closing the browser window, or the tab resets the number of WebSockets to 0.
I've done some researching and this is what I've found out:
Browsers do only support a specific amount of WebSockets to be connected at the same time.
IE supports 6 websockets to be connected [link]
Chrome supports 255 websockets to be connected [link].
And socket.onclose() isn't triggered when you do socket.close(), it is called when the endpoint responses with a close message. [link]
IE waits 15 seconds for the endpoint to send the close message [link].
Chrome waits for 60s for the responding message [Sorry, no link for this, found this out by testing].
If no response message is received, the browser closes the WebSocket connection and a TimeoutError should occur.
Please correct me if I'm wrong :)
I've tried to use unbeforeload to disconnect from the endpoint in hope that the browser would close the connection after a while, but with no luck. [link].
It can also be the cause of that IE aren't able to do request inside the unbeforeload function [link].
Question:
Is there any way to reset the number of WebSockets that are
connected in the browser to the endpoint with JavaScript?
Is there a way to disconnect a WebSocket from the endpoint immediately without closing the connection cleanly?
Is the only way to get this to work to inform the ones who host their endpoint make some changes so they do send a closing frame back?
Is there anything I've misunderstood or that I could try to get this to work?
Here is (in my opinion) good documentation about the WebSocket protocols if somebody would like to read more about it [link1] [link2].
UPDATE:
Only by refreshing the web-application on IE the WebSockets don't get destroyed.
If you navigate between pages in the web-application a new WebSocket will be made but the last WebSocket will get destroyed.
If it is just an edge case problem, then using a http fallback might be your only option. I guess you already do this for proxy servers that block socket connection away.
There is just 1 idea to verify (unconfirmed). Unfortunately, don't have access to IE to verify.
Application may open websocket connection in WebWorker/iFrame. During page refresh, "websocket connection scope" will be deleted, and connection is freed
EXPLANATION
This content from the question body:
Only by refreshing the web-application on IE the WebSockets don't get destroyed. If you navigate between pages in the web-application a new WebSocket will be made but the last WebSocket will get destroyed.
Says that Websocket connection is not destroyed ONLY when page refreshes. During normal navigation, everything is OK.
So, if websocket connection is opened within other scope which will be deleted during page reload, then hopefully connection will be destroyed.
Have some way to keep the same socket.io connection on client side if user open a new page or refresh the page, maybe store the socket in session or it's impossible?
It's impossible. You cannot keep the same socket.io or webSocket client connection when the page is changed or refreshed. The browser simply does not do that. When a new page is loaded or the current page is refreshed, all resources from the previous page are closed and freed by the browser, including socket.io/webSocket connections.
So, your server has to expect a new socket.io connection from the newly loaded page. If you use cookies or a server-side session object, you can identify, on the server, when a connection is coming from a client that you have previously seen and the server can then act accordingly to realize that this is just a previous client reconnecting on a new page.
It seems now that WebWorker are a more widespread technology that it could be use to share websocket.
As explain in this article https://crossbario.com/blog/Websocket-Persistent-Connections/
Webworker are Javascript that is running outside the "thread of the page" and thus are not deleted on page change.
Note that it is running only in the same domain.
You can also look at Kanaka's answer here How to maintain a WebSockets connection between pages? (2012-2017 answer beware)
I'm considering using redis as a key value store for my api application. The api basically only needs one client connection to the redis. What I'm not sure is that should I keep the connection open forever? Or should I only open the connection when I need to set or get values from redis?
One could think that opening the connection is an expensive operation, so in that sense one should prefer forever connections. On the other hand, keeping the connection always open is not as secure as opening it only when you need it. And also, having long open connections open could result in timeouts. Does redis try to reconnect if the connection fails for some reason? How well does redis handle long open connections? Any help is appreciated!
Redis auto-connection depends on the redis-client that you are using. For example,
if you use ioredis, it will automatically try reconnect when the connection to Redis is lost except when the connection is closed manually.
Source: https://github.com/luin/ioredis#auto-reconnect
I am making a game where a node server speaks to javascript clients using socket.io. Players can connect and disconnect from the game and the server keeps track of who is connected. However, I have found that on many occasions when i close the server, close all open client tabs, then restart a new node server, the number of clients connected seems incorrect.
For example, I will connect with just one client but the node debugger shows that the server is keeping track of three sockets.
This is a problem because often these orphaned clients will receive messages from the server or timeout, and this messes up the game logic on the server (it was not expecting this many players etc.)
I think the reason this is happening is:
1. Clients in socket.io automatically attempt a reconnect periodically when they are disconnected
2. When closing a tab the sockets associated with that page are not being "flushed" or cleared for some reason.
3. When the server is closed and then started up again, these unflushed clients think "oh, the server is back up, i will try and reconnect"
How can I tell the difference between sockets that have had their tabs closed/were associated with the old server, and new clients attempting to connect to the newly restarted server? Or is there a way for me to ensure the clients get "flushed" when either the server is closed or a tab?
Without any code, I am really only guessing here.
http://socket.io/docs/#sending-and-receiving-events
Above, you will find code and I will copy it. Basically, you need to listen to the 'disconnect' event on the socket and remove your reference of the client from whatever array you are using to keep track of your clients.
socket.on('disconnect', function () {
// remove from list here
});
Connections from the browser will die on tab close and this event will be called when this happens. Yes, if you reopen the page, they will reconnect.
You should create some sort of "handshake" that actually adds a client to your list of game clients. Anyone can technically connect to a websocket. It can be as simple as emitting an "init" message that is empty but at least have something there.
I am working with socket.io and node.js. I'm am having problems tracking which users are online because of the few seconds delay before socket IO recognises an XHR-Polling client has disconnected.
If an XHR-Polling client refreshes the page their new connection message seems to precede their disconnection message. This causes confusion when trying to track which users are online.
One solution could be to detect the transport method on the serverside and delay the connection for XHR-Polling clients to ensure that the disconnection functions have been run first.
Has anyone had any experience of this?
The main problem with presence, as #davin and #jcolebrand point out in the comments, is that connections alone can't be relied upon. Network devices can hold on to connections after a user has navigated away from a page. So, you need something else in place to confirm a users presence.
This is something we've added support for in Pusher and we do this using something called Presence Channels.
We manage this using a unique user id, which you (the developer) have to supply when a user connects, in combination with a unique socket id which identifies the connection. Since this unique user id can only occur once within a presence member list it means that that user will only be listed once - even if they have multiple connections open, and thus multiple socket connections.
The same idea can be applied to HTTP connections.
The general approach for this is to use the session to uniquely identify the user. In that way even if they are just a "Guest" you can still identify them as long as they are allowing the use of cookies.
So, the number of users on your system should only ever max at the number of active sessions you have running on your server.
Hope this helps. Let me know if you'd like anything clarified.
I'm developping a chat support solution and the attendent have to know when a client connect. With websocket works fine, but with whr-pooling, sometimes the attendent just disconnect (with 5 seconds in some cases). Sometimes dont heppend. What I do: I just enter the page and wait looking the terminal app.
I'm using nodejs, nowjs
What version of socket.io are you using? I encountered this issue and solved it on this post. It turns out there was a bug introduced in socket.io 0.9.5 on the request sent when the beforeunload event was triggered that prevented the proper disconnection.