[En-Nut-Discussion] NutTcpAccept blocks the tread

[Ole Reinhardt]

Hi Harald

> So, the patch given above exactly reflects my preference regarding the API.

Yes, I would agree too, as one could change the socket timeout later
again (when it is successfully opened)

> 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

Right. I was afraid that this would become a problem when I first
thought about this issue without deeper knowledge of the internal tcp
state machine.


>     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.

Posix accept will return -1 in case of an error, the socket descriptor
otherwise. If an error occurs errno is set appropriate.

So perhaps we should implement it in the same way? If it fails it should
leave the socket definitely in the TCPS_CLOSED state.

> 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.

If I correctly understand Urbi he is searching for a posix accept like
solution where you just create one socket, put it in listening state
(listen) and then create a new file descriptor to the new connected
socket with accept where you then can read / write to. In this case you
can start a thread when you got a new connection and leave the main
thread in listening state...

If we don't want to rework the socket api totaly your solutions seems to
be what I would expect from it... (connections will be rejected as long
as NutTcpAccept() is not running.

But even if it's lot of work it might be reasonable to implement a posix
like socket api? This would allow us to use the same api calls for
different socket types (which might be implemented in the future). And
at least to listen on a port for multiple connections without starting
multiple threads.

Unfortunately my knowledge about the TCP statemachine internals are
quite limited so I can't estimate how much work this would be.

Bye,

Ole

-- 
 _____________________________________________________________
|                                                             |
| Embedded-IT                                                 |
|                                                             |
| Ole Reinhardt        Tel. / Fax:        +49 (0)271  7420433 |
| Luisenstraße 29      Mobil:             +49 (0)177  7420433 |
| 57076 Siegen         eMail:    ole.reinhardt at embedded-it.de |
| Germany              Web:         http://www.embedded-it.de |
|_____________________________________________________________|