[Top][All Lists]

[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: Tue, 11 Aug 2009 19:39:19 +0200
User-agent: Thunderbird (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.
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().
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).

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).
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.
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).


reply via email to

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