Hello, > STEP 1 means separating files in ipadapter. > Actually ipadapter include udp specific logic(socket, > send, receive ..). So if I implement tcp logic in same > file, it will be not easy to read some codes. > So I want to separate udp logic from ipadapter.
This is not strictly necessary if adding TCP support to the IP adapter is mostly incremental work, which I believe is the case. Moreover, do realize that we’d prefer to reuse the existing network_event_thread to wait on TCP endpoints and all established TCP connections, in addition to the UDP sockets. So, I reckon that merely updating the existing file might keep things more straightforward. (Its already large enough; whats a few more lines?) > Especially, because ip_context_t is core feature and all > know about this, ip_context_t is not a “core” feature; by this I mean that the framework does not specify it. Rather it is defined and used only in the connectivity implementation, i.e. ipadapter.c for the purpose of storing context pertaining to the underlying network stack (sockets, etc.). > And then I'm going to implement TCP adapter as I said in > STEP 2. This will include adding TCP flag in endpoint > and TCP send/receive routines. > After finish implement tcp adapter, then CoAP over > TCP(use these header in packet. serialize/parse also) > logic should be implemented(STEP 3). As I’ve mentioned before, the most important step is adding “TCP awareness” to the core framework. This, yes, includes adding a TCP flag to endpoints, but also updating internal code paths in the framework to act upon it appropriately, along with augmenting the CoAP serialize/parse logic to reflect the RFC. This is cross-platform code that would be common across all ports. Changes to the connectivity implementations (adapters) themselves are more direct because once you’ve done with the above, someone (and I can volunteer) can update the Windows ipadapter to add TCP support and utilize the same logic above. > I think this will be reasonable to implement from > bottom(transport). You may implement it in whatever order, and I can understand that having a working TCP implementation at the bottom makes it possible to test your work above during your development. You haven’t touched upon your strategy for maintaining state of all ongoing TCP connections. Also, ip_context_t is currently instantiated as an array to maintain distinct state for each OCF logical device in the application. So, perhaps you could choose to store TCP connection states per logical device. It will become clearer to me when I review your patches, but I want to make sure you fully understand the project’s design and the scope of this task as you work through it. So, please feel free to ask specific questions. Thanks, -Kishen. - Kishen Maloor Intel Open Source Technology Center From: 조제현 <jaehyun3....@samsung.com<mailto:jaehyun3....@samsung.com>> on behalf of 조제현 <jaehyun3....@samsung.com<mailto:jaehyun3....@samsung.com>> Reply-To: "jaehyun3....@samsung.com<mailto:jaehyun3....@samsung.com>" <jaehyun3....@samsung.com<mailto:jaehyun3....@samsung.com>> Date: Tuesday, March 13, 2018 at 8:59 PM To: Kishen Maloor <kishen.mal...@intel.com<mailto:kishen.mal...@intel.com>>, 최우제 <uzc...@samsung.com<mailto:uzc...@samsung.com>>, 조제현 <jaehyun3....@samsung.com<mailto:jaehyun3....@samsung.com>> Cc: "iotivity-dev@lists.iotivity.org<mailto:iotivity-dev@lists.iotivity.org>" <iotivity-dev@lists.iotivity.org<mailto:iotivity-dev@lists.iotivity.org>> Subject: RE: Re: Regarding iotivity-constrained TCP contribution. Hello, STEP 1 means separating files in ipadapter. Actually ipadapter include udp specific logic(socket, send, receive ..). So if I implement tcp logic in same file, it will be not easy to read some codes. So I want to separate udp logic from ipadapter. To do that, some construct and function will change their location. Especially, because ip_context_t is core feature and all know about this, ip_context_t need to move ipadapter.h file and every .c file will include this. (I think it will be as described in the picture below) [cid:BGFC2LL5XOK0@namo.co.kr] And then I'm going to implement TCP adapter as I said in STEP 2. This will include adding TCP flag in endpoint and TCP send/receive routines. After finish implement tcp adapter, then CoAP over TCP(use these header in packet. serialize/parse also) logic should be implemented(STEP 3). I think this will be reasonable to implement from bottom(transport). And I also agree that update linux port first. If this step is agree with you, I'll contribute TCP regarding feature soon in master branch. Thanks. - jaehyun [http://gais.sec.samsung.net/gaps/images/card_samsungKor2.gif] 조제현 Jaehyun Cho Assistant Engineer IoT Lab Convergence Team Software R&D Center SAMSUNG ELECTRONICS CO., LTD. Mobile : 82-10-9621-2800 E-mail : jaehyun3....@samsung.com<mailto:jaehyun3....@samsung.com> --------- Original Message --------- Sender : Maloor, Kishen <kishen.mal...@intel.com<mailto:kishen.mal...@intel.com>> Date : 2018-03-14 02:52 (GMT+9) Title : Re: Regarding iotivity-constrained TCP contribution. Hello, Thanks. I’m not clear about what STEP 1 entails in your proposal. However, the initial (and most critical) step is to cleanly enable cross-platform support for TCP within the framework. This work would subsume STEP 3. Work within IP adapters themselves (STEP 1/2) should be the last step that follows from the above work. Which port(s) will you be updating? (I assume Linux is starting point) You may implement the different bits in any order of your choosing, but I’d like to see patches in the order prescribed above. Also, you may submit your patches directly to master for review. Thanks, -Kishen. - Kishen Maloor Intel Open Source Technology Center From: 조제현 <jaehyun3....@samsung.com<mailto:jaehyun3....@samsung.com>> on behalf of 조제현 <jaehyun3....@samsung.com<mailto:jaehyun3....@samsung.com>> Reply-To: "jaehyun3....@samsung.com<mailto:jaehyun3....@samsung.com>" <jaehyun3....@samsung.com<mailto:jaehyun3....@samsung.com>> Date: Monday, March 12, 2018 at 11:45 PM To: Kishen Maloor <kishen.mal...@intel.com<mailto:kishen.mal...@intel.com>> Cc: "iotivity-dev@lists.iotivity.org<mailto:iotivity-dev@lists.iotivity.org>" <iotivity-dev@lists.iotivity.org<mailto:iotivity-dev@lists.iotivity.org>> Subject: Regarding iotivity-constrained TCP contribution. Hello, I have a plan to contribute tcp feature in iotivity-constrained repository. below is contribute plan. ------------------------------------------------------------------------------------------------------ STEP 1. separate ipadapter with UDP & make space for TCP adapter. (like below) ipadapter | ┏-------┐ UDP TCP STEP 2. implement TCP adapter. STEP 3. implement CoAP over TCP. ------------------------------------------------------------------------------------------------------ The question is that do I need to make separate branch for this? or just push to master and review for it. Thanks. jaehyun [http://gais.sec.samsung.net/gaps/images/card_samsungKor2.gif] 조제현 Jaehyun Cho Assistant Engineer IoT Lab Convergence Team Software R&D Center SAMSUNG ELECTRONICS CO., LTD. Mobile : 82-10-9621-2800 E-mail : jaehyun3....@samsung.com<mailto:jaehyun3....@samsung.com> [cid:cafe_image_0@s-core.co.kr]
_______________________________________________ iotivity-dev mailing list iotivity-dev@lists.iotivity.org https://lists.iotivity.org/mailman/listinfo/iotivity-dev
