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
Related
I have an application that spins up websocket connections on random ports after checking to make sure the port has not yet been assigned. Each connection has a front facing card with a slider to create/destroy the TCP connection based on the port number they are assigned (and stored). It is simple to spin up a server for each socket with the predefined event handling that it comes with but i am unsure of a way to allow the user to kill the tcp connection. What this would look like is the user from the front end woudl slide the toggle intot eh off position and I would take that entities id, query for its port number and would then need to close that port's connection. I am hoping there is a way with node to be able to query for its active servers and act on them as one pleases but I have not found any articles suggesting a way.
I am hoping there is a way with node to be able to query for its active servers and act on them as one pleases but I have not found any articles suggesting a way.
There is no such thing built into node.js.
If you wanted to be able to operate on all the webSocket servers you had started, then you could just add them to an array as you start them.
const serverArray = [];
// code elsewhere that starts a server
let server = new WebSocketServer(someRandomPort);
// push an object into an array that has the port and server
serverArray.push({server, port: someRandomPort});
Then, you could iterate over that array at any time to do something to all of them or to find a server that is using a particular port.
But, it sounds to me like you don't really need multiple webSocket servers. Multiple clients (with however much security you want) can all share the same server. That's the usual client/server design (multiple clients talking to one server).
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.
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 have a client/server application using nodejs on the server and socket.io as the connection mechanism. For reasons relevant to my application I want to have only one active connection per browser, and reject all the connections from other tabs that may be opened later on during the session. This works great with WebSockets, but if WebSockets is not supported by the browser and XHR-polling is used instead, the disconnection never happens, so if the user just refreshes the page, this is not interpreted as a reconnection ( I have a delay for reconnection and session restoring), but as a new tab, which ends in the connection being rejected because the old connection made by this same tab is still active.
I'm looking for a way to effectively end the connection from the client whenever a refresh occurs. I've tried binding to the beforeunload and calling socket.disconnect() on the client side, and also sending a message like socket.emit('force-disconnect') and triggering the disconnect from the server with no success. Am I missing something here? Appreciate your help!
I've read this question and couldn't find it useful for my particular case.
Solved the issue, it turns out it was a bug introduced in socket.io 0.9.5. If you have this issue just update BOTH your server and client-side code to socket.io > 0.9.9 and set the socket.io client-side options sync disconnect on unload to true and you're all set.
Options are set this way:
var socket = io.connect('http://yourdomain.com', {'sync disconnect on unload' : true});
You can also get "Error: xhr poll error" if you run out of open file descriptors available. This is likely to happen during a load test.
Check the current open file descriptor size:
ulimit -n
Increase it to a high number:
ulimit -n 1000000
I just got started in node.js and created a server where browser clients can connect to it.
Problem: When there is an error in the nodejs server and it crashes and restarts, the connected clients will usually reconnect automatically, but I notice that many clients usually make multiple reconnections back to the server!
How can I prevent that from happening, either serverside or clientside?
I suggest implementing it server-side. Apperantly, there is no implementation of it in socket.io (Source Code), so you can use key-value caches like Redis and map every connection in the Redis and check if user is already connected.