Note: I've contributed a patch that I'd had sitting around (needed to update it) here that tries #2 below: https://gerrit.iotivity.org/gerrit/#/c/2141/.
I haven't made the changes to tinycbor yet (I'm going to start on that today/this weekend with Thiago's advise), so the result will be a necessity to update that once it has been done. This patch removes the limit in OCPayloadConvert, however you may still find references to the size-limit elsewhere in the RI layer, so feel free to remove those and submit a patch. Thanks! -Erich On Fri, 2015-08-07 at 16:11 +0000, Keane, Erich wrote: > 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:iotivity-dev-bounces at lists.iotivity.org] 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 > > > > > > > > > > > > _______________________________________________ > iotivity-dev mailing list > iotivity-dev at lists.iotivity.org > https://lists.iotivity.org/mailman/listinfo/iotivity-dev
