AnsweredAssumed Answered

MQX 3.8 FTP Client BLOCKED indefinitely

Question asked by Francesco Contin on Jun 26, 2014
Latest reply on Jul 8, 2014 by Carlos_Musich

Hello

I'm using MQX 3.8 and Freescale K60 for a DataLogger application that uploads periodically files to a FTP server.

There is a specific task that calls FTP client functions:

- FTP_open

- FTP_command

- FTP_command_data

- FTP_close

exactly like in the ftpc_cmd shell commands.

The application works fine for days, and weeks and months, if the server answer correctly to all the requests.

But sometimes a wrong/missed answer or a connection lost or a link error leaves the task in the blocked state indefinitely.

- There are no stack or memory overflows.

- RTCS is still running correctly (ping/web server)

- MFS file system is correctly accessible

Note:

- sometimes task is blocked in the FTP_open function, before I could get the socket handler

- RTCS is RTCS_MINIMUM_FOOTPRINT except for

    _RTCSPCB_init = 6; // 4;

    _RTCSPCB_grow = 2;

    _RTCSPCB_max = 20;

    _RTCS_msgpool_init = 6; // 4;

    _RTCS_msgpool_grow = 2;

    _RTCS_msgpool_max  = 20;

    _RTCS_socket_part_init = 6; // 4;

    _RTCS_socket_part_grow = 2;

    _RTCS_socket_part_max  = 20;

               

The only work around I found is to restart the task:

- blocking socket is "shutdown"

- memory and sockets frees (with no leak, seems)

 

Questions:

1) is this the correct way (safe and clean) to build a FTP client? (one socket, one client, one task..)

2) restarting tasks could generate memory leak problems and unpredictable long time RTU crash/reset (a DataLogger must avoid resets) : there is a way to change socket options in ftpc_cmd (OPT_RECEIVE_TIMEOUT) and handle timeouts in blocking mode?

3) why socket "blocks" forever? (OPT_TIMEWAIT_TIMEOUT is 1000)

 

Thanks

Outcomes