search

moscajs / aedes

Barebone MQTT broker that can run on any stream server, the node way
MIT License
1.79k stars 231 forks source link

event sequence on reconnect #8

Closed behrad closed 8 years ago

behrad commented 8 years ago

In mosca, when an offline client (which is not yet keep-alived in mosca side) tries to reconnect, server emits a connected event followed by a disconnected for old connection which mosca closes. This makes it hard for apps to easily recognize correct client status (online/offline) and also produces a race. How is this in Aedes? and can server first emit disconnected (or even don't emit it in such scenario) and finally emit connected event at the end of processing new connection?

mcollina commented 8 years ago

I believe aedes should respect the real order 'clientDisconnect' first, and then 'client'. Would you mind contributing a unit test to keep checking that order is preserved?

(it's much easier to tests those cases here, as all the tests do not involve the network)

behrad commented 8 years ago

Can we add a reason to clientDisconnect then? (connect also can have more detailed info, like ipaddress)

I will give it a try to write a test when I'm more idle, but currently too busy.

mcollina commented 8 years ago

It would be great to get a PR, It should be easy enough.

What do you think the reason should be? Just a string?

behrad commented 8 years ago

What do you think the reason should be? Just a string?

Can you enumerate some? like normal (client closes the connection normally), reconnect (the same scenario as I mentioned above), error (protocol errors, ... ), ... !?

mcollina commented 8 years ago

Error will emit 'error', and then 'disconnect'.

Also there are 'wrong user/password' and 'unable to publish'.