I'd like to force client disconnect by socket id using socket.io-redis.
I tried a lot of research in google, but methods mentioned in old topics does not work.
Let's say, I'm making clustered application and my code at the moment runs at cluster1 instance (also I have access to all connected client's socket ids), but the client is connected to cluster2 instance. How can I force disconnect to that client by socket id only?
I've implemented it by myself and pulled in the socket.io-redis repo. Method name is remoteDisconnect.
Related
I’m bulilding a web app that requires communication between clients. For this I’m using socket.io. Some data however has to be updated regularly in the database.
Some of them not that often (preferences, on button click) others in every second for example a timer value. This can not be calculated because the timer can be paused.
Right now whenever a client emits an event, it also makes a request to the backend to updated the database. I was wondering if it would be a good idea to have the socket.io server update the database so the clients would only have to take care of the socket communication? It seems to me that having the browser do a request to the backend is a bit resource heavy and takes out a bit from the advantages of the socket based communication
Edit: the back end of the app and the socket server are two different servers but physically they are on the same machine so their communication could be faster
the main point of using socket.io is that it allows you to push data to clients and clients do not need to check your server constantly to get the last changes, and providing a low-overhead communication channel between the server and the client.
you can call an API and also emit data and many other things on user click in your application.
it is a good idea to have the socket.io server update the database and you can also authorize each socket, save client sockets information and ...
NestJS 8， socket.io 4
Client user has a socket being able to receive data from the server. Not sending.
Refresh browser, the socket ID changed. Socket on the client receive 'connect' event! Yet. On server side, no logging at all. Which kind of explained point 1.
After reboot nest, problem is gone. But it comes back eventually.
My current troubleshooting direction is
Was the connection on the client dead already and it's still trying somehow to update the socket?
Browser does some caching, service worker?
I hope someone can enlighten. This happens after upgrade to socket.io 4 from 2.
It's my own stupidity.
My tenant who own the namespace. In order to reach him, I create his namespace and send message to it no matter he's online or offline.
This works fine in socket.io 2. I don't know why.
What I should do, is to check whether or not, the namespace exists or not first.
That's why the issue that I have is that the server somehow seems able to pipe message to the namespace, yet the tenant cannot send the message to the server because the tenant was not initialized properly in the nest gateway.
I have WebSocket implemented in a real-time application, where connected clients get all server updates without page refresh. That's fine and it's working very well. The problem is as follows:
Lets say I use two servers (server1 and server2) to serve client requests. If a client on server1 updates the database, all clients connected to server1 will get the updates, as expected, because server1 is aware of all connected clients. However, clients connected to server2 do not get any updates because they are being served by server2 who is not aware of the database updates (the updates were done by a client on server1)!
Is there a standard way of handling this? Also assume I have many servers.
If this has been addressed before, I'd also appreciate a pointer to it. Thanks
Handling the DB values, changes should be the responsibility of each instance connected to the DB. Whereas sharing updates (requires DB change or not)across various clients should be the responsibility of the handler. For websocket usually such updates are handles by writing it to a pub/sub channel/queue such as reddis and all instances subscribed to appropriate channel. Whenever any instance wants all clients to receive an update it puts it on that queue and all the instances are able to receive and broadcast it
I have TCPListener server based on this source code https://gist.github.com/leandrosilva/656054#file-server-cs
I created a server on port 3340. Whenever a client connects to the server, then server waits for the new client connection. When I connect from my Chrome browser to the server, then it seems there are three clients connected (expected only one).
Why it is like that?
Most clients maintain multiple connections in parallel, including more than one connection per server endpoint.
And RFC7230 section-6.4 explains. Multiple connections are typically used to avoid the "head-of-line blocking" problem
I'm writing a chat server application where the users can exchange messages with one of his friends. When the user connects i store his connection on an class variable hash:
##connections[:user_id] = conn
When someone sends the user a message, I look for his connection on the hash and send the message through it. Sometimes the connection whith the clients simply dies, and the onclose callback is not invoked.
That works fine, and it's what I did when I started writing a web IRC client, but the problem is you're coupling your connected users to a single ruby process. If you wanted to spin up a 2nd em reactor, that 2nd process would not share the same class variables. You can get around that by using haproxy to split users between the different processes, but it's something to watch out for.