个人建议32位缓存大小不要超过1100M，进程空间上限包含缓存不要超过1200M，，，因为1500M是32位的极限，32位单个进程内存上限1500M，一旦达到1500M，就很不稳定，容易出现内存指针被破坏，32位而不是1.99G，自然崩掉了
不要相信网上的这些做法，，我都试过，没有用的，进程达到1500MB还是会内存溢出崩掉，什么改进程空间为4G都是没有用的
针对32位，这里可以做的的科学一点? 比如检测到到内存不足，直接自动降低线程数量，并且在此处通知内存不足字样，实现线程动态调整，此时较少的线程可以降低内存使用量，用户也应该知道内存爆了 开不了那么多线程了
不过32位感觉没什么存在的必要了，还是不要针对32位做那么多智能调整的代码浪费时间了
32位要不要加个运行软件时候每次一次提示，每次32位软件重新启动后会再次触发检测，在右下角通知之类 64位就没必要做了
检测到提交大小占用超过1.2G时（不是工作集，这个会被压缩有可能导致误判），
提示“当前正在运行32位软件，进程可用内存空间不足，请检查缓存大小使用情况，或者使用64位版本。”
或者要不然，，，检测在64位系统时，运行32位版本的时候直接重定向拉起64位版本进程启动！
免得有傻瓜老是崩溃，远程定位一看发现是用的32位的然后内存不足引起进程崩溃！
1個讚
和官方说的一样，，不方便判断，因为torrent文件不一定是.torrent结尾，例子有很多，随便挑选一个都是非torrent文件结尾
并不是判断下载链接，链接返回的响应头是 Content-Disposition:attachment; filename=“xxx.torrent”。判断文件名即可
beta2又测试了一下，没有遇到下载磁链时不去请求元数据的情况。理论上只要建立了TCP、uTP连接，没有元数据的一方就会主动向另一方请求元数据。是否请求元数据和TCP是否阻塞没有关系。 你遇到的情况具体是怎么操作的呢？
默认情况下建立了TCP连接，就不会再发送UDP数据包尝试建立uTP连接了，这样A就只能得到B报告的UDP本地监听端口，而无法通过接收B发送的UDP数据包获取B实际的UDP外网端口。
接收到Content-Disposition确实能判断是否为种子文件，但就得删除已创建的HTTP下载任务，重新创建一个BT下载任务，流程上比较麻烦，界面上也容易造成困惑。
感谢建议
之前测试这个地址没遇到超时的情况，可能和网络状况有关系
感谢反馈
btcache这个确实好，库也大，我也经常用，但是没有提供api诶，下载的时候有验证码，要是有api就好了，可以在我的分享新增种子的时候自动上传一份到btcache存储，下磁力数据的时候自动api下载一次，当然还是官方提供服务器的话更可靠了
话说要用第三方的话，有没有可能直接调用迅雷的种子文件库？
那，，我还是录屏吧，稍后编辑补充
视频体积要小于5MB，不然无法上传上来，，为了保持清晰度，视频画面帧数有点低，这回应该能看懂吧
有没有一种可能，在B建立TCP成功到A并且传输数据成功后，同时额外发送一个握手utp包给对方（代码上需要判断B启用UTP为自动检测及以上选项时才额外发送），然后此时B就可以拿到对方拒绝新产生的UDP连接连入到A的回复，实际远程UDP端口号就来了！因为已经建立了一个TCP连接，大部分客户端一个IP不允许同时建立两个链接请求，此时B所产生的UTP的远程端口就可以通过PEX交互出去了给A？我这个想法能实现吧，可以做的话能大幅度提高打洞效率了
所以我也觉得保持现状比较好，目前磁力的http种子会自动发起cookie等，并且有超时下载失败重试之类，无需另外再改动了，这两个功能需要分开，不用改动它
任务列表多加点试试，，或者找个网络烂点的电脑。。在早期的版本是会超时的，然后后来去掉了，因为当时的超时会错误把已经建立连接成功的ws tracker给超时中断掉
希望能支持如QBittorrent一样的搜索插件，这样就可以支持快速搜索其他网站了
感谢视频反馈，已查明原因，下一版修复。
发送一个简单的UDP数据包（uTP或者DHT协议）难以和已建立TCP连接的peer关联起来，可能得设计私有协议了。
感谢建议
1個讚
好的，什么原因呢？
只要能拿到对方的拒绝连接的响应包就可以了吧？
不需要连接成功上，只要对方放回了拒绝连接的响应包，就能代表是公网形并且对方的udp端口是通的。
也没必要和某个已经建立成功的TCP连接进行关联起来，，除非要做NAT2 NAT3的打洞？，因为NAT1的远程端口，是允许任意一个外部ip连入的
这种情况下用现有的UTP协议（DHT可能被对方丢弃包不响应）发出去就可以了，兼容性更广泛些（对方客户端禁用UTP时候也不会响应包）
这种情况下拿到的响应包产生的远程端口就可以用于NAT1的UDP打洞了，然后把端口信息PEX交互出去就OK了
先照这个思路做个版本，然后测试一下可行性就知道了。
大概就是，，客户端在设置UTP为自动检测及以上选项的时候
建立TCP连接成功后（不是在connect阶段），可以多开一个工作线程，额外进行发送一个20字节（0.02KB）的UTP握手包给对方，例如hex包文内容：
4100a2a2043ed63c0000000000000000fa640000
客户端保持3秒，3秒内如果收到对方响应20字节（0.02KB）的hex内容则进行下一步，如果3秒内未收到则丢弃防止内存泄漏情况：
2100a2a2cd199716c8dac05a001000003f26fa64
理论上只要收到任意响应内容即可，不需要判断hex内容是什么
此时就能拿到本地客户端产生的UDP远程端口了，然后吧这个端口信息写进PEX列表，以便交互给所有人
此时其他人连接到公网TCP开放者，他就会把这份PEX信息返回给其他人。从此实现更高效率的打洞
DHT打洞的我还没来得及去测。。。因为每30分钟一次的DHT打洞效率也太低了
这个peer_hole_punch 和utp_after_holepunch 作用为0，这个的作用自是通知对方自身的监听端口以便升级到同端口UTP传输
PEX交互这个已经实测能成功了，但是有待改善，也就是本贴说的方法，，，因为这个一定要使用UTP优先去发起才能交互端口信息，如果是TCP发起时就废了
关于打洞成功后，UTP的传输速率。。。希望也能改善，修改调大包的大小
目前瓶颈可能在代码判断过多导致的CPU占用上，因为utorrent进行UTP传输的时候基本不占用多少CPU
考虑B的UDP本地监听端口与TCP本地监听端口相同，但与UDP外网端口不一致的情况，如果B通过TCP连接A后，希望A直接向B发送UDP数据包，那么其实A此时还不知道B的UDP外网端口，没法发送。只有由B主动向A发送UDP数据包，A才能获知B的UDP外网端口。
BitComet\tools\ChromeExtension.crx还是旧版2015的，望更新为 Chrome Web Store的最新版本
现在的浏览器插件 一直捕获不了 是我设置不对么 傲游浏览器 bitcomet1.84的插件
再就是阿里云盘 用插件解析出来的地址bicomet也下载不了 下载界面点击获取按钮显示403错误
拿idm和xdown却能下载
Chrome浏览器插件现在没法本地安装了，安装包里的这个文件其实没用了。彗星主程序里选项窗口启用Chrome插件后，Chrome会去自己的插件市场下载最新的彗星插件进行安装。
主要需求是C能连上B，B不需要和A进行UTP通讯，因为B和A使用TCP更快更可靠，B只要负责把UDP远程端口信息通过PEX发给A就可以了！用UTP的目的是因为没有公网
还是说这个远程端口不能做到B去获取吗？难道要在A才能获取到
我感觉B发出去一个UDP请求，应该能拿到所使用的远程端口吧。。。大概能行，因为A回复了一个拒绝连接的响应包
有用，把crx拖动进去插件列表就可以。但是需要插件在chrome商店存在，否者会提示未过审插件，未过审的需要使用开发者模式解压文件夹去安装
可能你的解析脚本有问题，没有传递referer
https://www.aliyundrive.com/
可以啊，chrome需要打开开发者模式才可以直接拖