From an MQTT bytes perspective. Once
the subscribe is in place the MQTT bytes that are flowed will be:
- ping req and ping resp every keepalive
interval which is 2 bytes in each direction. (If other messages flow
then a keepalive is not needed while there is other activity)
- for each event that matches the subscription
a message will be published to the client. The number of bytes will
depend on QOS. For example using QOS 0 the number of bytes will be 2 bytes
for the fixed header + UTF encoded topic string (including length) +
message payload.
This does not include TCP bytes
including headers and keepalive.
What keepalive period to use comes
down to 1) What the network requires to keep the connection alive 2) max
time to wait before being notified a connection has broken.
For 1) some networks are configured
to drop connections if no data flows in a finite time. Where this is the
case the keepalive needs to be configured to be less than the network no
data kill time.
For 2) In many cases the "network"
will inform the MQTT client / server the connection has broken without
needing to rely on the MQTT keepalive - the keepalive is really a fall
back / safety mechanism
All the best
Dave
--
To learn more about MQTT please visit http://mqtt.org
---
You received this message because you are subscribed to the Google Groups
"MQTT" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to mqtt+uns...@googlegroups.com.
To post to this group, send email to mq...@googlegroups.com.
Visit this group at http://groups.google.com/group/mqtt.
For more options, visit https://groups.google.com/d/optout.
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU