I'm going to take silence as assent: i.e. we will specify a default maximum message size of 2048, and leave the question of how it can be exceeded to be a negotiable property of individual objectives.
Regards Brian On 20/10/2016 15:34, Brian E Carpenter wrote: > On one point: > >> *could* we make the maximum objective (assuming intents are directly in an >> objective) size itself be a synchronizable parameter? > > We could even make it negotiable, since GRASP supports negotiation :-). > But I think we'd better start off with a hard limit so that we don't > encounter 10GB requirements during initialization. > > I could imagine adding a max_size parameter to the API, too, so that > a given ASA could accept larger messages for a given objective. So maybe > the best thing for now is to define a *default* maximum size in the spec. > > Regards > Brian > > On 20/10/2016 09:13, Michael Richardson wrote: >> Brian E Carpenter <[email protected]> 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 <[email protected]>, Sandelman Software Works >> -= IPv6 IoT consulting =- >> >> >> _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
