[En-Nut-Discussion] NutTcpAccept blocks the tread

[Harald Kipp]

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