This exception should only be thrown after a previous FtpException (representing the actual cause of the problem) was silently ignored.
The cause of the first exception is usually a timeout while waiting for the response of a command that the client sent to the FTP server. When a timeout or similar exception occurs, the Ftp object is most likely left in an unusable state because it has not received the response it was waiting for, and any attempt to send another command would most likely result in a similar problem. Therefore, if the application tries to issue another FTP command using an Ftp object in this state, we throw the exception you are seeing.
To handle this, detect the "bad" state of the Ftp object after catching the first FtpException that caused it - simply check whether Ftp object's State property is FtpState.Ready. If it's not, re-connect and try again.
It might also help to create a communication log using Ftp object's LogWriter property (as described at http://www.rebex.net/kb/logging/) - looking into the log, it should be easily possible to tell what is going on and what caused the bad state in the first place.
NOTE: Although reported as an error from the Rebex FTP/SSL component, the same exception can be also thrown from the SMTP, IMAP or POP3 components (parts of the Rebex Secure Mail package). A solution is the same there.
