On 05.08.2011 09:51, Lambrecht Jürgen wrote:
> Be carefull: the eCos freeBSD stack has no timeouts on TCP connections I
> believe, but often the PC stack has!
Well the TCP timeouts that are in place when the connection
is not sending any data are basically unusable on any
standard-conforming TCP/IP stack. Whoever designed
SO_KEEPALIVE the way it is specified was smoking something
quite strong...
> So the eCos TCP session stays alive, but the PC (used to test) stack
> shuts down the TCP connection when the cable breaks (after a timeout, or
> it can also detect the cable fault). And the TCPs are out of sync
> (something like that), and then it uses a lot of sockets, and indeed (as
> in your next mail) the timeouts are very big to free sockets.
> If that is your problem, I can ask my college: he recompiled ecos to
> change the minute timeout to seconds.
This is most probably not the source of the problem I am seeing
in this test setup. Thanks for the hint anyway.
> With a slow device and big burst of data, I had to increase the space
> for mbufs.
Well, but to what size? I'd like to know the formula to calculate
the worst-case mbufs needs based on the number of active TCP
and UDP sockets... I am probably asking for too much :(
My gut feeling is that the TCP windows of all open connections
do not fit into the allocated mbufs. I'll try to tune this
stuff - unfortunately the FreeBSD stack is not really
friendly here.
> Better use lwIP on memory-constrained devices. And lwIP is more actively
> maintained..
This is on my todo list for quite a long time - unfortunately
there are issues that have to be solved first. AFAIK lwIP
is not thread-safe on a single socket level and our present
framework does read from and write to a single socket from
different threads :/
I have also no idea whether everything from eCos we are
using/planning to use is able to work with lwIP (e.g. SNMP).
Regards
--
Stano
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
