欢迎下载测试版，尝试新功能。请多提反馈意见，谢谢大家支持。
v1.78.0 macOS版
界面修正：macOS版暂不支持代理功能，已屏蔽相关设置界面
核心修正：macOS版增加IPv6协议的UDP传输支持
https://download.bitcomet.com/mac/BitComet_1.78.0.dmg
v1.78 正式版 (1.78.7.27)
核心改进：阻止Sonic Studio 3 DLL注入，增强程序稳定性
核心修正：优化同时选择BT协议加密“自动”选项与uTP协议“自动”选项时的连接策略
https://download.bitcomet.com/achive/BitComet_1.78_setup.exe
https://download.bitcomet.com/achive/BitComet_1.78.zip
v1.78 Beta3 [20210723]
界面改进：种子文件制作窗口显示自动选取的分块大小
界面改进：BT任务及Tracker种子列表下方的Tracker列表增加Ctrl+A快捷键
界面改进：BT任务及Tracker种子列表下方的Tracker列表右键菜单增加清理失效Tracker的命令
界面修正：Tracker种子列表下方的Tracker列表无法按状态排序
界面修正：文件列表未能正确显示0字节文件分块信息
界面修正：全局统计里的防火墙信息应处理"程序例外"
v1.78 Beta2 [20210722]
界面改进：高级选项增加 bittorrent.utp_after_holepunch，默认启用
界面改进：用户列表右键菜单设置的uTP连接发起方式增加默认选项，遵循 bittorrent.utp_after_holepunch 的设置
界面改进：用户列表增加“协议”、“加密”、“标志位”信息
核心修正：同时选择BT协议加密“优先”选项与uTP协议“自动”选项出现连接失败的问题
核心修正：程序启动时没有正确读取任务累计长效上传流量
v1.78 Beta1 [20210720]
界面改进：全局选项增加uTP协议启用选项，默认关闭
界面改进：高级选项增加 bittorrent.peer_hole_punch，默认启用
界面改进：用户列表增加uTP状态信息
界面改进：用户列表右键菜单手动添加用户时，可选择uTP连接发起方式
界面改进：用户列表右键菜单可设置uTP连接发起方式
界面改进：统计页面增加uTP数据包统计
核心改进：支持使用uTP协议连接其它BitTorrent用户
核心改进：支持通过其它BitTorrent用户协助进行UDP打洞，以建立uTP连接
3個讚
我理解的UDP打洞流程，欢迎大家讨论、测试：
1、两个内网用户先后通过TCP连接到同一个外网用户，并申明自己支持uTP协议及打洞协议；
2、这两个内网用户通过该外网用户的pex报文交换到其它内网用户的IP及端口；
3、默认设置下，内网用户先尝试TCP连接其它内网用户。等TCP连接失败后，再尝试通过之前提供pex报文的外网用户来协助打洞：由该外网用户向这两个内网用户同时发送UDP报文；
4、这两个内网用户任何一人收到外网用户UDP报文后，尝试直接向另一个内网用户发送UDP报文，以尝试建立uTP连接。如果之前外网用户协助打洞已成功，则内网用户之间的UDP报文可互通，uTP连接得以建立。
2個讚
大致跟我的理解相同。
以下一些提问。
这个“连接”指什么连接？TCP还是uTP？还是不问连接类型？
这个“外网用户”的定义是什么，TCP端口还是UDP端口开放？
后者的话，只要两个内网用户能够同时连接，NAT1及特定情况下的NAT2、3也被看作是“外网用户”吧。
这个在BEP55中没提及，是BC独自的逻辑吗？
BEP55的方案比较随缘，接下来应该重点测试实际通过用户交换的打洞效率。
有意开发之前论坛提到的服务器调度方式吗？
用户列表选中右键后，看到uTP连接发起方式有“UDP打孔”和“直接”，请问具体代表什么含义？
观察了一下，即使把uTP协议改为“强制”，用户列表中看到的默认方式还是“UDP打孔”。
用户列表中显示的“uTP”列具体是什么含义？
“已启用”表示的是对方支持uTP？还是与对方的连接使用了uTP？
当与对方建立了uTP连接后，是否能够同时保持TCP连接？
目前用户列表界面似乎无法确认正在使用的连接方式。
是指内网用户通过TCP连接到外网用户
外网用户是指TCP端口开放
彗星选项里uTP连接有“禁止、自动检测、优先、强制”四个选项，其中的“自动检测”就是先TCP后uTP。qBittorrent也是如此。
目前暂无提供服务器来协助UDP打洞的计划
“UDP打孔”是指又第三方外网用户协助打洞后，再向内网用户发起uTP连接。“直接”是指不打洞直接发起uTP连接，主要用于测试。
全局设置里的四个uTP选项主要是用于设置TCP和uTP两种连接方式的优先级。用户列表里的"uTP连接发起方式"主要是控制是否先打洞再发起uTP连接。
这个信息是当前peer的uTP连接状态。“已启用”是指已建立了uTP连接。对方是否支持还没有地方明确显示，后续版本继续改进。
理论上可以，目前未实现。估计大部分客户端遇到一个IP发起多条连接都会只保留一条。
没有显示uTP状态的都是TCP连接。
2個讚
感谢解答。
最后烦请确认一下。
内网用户与中继方的外网用户需要完成以下交互
这两个操作必须通过TCP连接才能完成吗？
如果能通过UDP连接（比如已建立的uTP）来交互，那么“UDP端口开放（包括NAT1，甚至NAT2、3）的用户”也能成为中继方，提高穿透效率。
理论上在网络层和传输层上应该可以实现，是否受限于BT协议而只能用TCP？
前提：
目前无法与同一用户同时保持TCP与uTP连接
那么：
当用户的uTP状态为空时，代表正在使用TCP连接
当用户的uTP状态为“已启用”时，代表正在使用uTP连接
虽然可以判断，但不够直观，建议改善显示内容。
我在用户的uTP状态中看到有显示“不支持”的，又代表什么含义呢？
开启长效上传后，如果退出程序的话，任务摘要里长效做种的数据会清空，同时整个任务的分享率会因为长效做种上传的数据被清空而减少
右下角的“重新检测”不生效，修改端口后也不会重新检测端口状态
重新启动程序后会再次检测，但检测结果不正确
只有IPv6的TCP端口有重新检测，实际上全部阻塞
IPv6网络不可用时，UDP端口状态仍然没变化
这是BT协议层的事务，已建立uTP连接的内网用户也可以完成这两个操作。
谢谢建议，后续版本改进
此用户在BT协议握手时没有设置支持打洞协议的标志位
感谢反馈。接收到连入的连接，就会自动切换为绿灯。切换端口的端口实际堵塞的情况我再测试一下。
1個讚
居然要3台设备，，，才能打通，晚上测一下可不可行
如果没服务器支撑的话，有没有可能判断长效客户端来用作打洞超级节点？
例如在线时长超过7天的客户端话，（需要客户端打开打洞超级节点选项，自愿参与，为什么要天数高，因为基本是服务器，稳定长期运行）则可以分配为超级节点，服务器仅记录这份列表，然后客户端下载时候仅需请求服务器来获取这份超级节点列表，然后客户端对每个超级节点请求这发送UDP报文打洞？
服务器对这份超级节点最多保持50个，每24小时仅更新一次列表，可通过br压缩降低列表大小，以便减少流量开销。
不知道nat检测功能有没有加上，等会晚上下载客户端试试。。说真的没服务器支持的话，，，打洞起来应该会很艰难，有nat检测功能的话，如果检测到并不是nat1，可以直接禁用打洞功能，以便节省客户端CPU性能开销，因为没必要做nat234的打洞，，
当处于TCP端口阻塞，NAT3环境下时
挂了5分钟只有少数本地发起的TCP连接，暂未看到uTP打洞的连接
挂了10分钟后本地发起的TCP连接增加，速度也上去了，但仍未看到uTP连接
当处于TCP端口阻塞，UDP端口开放（固定映射）时
挂了不到1分钟就能看到大量的来自远程的uTP连接
是的 1.78BETA和1.77f都是 试过好几个版本 好像从任务摘要里加入长效做种信息以后就一直是这样了
pex交换来的peer才带有是否支持utp和打洞协议的标志位，tracker及DHT得到的peer是不知道的。所以用发送pex的peer作为协助打洞的节点是最合适的。
还没有做这个功能，后面再考虑吧
感谢反馈。目前协议是跑通了，可能还有bug，还得多做测试
感谢反馈
1個讚
默认设置下，先尝试发起TCP连接，失败后再发起uTP连接，这一点已经理解了。
但在发起uTP连接时，是否始终经过第三方外网用户，通过“UDP打孔”的方式进行？
这意味着，目标的uTP节点只能通过PEX获得，并且需要记录来源节点，才能请求公网用户协助打洞。
但应该无法准确判断目标uTP节点的端口是否畅通，无条件地经由公网用户，效率会不会变低？
我直观地认为，可以先尝试直接连接目标uTP节点，超时后再请求公网用户协助打洞。
还是说，在等待超时的过程中，会造成额外的硬件开销？
同时，是否可以直接使用uTP（或在TCP失败后）连接从tracker（或DHT）获得的节点？
这些节点无法确认与其保持连接的外网用户，也就无法通过“UDP打孔”的方式发起连接。
对于这些节点，在TCP连接失败后，是否不会尝试uTP直连而放弃？
我在仅开通UDP端口的情况下进行测试，新任务启动10秒内就能接收到来自远程的uTP连接。
这些连接难道也是走了一遍PEX和中继的公网用户之后才连上我的吗？
但我观察时也没看到通过TCP连接上公网用户，他们从哪里获得我的节点信息？
，已下载体验，谢谢楼主和开发者
