Hyuna: I've actually been working on this on the side as well. I have 2 different solutions I've been working towards.
1- A bit of a re-factoring to have the allocation happen all at once in a single function that calls with a growth method (so if, say, 256 bytes fail, try 512 and so forth). 2- A significant refactoring plus contribution to tinycbor that allows for a NULL buffer. Run through once with the NULL buffer, get the size out of that, then allocate, and run through it again. I'm definitely preferring #2, and have done a bit of work on it lately. I still need the tinycbor contribution, but since it is something important for you guys, I can dust off my RI work and get it done, though perhaps it'll take some help from Thiago for the tinycbor fixes. -Erich From: Lankswert, Patrick Sent: Friday, August 07, 2015 7:09 AM To: hyuna0213.jo at samsung.com; iotivity-dev at lists.iotivity.org; Keane, Erich; Macieira, Thiago Subject: RE: [dev] RI layer changes to enable blockwise-transfer Hyuna, If you know your representation and the types, you should be able to calculate the worse-case encoding size in most cases. Collections, on the other hand, are more difficult and will require calculation of worse case size at run time. FYI, the problem of not knowing the size before encoding would be worse with JSON, right? I am not as big a fan of Thiago's suggestion of try and reallocate on fail. In bad cases, it will have a performance impact. In worse case, a flaw in the encoder could case cycles that result in memory exhaustion. In most cases, it would be better to calculate, try and if encoding fails, fail the operation. The compromise is the Windows API practice of running the encoding twice, the first time without a buffer to calculate the size. If the size is acceptable, allocate the memory and encode for real. Pat From: iotivity-dev-bounces at lists.iotivity.org [mailto:[email protected]] On Behalf Of ??? Sent: Friday, August 07, 2015 1:33 AM To: iotivity-dev at lists.iotivity.org; Keane, Erich; Macieira, Thiago Subject: [dev] RI layer changes to enable blockwise-transfer Hi Erich, Thiago I'm working to enable blockwise-transfer in RI layer. In my understanding, currently RI layer allocates memory for payload before CBOR encoding. *outPayload = (uint8_t*)OICCalloc(1, MAX_REQUEST_LENGTH); *size = MAX_REQUEST_LENGTH; RI always allocate 1024 bytes memory. and re-allocate actual consumed size after encoding. By using cbor_encoder_init() function, CborEncoder object manage the allocated memory address and then start CBOR encoding. If encoder->ptr + len is bigger than encoder->end in the encoding process, returns the CborErrorOutOfMemory. but i have a question about this. if the maximum size of the payload is not 1024 bytes and there is no size restriction, We have no way of knowing the size information before encoding. so we cannot allocate memory for payload in advance. accordingly, we are unable to create CborEncoder object. because we have to call cbor_encoder_init() function by using size parameter. I have a problem enabling blockwise-transfer in RI layer because of this issue. Can you suggest any solution for this problem? I'm not totally understanding RI layer. please tell me if I misunderstood. Regards, Hyuna Jo [cid:image001.gif at 01D0D0F1.1BCC1640] [http://ext.samsung.net/mailcheck/SeenTimeChecker?do=60dc5d56177c6e7d8730d3acb6b24f682896f9581553361664a12c9b4c260b8813d69ea60670f66e1fac5bf6c61543587bc8a6096cfbfc9f02e038c8d853bffbdb9fdddda33e82cbe4a391424e62fcf6cf878f9a26ce15a0] -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20150807/528ebaac/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 13168 bytes Desc: image001.gif URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20150807/528ebaac/attachment.gif>
