SocketCluster/socketcluster

Highly scalable realtime framework

Kevin Boon

@SloppyShovel

Object.values(agServer.clients).forEach(client => {
 client.disconnect(4100, 'Disconnect Reason Here.');
});

Kevin Boon

@SloppyShovel

@haakonnessjoen let me know if that worked for you

Håkon Nessjøen

@haakonnessjoen

Well, that is basically exactly the same as my code

But the "disconnect" listener on the server side is not run

Kevin Boon

@SloppyShovel

Owe Oke, this is what i have in my example

what you mean it's not run on the server side ?

Håkon Nessjøen

@haakonnessjoen

when clients disconnect, the server cleans up some data on the server.

but when the server is shutting down, I manually run client.disconnect() as you say. But none of the "disconnect" listeners is runned. So the server is not able to clean up the clients from the same code.

Kevin Boon

@SloppyShovel

Håkon Nessjøen

@haakonnessjoen

Yes, I also see the error on the server side

but the socket.listener('disconnect') event is not called

on the client socket on the server

Kevin Boon

@SloppyShovel

oke and the client is disconnected, you are calling the disconnect on the client socket server sided

Håkon Nessjøen

@haakonnessjoen

on a specific client socket

Kevin Boon

@SloppyShovel

disconnect and unsubscribe are called a normal

Håkon Nessjøen

@haakonnessjoen

                ;(async () => {
                    for await (let info of request.socket.listener('disconnect')) {
                        console.log('Client disconnecting, clearing up a seat')
                        await redis.decr('seats:' + authData.id)
                    }
                    console.log('After disconnect')
                })()
`

it works correctly when the client disconnects, but not when the server disconnects the client

this is inside a socket.procedure()

it installs an extra disconnect handler to clean up something that procedure activated for the user. So that it is cleaned up when the user disconnects. So I need it to happen when the server shuts down too. Hence I called client.disconnect() like in the examples, in the hope that the disconnect event fires for the agserver client socket.

Kevin Boon

@SloppyShovel

i will check it for you in a sec

Kevin Boon

@SloppyShovel

Oke sorry @haakonnessjoen i'm back

let me read what you said

oke i see, where does request come from ?

request.socket.listener('disconnect')

???

There is a different between a client socket (AGServerSocket) server side and general AGServer events

think that's whats happening here, i'm not sure what request is in your code but if you want to listen to a client socket disconnect event you can do it in the connection event

Kevin Boon

@SloppyShovel

(async () => {
  for await (let {socket} of agServer.listener('connection')) {

    // Client Connected.

    (async () => {
      // Client Disconnect Event Listener.
      for await (let {code, reason } of socket.listener('disconnect')) {
        // Code on Disconnect
      }
    })();

  }
})();

is that what you mean ?

Håkon Nessjøen

@haakonnessjoen

As I said, I add the AGServerSocket disconnect listener inside a socket.procedure() procedure. It works fine when the client disconnects, so it works as expected.

But it does not however run when you disconnect the client from server side.

I would think the same problem would occur with your last example. The disconnect code is run when the client disconnects, but not when the server disconnects the client.

Kevin Boon

@SloppyShovel

That's not what the procedure stream is for

no, the above example i showed you works for both server and client disconnects.

in the documentation there is also something listed that you should not listen to events in procedure stream

Kevin Boon

@SloppyShovel

When the client disconnects.

When the server disconnects the client, events always gets called.

Håkon Nessjøen

@haakonnessjoen

where is the notice about not listening to events in procedure stream?

Kevin Boon

@SloppyShovel

under streams and back pressure i think it's under

@haakonnessjoen did you try the code i showed you ?

Håkon Nessjøen

@haakonnessjoen

I already have code like that for other stuff. But the code I am asking about Is related to a procedure, not to each client, and as I have split up things in separate modules for socket functionality, I don't want to add more disconnect handlers on all connections, for something that is only present in some socket connections (after running that one procedure). I will do some more testing on my own. But I just don't see why a listener defined inside a procedure should not work. As it is just a long living function closure. Haven't had time to look at it yet.

Kevin Boon

@SloppyShovel

when you are talking about per socket, you are talking per each client there is no other concept you can only disconnect a client so its per client you cant disconnect a function, but good luck hope you figure it out.

Håkon Nessjøen

@haakonnessjoen

I am not disconnecting a function. I am disconnecting a long running listener for 'disconnect' that was started inside a procedure. It will only live until the client disconnects. It is just a cleanup from the stuff that the procedure set up. I am just installing a new disconnect handler inside the procedure so to speak. But yeah, I will look more into it. Worst case, I have to make my own event handler for disconnects that can be used by my "modules".

hamiltontt2

@hamiltontt2

We are upgrading a socketcluster server to 16.0.1 from 14.2.2. In order to support "old" clients in the field we are running the server with ProtocolVersion 1. Are there any disadvantages to using ProtocolVersion 1 vs 2?

eranegozy

@eranegozy:matrix.org

[m]

hello. I am considering upgrading from v14 to v16. But I am using SCExchange's broker methods like worker.exchange.set() and worker.exchange.get(). I don't see these function in v16. Does this functionality still exist in v16? Thanks...

Where communities thrive

People

Repo info

Activity