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

[Chris Strahm]

> It's called, I'm guessing, when the other side processes the FIN.  The
> sent callback is called as a result of data being ACKed, which means
> that buffer space should be available to send.  It just so happens in
> this case that the sequence being acked is the FIN to mark the end of
> the connection.  This could probably be improved, as I can see it's
> confusing and not useful.

With that being the case, then the http_sent() "len" parameter cannot really
be used to measure whether the data has all been sent, since it also ends up
containing false ACK byte.  Can I assume the "len" will always come out 1
byte more, or should "len" just be considered useless?

What module is this being generated from?  I might make a stab at fixing it.

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

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.

Thanks,  Chris.