Hi All. On more thought, it occurs to me that at a minimum, it should be feasible to have the Layer3 (IP) Layer functionality at the application itself, if we are just concerned with adding/stripping the IP to/from the packet just-before-sending/just-after receiving it to/from Layer 2 (more so when Layer2 is PPP, which means there is no IP-Routing/IP-Forwarding required).
Kindly approve/reject my understandings. Thanks and Regards, Ajay On Sun, Aug 23, 2015 at 9:15 AM, Ajay Garg <[email protected]> wrote: > Hi All. > > I began navigating the code. > > First of all, let me present the scenarios where we intend to run our code > :: > > a) > Our client-application, deployed on a vanilla Linux-Desktop, using WIFI to > communicate with a "normal" server running on a public IP-Address. > > b) > Our client-application, flashed on a micro-controller, which interfaces > with a GPRS-module to communicate with the same "normal" server running on > a public IP-Address. > > > Following are the options :: > > > OPTION 1 : > ======== > > Segregate the application-code in a way, so that all code "including and > below" Layer-4 (TCP) is end-device specific. > > That means that for vanilla Linux-Desktop, we use the vanilla > Berkley-Socket SOCK_STREAM APIs. > > For embedded, we utilize the extended-AT-command-set exposed by the > GPRS-module (which has been built over the embedded TCP/IP stack of the > GPRS-module). > > Above approach works for both the end-devices, but suffers from the fact > that the extended-AT-command-set is not a standard, so deploying our > application on some other GPRS-module will require integration with some > other extended-AT-command-set. > > > > OPTION 2 : > ========= > > Use lwIP for TCP-headers (Layer-4) in the application, and segregate the > application in such a way so that all code "including and below" Layer-3 > (IP) is end-device specific. > > That means that for vanilla Linux-Desktop, we use vanilla SOCK_RAW APIs, > with the default option of letting the API add the IP-header. > > For embedded, we let the GPRS-module AP+BP handle the Layer3/Layer2/Layer1 > functionality. > > *Above seems feasible "logically", please confirm.* > > > > OPTION 3 : > ========= > > Use lwIP for TCP-headers (Layer-4) and IP-headers (Layer-3) in the > application, and segregate the application in such a way so that all code > "including and below" Layer-2 is end-device specific. > > Now, here is my biggest query :: > > *Is it even logically-possible to separate the "Layer3 (IP) handling" (in > the application) from "Layer2 handling" (in the end-device)? According to > the limited knowledge that I have, the IP-layer needs accesses to the > interfaces (as even evident from code in ip.c in lwIP). That would mean > that BOTH the Layer3-handling and Layer2- handling must be present in the > same code context? * > > > > Kindly help resolve these architectural doubts ... I will be grateful no > end ... > > > Thanks and Regards, > Ajay > > > On Sun, Aug 23, 2015 at 7:38 AM, Ajay Garg <[email protected]> wrote: > >> Hi Sylvain. >> >> Thanks a ton for the clarifications !! >> >> On Sat, Aug 22, 2015 at 10:42 PM, Sylvain Rochet <[email protected]> >> wrote: >> >>> Hi Ajay, >>> >>> On Sat, Aug 22, 2015 at 10:20:27PM +0530, Ajay Garg wrote: >>> > >>> > I am sorry, I am not sure what is meant by an OS here. >>> >>> OS = FreeRTOS, ChibiOS, … understand something which provide multiple >>> loops using lightweight threads. >>> >>> >>> > I presume if there were an OS, then the environment would "not" be >>> > bare-metal (since we would be depending on the functionalities being >>> > provided by the OS) ? >>> >>> In embedded context, bare metal = everything runs in the main loop, no >>> threads, no context switch, no task priorities. >>> >>> For lwIP, >>> >>> NO_SYS = 1 = bare metal, lwIP event handler is integrated within the >>> main loop. >>> >>> NO_SYS = 0 = threaded, lwIP event handler runs within its own thread. >>> >> >> Well, that's it ... >> >> In the application that we have designed and coded so far, everything has >> been kept single-threaded only (so as now to have any dependency on any >> third-party embedded-device-vendors). >> >> So, it turns out, that we "do" need to use NO_SYS = 1 >> >> But I get your point, it should be feasible to integrate the >> functionality with NO_SYS = 1 (though it might require some >> code-rearrangement in lwIP). >> >> Anyhow, if there are some examples of this particular scenario (NO_SYS = >> 1, everything within the main loop), kindly let know. It would save some >> time ticks for us :) >> >> Thanks again. >> >> >> Thanks and Regards, >> Ajay >> >> >>> >>> >>> On a Linux/win32 host, everything obviously runs inside a heavy process, >>> but the bare metal vs threaded still apply. >>> >>> >>> Sylvain >>> >>> _______________________________________________ >>> lwip-users mailing list >>> [email protected] >>> https://lists.nongnu.org/mailman/listinfo/lwip-users >>> >> >> >> >> -- >> Regards, >> Ajay >> > > > > -- > Regards, > Ajay > -- Regards, Ajay
_______________________________________________ lwip-users mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/lwip-users
