Hyuna, I'm doing a quick GREP as well, and found some areas to that'll be a good spot to start.
I'd likely begin by removing the MAX_REQUEST_LENGTH and MAX_RESPONSE_LENGTH defines from everywhere. First, the OCServerProtocolRequest currently has a uint8_t payload of MAX_REQUEST_LENGTH. You'll need to convert this to a pointer, then inspect all usages of this struct to ensure it is being treated properly. Second, oicgroup.c has 3 instances where it uses MAX_RESOPNSE_LENGTH to store its packages. You can likely simplify the logic in these areas, since it doesn't need to worry about package size anymore. Finally, line 522 of ocserverrequest.c has a check against MAX_RESPONSE_LENGTH that is no longer true, so you'd be able to remove that. I'll note that I did most of the removal of the 'error on too long' when working on the CBOR stuff in anticipation of this fix, but I guess I missed a few places! Let me know how this goes for you, and if I get to anything else, I'll send out a message at the end of my work day. If I get time early next week, I can look into these as well (or help out with whatever I can!). Thanks, -Erich On Fri, 2015-08-07 at 17:24 +0000, Keane, Erich wrote: > 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 > > _______________________________________________ > iotivity-dev mailing list > iotivity-dev at lists.iotivity.org > https://lists.iotivity.org/mailman/listinfo/iotivity-dev
