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