[En-Nut-Discussion] NutTcpAccept blocks the tread

[Henrik Maier]

Hi Harald,

Unfortunately I don't have the complete patch anymore, but I remember now
that I had to do more than just the time-out when I experimented with it.

I have server tasks which work on a certain TCP ports. This TCP port shall
be configurable during run-time, eg change from port 80 to 8080 or something
similar. In addition I like every thread to increase a watchdog/alive
counter for system supervision.

Both requirements can be easily met if NutTcpAccept would time-out for
example every 1000 ms. The following simplified pseudo code illustrates this
concept:

    for (;;) 
    {
        sock = NutTcpCreateSocket();
        while (NutTcpAccept(sock, myPort) == 0)
        {
           threadStillAlive++;
           if (settingsHaveChanged())
           {
              myPort = settings.port;
           }
        }
        threadStillAlive++;
        stream = _fdopen((int) sock, "r+b");
        processsRequest(stream);
        fclose(stream);
        NutTcpCloseSocket(sock);
    } 

As NutTcpAccept is called again after the time-out I would assume this would
have no side-effect on connect attempts as long as the socket value stays
the same. Is this assumption correct?

Regards

Henrik


> -----Original Message-----
> From: en-nut-discussion-bounces at egnite.de [mailto:en-nut-discussion-
> bounces at egnite.de] On Behalf Of Harald Kipp
> Sent: Wednesday, 21 October 2009 6:30 PM
> To: Ethernut User Chat (English)
> Subject: Re: [En-Nut-Discussion] NutTcpAccept blocks the tread
> 
> Hi Henrik,
> 
> Henrik Maier wrote:
> 
> > I propose to change tcpsm.c so NutTcpAccept honours the read time-out.
> > In NutTcpStatePassiveOpenEvent change:
> >
> >      NutEventWait(&sock->so_pc_tq, 0);
> >      return 0;
> >
> > to:
> >      return NutEventWait(&sock->so_pc_tq, sock->so_read_to);
> 
> ...
> 
> > Harald finally agreed to this implementation:
> >
> > http://lists.egnite.de/pipermail/en-nut-discussion/2006-July/006829.html
> 
> I'm now confused by my own comments on this as it looks like I confirmed
>  using special socket options. In fact I'd prefer to use the existing
> SO_RCVTIMEO. Adding SO_ACCTIMEO and SO_CONNTIMEO would require 2
> additional long values in the socket structure.
> 
> So, the patch given above exactly reflects my preference regarding the
> API.
> 
> Hoooooweeeever, after looking into this in more detail: Are you aware
> that this would leave the socket in listening state? The next call to
> NutTcpAccept will fail, because
> 
>     if (sock->so_state != TCPS_CLOSED)
>         return (sock->so_last_error = EISCONN);
> 
> Furthermore, the function doc says
> 
>  return 0 if granted, error code otherwise.
> 
> but NutEventWait() will return -1 on time out.
> 
> IMHO, NutTcpAccept and NutTcpConnect are comparable to open. If it
> fails, the status of the handle is still CLOSED.
> 
> May be there are even more difficulties with NutTcpConnect aka
> NutTcpStateActiveOpenEvent. OK, different story. Let's handle the server
> side first!
> 
> If we put the socket back to TCPS_CLOSED after time out, then any
> connection attempt will be rejected until NutTcpAccept is called again.
> 
> Is that what you want? Probably not, but I'm not sure.
> 
> Harald
> 
> 
> _______________________________________________
> http://lists.egnite.de/mailman/listinfo/en-nut-discussion