Closed andresv closed 2 years ago
I think this documentation can be even further improved.
The length L
is actually the number of bytes of serialized MQTT packets that can be squeezed into the transmit buffer.
As an example, if you send a publish
packet at QoS 1 with 20 bytes payload and 30 bytes topic name, the serialized packet length would be determined by https://github.com/BlackbirdHQ/mqttrust/blob/63a3a76e597d9a04337baa86686dd634777f32c1/mqttrust/src/encoding/v4/packet.rs#L88-L105 to be 5 + 2 + 20 + 2 + 30 = 59 bytes
. With an L
length queue of 200 bytes
you would be able to client.send()
200 / 59 = 3
of those publish packets before needing to flush them to the network with eventloop.yield()
. Usually you would yield on every pass of your main loop, but there are lots of cases where one would push multiple publish packets into the transmit queue in a single event loop pass.
Not sure if above makes sense?
As an example, I often have multiple subscribes happening rapidly in a row.
Yes makes sense. I try to come up how to add this info to docs.
Added some more info about L
.
Base: 39.16% // Head: 39.21% // Increases project coverage by +0.05%
:tada:
Coverage data is based on head (
1bb0d3a
) compared to base (3f175ec
). Patch has no changes to coverable lines.
:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.
Thanks
L
does not actually mean the number of packets. It shows underlyingBBQueue
buffer size in bytes whereFrameProducer
is taken.It would be good to give some tips what minimum required length would be. Like if your max expected MQTT payload is 100 bytes and topic name 20 bytes then
L
should be at leastN
bytes. @MathiasKoch do you happen to know what it might be?