1.78测试版

欢迎下载测试版,尝试新功能。请多提反馈意见,谢谢大家支持。

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连接

2個讚

我理解的UDP打洞流程,欢迎大家讨论、测试:
1、两个内网用户先后通过TCP连接到同一个外网用户,并申明自己支持uTP协议及打洞协议;
2、这两个内网用户通过该外网用户的pex报文交换到其它内网用户的IP及端口;
3、默认设置下,内网用户先尝试TCP连接其它内网用户。等TCP连接失败后,再尝试通过之前提供pex报文的外网用户来协助打洞:由该外网用户向这两个内网用户同时发送UDP报文;
4、这两个内网用户任何一人收到外网用户UDP报文后,尝试直接向另一个内网用户发送UDP报文,以尝试建立uTP连接。如果之前外网用户协助打洞已成功,则内网用户之间的UDP报文可互通,uTP连接得以建立。

2個讚

好的:ok_hand:,已下载体验,谢谢楼主和开发者

前来捧场,为了方便群内小伙伴下载,已经转发 :grinning:

吼吼吼吼吼吼,终于有新版了

大致跟我的理解相同。
以下一些提问。

这个“连接”指什么连接?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连接上公网用户,他们从哪里获得我的节点信息?