KB Rollback on Resumed Downloads

[Ascii2]

The FlashFXP 4.0.0 "File Transfer Rules" dialog box has an option "KB to Rollback on resumed downloads".

Is there any benefit to a KB Rollback for resumed downloads? If so, then what?

[MxxCon]

Have you looked in the help file?

[Ascii2]

Have you looked in the help file?Yes. The help file documentation states:KB’s to Rollback on resumed downloads
When checked, When performing a resume this allows you to rollback a defined number of KB to insure the file integrity.The documentation's relevant language is malformed.

[bigstar]

This is only necessary if you're having problems with file corruption as a result of resuming the file. In some cases when a file transfer fails the last packet received can contain garbage.

Thanks for pointing out the lack of details in the help file, additional info will be added to the next release.

[Ascii2]

This is only necessary if you're having problems with file corruption as a result of resuming the file. In some cases when a file transfer fails the last packet received can contain garbage.Is there a way to determine when "such cases" apply?

So, should there be no benefit to setting "KB to Rollback on resumed downloads" to the a value larger than the greatest value of Maximum Transmission Unit used on networks being used? (typically 1500 bytes for Internet and 9000 bytes for local network with maximum Jumbo Frame size being used)

[MxxCon]

You would use this feature if you have an unstable connection to a server.
Sometimes you experience connection problems that are not just a simple disconnect, but rather it becomes "flaky" for a few seconds and then disconnects. During those few seconds your transfer might get corrupted.
What this feature does is allows FlashFXP to throw away last X bytes as if they were corrupted and re-download them again. It has nothing to do with the size of MTU.

[Ascii2]

Are such "flaky" connections quite rare?