tcp_close and the unsent queue

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

tcp_close and the unsent queue

Tom Hennen
So as I understand it the 'correct' way to use tcp_close is to wait
for pcb->unacked and pcb->unsent to both equal NULL.  Only then should
tcp_close be called.

Can someone explain why this is?  I'm finding it to be cumbersome.

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?

Thanks,

Tom


_______________________________________________
lwip-users mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

Re: tcp_close and the unsent queue

Kieran Mansley
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
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

Re: tcp_close and the unsent queue

Tom Hennen
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 <[hidden email]> 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
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-users


_______________________________________________
lwip-users mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

RE : tcp_close and the unsent queue

Frédéric BERNON
In reply to this post by Tom Hennen
Message
Hi Tom,
 
Which API do you use ? sockets or raw api ? If you use sockets API, I can suggest a little patch to fix this problem in lwip_close.
 
 
====================================
Frédéric BERNON
HYMATOM SA
Chef de projet informatique
Microsoft Certified Professional
Tél. : +33 (0)4-67-87-61-10
Fax. : +33 (0)4-67-70-85-44
Email : [hidden email]r
Web Site : http://www.hymatom.fr
====================================
-----Message d'origine-----
De : lwip-users-bounces+frederic.bernon=[hidden email] [mailto:lwip-users-bounces+frederic.bernon=[hidden email]] De la part de Tom Hennen
Envoyé : mercredi 11 octobre 2006 13:32
À : Mailing list for lwIP users
Objet : Re: [lwip-users] tcp_close and the unsent queue

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


_______________________________________________
lwip-users mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

Re: RE : tcp_close and the unsent queue

Tom Hennen
I'm using the raw API.

On 10/11/06, Frédéric BERNON <[hidden email]> wrote:
Hi Tom,
 
Which API do you use ? sockets or raw api ? If you use sockets API, I can suggest a little patch to fix this problem in lwip_close.
 
 
====================================
Frédéric BERNON
HYMATOM SA
Chef de projet informatique
Microsoft Certified Professional
Tél. : +33 (0)4-67-87-61-10
Fax. : +33 (0)4-67-70-85-44
Email : [hidden email]r
Web Site : <a onclick="return top.js.OpenExtLink(window,event,this)" href="http://www.hymatom.fr/" target="_blank">http://www.hymatom.fr
====================================
-----Message d'origine-----
De : lwip-users-bounces+frederic.bernon=[hidden email] [mailto:[hidden email]] De la part de Tom Hennen
Envoyé : mercredi 11 octobre 2006 13:32
À : Mailing list for lwIP users
Objet : Re: [lwip-users] tcp_close and the unsent queue

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 <[hidden email] > 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
[hidden email]
<a onclick="return top.js.OpenExtLink(window,event,this)" href="http://lists.nongnu.org/mailman/listinfo/lwip-users" target="_blank">http://lists.nongnu.org/mailman/listinfo/lwip-users


_______________________________________________
lwip-users mailing list
[hidden email]
<a onclick="return top.js.OpenExtLink(window,event,this)" href="http://lists.nongnu.org/mailman/listinfo/lwip-users" target="_blank">http://lists.nongnu.org/mailman/listinfo/lwip-users



_______________________________________________
lwip-users mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

RE : tcp_close and the unsent queue

clive-5
In reply to this post by Frédéric BERNON
At 13:37 11/10/2006, you wrote:
Content-Type: multipart/related; type="multipart/alternative";
        boundary="----_=_NextPart_001_01C6ED32.132CF677"
content-class: urn:content-classes:message

Hi Tom,
 
Which API do you use ? sockets or raw api ? If you use sockets API, I can suggest a little patch to fix this problem in lwip_close.

Hello Frédéric,

Can you post the lwip_close patch here? I'm very interested to see what it is.

Kind regards,

Clive Wilson
_______________________________________________
lwip-users mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

RE : RE : tcp_close and the unsent queue

Frédéric BERNON
In reply to this post by Frédéric BERNON
Hi Clive,

Here the lwip_close() code. I have disable the protection against "We cannot allow multiple closes of the same socket" because I don't have this kind of problem with my application, and waiting inside the "socksem" critical section block others tasks.

There is no a real "mssleep" in lwip (the sys_msleep() is implemented with sys_sem_new/sys_sem_wait_timeout/sys_sem_free, and it's not - to my point of view - a good implementation for this issue), so I use my OS "sleep()". I will extend sys and sys_arch to do something more in the lwip spirit.

I will put this code in netconn API when I will got few minutes. I have change some little things in netconn to implement a "recv timeout" with the SO_RCVTIMEO, IP_MULTICAST_TTL, IP_ADD_MEMBERSHIP and IP_DROP_MEMBERSHIP options.

There is some others informations in :
http://savannah.nongnu.org/bugs/?func=detailitem&item_id=15926

Regards


int
lwip_close(int s)
{
  struct lwip_socket *sock;

  LWIP_DEBUGF(SOCKETS_DEBUG, ("lwip_close(%d)\n", s));
  if (!socksem)
      socksem = sys_sem_new(1);

  /* We cannot allow multiple closes of the same socket. */
  //FB sys_sem_wait(socksem);

  sock = get_socket(s);
  if (!sock) {
      //FB sys_sem_signal(socksem);
      set_errno(EBADF);
      return -1;
  }

  if (sock->conn->type==NETCONN_TCP)//FB  have to add a timeout
   { while (((sock->conn->pcb.tcp->unacked!=NULL) || (sock->conn->pcb.tcp->unsent!=NULL)) && (sock->conn->err==ERR_OK))
      { //FB sys_msleep(1);
        tmosalTaskSleep(1);//FB wait here 1ms, but not use sys_msleep() because not usefull
      }
   }
  sys_sem_wait(socksem); //FB now, enter in critcal section
  netconn_close(sock->conn);//FB was never call before, to check if really necessary/usefull
 
  netconn_delete(sock->conn);
  if (sock->lastdata) {
    netbuf_delete(sock->lastdata);
  }
  sock->lastdata   = NULL;
  sock->lastoffset = 0;
  sock->conn       = NULL;
  sys_sem_signal(socksem);
  sock_set_errno(sock, 0);
  return 0;
}




====================================
Frédéric BERNON
HYMATOM SA
Chef de projet informatique
Microsoft Certified Professional
Tél. : +33 (0)4-67-87-61-10
Fax. : +33 (0)4-67-70-85-44
Email : [hidden email]
Web Site : http://www.hymatom.fr 
====================================
-----Message d'origine-----
De : lwip-users-bounces+frederic.bernon=[hidden email] [mailto:lwip-users-bounces+frederic.bernon=[hidden email]] De la part de Clive Wilson
Envoyé : mercredi 11 octobre 2006 19:31
À : Mailing list for lwIP users
Objet : RE : [lwip-users] tcp_close and the unsent queue


At 13:37 11/10/2006, you wrote:

Content-Type: multipart/related; type="multipart/alternative";
        boundary="----_=_NextPart_001_01C6ED32.132CF677"
content-class: urn:content-classes:message

Hi Tom,
 
Which API do you use ? sockets or raw api ? If you use sockets API, I can suggest a little patch to fix this problem in lwip_close.

Hello Frédéric,

Can you post the lwip_close patch here? I'm very interested to see what it is.

Kind regards,

Clive Wilson


_______________________________________________
lwip-users mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-users