[En-Nut-Discussion] TCP sockets stuck in closing state

[Coleman Brumley]

Harald,

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

Coleman

> -----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
remaining
> heap space.
> 
> While reading through this thread, I just see wild guesses and trials in
the
> 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
tiny
> 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
> incarnation.
> 
> I'm currently working on a large application with all kinds of listening
and
> 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
this
> thread starts to make it highly visible. :-) Anyway, not much information
is
> provided, which would again attract me to dive in.
> Could be thread priority, could be HTTP, could be... followed by a number
of
> 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
latest
> trunk or other versions on several platforms. In this sense, this is also
no
> valuable information, like several other contributions to this thread. It
just
> 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
version.
> I'd suggest 4.10, but it's not really required to do this upgrade. Both
are
> known to work with SAM7X.
> 
> So what? Simply this way: Create a test case, which is so simple and easy
to
> 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
sure,
> that this will fix your problem less days, than a fraction of the age of
this
> thread.
> 
> If you need someone to debug your full application, there are several
> companies offering commercial support. If it's not a commercial
application,
> than put the source code on Github or elsewhere and lets see, if it is
useful
> enough, so that someone else would need it and spend some time on it.
> 
> Regards,
> 
> Harald
> 
> 
> 
> _______________________________________________
> http://lists.egnite.de/mailman/listinfo/en-nut-discussion