> 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. _______________________________________________ lwip-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users
