Thanks for clarifying MJ. So it makes sense retaining MAX_REQUEST_LENGTH and MAX_RESPONSE_LENGTH for Arduino. --Vijay From: ??? [mailto:[email protected]] Sent: Saturday, August 08, 2015 7:47 PM To: Keane, Erich; Kesavan, Vijay S; Lankswert, Patrick Cc: iotivity-dev at lists.iotivity.org Subject: Re: Re: [dev] RI layer changes to enable blockwise-transfer
Erich, Vijay. As we had discussed in F2F meeting on May, BWT can be applied Linux, Android and Tizen. Arduino platform is not considered as the target for large data transmission.. Thanks. Best Regards, --- MyeongGi Jeong Senior Engineer, Software Architect Software R&D Center, Samsung Electronics Co., Ltd. +82-10-3328-1130 ------- Original Message ------- Sender : Keane, Erich<erich.keane at intel.com<mailto:erich.keane at intel.com>> Date : 2015-08-08 06:04 (GMT+09:00) Title : Re: [dev] RI layer changes to enable blockwise-transfer I think it does. Hyuna, mind clarifying? -----Original Message----- From: Kesavan, Vijay S Sent: Friday, August 07, 2015 12:36 PM To: Keane, Erich; Lankswert, Patrick Cc: iotivity-dev at lists.iotivity.org<mailto:iotivity-dev at lists.iotivity.org> Subject: RE: [dev] RI layer changes to enable blockwise-transfer Does Arduino support BWT as well? If not, we will need MAX_REQUEST_LENGTH and MAX_RESPONSE_LENGTH for Arduino. --Vijay -----Original Message----- From: iotivity-dev-bounces at lists.iotivity.org<mailto:iotivity-dev-bounces at lists.iotivity.org> [mailto:[email protected]] On Behalf Of Keane, Erich Sent: Friday, August 07, 2015 10:33 AM To: Lankswert, Patrick Cc: iotivity-dev at lists.iotivity.org<mailto:iotivity-dev at lists.iotivity.org> Subject: Re: [dev] RI layer changes to enable blockwise-transfer 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<mailto:hyuna0213.jo at samsung.com>; > > iotivity-dev at lists.iotivity.org<mailto: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> > > [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<mailto: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<mailto:iotivity-dev at > > lists.iotivity.org> > > https://lists.iotivity.org/mailman/listinfo/iotivity-dev > > _______________________________________________ > iotivity-dev mailing list > iotivity-dev at lists.iotivity.org<mailto:iotivity-dev at lists.iotivity.org> > https://lists.iotivity.org/mailman/listinfo/iotivity-dev _______________________________________________ iotivity-dev mailing list iotivity-dev at lists.iotivity.org<mailto:iotivity-dev at lists.iotivity.org> https://lists.iotivity.org/mailman/listinfo/iotivity-dev _______________________________________________ iotivity-dev mailing list iotivity-dev at lists.iotivity.org<mailto:iotivity-dev at lists.iotivity.org> https://lists.iotivity.org/mailman/listinfo/iotivity-dev [cid:image001.gif at 01D0D220.AE5EF6F0] [http://ext.samsung.net/mailcheck/SeenTimeChecker?do=60dc5d56177c6e7d114e9215fd4b4f3d1af874230d2c37ef032aa89e99be1a3e74d030de18d46904706414a29aace7be09060032c89b30e00407d1a278fe738d3298a32fe7c0f484cf878f9a26ce15a0] -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20150809/e899732a/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/20150809/e899732a/attachment.gif>
