I have two browser socket.io clients. For example. Client A and Client B and They are connected to Room one.
Following behavior is happening on my computer (installed nodejs 5, socket.io 1.4.5):
We suppose that both of clients are connected to Room One. When Client A is disconnected (lose connection) and reconnect after timeout and Client B does not use emit for send message to Room one, then original socket of Client A will be closed with transfer reason: timeouted. Thats good for me. I need it this behavior.
On other side:
When Client A is disconnected (lose connection) and reconnect in timeout time and Client B during that disconnected time uses emit for send message to Room one, then original socket of Client A after reconnect will be immediately closed with transfer reason: closed and not timeouted.
It looks that there is some behavior that selects disconnected sockets in timeout time for that some other online socket try emit message to same room. When emited message cannot delivery to disconnected socket (on client side), then this socket is probably select for immediately close of transaction after reconnect in timeout time.
I noticed futher issue. When mobile client lost connecting and somebody send emit to room where mobile client was connected, then mobile socket is disconnected immediately without timeout with reason transport close on linux.
the situation above is different for mac system. The socket is disconnected either timeout is gone or immediately if client mobile is reconnected.
Can anybody help what is a reason that this behaviors on same version of node (6.2) and same version of socket (1.4.6) are different?
Related
We are facing an problem with socket on internet switching case.
For example : An user connected to Internet A & switched the internet to network B .
When user disconnected then Socket taking time to fire socket.disconnect() event but in meanwhile User connected again to socket with new socket_id (after switching the network).
After user re-connect we also received Socket.on('disconnect') event with old socket_id but it should not be. Because user is already reconnected.
We are doing this because we have to manage the duplicate session of an user on socket.
Is that possible if user reconnected in meanwhile time we should not received any disconnect event ?
We are using below configuration on our server end
Socket Lib 2.1.1 with pooling & websocket
Node server with single/multi thread socket.
In single thread with Pooling we are facing above problem in rare case. But in multi-thread socket server, we are facing this problem each time.
But In Multi-thread with Websocket we are facing above problem in rare case and in single thread socket server, we are facing this problem each time.
Is that possible to increase the socket respond time ?
Socket should fire disconnect queue first before to connect an user ?
which is the best practice to use socket with Pooling or websocket in single/multi thread socket ?
When the socket.io client performs an (automatic) reconnection - as might happen if a mobile client went to sleep then woke up again - does the server get a reconnect event? Or does it just see a disconnection and fresh connection?
In either case is there a way to
identify that it's the same client e.g. by a unique client id that persists across connections
have the client automatically re-join any rooms it was in before
Or do I need to code that functionality manually e.g. by having the client supply the id or rooms itself on reconnection?
I had a read of the socket.io docs and can't see any list of events that the server might receive.
I'm developing server application and have following problem with sending data back to client, that suddenly terminates the connection.
When I call send on blocking socket with write timeout set via setsockopt(SO_SNDTIMEO) and client disconnects during sending (i.e a few bytes are sent, then client properly terminates TCP - as can be seen in wireshark), send still blocks, until send timeout elapses. Following call to send returns error as expected.
I would expect that TCP termination (FIN/ACK) will cause blocking send to return immediately, not after timeout.
Have someone ever seen such behaviour? Is it normal?
No, the FIN sent from the client does not unblock the send() at the server. When the client calls close() the FIN is sent to server and the connection is closed for the direction from client to server. The direction from server to client is still open till the server calls close() and FIN is sent to the client.
When the client sends FIN and the server sends ACK back then connection on server is in the CLOSE_WAIT state and the connection on client is in the FIN_WAIT_2 state. Server still may send data and client still may receive data till server close the connection.
The close connection cannot be detected through send(). Only recv() detects the connection closed by peer.
If your code must execute an immediate action when client close the connection then it must call poll() or select() and use non-blocking send() and recv() calls.
I am using socket.io to send data from my sever to clients. There are situations when a client looses its connection but the server gets to know about this only when the next heartbeat is not recieved from the ckient.
the messages that are sent between the client loosing its network connection to the time when the sever derives this from absense of heartbeats are lost and I am not able resend them when the client rconnects.
I know there I can send a callback in my message which the client will call on successfull delivey of message. however this callback is asynchronous and I Am not aware of any way by which I can getto know that the message delivery failed. Can anyone please help me findhow can I capture a failure to delive a message.
Thanks in advance
According to the documentation, you can configure "max reconnection attempts" for
How many times should Socket.IO attempt to reconnect with the server after a a dropped connection. After this we will emit the reconnect_failed event.
On the socket io server I have something like:
io.sockets.on('connection',function(client) {
console.log(client.id + ' connected at '+(new Date()).getTime());
client.on('disconnect',function() {
console.log(client.id + ' DISCONNECTED at '+(new Date()).getTime());
});
});
And my problem is that this happens:
debug - client authorized
info - handshake authorized 15229479751557595508
debug - setting request GET /socket.io/1/websocket/15229479751557595508
debug - set heartbeat interval for client 15229479751557595508
debug - client authorized for
debug - websocket writing 1::
15229479751557595508 connected at 1313769716321
debug - websocket received data packet 5:::{"name":"estimatepp","args":[9]}
debug - websocket received data packet 5:::{"name":"ready","args":[null]}
info - transport end
debug - set close timeout for client 15229479751557595508
debug - cleared close timeout for client 15229479751557595508
debug - cleared heartbeat interval for client 15229479751557595508
15229479751557595508 DISCONNECTED at 1313769716454
debug - discarding transport
I don't know if this is normal but as you can see, the client 15229479751557595508 connects at 1313769716321 and disconnects at 1313769716454, just 133 mili-seconds later (this number is always either 132 or 133). I'm not ordering the client to disconnect after something.
Any ideas on why does this happen ?
Also I have another doubt. If I listen for connection events on io.sockets.on, shouldn't I be listening for disconnect events also there ? Except there's no client there...
What is the correct way to listen for disconnections ?
Thanks for any help.
EDIT: You can ignore the lines
debug - websocket received data packet 5:::{"name":"estimatepp","args":[9]}
debug - websocket received data packet 5:::{"name":"ready","args":[null]}
It's part of the project I'm working on. Maybe the thing is that it just receives those events and after that because there's no activity for a while it closes the connection ? But this is not wanted behavior is it ?
The server-side code that you have posted is fine and should work as expected. Check for bugs in your client-side code (or post your client-side code here). If nothing there, try a different browser.
Regarding your disconnect event.
You have an io.sockets.on("connection", function (client) { ... }) event handler where when a new connection is made, a session is created for the connection and is stored in the client variable.
You then attach event handlers (like the disconnect one) to this client object.
Now when that client disconnects, the disconnect event handler attached to that particular client object is invoked.
Moreover, as you can see in Exposed Events — Socket.io, io.sockets.on only exposes the connection event.
I have similar thoughts as the creator of the question.
The time in ms is probably your roundtrip time to the server or the time it takes to manage connects with the client etc etc. So I wouldnt bother so much with the time factor.
I get same result when I refresh the client manually and repeatedly. between say half and one second intervals. This seems to create a scenario which otherwise only happen with poor network quality.
I can see in the logs that I get a connection, before a disconnection with the same socket.id.
client connected: qEcxQQCivSyKJVbF85dc
client disconnected: qEcxQQCivSyKJVbF85dc
However my on.disconnect event does in this scenario NOT fire.
On disconnects I clean up my local object of connected clients and I can see that I a client left in there and when I analyze the socket.connected status it is disconnected.
So under certain circumstances the above scenario causes a disconnect event to not fire.
Probably due to timings, asynch, network quality etc.
Two ways to go.
Build the application according to those constraints or
find someone who can come up with a more solid method for listening to on.disconnect, which, as the original question eluded, does not involve being attached to a specific socket client.
It is like the event listener is overwritten when the client connects again with the same id. A more general disconnect event listener would disregard that but potentially cause other issues instead.
I am personally going with option 1. and instead creating a garbage collector of sorts that clean up my local array of clients if they are disconnected.