[En-Nut-Discussion] NutTcpAccept blocks the tread

[Bernd Walter]

On Wed, Oct 21, 2009 at 05:31:23PM +0200, Harald Kipp wrote:
> 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?

One good reason for listen timeout is FTP.
Wait for a data connection - if the client won't connect within a
given time cancel the request.

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

If the listen queue is full the connect is rejected.
Having a listen queue qould be nice.
Having the ability to have a single thread listen to multiple services
would be nice as well.
But I've missed those Features more when I started with Ethernut than
I do today.
I'm running SAM7X256 systems with 40+ threads and 20+ active connections.
It requires a bit of finetuning stack and socket sizes, but it runs
stable.

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

I tried it when I started with AT91SAM7X256 using FreeRTOS.
In the end I must say that it is full of problems.
You have a listen queue, but it is missing many timeouts and memory
handling is just horror.
lwIPs socket API sounds attractive at the first though because as a
FreeBSD person I'm used to sockets, but the implementation useless to
build rugged systems.
So far I've ported all systems to Ethernut, because it was easy porting,
since I'd already used Ethernet on Mega128.
I might use lwIP again some day, because of routing and 6LoWPAN supprt,
but definitively not using the socket API.

-- 
B.Walter <bernd at bwct.de> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.