希望能支持如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需要打开开发者模式才可以直接拖
下载地址错了，两个都是zip
win11打开后，登录的密码框都看不清了
Chrome Web Store的crx可以本地安装，不提供新版的crx，就只能去第三方网站下载
理论上是可以的。但如果A收到B的UDP数据包后，如果B的UDP外网端口和TCP端口不一致的话，A可能会把B当成一个新的peer，不会断开连接，直到B主动断开。实际上A要判断来自同一IP不同端口的TCP连接和uTP连接是否为同一个peer，会比较麻烦。
感谢指正，下一版安装包更新一下crx文件。
感谢反馈
那要不然这样，，在建立TCP传输后，B额外发起的UTP握手包不管收没收到回应包，都强制3秒超时丢弃或者3秒断开这个UTP通道？
我之前居然没想到这个，万一对方A给连上保持通道了，就变成TCP+UDP双通道传输了。毕竟A不一定是比特彗星，可以是utorrent等其它客户端，只要对方A是公网即可充当A的身份
比特彗星的身份为B，C也是任意一个BT客户端。
如果要做成私有协议，那么除了B是比特彗星外，此时A也需要为比特彗星，所以UTP兼容更好点
