> > So the protocol it expects to work with assumes a message-based upper bound,
> > and of trivial size. This is not good. In light of this, I would suggest a
> > QCborDataStream class that implements efficient parsing.
>
> No needed. You simply misunderstood the CoAP spec.
In what way? The spec continues:
Implementation Note: CoAP's choice of message size parameters works
well with IPv6 and with most of today's IPv4 paths. (However,
with IPv4, it is harder to absolutely ensure that there is no IP
fragmentation. If IPv4 support on unusual networks is a
consideration, implementations may want to limit themselves to
more conservative IPv4 datagram sizes such as 576 bytes; per
[RFC0791], the absolute minimum value of the IP MTU for IPv4 is as
low as 68 bytes, which would leave only 40 bytes minus security
overhead for a UDP payload. Implementations extremely focused on
this problem set might also set the IPv4 DF bit and perform some
form of path MTU discovery [RFC4821]; this should generally be
unnecessary in realistic use cases for CoAP, however.) A more
important kind of fragmentation in many constrained networks is
that on the adaptation layer (e.g., 6LoWPAN L2 packets are limited
to 127 bytes including various overheads); this may motivate
implementations to be frugal in their packet sizes and to move to
block-wise transfers [BLOCK] when approaching three-digit message
sizes.
_______________________________________________
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
