PING response from client?
DanAnderson
I was working on finishing up subscription support on my MQTT program
when I had a thought...
The spec doesn't currently allow it, but maybe it would be useful if
it did allow clients to respond to PINGREQ messages from the broker.
It's clearly useful for the client to be able to ping the broker. It
might be similarly useful for the broker to ping the client.
What do you think?
Thanks
Dan
DanAnderson
Interestingly, MQTT-S already has this behavior.
Section 6.11:
http://mqtt.org/MQTT-S_spec_v1.2.pdf
Dan
On Jan 28, 11:52 pm, DanAnderson <dan-ander...@cox.net> wrote:
Nicholas O'Leary
if you're running on a wholly reliable TCP connection, and reliable
client/broker implementations, then the keep-alive is technically not
needed - you can just let TCP deal with it. But MQTT comes from a
background of unreliable connections running on less than perfect TCP
stacks - so something more was needed.
Earlier drafts of the spec did not specify the direction of the
PINGREQ/PINGRESP exchange, but in reality all implementations we had
only had the client sending the PINGREQ.
Of course, if the spec didn't specify a direction, then all
implementations would have to support both ends of the exchange -
regardless of whether they ever got exercised.
With the focus on keeping the footprint as small as possible, both in
implementation and on-the-wire, we couldn't see a good reason to
require the PINGs to flow in both direction.
Cheers,
Nick
> --
> To learn more about MQTT please visit http://mqtt.org
>
> To post to this group, send email to mq...@googlegroups.com
> To unsubscribe from this group, send email to
> mqtt+uns...@googlegroups.com
>
> For more options, visit this group at
> http://groups.google.com/group/mqtt
Zvi
not in MQTT), since it's much easier to manage.
Usually only server/broker know the network topology and best ping
periods.
So I'm +1 for server side pings.
On Jan 30, 10:08 pm, "Nicholas O'Leary" <nick.ole...@gmail.com> wrote:
> Hi Dan,
>
> if you're running on a wholly reliable TCP connection, and reliable
> client/broker implementations, then the keep-alive is technically not
> needed - you can just let TCP deal with it. But MQTT comes from a
> background of unreliable connections running on less than perfect TCP
> stacks - so something more was needed.
>
> Earlier drafts of the spec did not specify the direction of the
> PINGREQ/PINGRESP exchange, but in reality all implementations we had
> only had the client sending the PINGREQ.
>
> Of course, if the spec didn't specify a direction, then all
> implementations would have to support both ends of the exchange -
> regardless of whether they ever got exercised.
>
> With the focus on keeping the footprint as small as possible, both in
> implementation and on-the-wire, we couldn't see a good reason to
> require the PINGs to flow in both direction.
>
> Cheers,
> Nick
>
>
>
>
>
>
>
>
> > Hi,
>
> > Interestingly, MQTT-S already has this behavior.
>
> > Section 6.11:
> >http://mqtt.org/MQTT-S_spec_v1.2.pdf
>
> > Dan
>
> > On Jan 28, 11:52 pm, DanAnderson <dan-ander...@cox.net> wrote:
>
> > --
Nicholas O'Leary
I remembered another rationale for having the clients responsible for
the ping rather than the broker.
First, let me remind all that the keep-alive flow serves two purposes.
Firstly, it allows the broker to know that the client is still alive.
Secondly, and this is sometimes overlooked, it allows the client to
know that the broker is still responding to it and that the connection
is still good. I have seen a number of naive client implementations
that ensure the PINGREQ is sent, but they don't verifiy the PINGRESP
is received - they don't notice all their data is disappearing into a
black-hole.
In most scenarios, the server is running on reliable hardware with an
established operating system and networking stack underneath it. This
means the broker implementation can rely on these layers to notify of
any problems with the socket at the TCP level.
The client is more likely to be found on smaller platforms that cannot
be relied upon as fully. For example, you call pull the ethernet cable
out of the Arduino and it takes a very long time for the software
stack to notify the application that anything is wrong, if at all. So
the client needs to take responsibility for monitoring its connection
is still active.
Regards,
Nick
> To learn more about MQTT please visit http://mqtt.org