RE : [lwip-users] Project based on lwip - design strategies (raw vs.sequential)

[Frédéric BERNON]

>I'm new to lwip stack and I'm climbing the learning curve. I plan to use 
>the stack to send data to a server (and receive some) over a gprs 
>connection. I have my own preemptive RTOS based environment and my 
>platform is based around an ARM7 with 32kb of RAM. Flash is not a problem.

>I'm a little bit confused on which interface to use for my application. 
>As I understand RAW api gives more performance in terms of throughput 
>wile sequential API is more application developer friendly. However 
>throughput is not critical for my application so using sequential api 
>seems more appropriate for me.

So, in this case, using one of the sequential api (netconn or socket) should be 
the best choice. One of the main advantage of sequential api is it's faster to 
learn it (maily if you already use socket api), and it already provide all 
thread-safing features, which is not provide by raw api.

>1) I presume RAW api is well tested as represents the lwip core. Is also 
>sequential api tested, reliable and widely used ?

Yes, I think that sequential API is reliable, mainly with last CVS HEAD code, 
where thread-safing is improved. Performance is also improved, and differences 
between sequential api and raw api are not so sensible now (but raw api stay of 
course more efficient).

>2) As I can see there are two sequential API interfaces. One is 
>"netconn" an the other is "sockets". What's the difference ? I'm a 
>little bit familiar with socket programming but I have no idea what 
>"netconn" is. Please excuse my ignorance here as I might be asking 
>nonsenses here.

Current sockets api is based on netconn api (by example, sockets's sendto calls 
use netconn_sendto), and you can see it like an api to use if you want to have 
a portable code (since socket api exist in lot of systems). Netconn api is lwIP 
specific, so, your code can't be portable. But you got something closer of the 
raw api concepts: you can directly receive and send "pbuf" (chains), which are 
the basic packets descriptors. One of the advantage is you can directly access 
to some internal lwIP features (without using functions like get/set-sockopt), 
and, more important, you can directly access to internal pbufs' buffers without 
any copy like you have to do with sockets'recv/recvfrom (these functions 
provide a "user buffer" where we "memcpy" datas from pbufs' buffers). Next, 
since netconn api can be used without socket api, directly use it reduce your 
footprint. Since you have "only" 32kb ("" because it's big for some users, 
small for some others), perhaps netconn is a best choice? But it's not 
portable. So, this design choice can be see like "faster development time vs 
footprint".

>3) Which version do you suggest. Should I go with 1.2 or use a CVS 
>snapshot ? Comparing the sources it seems the major difference was in 
>"sequential api" sources.

If you choose sequential api, CVS HEAD, sure !!! Even in raw api, there is some 
improvements, and some new features. Take a look to 
http://lwip.scribblewiki.com/LwIP_version_1.3.0_release_notes for differences 
with 1.2.0 (1.3.0 is not released, it's just to name the CVS HEAD code).

I hope it help you...


_______________________________________________
lwip-users mailing list
address@hidden http://lists.nongnu.org/mailman/listinfo/lwip-users

Frédéric BERNON.vcf
Description: Frédéric BERNON.vcf