[En-Nut-Discussion] TCP stops working after some time

[Harald Kipp]

Well, unfortunately it's not that reliably as we thought.
It's much better now, but further tests showed, that fgets()
on sockets sometimes doesn't return. The stack seems to fail
in NutTcpReceive().

Our assumption is, that the problem appears when segments
are processed, which were received in advance. This is
caused by a packet loss after the segment had been resent.
But, as I said, this is an assumption.

As usual, problems seem to disappear after adding trace
outputs. It may take several days to catch it. Last result
was, that the stack failed at memcpy() in NutTcpReceive(),
but still this has to be verified.

You can always use CVS to retrieve the latests fixes. Or
visit
http://www.ethernut.de/en/download.html
to download a dynamically created snapshot
(Under "Nut Developer Release").

Harald

At 09:34 08.01.2005 -0200, you wrote:
>Hi Harald,
>
>Congratulations for the positive result, uffaa.... I was already very 
>worried with that, because this associated the ethernut reliability.
>Does continue working after many days?
>How do I do to apply the revision in my projects?
>Already this available one in releasing 3.9.3 ?
>
>Best Regards
>
>Magalhaes
>
>
>----- Original Message ----- From: "Harald Kipp" <harald.kipp at egnite.de>
>To: "Ethernut User Chat (English)" <en-nut-discussion at egnite.de>
>Sent: Monday, January 03, 2005 7:00 AM
>Subject: Re: [En-Nut-Discussion] TCP stops working after some time
>
>
>>Finally I succeeded in reproducing the TCP stack halts
>>by running four TCP server threads concurrently exchanging
>>data with four clients running on a Win PC.
>>
>>Simpy protecting the calls to NutEventPostAsync() doesn't
>>help, btw. During the implementation of round trip time
>>calculation Oliver changed these original NutEventPost()
>>calls for good reasons. If application threads are running
>>at higher priority than the state machine, they may take
>>over. But in most situations the socket's status hasn't
>>been fully updated at that point. So I moved the event
>>posting (using NutEventPost() again) to the end of the
>>state processing.
>>
>>In the buggy version the test application failed within
>>one or two hours. After applying the fixes mentioned
>>above it has been running now for several hours without
>>any problem. I just committed the changes to CVS HEAD.
>>Before releasing 3.9.3 we will run a few more tests.
>>
>>Harald
>>
>>At 09:14 22.12.2004 +0100, I wrote:
>>
>>>We still haven't been successful with reproducing the
>>>TCP halt. Using four server threads plus read time out
>>>doesn't help. However, the test concentrates on connect
>>>and disconnect. Thus, we will now use larger data
>>>transfers, exchanging about 20k bytes in both directions
>>>during each session. This will trigger more NutEventPostAsync()
>>>calls. Most of them are located in data and ACK handling.
>>
>>_______________________________________________
>>En-Nut-Discussion mailing list
>>En-Nut-Discussion at egnite.de
>>http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion
>>
>>
>>
>>
>>--
>>No virus found in this incoming message.
>>Checked by AVG Anti-Virus.
>>Version: 7.0.298 / Virus Database: 265.6.7 - Release Date: 30/12/2004
>>
>
>
>
>--
>No virus found in this outgoing message.
>Checked by AVG Anti-Virus.
>Version: 7.0.300 / Virus Database: 265.6.9 - Release Date: 6/1/2005
>
>_______________________________________________
>En-Nut-Discussion mailing list
>En-Nut-Discussion at egnite.de
>http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion