是BT任务下载元数据，还是种子列表下载元数据？torrent_share.metadata_dl_timeout应该是只对后者有效。如果显示Unexpected Disconnect后任务立即停止，是不是没开DHT？
是BT任务下载元数据，，connection timeout那可能是torrent_share.metadata_dl_timeout有BUG导致对BT任务列表也同时去生效了，Unexpected Disconnect测试时候没有开DHT
那测试时是从tracker获取peers，再连接peer下载元数据对吧？
对的，单独从tracker获取的，不是手动添加用户ip
会同时生效Unexpected Disconnect和connection timeout两者
测试了一下，目前元数据下载出错的几种情况如下：
1.种子列表下载元数据
a. 单个连接连接后意外断开：PROTOCOL_ERROR - Unexpected Disconnect
b. 单个连接超时：CONNECT_FAILED - connection timeout
c. 开启DHT时没有从任何来源获取到元数据，直到 torrent_share.metadata_dl_timeout 超时错误：Failed to download torrent: connection timeout
d. 关闭DHT但磁链里有tracker时没有从任何来源获取到元数据，torrent_share.metadata_dl_timeout设置未生效，会提前停止元数据下载。
2.BT任务下载元数据
a. 单个连接连接后意外断开：PROTOCOL_ERROR - Unexpected Disconnect
b. 单个连接超时：CONNECT_FAILED - connection timeout
c. 开启DHT时没有从任何来源获取到元数据，任务不会主动停止。
d. 关闭DHT但磁链里有tracker时没有从任何来源获取到元数据，任务会主动停止。
下一版准备完善无DHT但有tracker的判断，修正1-d和2-d情况的处理。种子列表始终由 torrent_share.metadata_dl_timeout 控制超时，BT任务则保持一直运行。
好的，没看明白，下个版本是可以废弃掉Unexpected Disconnect吗？不然还是会被1a和2a触发，还是说1d和2d时候可以跳过这个触发状态
简单地说，下个版本1a, 2a不会再导致停止下载了
才看到回帖消息。。。
对，，，就是这个彗星的限制东西拦截了
因为下载方只有一个ip，或者是一个相同的客户端ID，所以发起连接到做种的时候，做种方检测到是相同的源ip，或者客户端ID相同导致做种方触发拦截
做种方才是多个ip的情况，然后做种方把下载方拦截导致连不上做种方的多个ip地址
这回你应该理解是说的什么东西了，，，要的就是去掉这个限制的一个选项
最好做种方可以把本地所有IP通过DHT广播出去，以便下载方通过DHT检索到做种IP（这也可以做成一个选项 bittorrent.dht_send_double_localip ）
这个不用管，像你说的是透明的，但是比特彗星会拦截导致连不上。
这个也不用管，因为只有一个网卡，不是多个网卡来分配多个ip，系统默认选中主ip发起就行，需要的是获取网卡的本地IP，并且通过DHT广播出去，DHT应该能附带ip地址吧？不像tracker那样是获取和服务器的连接握手ip
以上考虑均为做种方多IP的情况
如果我想得没错的话，DHT可以附带ip地址的话
下载方其实也可以获得受益，其他人可以通过DHT获取到下载方的多个ip
以上前提条件建立在，，，把IP地址广播进DHT时候不是什么握手IP，只需要dht的udp数据包里附带ip地址能识别上就行
要想让做种方充分利用多IP，最直接的方式是每个IP单独模拟一个做种的seed，这样不用修改任何协议，兼容性最好，麻烦是需要重构部分代码。
确实，你说的这样，甚至还能更好的兼容到其他客户端。算是最好的方案，但是开发起来会很复杂繁琐。
反馈一个不知道算不算bug的情况，软件打开很多天不关以后（大部分时都在上传 偶尔暂停 ），上传速度会基本等于零。具体打开多久不记得了（dht连接节点累计到一万三以上了），这个情况遇到过大概两次。
