0 votes
by (120 points)

Hello,

I am using Rebex FTP/SSL for .NET Release 2014 R1.

Is there a way to reset the ftp state to "Disconnected"?

My application has scenarios whereby the WiFi signal will be lost occasionally, causing the FTP state machine to "hang" at the "Read" state. This prevents me for initiating another FTP upon the recovery of the WiFi signal.

If need, I can show you guys my source code. Please let me know.

Thanks,
Steve

Applies to: Rebex FTP/SSL

1 Answer

0 votes
by (147k points)

Hello, have you tried calling Ftp object's Disconnect() method?

by (120 points)
Hello Lukas,

We notice that FTP throws System.Net.Sockets.SocketException.

However, I am unable to capture the exception, despite implementing (1) try /catch and (2) ftp event.

I attached a snippet of the FTP code in the same dropbox link (.cs file) for your reference.  Please have a look at the "FtpWorkerThread" method.

Thanks,
Steve
by (147k points)
Hello Steve,

- It looks like you are running your application on .NET Compact Framework, which we have not realized before. Which version of .NET CF do you use? Please try using the latest release (2018 R2) and let us know whether it still behaves the same.

- From the logs, it looks like Rebex FTP/SSL gets stuck inside the Upload method because the "finally" block in FtpWorkerThread never logs the "FtpDisconnect" message. This would explain why the Ftp object is stuck in "Reading" state. It's unclear whether this is a bug in Rebex FTP/SSL or in .NET Compact Framework, but calling ftp.Dispose() method from the foreground thread might be able to "unstuck" it, making FtpWorkerThread throw an exception.

- In FtpWorkerThread method, you only catch FtpException, but not any other kind. Adding "catch Exception" is recommended to make sure there are no unhandled exceptions.
by (120 points)
Hello Lukas,

I am using ,Net CF 3.5.  I am using WinCE 6.0.  Let me try your suggestions and will get back to you.

Thanks,
Steve
by (120 points)
Hello Lukas,

I managed to resolved the issue when (1) changing to catch "exceptions", instead of "ftpexceptions" and (2) using the latest Rebex FTP/SSL 2018 R2 release.

When using the Rebex FTP/SSL 2014 R2 release + catch "exceptions", it did not worked.

So it seems that the latest Rebex FTP/SSL 2018 R2 release fixed some earlier bugs.

I will do more testing and come back with a final confirmation.

Thanks,
Steve
by (147k points)
There have been lot of improvements since Rebex FTP/SSL 2014 R2 (see https://www.rebex.net/ftp-ssl.net/history.aspx#5298 for details).
It might be interesting to determine which release actually fixed this (I have not been able to identify any related change), but as the latest release works, it would not be an efficient use of time.
...