Chris Strahm wrote:
The second is when it receives a packet and it's either not a
GET request, or it's a NULL pbuf. You're almost certainly seeing a NULL
pbuf passed to the receive callback which means that the other end has
closed the connection.
I have not seen a single http_rcve() with pbuf=NULL yet.
That's because the http server in contrib only implements HTTP 1.0
(without keepalive option), where the server closes the socket after
sending the page contents (i.e. in the code, close_conn() is called
after all data has been sent). Since close_conn() resets the
recv-callback of the pcb to NULL, it doesn't get called with a NULL pbuf
when the FIN from the other side is received.
I've played around trying different combinations of closing, but when I get
it setup to close when my BytesToSend goes to zero, and no multiple calls to
close, I always end up with FIN_WAIT_2 pollings at the end. It goes 12
times I think and then stops. It's not right.
The only way I see the traffic work right/clean, is with the original setup.
But that ends up with the 1 trailing byte shown and double calls to close.
So far I have not found a way to get rid of this and still get packet flow
that works right.
I still don't get it: why do you see a double close? Looking at the
(original) code, close_conn() resets both the recv-callback and the
sent-callback. That means after calling close_conn() once, it should
*never* enter http_sent() or http_recv() again! (In turn, close_conn()
shouldn't get called again, since it is only called from http_sent() and
http_recv().)
Having set these to null, http_sent() with arg==NULL should also not
appear (your original post, if I remember correctly?). Could it be that
you changed close_conn() to not reset these callbacks??
That leaves us with the offset in sent of 1: we can argue if this is
correct or not. Removing it would keep us from telling the application
when the remote side has ACKed our FIN (if the offset comes from the
FIN, which I am, like Kieran, pretty sure: the len parameter is
calculated like this: "ackno - pcb->lastack", and a FIN counts as 1).
Looking at the original code, the len parameter is not even used; the
sent callback is only used as a trigger to send more: how much has been
already sent is kept in an internal data structure (everything passed to
tcp_write without an error will get sent, eventually - and you can
always send as much as tcp_sndbuf() tells you).
Simon
_______________________________________________
lwip-users mailing list
lwip-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/lwip-users