Abort and/or Resume FTP on Network failure

Aspose.Email Product Family
1

I don't believe that there is currently any type of functionality in place to support what I need, but please correct me if I am wrong.

I have an application that downloads files overnight. Since it is unattended there is always the possibility that the Internet connection to the app could be interrupted for any period of time. If this happens I would like to be able to have Aspose.FTP notify my app in some way that it has lost connection to the FTP server. Then I can abort the transfer and handle the reconnect to the server in my code. Of course if Aspose.FTP could also handle the resume, that would be wonderful.

Let me know what you think.

Thanks!

Dan

2

Thanks for your post,

We will provide a built-in support for this scenario the week to come. A new class will be added and handle this broken-resume scenario.

3

Dear Dan,



Could you give me your mailbox, I wanna send you a beta dll for reviewing. Please send it to guangzhou#aspose.com, Thanks very much.



Thanks

4

The beta DLL seems to work fine although I do have a question about the changes. Before using this beta a broken download would not resume, but after using this beta it resumes without me even implementing the Transfer_Broken event method. Is this how it is suppose to work?

Dan

5

Hello,

Thanks for considering Aspose.Network!

No, it not how it's supposed to work. It will not auto resume after transfer broken. But there is one thing, when you handling a TransferProgress event, the transfer will go on (non-blocking, will not pause) and may fire another TransferProgress event during that period. That is, TransferBroken may be fired when you are handling previous events.

Anyway, if you're experiencing any confusion, please send the corresponding code snippet to guangzhou@aspose.com, our test team will test it for you.

Thanks again.

6

Ok, I didn't think that was how it was suppose to work. Since I have only been simulating a network interruption (unplugging the network cord), and it has only been for short durations, you are probably correct in saying that the TransferProgress event is continuing to run, and thus picking up the transfer when the network connection is resumed.

My question now is, what is the default timeout for the TransferProgress event? How long will in continue to fire (non-blocking) before it gives up? This will be important for me to correctly design the auto-resume functionality in my application.

Thanks!

Dan

7

Dear Dan,

It seems I made some mistakens in my previous post. The TransferProgress is not always firing. Just there are lots of TransferProgress events in the message queque waiting for your consuming.

In this version we added some multi-threading features into the Ftp Component, like non-blocking event firing. It is to say, the TransferProgress, TransferBroken, and TransferCompleted will be fired in another threading, instead of the same thread as the version before. Therefore, if there lots of events sent to the System Message queque, and your event handler cannot consume them fast enough, you will found the situation like the event keeps firing.

For example, in the pervious version, which the event producer (FtpClient instance) and event consumer (your event handler) are in the same thread, the FtpClient fires a TransferProgress event, and then it stops, the TransferProgress will work, and then return to the FtpClient, the FtpClient continue to download files. And then, the FtpClient fires another TransferProgress event, and stops again. so on ...

The code works behind like:

while (is download completed?)
{
download file from website

//stop the download, call your event handler. after your event handler return, the loop will continue
transferProgressCallback(TransferStatus.Downloading, totalReceived, len);

}

However, in the new version, we change the blocking event mode to non-blocking mode for the performance concern. The download process will keep going, since it does not wait for the event handler return. and so the event firing and download is faster than the blocking mode.

The code works behind like

while (is download completed?)
{
download file from website
//use another thread to fire the transferprogress event, therefore not blocking here, the loop gos on
}

In short, the TransferProgress event is not continue to fire after you break the network. Just too many TransferProgress are here waiting your processing.

Some suggestions for the resume-broken senario:

  • listen the TransferBroken event handler and do the resume in the handler
  • do not listen the TransferProgress event , which will hurt some performance, even in the non-blocking mode
  • if you Have to listen the TransferProgress event, it is better to do it in anthoer thread

8

Dear Dan,

Thanks for your support.

When TransferBroken event is triggered, that means the connection is definitely broken. I think that's the good time to re-connect and resume download.

As for those previous TransferProgress events, how long will they last? That depends on the how fast will the handler finish its job and how much is the transfer speed.

Please excuse me for being verbose, but we do very much hope to improve our product, fulfill our user's needs, so if you think the transferProgress event just happens too frequently, please let us know, then we could make some adjustments. Your feedback will be much appreciated.

best regards