[Interest] CBOR Questions

[Thiago Macieira]

On Wednesday, 6 March 2019 08:44:31 PST Jason H wrote:
> > > 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:

In the way that your argument is not supported at all by the part of the spec 
you quoted.

The spec says that each CoAP request or response must fit inside a single UDP 
datagram, without IPv4 fragmentation like the text below talks about. If you 
need to go higher, you need to use the BLOCK extension, which the text also 
talks about.

Whether you're using BLOCK or not, the size of the PDU is known well in 
advance. If you need to, you can wait for the entire content to be received 
and, in the case of blockwise transfers, reassembled, before you start 
parsing. You don't need to send a size count, if that size count is going to 
be the CoAP PDU's size minus the size's size. This is also why CoAP does not 
explicitly indicate sizes in non-blockwise datagrams: the PDU size can be 
inferred from the UDP datagram's size. In turn, the UDP datagram size can be 
inferred from the 802.x frame size.

But if you want to implement a streaming receiver, you also can. That's what 
QCborStreamReader is for (hence the name). It's suitable for parsing on 
streaming sockets (TCP), not just datagram ones.

>  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.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products