Download resource which response dynamic but valid instance-length for each-block

[fusionseek]

我之前浏览了历史issues,发现也有相关的问题：#17 (comment) 我不知道跟我遇到的问题是否相似？我尝试使用最新的1.0.1的SNAPSHOT还是会遇到这个问题，

taskEnd cause:ERROR realCause:The current offset on block-info isn't update correct, 4447894 != 4535848 on 2

这是我创建task的代码（kotlin）的

我使用的是下面这些下载链接，而且还有很多。
https://play.podtrac.com/npr-510318/npr.mc.tritondigital.com/NPR_510318/media/anon.npr-mp3/npr/upfirst/2018/04/20180406_upfirst_upfirstfacebookspecial.mp3?orgId=1&d=893&p=510318&story=600081084&t=podcast&e=600081084&ft=pod&f=510318

https://play.podtrac.com/npr-510318/npr.mc.tritondigital.com/NPR_510318/media/anon.npr-mp3/npr/upfirst/2018/03/20180329_upfirst_180329upfirst.mp3?orgId=1&d=803&p=510318&story=597870311&t=podcast&e=597870311&ft=pod&f=510318

我们做的是一款播客类的APP，会遇到各国的播客源，而且各个播客类的APP都是相同的源，所以如果别的APP是可以下载的，不应该我们这边的不能下，其实到也不是不能下，主要就是会很容易出现下面的错误

taskEnd cause:ERROR realCause:The current offset on block-info isn't update correct, 4944990 != 4949823 on 2

而且我发现，我之前使用FileDownloader-1.4.X的版本是不会遇到这类问题的，直到升到最新的FileDownloader后发现该问题出现非常多lingochamp/FileDownloader#974 ，而且在FileDownloader的ISSUES列表里也有很多用户遇到这个问题，我也照着FileDownloader的方法进行设置了:

使用单连接下载方案一

1. 在filedownloader.properties中配置不使用独立进程: 实现FileDownloadHelper.ConnectionCountAdapter，并在里面配置需要单连接的连接缓存，当下载出现类似错误的时候，将连接加入缓存，然后重新下载。
2. 通过FileDownloder.setupOnApplicationOnCreate注册该ConnectionCountAdapter

使用单连接下载方案二

1. 实现FileDownloadHelper.ConnectionCountAdapter全局都该用单线程下载。

但针对上面的进行设置后，FileDownloader-1.5.+版本还是会有问题!!!

后来我看到lingochamp/FileDownloader#990 (comment) 你说在OkDownload中解决了该问题.

然后尝试使用OkDownload，但是问题好像还是存在。

我截了个LOG：

刚才用Charles截了一段HTTP的数据，不知道可以不可以给你一些线索

是一个302的地址转移，但是我用的是OKHTTP，应该当是可以自己处理302的问题的

之后我又在FileDownloader-1.4.3的版本中我又尝试下了同一个链接，正常的，试了10来次都是正常的，但是1.4.3的版本好像对okcat支持的不是很好，所以没有捉到什么有用的LOG：

之前我已经了解过你写的 TCP 窗口的文章

@Jacksgong

[Jacksgong]

我认真看了，和302无关，302无论是okhttp还是okdownload本身都有处理，那么问题出在哪里呢。

首先，你的这个问题与#17 也不一样，#17 中是因为我们给的Range是x-，这么一来由于没有明确的区间右值，所以后端返回的数据不符合预期的情况。

你的情况是，我们给了明确的Range了，但是后端返回的数据大小不符合协议，具体我下面说明下:

以下是测试链接: https://play.podtrac.com/npr-510318/npr.mc.tritondigital.com/NPR_510318/media/anon.npr-mp3/npr/upfirst/2018/04/20180406_upfirst_upfirstfacebookspecial.mp3?orgId=1&d=893&p=510318&story=600081084&t=podcast&e=600081084&ft=pod&f=510318

P.S. 测试下来，以下的情况对于该资源来说，该问题只第一次验证的时候，出现而后便没有再出现。第二个资源地址也是类似。

试探链接返回的数据总大小: 14545615

根据试探链接，我们去分块，最后一个分块是9697077-14545614，但是返回的与请求的却不一致:

导致最终，结束时，发现需要下载的大小，与后端给过来的大小不一致

并且我们还观察到你这个比较独特的，只有最后一个分块的区间大小发生了变化(分块0，分块1都是符合预期的，只有分块2不符合协议)，前面的包括试探链接在内，显示的总大小都是14545615，但是最后一个分块居然突然变成14260149

---

介于这种是非常明显的服务端错误，我这边其实验证下来这两个资源也是在很少的情况下会出现，出现的概率极低。（第一个链接资源就第一次验证的时候确实是出现，后续就没有出现过；第二个资源链接没有出现过类似的服务端错误问题。），如果你实在想要忽略这种服务端错误，将只要最后流拉取完成就当作正确完成下载，你需要解决以下两大问题:

这里有两个大的矛盾点:

1. 在试探链接结束后，默认如果支持的话，我们会对文件进行预分配空间，比如将文件大小设置为14545615
2. 最终流结束时，我们会检测获取到的数据与请求的数据长度是否一致

第一个矛盾点，可以通过在1.0.2-SNAPSHOT中的DownloadTask.Builder#setPreAllocateLength(false)来关闭。
第二个矛盾点，这边确实是可以实现一个接口让下载结束后不再做这块的检测，如果是确实如此，可否再提供几个链接以便于验证这类链接的规律（由于你提供的两个链接我在1.0.2-SNAPSHOT中只出现了一次就没有再出现类似问题了）

[fusionseek]

下面是一些链接，这是现在全球比较大的播客类RSS源。下载的过程中会遇到这类问题。

还有一个是。我下载的时候连着VPN。不知道VPN会不会影响 这块的数据？

https://play.podtrac.com/npr-510318/npr.mc.tritondigital.com/NPR_510318/media/anon.npr-mp3/npr/upfirst/2018/04/20180427_upfirst_42718upfirst2.mp3?orgId=1&d=853&p=510318&story=606301138&t=podcast&e=606301138&ft=pod&f=510318"

https://play.podtrac.com/npr-500005/npr.mc.tritondigital.com/NPR_500005/media/anon.npr-mp3/npr/newscasts/2018/04/28/newscast030647.mp3?orgId=1&d=300&p=500005&story=606699149&t=podcast&e=606699149&ft=pod&f=500005

https://play.podtrac.com/npr-510318/npr.mc.tritondigital.com/NPR_510318/media/anon.npr-mp3/npr/upfirst/2018/04/20180426_upfirst_42618uf_speacial.mp3?orgId=1&d=653&p=510318&story=606004121&t=podcast&e=606004121&ft=pod&f=510318

https://play.podtrac.com/npr-500005/npr.mc.tritondigital.com/NPR_500005/media/anon.npr-mp3/npr/newscasts/2018/04/28/newscast020651.mp3?orgId=1&d=300&p=500005&story=606696138&t=podcast&e=606696138&ft=pod&f=500005

https://play.podtrac.com/npr-500005/npr.mc.tritondigital.com/NPR_500005/media/anon.npr-mp3/npr/newscasts/2018/04/28/newscast010645.mp3?orgId=1&d=300&p=500005&story=606691021&t=podcast&e=606691021&ft=pod&f=500005"

https://play.podtrac.com/npr-510318/npr.mc.tritondigital.com/NPR_510318/media/anon.npr-mp3/npr/upfirst/2018/04/20180426_upfirst_42618upfirst.mp3?orgId=1&d=730&p=510318&story=605949695&t=podcast&e=605949695&ft=pod&f=510318

[Jacksgong]

这个与VPN无关，我发现这些资源都有一个特点，就是每个链接返回的content-range所表示的总大小都有所不同，这是非常不make sense的，如下面是针对该链接(https://play.podtrac.com/npr-510318/npr.mc.tritondigital.com/NPR_510318/media/anon.npr-mp3/npr/upfirst/2018/04/20180427_upfirst_42718upfirst2.mp3?orgId=1&d=853&p=510318&story=606301138&t=podcast&e=606301138&ft=pod&f=510318 )的测试所有可能的返回的总大小:

如下，对该资源做1次试探链接，与3个分块链接返回的该资源的总大小都不同(分别是: 13898193, 13887562, 13899265, 13907206):

---

这个其实看来应该是chunked动态大小的流式资源，但是返回的请求头中并没有告知是流式资源。因此这类资源按照服务端的设计来看，应该本身就不支持分块下载。
但是实际上与流式资源又略有不同；流式资源在响应头中我们无法获知当前链接可供获取的数据的总大小，而该响应头又支持。。

---

这种资源的特征就是

如果你简单的发一个请求来下载，应该都是正常的。
但是如果分块下载，需要多个链接协同下载就很容易出现各种问题，但是我分析其响应头来看内部并无法获知是否是该情况。

---

为了保证okdownload更加可靠我会采用这个策略修复这个问题: 在单链接情况，如果试探链接与实际单块链接不一致，将会采用单块链接为主以继续正常下载。

在上面这个修复策略的基础上，以上资源都可以通过DownloadTask.Builder#setConnectionCount(1)来正常下载； 但是由于其长度不断的在变化，因此如果下一次启动任务的时候发现总大小不同，断点续传便会被弃用，因此很容易无法断点续传，这个是无法避免的。

[fusionseek]

Ok,非常感谢你抽空分析这类问题，无法断点续传没关系，只要可以正常下载就可以 。