|
From: | address@hidden |
Subject: | Re: [lwip-users] http_sent cb shows 1 byte trailer [RAW] |
Date: | Tue, 11 Aug 2009 19:39:19 +0200 |
User-agent: | Thunderbird 2.0.0.22 (Macintosh/20090605) |
Chris Strahm wrote:
As you can see it clears the tcp_sent cb. Yes I agree with you it seems outright impossible that lwip can still be calling the cb after this has been cleared, but that's exactly what it does.
Yeah, that's strange. I will have to look into that when I find the time.
I can understand why this happens, but strictly spoken, this is not really clean: calling close() on the server first is defined in the HTTP RFC. The last call to http_recv() is made to let the application know the other side closed, too. However, in this stage, the server should not call close again (however, it doesn't hurt the lwIP tcp code).Now in the BYU code, they do something interesting. They do NOT clear the cb's for sent or rcve in close_conn() at all. I've run that setup too, and the output is shown below. Note that there are 2 additional calls made at the end. http_recv() gets triggered again and so does close_conn(). Here we have another case of double close_conn().
After the last bit of data has been passed to tcp_write() without an error, the rest can be handled by the tcp timers and it's OK to call close at that point (as you do, I believe).
Maybe they support http-keepalive? If not, I don't see a reason to let the recv-, sent- or err.callback active. Leaving the poll-callback might make sense to prevent too many pcbs from being blocked (to abort the connection before the tcp timers would do it to prevent consuming too much resources on bad connections).The wireshark trace is clean with this setup as well. I don't know why the guys at BYU removed those 2 NULLs, but apparently they have them commented out for a reason. Personally I don't see much effective difference either way, the end results are nearly identical. But perhaps they did other tests and found a problem this solved.
Simon
[Prev in Thread] | Current Thread | [Next in Thread] |