Clear ping timer and delay puback/pubcomp

[davedoesdev]

Couple of things here:

1. Clear the ping timer on close (sometimes you can get a close without an error, e.g. if the server is restarted). I don't think this should be controversial.
2. When emitting 'message', pass a callback function which the event handler should call when it's done (the callback then does puback/pubcomp). This gives it the opportunity to do some asynchronous work before puback/pubcomp is done. For instance, I'm relaying messages to another message queue system and only want puback/pubcomp to be sent once that system has acked the message. I realise this changes the API; I wonder if there's a way to do this and keep compatibility with existing code?

[mcollina]

Could you please split these in two pull-request?

1. is easy, could you please try to add some tests? As an example, you can close a Broker when the client is connected.
2. is not really going to get through, as it requires a substantial API change. The problem is that an eventemitter is a pub/sub system, so you can have multiple callbacks, and the parent broker will se multiple acks. I think we should add a new method for this that can be overwritten by an user and leave the simple eventemitter as it is. Some tests are needed for this too.

On a side node, have you tried https://github.com/mcollina/mosca? It does exactly what you are trying to do. Maybe we can collaborate.

[adamvr]

The other problem with 2 is that puback/comp are only concerned with receipt of the message at the mqtt level. I guess you could say that if it gets lost between the mqtt client and the message queue, that's your problem. Nice idea though!

[davedoesdev]

Yes- my use case is somewhat different to the normal one for MQTT.js. I'm using it to relay messages to my custom server and I want to puback/comp back to mosquitto only when my custom server has delivered the message to one of its clients. I'll maintain my fork with these changes and rebase it from time to time to pick up other fixes.

[mcollina]

Beware, Mosquitto is not performing very well with this kind of setup. The more messages are 'in flight', the more Mosquitto slows down (at least from my tests).

[davedoesdev]

Thanks. It's fine for now as I have a small number of sensors so far.
I can also configure my relay to ack straight away if required (my custom server has persistent message queues).