Problem in developing FTPClient using Qt

Question

I am trying to implement FTPClient in using QT Network .

How can i handle exceptional cases like during downloading network cable is unplugged , not internet connection gone etc.. ?

How can my FTPClient can come to know about such event and is there such kind of notification available ?

I have tried to use signals like done(bool) , ommandFinished ( int id, bool error ) but i m not getting any sort of signal.

Veron

Answer 1

You seem to use QFtp, which is obsolete. You should use QNetworkReply (and QNetworkAccessManager), which has finished() and error() signals: QNetworkReply documentation.

Dashiell

I am using Qt 4.7 library. It does downloading of file but i am not getting such events. – Veron

Still, QFtp is obsolete and possibly buggy. Did you try with QNetworkReply? – Dashiell

I don't think talking Ashish into using QNAM for an FTP client is right. QNAM serves as an abstraction layer for applications that need to deal with different protocols. An FTP client, on the contrary, is meant to speak only the FTP protocol by design and it likely needs more sophisticated features than what is exposed in the universal QNAM interface. – Hornblende

From the QFtp apidocs: "This class provides a direct interface to FTP that allows you to have more control over the requests. However, for new applications, it is recommended to use QNetworkAccessManager and QNetworkReply, as those classes possess a simpler, yet more powerful API." It's not explicitely marked as obsolete though as is QHttp (I thought it was the same for QFtp), insofar you are right. Still, I'd expect QNAM to be better supported these days. I haven't used it heavily for FTP myself though. – Dashiell

Answer 2

Have you tried creating a custom SLOT and connecting it to the QNetworkReply error SIGNAL?

You can then inspect the argument to determine the error and decide how you want to deal with it.

QNetworkReply::NoError  0   no error condition. Note: When the HTTP protocol returns a redirect no error will be reported. You can check if there is a redirect with the QNetworkRequest::RedirectionTargetAttribute attribute.
QNetworkReply::ConnectionRefusedError   1   the remote server refused the connection (the server is not accepting requests)
QNetworkReply::RemoteHostClosedError    2   the remote server closed the connection prematurely, before the entire reply was received and processed
QNetworkReply::HostNotFoundError    3   the remote host name was not found (invalid hostname)
QNetworkReply::TimeoutError 4   the connection to the remote server timed out
QNetworkReply::OperationCanceledError   5   the operation was canceled via calls to abort() or close() before it was finished.
QNetworkReply::SslHandshakeFailedError  6   the SSL/TLS handshake failed and the encrypted channel could not be established. The sslErrors() signal should have been emitted.
QNetworkReply::TemporaryNetworkFailureError 7   the connection was broken due to disconnection from the network, however the system has initiated roaming to another access point. The request should be resubmitted and will be processed as soon as the connection is re-established.
QNetworkReply::ProxyConnectionRefusedError  101 the connection to the proxy server was refused (the proxy server is not accepting requests)
QNetworkReply::ProxyConnectionClosedError   102 the proxy server closed the connection prematurely, before the entire reply was received and processed
QNetworkReply::ProxyNotFoundError   103 the proxy host name was not found (invalid proxy hostname)
QNetworkReply::ProxyTimeoutError    104 the connection to the proxy timed out or the proxy did not reply in time to the request sent
QNetworkReply::ProxyAuthenticationRequiredError 105 the proxy requires authentication in order to honour the request but did not accept any credentials offered (if any)
QNetworkReply::ContentAccessDenied  201 the access to the remote content was denied (similar to HTTP error 401)
QNetworkReply::ContentOperationNotPermittedError    202 the operation requested on the remote content is not permitted
QNetworkReply::ContentNotFoundError 203 the remote content was not found at the server (similar to HTTP error 404)
QNetworkReply::AuthenticationRequiredError  204 the remote server requires authentication to serve the content but the credentials provided were not accepted (if any)
QNetworkReply::ContentReSendError   205 the request needed to be sent again, but this failed for example because the upload data could not be read a second time.
QNetworkReply::ProtocolUnknownError 301 the Network Access API cannot honor the request because the protocol is not known
QNetworkReply::ProtocolInvalidOperationError    302 the requested operation is invalid for this protocol
QNetworkReply::UnknownNetworkError  99  an unknown network-related error was detected
QNetworkReply::UnknownProxyError    199 an unknown proxy-related error was detected
QNetworkReply::UnknownContentError  299 an unknown error related to the remote content was detected
QNetworkReply::ProtocolFailure  399 a breakdown in protocol was detected (parsing error, invalid or unexpected responses, etc.)

Some of this error codes are specific to HTTP but others are more generic.

Rhpositive

Answer 3

To handle network exceptions when using QFtp, you can listen to the stateChanged() signal. If the state becomes Closing or Unconnected, you can check what the error() is.

About QNAM vs QFtp: QNAM is the cleaner and newer api, but both are very much meant to work and officially supported. API-wise, QFtp uses the old command-id pattern (each command returns a command-id), which require us to keep track of the commands (for eg.: to figure out for what command a signal was raised). I find QNAM's api pattern to be much better because its commands return a QNetworkReply object that in turn emits signals. But then, QNAM's api doesn't seem tuned for ftp as well as it handles http/s (like no deletion of files over ftp), so maybe you're good sticking to QFtp for now.

Exclusive

Answer 4

Here is a complete example of an QT FTP client, along with documentation. I would recommend using their wrappers around the QFTP class.

Excerpt on handling errors when downloading:

 if (ftp->currentCommand() == QFtp::Get) {
     if (error) {
         statusLabel->setText(tr("Canceled download of %1.")
                              .arg(file->fileName()));
         file->close();
         file->remove();
     } else {
         statusLabel->setText(tr("Downloaded %1 to current directory.")
                              .arg(file->fileName()));
         file->close();
     }
     delete file;
     enableDownloadButton();
     progressDialog->hide();

It's a fully working demo, too. Here's a screenshot:

Disyllable

ya i know thats working but it does not give any event when network gets disable. – Veron

when the network is disconnected, the client should believe that the download is "done" and then this code will fire. Is that not what is happening? – Disyllable

Answer 5

QNetworkAccessManager, as stated in comments I’m not able to answer, is basic network utility for common needs and not for low level access.

There are few options you can do:

1) Implement FTP protocol yourself and all features you want using QTcpSocket and server.

2) Use QNetworkAccessManager and hope you can work around all issues with it.

Benefits from each approach should be clear, but remember, that Qt is not just a toolkit for FTP client creation.

Dhiren