[En-Nut-Discussion] NutTcpAccept blocks the tread

[Harald Kipp]

Ole Reinhardt wrote:

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

We are not in NutTcpAccept, but in NutTcpStatePassiveOpenEvent.
NutTcpAccept claims to return -1 in case of an error. Actually it
doesn't....


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

Again my question then: Is that what you want on time out, rejecting
further connections? What could be the motivation for this?

I assume that this is not the desired goal, so why implement a time out
then at all?


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

Good that you direct me to the original message. Indeed, I answered to
follow-ups, but Urban was asking for something different.

While the original Liquorice source was based on callbacks, I wanted to
have file streams attached to TCP connections. This required a Berkeley
style socket interface, which I tried to mimic with what was available.
I have no idea what a Berkeley socket compatible implementation would
cost. But I assume that this would be a bigger task.

Unfortunately Urban's request wasn't that specific: "...so I have to
spend for each connection his own thread." This would be true for
Berkeley/Posix sockets as well. Btw. dynamically creating threads on
incoming connections is shown in the current app/httpd sample.

Urban, can you please specify in more detail, what you are expecting?


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

Berkeley sockets do have a similar problem. If more than one connection
are coming in at the same time, they will be rejected (or ignored?) as
well. However, the listen call allows to specify a backlog, which Nut/OS
doesn't.


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

I doubt that will never be able to implement all the internals, because
it is based on systems with far more memory resources. We will have to
simulate certain parts. I also have no idea, how much effort this may
require. In any case I'd suggest to implement this from scratch and add
it as an alternative to the existing interface.

Does anybody have experience with the optional lwIP Berkeley socket API
or does anybody know about another TCP stack for 8-bitters, providing a
Posix like socket interface?

Harald