Re: [mosquitto-dev] persistent_client_expiration, async connections with

[Roger Light <roger@xxxxxxxxxx>]

Hi Steve,

> So far I've posted two questions here and haven't received any response
> whatsoever, don't know if I'm asking bad questions - I hope not.

This is only the second of your emails I've seen, so I'm sorry it
seems like I didn't get the first one. I've been trying to keep my
time at the weekends free of this sort of work, which is why I'd not
replied to your previous email until today.

> I had noticed that in the event that the broker unexpectedly disconnects a
> connection it appears that libmosquitto will attempt to reconnect.  Since I had
> used clean_session=true it also appears that any existing subscriptions will be
> lost (am I correct in this???) which means that a client with subscriptions will
> need to set an on_disconnect callback not to reconnect, but to resubscribe to
> previous subscriptions.  This seems a little odd to me if correct that the
> library tries to be so helpful about re-establishing the connection but then
> requires manual intervention to resubscribe.

I've covered this in my previous reply, but for anybody else who find
this email first - if you're using clean_session=true, then the best
plan is to make your subscriptions in the on_connect callback. You
might consider that to be manual intervention, but I'd say that I
think it's entirely appropriate for the application to be keeping
track of what subscriptions should be made on connect, not the
library.

> If this is true it would seem to encourage clients to connect with
> clean_session=false.  But then according to the documentation for mosquitto.conf
> for the persistent_client_expiration option "Badly designed clients may set
> clean session to false whilst using a randomly generated client id."  This
> sounds like unless this option is set clients which set clean session to false
> whilst using a randomly generated client id effectively set up a potential
> resource leak on the server which opens up a denial of service attack.

It could make the server use lots of resources, yes. There are quite a
few ways you could mitigate the risk like
persistent_client_expiration, max_packet_size, max_queued_bytes,
max_queued_messages, memory_limit, and max_connections. You do have to
set those yourself though.

Regards,

Roger