Brian E Carpenter <brian.e.carpen...@gmail.com> wrote:
> BC: Me too. I coded my prototype with recvfrom limited to 2048 bytes,
> but we probably need to specify something. On the other hand, Michael B
> wants to send infinitely long Intents, I think.libcbor nicely responds to an incomplete message with CBOR_ERR_NOTENOUGHDATA. This lets you grow the data structure for the situation where Intents are large. https://libcbor.readthedocs.io/en/latest/api/decoding.html#associated-data-structures It would be better if the initial parts of the structure could be examined even in the error case, and if it was the case that one didn't want to deal with the rest, one could be told how much more to discard. Or, in some cases, one wouldn't know (streaming arrays, etc), and perhaps the answer is drop the TCP connection. I think that this could be added to libraries. What I guess I'm concerned about is a CBOR definite array structure that says that there are 10 Billion items to be expected, the library goes and allocates that much ram (10G), and the system fails or goes into swap hell. No need to actually transmit the 10G of data. libcbor can be configured to use a custom allocator rather than malloc(3), and this is likely the correct answer: to provide some reasonable limit on amount of memory for decoding... which comes back to how big will the Intents be. kilobytes? probably. megabytes? maybe one or two Mbytes. gigabytes? most certainly not. *could* we make the maximum objective (assuming intents are directly in an objective) size itself be a synchronizable parameter? -- Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
