Prevent FIN_WAIT connections by using stream.destorySoon()

[eladnava]

As per #306.

[mcollina]

can you please move the else inline with the }?

[mcollina]

I'm thinking we can have a three way case: destroySoon, destroy and end. In this order.

What do you think?

[eladnava]

@mcollina Done, however I wasn't able to run the tests completely as I don't have Redis installed.

[mcollina]

@behard what do you think?

[eladnava]

I think you meant @behrad =)

[mcollina]

Oh yes :D.

[behrad]

So it should reduce FIN_WAITs :)
If destroySoon is preferable, how will that affect on the mobile/public facing client end?

[eladnava]

@behrad When connected clients passively disconnect from the internet, they will eventually be kicked due to Mosca's keepalive timeout mechanism, which calls socket.end() if the client hasn't sent an MQTT keep alive packet within the client-defined time limit.

In its current implementation, calling socket.end() on those connections will have them stuck (if not indefinitely, then for a long time) in FIN_WAIT states because the TCP stack will attempt to let the client know it's closing down the connection. But since the client is no longer reachable then the server will never be able to deliver the FIN/ACK packet to the client, nor will it receive a FIN/ACK or an ACK from the client in response to the FIN/ACK.

Does that answer your question?

[behrad]

great explanation @eladnava 👍
I can test to see how this patch will change the real world scenario :)

[eladnava]

@behrad excellent, please let us know if it's OK to merge :)

[mcollina]

Ping @behrad? I'll like to merge this and release next week!

[behrad]

Sorry guys, so busy these days, it takes me some time to test this, I'l let you even after @mcollina releases this :)

[eladnava]

@mcollina Has this been released yet? I'd love to use it in production. Thanks! 😄

[mcollina]

Sorry, released now as v2.1.0.

[eladnava]

Excellent, thank you! 👍