[En-Nut-Discussion] Blocked NutTcpAccept ?

Petr Odlozil zip357 at centrum.cz
Wed Nov 1 10:00:55 CET 2006


Harald,

  thanks for your reply.

  I upgraded to the newest ethernut 4.2 and it seems all better and it 
doens't happen so early.

But still after some time it stops accepting connections.

I probably did not understand the rest of your reply.

Do you mean the previously accepted socket should be closed or the 
socket to the next server, when calling NutTcpAccept  should be closed ?

The reason I'm doing this is that, I have a network device which accepts 
connections from 1 IP address only, but I need to control it from 2 
computers.

The first thread accepts new connections on tcpport and saves the 
pointers to the created sockets to the que.

The seconst thread tries to connect to another server on the same 
tcpport. It if connects it gets the socket from a que and resends the 
data to the other server.

If it doesn't connect it takes the socket pointers from the que, close 
these sockets and wait for next new accepted sockets in the que.

I'm attaching the source code.

Best Regards

Petr Odlozil

Harald Kipp napsal(a):
> Petr,
> 
> Sure, that the socket from the last connection has been
> properly closed?
> 
> Does Ethereal show FIN and its ACK? If that it missing
> (peer killed the hard way) there is no chance for a TCP
> receiver to detect a broken connection. (Except keepalive,
> which is not available in Nut/OS.) Would a receive timeout
> help (see NutTcpSetSockOpt())?
> 
> 
> There had been a few fixes (ARP, IP) during the last weeks.
> Did you try version 4.2? If the problem still exists with
> this version, we may add it to the bug list.
> http://sourceforge.net/tracker/?group_id=34079
> 
> Harald
> 
> 
>> Everything works fine when the server is connected to the network.
>>
>> When I disconnect the server, the thread awaiting connections from a 
>> client blocks and  doesn't accept any new connections.
>> Socket is correctly created, but it hangs on NutTcpAccept(). And the 
>> thread isn't resumed (it's still in the sleep state), when some client 
>> is trying to connect.
> 
> _______________________________________________
> En-Nut-Discussion mailing list
> En-Nut-Discussion at egnite.de
> http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion
> 
> 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: SIAcmd.c
URL: <http://lists.egnite.de/pipermail/en-nut-discussion/attachments/20061101/7ddff11d/attachment.c>


More information about the En-Nut-Discussion mailing list