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

[address@hidden]

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

Simon