[lwip-devel] [task #6994] Redesign Socket Layer with LWIP_TCPIP_CORE_LOCKING

[Frédéric Bernon]

URL:
  <http://savannah.nongnu.org/task/?6994>

                 Summary: Redesign Socket Layer with LWIP_TCPIP_CORE_LOCKING
                 Project: lwIP - A Lightweight TCP/IP stack
            Submitted by: fbernon
            Submitted on: samedi 09.06.2007 à 13:40
                Category: None
         Should Start On: samedi 09.06.2007 à 00:00
   Should be Finished on: samedi 09.06.2007 à 00:00
                Priority: 3 - Low
                  Status: In Progress
                 Privacy: Public
        Percent Complete: 0%
             Assigned to: fbernon
             Open/Closed: Open
         Discussion Lock: Any
                  Effort: 0.00

    _______________________________________________________

Details:

Very first thing, it's a low task priority for developers which don't work on
other tasks....

task #6935 "Problems to be solved with thecurrent socket/netconn API" have
introduced the possiblity to communicate with the lwIP'core with a different
way (a global semaphore insight the current mailbox feature).

This task is to define and implement what could be a new socket layer for
that.

One of the problems is to avoid to do lot of patchs with #if/#else/#endif in
the code (one is already done in lwip_sendto, but just to show the use of
LWIP_TCPIP_CORE_LOCKING, and should be remove in some time).

So, a first idea would be to add in the repository a sockets2.c file in the
same folder than the current one.

A second one is to process in multiple steps:

1/ Integrate the global mutex in tcpip.h/.c, api_msg.c, and api_lib.c
(already done).

2/ Use the global mutex to simplify most of sockets functions (like in the
lwip_sendto sample), but keeping the netconn struct. We first have to decide
if we are ok to add a sockets2.c file.

3/ Separate socket layer from netconn layer (the problem is of course in
api_msg, where lot of fields directly reference netconn). For this, perhaps
alternative api_msg2.c file will be better to avoid problems. In this step, I
also propose to remove netbuf struct by adding "addr" & "port" fields directly
in pbuf struct.

Resume some others goals:

- Should be reliable: something as reliable than raw api can be...

- Should be safe-thread for most of cases (and enable to support full-duplex
protocols, see http://savannah.nongnu.org/patch/?5960).

- Easily disable code that is not used (like for select and non-blocking
code, see http://savannah.nongnu.org/patch/?5919)

- Increase socket layer performance (speed) to got a performance near of raw
api (limit use of netbuf, memp and other "dynamic" allocations if they can be
replaced by local variables). Try to reach hardware performance as few of
processor time as possible...

- Reduce footprint (for socket layer, of course, if we don't use all api_lib
or api_msg),

- Get an independant socket layer from netcon layer, to enable to add some
feature without changes in netconn layer.

- Have a better error forwarding: do difference between minor errors
(ERR_MEM, ERR_BUF...), and really fatal errors...

- And anything else useful...

Comments?





    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/task/?6994>

_______________________________________________
  Message posté via/par Savannah
  http://savannah.nongnu.org/