You can clone with
HTTPS or Subversion.
Hi, it seems that a client can occasionally get dozens on noop packets from engine.io server during websocket upgrade, perhaps due to checkIntervalTimer in lib/socket.js triggering ten times per second, and not checking if it has succeeded in sending a noop packet already? Or is it intended to just keep sending until upgrade packet is received. The issue is seen mostly behind slow connections, of course.
master or latest tag?
@plievone after sending one packet we should clear the timer. GOOOD catch
I guess you closed this by accident? :)
Now, perhaps sending multiple noop packets is intentional -- in my brief testing now the client failed to upgrade with only one packet, as it came before polling cycle started pausing and then the situation stalled until eventually ping timeout was emitted and the socket was closed. If it really is so, there might be a problem with the process here... Hopefully it is my setup (open socket, client side close it in 300 ms, then open it again in 1000 ms, then see what happens).
socket: clear timer after sending one noop packet (fixes #174)
Hi @guille, thanks for this, but unfortunately now the client can miss the noop packet (it comes via polling transport, whereas probe pong comes via websocket, the ordering can change?) and stall in upgrade? Perhaps best for now would be to have a longer, 500 ms interval just in case, and trigger it also on the leading edge separately.
Revert "socket: clear timer after sending one noop packet (fixes #174)"
This reverts commit 752dab4.
Open for discussion on how to improve
@plievone Is this still an open issue?