[lwip-devel] [bug #19157] lwip_close problems

[Frédéric Bernon]

Follow-up Comment #9, bug #19157 (project lwip):

Ok, the "classic" example is a - simple - web server, which only return one
document per connection.

The algorithm is 

WEBSERVER::accept HTTP connection()
WEBSERVER::recv headers()
WEBSERVER::recv datas()
WEBSERVER::send headers()
WEBSERVER::send datas()
WEBSERVER::close socket()

The problem is when you close the socket just after a send(), at socket
layer. In the current socket implementation, lwip_close just delete the
connection: it call netconn_delete() in api_lib.c, which call do_delconn() in
api_msg.c. In this last, we try to send last datas with a tcp_output() (it is
done at the end of tcp_close, or in tcp_abort() if tcp_close "failed"). There
can be several cause that these last datas are not received by peer, and,
because we don't wait acknowledge, last "writes" can be lost (so, the tcp
connection can't be defined "reliable"). 

I think that most of implementation have to guarantee that any write is
successfuly received, or that you can detect an error. I only can suppose
they "block" until an error or until all datas are sent & acknowledge.
Perhaps some implementations can to this process in a asynchrone way, but
with lwIP it's not a simple thing to change...

Most of time, this blocking is very short. And it seems to be an old problem,
which was never really solved. We can find it from 
bug #15926, and always this morning in "local connection failed on loopif,
race?" thread.

A first and simple thing to do is perhaps to call netconn_close in lwip_close
(it also force a tcp_output, and check there is no ERR_MEM error). But, even
with that, we can be sure that peer received the data if we don't check the
pcb's unack list.

I surprise we don't get more problems with that in socket layer. So, perhaps
it's something in my port, but I don't see what in lwIP can guarantee
receive... 

But if you don't think it's a problem, ok, we can close this item...









    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/bugs/?19157>

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