[En-Nut-Discussion] NutTcpAccept blocks the tread

[Harald Kipp]

urbi wrote:

> I would like to have a non blocking function NutTcpAccept() that gives me
> back a socket when the connection is ready otherwise an Error. So I can
> query sequently in one thread each port for an incomming connection and
> handle this connection. In an other thread (in fact thats th main-loop) I am
> handling sequently reading and writing the data from all sockets and the
> uart.

Thanks Urban, now I have a clear picture.

One idea was to implement a SYN buffer, which would not immediately
reject incoming SYNs if there is a socket on this port, even if not in
LISTEN state. The SYN-ACK would be send as soon as the application calls
NutTcpAccept again.

In your case this won't help, because the remote may time out before it
is his turn to get the next SYN-ACK. You need fully established connections.

As Bernd Walter pointed out, we may indeed split bind and accept. To
keep it simple, it is still not required to split the sockets into a
listening and established ones.

NutTcpBind may put a socket into listening state.

NutTcpAccept may work this way:

if (state = LISTEN) {
  if (NutEventWait(read_timeout))
    return (sock_error = E..);
  else
    return 0;
}
if (state != CLOSED) {
  return (sock_error = E..);
}
NutTcpStateChange(sock, TCPS_LISTEN);
if (NutEventWait(read_timeout)) {
  NutTcpStateChange(sock, TCPS_CLOSE);
  return (sock_error = E..);
}
return 0;

The last part is only required to maintain backward compatibility.

Did I overlook something essential?

Harald