[En-Nut-Discussion] TCP sockets stuck in closing state
cbrumley at polarsoft.biz
Mon May 11 21:57:23 CEST 2015
> Quite some years ago there had been some trouble with short lived
connections at high
> frequencies and also with sending a large number of tiny segments. We set
up simple test
> cases to address this problem and were able to fix it.
Is this documented somewhere, maybe in the discussion archives? I could find
no reference to it.
> -----Original Message-----
> From: en-nut-discussion-bounces at egnite.de [mailto:en-nut-discussion-
> bounces at egnite.de] On Behalf Of Harald Kipp
> Sent: Monday, May 11, 2015 2:32 PM
> To: Ethernut User Chat (English)
> Subject: Re: [En-Nut-Discussion] TCP sockets stuck in closing state
> Hi Coleman,
> On 07.05.2015 16:33, Coleman Brumley wrote:
> > Based on my overnight testing, this has worked very well. To be
> > honest, I don't if it's resulted in incorrect TCP behavior, but I have
> > noticed any negative side effects. But, the code no longer leaks heap
> > space and that is what is important to me. I'd rather the TCP SM have
> > to renegotiate that the board need to be reset because it has no
> heap space.
> While reading through this thread, I just see wild guesses and trials in
> dark. Quite some years ago there had been some trouble with short lived
> connections at high frequencies and also with sending a large number of
> segments. We set up simple test cases to address this problem and were
> able to fix it.
> In the meantime many things changed within the kernel and in the TCP state
> machine and one of the old monsters may have re-appeared in a new
> I'm currently working on a large application with all kinds of listening
> connecting TCP and UDP ports. Everything looks rock solid, running for
> months without any problem or reboot. Therefore, as you can imagine, this
> thread didn't really catch my attention. But the growing size and age of
> thread starts to make it highly visible. :-) Anyway, not much information
> provided, which would again attract me to dive in.
> Could be thread priority, could be HTTP, could be... followed by a number
> dubious hints, what could be tried else.
> While working on my current app, I also experienced problems with closing
> sockets, which looked to me like the behavior of Windows changed since
> Windows 7. I rarely see FINs, but frequently RSTs instead. As I'm using a
> hybrid Nut/OS version, something between 4.8 and the trunk, I haven't been
> able to create proper patches, not talking about testing them with the
> trunk or other versions on several platforms. In this sense, this is also
> valuable information, like several other contributions to this thread. It
> states: Yes, there is something wrong somewhere.
> The only thing I have so far is, that you, Coleman, are using Nut/OS
> 4.8.7 on an AT91SAM7X256. 4.8 is actually a nice and well maintained
> I'd suggest 4.10, but it's not really required to do this upgrade. Both
> known to work with SAM7X.
> So what? Simply this way: Create a test case, which is so simple and easy
> try, that almost everyone can reproduce the problem without spending
> more than half an hour. And simple means simple. Too often I asked for
> simple test cases and received too much. Every reference to any function,
> which is not directly related to the test, must be excluded. I'm quite
> that this will fix your problem less days, than a fraction of the age of
> If you need someone to debug your full application, there are several
> companies offering commercial support. If it's not a commercial
> than put the source code on Github or elsewhere and lets see, if it is
> enough, so that someone else would need it and spend some time on it.
More information about the En-Nut-Discussion