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