[MCF52235] - TCP Client - Multiple Connect/Disconnect memory problem.

[Kremer]

Hi

I´m developing a product that needs to run a tcp client.
Basically, this product will connect to TCP Servers (one at a time), and retrieve data from it by sending a command and receiving the data.
The code for the client is working with no problems for a single Server. I mean, it connects to a server, sends the command and receives the data, and does this loop with no problems at all.
But when i add more than one server, the problem starts to happen. Basically, it connects to the first server, sends the command and receives the data. Then it must disconnect from the current server and connect to the second server to do the same task. After finishing the last server, it must connect to the first server and repeats this process.
The problem is that, after disconnecting from the first server by calling m_close function, it connects to the second, then to the third and so on, but one time it fails and nothing happens anymore, basically because the memory is full. So i can see the m_connect function returns ENOMEM (error 18), wich means it could not allocate memory for the new control block.
When i make the socket non-blocking, this get worst, and sometimes it just can´t pass the second server.

Please, any advice is helpfull.
I´m based on the Interniche stack and coldfire lite project. I know this is not related to utasker, but any help will be very well accepted!!!

[mark]

Hi Kremer

First a firm slap-on-the-wrist for not using the uTasker to do this - then you wouldn't have a probelm ;-)

But seriously...I wonder whether the problem is with the compiler library? If you are using CodeWarrior there are various problems with the memory management in its library implementation - check the Freescale forum since there are various posts, also with some tips on how to configure the library to possibly avoid such.

Furthermore heap can develop some holes, resulting possibly in a case of really not being able to allocate any more memory until the heap has been cleaned up. The M5223X is rather tight on RAM resources and so using heap can be a little risky due to such a phenomena. Have you tried setting a break point on failed memory allocation and stepping back into the malloc() routine to see whether the reason is visible(possibly reducing the requested size to see where the limit is)? Check to see whether the libray supports a call to return the amount of chunks of memory allocated, the amount of free blocks, maximum allocation size and remaining place, or whether it has some form of garbage collection support.

The uTasker doesn't use heap in this way since it makes memory utilisation on a small footprint device difficult to control. This allows such applications to be created in a way to know the exact total memory use (stack and heap) down to one byte memory resolution (in worst case) and avoid possible long term stability problems when the footprint is tight.

Regards

Mark

[Kremer]

 Hi Mark

 Thanks for your suggestions my friend. Your are always helping people out. So when do you really work? 

 After a hard debug session i could realize what i need was a fast flush of the allocated socket more than i ever needed in life!!! So after being slapped on face many times by the stack, i could finally achieve the perfect desired behavior by making the socket LINGER !!! This immediately flushes all socket data, buffers and whatever it takes from RAM by calling m_close. Since the client is the one who will finish the session when it get´s what´s needed, making it´s socket linger incredibly reduces the time between multiple connect/disconnect actions, and is just what i needed to run my pooling thing!!!