Sure, that makes sense.
I wonder though if it would still worthwhile to free the unsent queue when the socket is closed. Because, as I read the code, the pcb itself will be deallocated anyways, so there isn't any chance of the data on the 'unsent' queue ever being sent and since the pcb is gone there's really no way to free the unsent queue otherwise.
Another alternative, I suppose, would just be to have tcp_close return an error when there is data remaining on the unsent queue.
Tom
On 10/10/06, Kieran Mansley <address@hidden
> wrote:
On Tue, Oct 10, 2006 at 12:53:12PM -0400, Tom Hennen wrote:
> If I ignore this best practice and just call tcp_close when I receive
> a close request from another host then any packets left on the unsent
> queue end up 'leaking'.
>
> Is there any particular reason tcp_close doesn't free the unsent queue
> when closing the connection?
>
> Is there any other side-effect to calling tcp_close before unacked and
> unsent are NULL?
I don't have the source to hand to check that you're right about the
best way to use tcp_close(), but it sounds plausible. The reason, I
expect, for waiting (and so the side effect of not waiting) for the
unacked and unsent to be NULL is to ensure that all the data you have
requested be sent to the other side have in fact been sent and
successfully received. If packets get leaked, this means they haven't
yet been sent or acknowledged, and so you risk data loss.
Kieran
_______________________________________________
lwip-users mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/lwip-users