Forced Disconnect - Client Side Issue

[austinh]

When using the socket.disconnect(); function from the server to force a client to disconnect, the client (when using XHR-Polling) continues to constantly send requests to the server. Not tested with WebSockets, but also possible issue there. Is this a bug? Or intended?

If this is intended, what is the correct way to force a client to disconnect (from the server), and stop any and all connections with the socket.io server.

[austinh]

Any response to this? I'm not 100% sure if this is a bug or intended. If it's a bug, I'd be glad to help fix it.

Edit: Damnit...The "Comment and Close" button is huge, I keep hitting it! I reopened the case because of my silly mistake.

[bminer]

+1 There is currently no documented way to properly kick / punt / boot a client. It makes me sad... I want to rudely punt my clients; politely asking them to disconnect is boring.

[chrisdew]

+1 This would help me too.

[nh2]

Is this a duplicate of issue #47? I think it is about the same question.

[austinh]

I guess it is a duplicate. Is there an official way to disconnect a client?

[bminer]

Yes, this is a duplicate of #47, but there is still no official, documented API function to disconnect/punt a client.

[Sembiance]

I have a test case for this problem, I attached it to issue #438

See: https://github.com/Sembiance/client_not_handshaken_test_case

[Jimflip]

+1 I really need this also.

[austinh]

Any update on this? Maybe this will be available when socket.io's codebase migrates to engine.io?

[Josh1billion]

+1, this seems like an important feature. I want to accomplish it as well, and so far I haven't found a good workaround yet.

You can send the client a message requesting that they disconnect, but what happens if they don't listen to it? I suppose you'd need to add your own variable to the socket, such as "valid", set it to true when the client connects and false when they disconnect, and only process messages when valid is true. Even then, they're still taking up your server's download bandwidth (though I suppose they could do that just by reconnecting anyway).

[chrisbnt]

+1, would I be right to assume this is non-trivial in some of the supported transports?

[bminer]

@barn3y - I could be way wrong here, but it's probably pretty trivial, actually. I think it's as simple as sending the client a special DISCONNECT message and then just disconnecting & ignoring future requests from that client. The client then has to worry about cleaning up as it normally would if you called disconnect() on the client. Or, maybe I'm way off... haven't looked at the socket.io source in a while.

[nh2]

#47 seems to be done.

[scanales]

Having the same issue, did any of you guys come up with a decent workaround for this?