Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [mosquitto-dev] Suggestion regarding `persistent_client_expiration`

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Are you trying to use client expiry to toss out queued messages?  That
sounds like a risky path.     If you want such short lived clients, why
make them durable clients at all?  With a keepalive for the connection
of 5-10 seconds, (very short) what would be the point in expiring
clients in anything less than a minute?

I  can sort of see the use in hours, but really, if you need them that
short, I don't know why you are using durable clients at all.  

I really don't see how client expiration has any bearing on response
time to data either.

Sincerely,
Karl P

Felipe de Andrade Neves Lavratti <felipelav@xxxxxxxxx> wrote:
> The configuration key `persistent_client_expiration` has its minimum
> value of 1 day.
> 
> There are network contexts, including the one I use Mosquitto with,
> where valid data has the expiration time lower than 1 day, for
> example, actuators in a real time network, where the network must
> respond in a time window of seconds to the user input.
> 
> If the configuration key `persistent_client_expiration` accepted
> _seconds_ and _minutes_ as valid value. Clients, in these real time
> networks, could catch only not expired data from the broker in the
> events of the connection getting dropped and re-established again.
> 
> To make it short:
> My suggestion is that `persistent_client_expiration` get implemented
> to work with time windows from 1 sec.
> 
> I can do the coding, just need to know if it is a welcome change.
> 
> Thanks!
> 

- -- 
Sent using Mailpile, Free Software from www.mailpile.is

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQIbBAEBAgAGBQJVmY7YAAoJEBmotQ/U1cr2kJQP93Z6FAn67bZzuWHdLP7A1SQ5
wmz0OCT9BRuU8m4JmggLC0yx9JoI5vwt7gqQrnd8fGNJkYFEQlCaD2eXBe+aUSyf
si/GKB6QtpKD+xdM4mGHMzK4J/GwAOUgPV+rzNF9a0NmMYBlx4GlfeytzwovHxz4
JCQX7owTMKzC3fWZDmWV3gQyc/0VvuwD+2o6DdtOBdHmUMsHvAAuE0Icq+e3oWn6
CA/BMgjzlrAtLf48PXc89xnsE3QQnLpiWluwHqZ0SnnNf+fWp6LiiV10wKZBdb6i
+xZSdHWThv+nTm7P40WP7XBWnU06altd9irTBxSebeoSb8JQWJD8BJPAfcvqJzxy
a8YSBAwWpkTroKfBUUU76NwzXqzZlg2lERzflD+YOPGIwoKb5lpwd7tyiyT2fxaO
NRmmBn0o3YfZ16XtXj7SAqc+is0Qom59WxJ23mgVqijXPrAaadB8q/W2GRThE6TY
NMu5Xa4ioDzrSSaTK40w5FCF0ruh1dzjsXVZkeUANZr1xrZ5NyQpBPLkrYs3r3o8
sbulmiUrLia6gveagzoIUjuD5+D8B1+XGch6ufpR4IV1cGD+XpYOmgv1La9G4dhn
DKRO1A2o9RROSEWaw2fTUFh+qyk+gIflgN962a36Of8kXDJvuac+Qb8hCS3zUYhM
LyNO9oJ6MqlDffPErVA=
=hZZt
-----END PGP SIGNATURE-----

Back to the top