[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[lwip-devel] [task #6930] Implement SO_LINGER

From: Frédéric Bernon
Subject: [lwip-devel] [task #6930] Implement SO_LINGER
Date: Fri, 29 Jun 2007 13:11:26 +0000
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv: Gecko/20070515 Firefox/

Follow-up Comment #13, task #6930 (project lwip):

A question about that: in the case of a web server, an external client
connect my lwip http server and request a "big" file. The web server return
the file (with the size in HTTP header), the client receive it, both close
the connection.

In this case, the lwIP web server do a lwip_close "in the same time" that the
client send a FIN packet (both know when close because the size of the datas
is in the header).

In my first time with lwIP I often got problem where the client doesn't
receive all the datas... A workaround I test was to add netconn_close in
lwip_close (before netconn_delete), and in netconn_close, to poll that
unacked & unsent tcp_seg lists were NULL (and next, do the normal
"do_close"). A such solution was working, even it is was in fact an
experimental workaround.

I think my problem was a little bit the same than Magnus: lwip_close calls
netconn_delete which call tcp_close with the send queue still full, so,
tcp_abort was called and my datas lost. This problem was difficult to
reproduce, since it was a timing problem (faster was the client and the
network, less I saw the case). That what I got in bug#19157.

Now, my question: since do_close shouldn't wait that datas could be sent,
more, since do_close is not call (by default) in lwip_close, isn't it in the
do_delconn that the problem should be processed (like Simon propose)? The
problem isn't it more the call (in do_delconn) to tcp_abort "too early" ?


Reply to this item at:


  Message posté via/par Savannah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]