lwip-users
[Top][All Lists]
Advanced

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

Re: [lwip-users] http_sent cb shows 1 byte trailer [RAW]


From: address@hidden
Subject: Re: [lwip-users] http_sent cb shows 1 byte trailer [RAW]
Date: Mon, 10 Aug 2009 17:58:49 +0200
User-agent: Thunderbird 2.0.0.22 (Macintosh/20090605)

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




reply via email to

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