1.79测试版

wxhere15 · 2021年08月22日09:32

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

v1.79.2 macOS版
核心改进：mac版开启utp协议支持
核心改进：mac版UDP监听增加绑定IP支持
核心修正：mac版开启远程访问时upnp崩溃
核心修正：mac版没有监听IPv6 TCP端口
核心修正：mac版UDP更改监听端口后无法发送数据

https://download.bitcomet.com/mac/BitComet_1.79.2.dmg

v1.79 正式版(1.79.8.25)
界面修正：任务列表不用显示私有任务的长效种子数量

https://download.bitcomet.com/achive/BitComet_1.79_setup.exe
https://download.bitcomet.com/achive/BitComet_1.79.zip

v1.79.0 macOS版
核心修正：macOS版在显示模态对话框时，部分情况下消息处理不正常

v1.79 Beta2 [20210823]
界面改进：手动检查更新时，更新NAT类型检测服务器配置信息
核心修正：对称型NAT的判断条件应考虑外网端口的变化
核心修正：处理torrent中的文件目录结尾含有空格的情况
核心修正：处理torrent中的文件名含有UTF8表情符的情况

v1.79 Beta1 [20210822]
界面改进：工具菜单新增NAT类型检测对话框
界面改进：支持Windows 11
界面修正：绿灯状态下重新检测监听端口状态未清除缓存信息
界面修正：手动添加peer的输入框长度限制过小导致无法输入IPv6地址
核心改进：监听端口状态检测增加针对UDP数据包的NAT类型检测
界面修正：任务未启用PEX时，不再自动连接peer返回的自身IPv4/IPv6地址

77777jhkj · 2021年08月22日09:57

两个链接都打不开

hz6615997184904 · 2021年08月22日10:13

请问这工具怎么用？自己找服务器吗？
似乎无法自定义

wxhere15 · 2021年08月22日10:30

不用自己配置服务器。客户端在检查新版本信息时会获取服务器配置信息，估计您的客户端还没获取到。

可以关闭彗星后，把 “%appdata%/bitcomet/BitComet.xml” 里的 LastAutoUpdateCheckDate 整行删除，再重新启动程序试试。

hz6615997184904 · 2021年08月22日10:55

仍然无法获取
在“帮助”菜单中手动更新时一直停在这里

追记：
刚才再尝试手动更新，已经可以了。

zhuxiaoying85309 · 2021年08月22日11:24

客户端未开启自动检测更新选项能用该功能吗。。

奇怪我1.77没复现这个问题，把端口封堵后重新检测，可以变为黄灯阻塞状态

HULU · 2021年08月22日12:52

说明你是大陆用户，可以请其他人分享百度网盘给你

wxhere15 · 2021年08月22日13:30

那就不能了

是没有清除是否有过外网连入的BT连接的记录

zhuxiaoying85309 · 2021年08月22日13:41

可以单独做一个选项出来吗

hz6615997184904 · 2021年08月22日13:57

请问uTP的优化有什么进展吗？

之前测试版的帖子提到uTP打洞需要对PEX来源peer的端口进行替换操作
libtorrent中有实现

github.com

arvidn/libtorrent/blob/95afba30e9acfd8411076a0b05f7ca69bf33b9bb/src/ut_pex.cpp#L154


      
          				{
          					// don't write too big of a package
          					if (num_added >= max_peer_entries) break;
          
          					// only send proper bittorrent peers
          					if (peer->type() != connection_type::bittorrent)
          						continue;
          
          					auto const* const p = static_cast<bt_peer_connection const*>(peer);
          
          					// if the peer has told us which port its listening on,
          					// use that port. But only if we didn't connect to the peer.
          					// if we connected to it, use the port we know works
          					if (!p->is_outgoing())
          					{
          						torrent_peer const* const pi = peer->peer_info_struct();
          						if (pi != nullptr && pi->port > 0)
          							remote.port(pi->port);
          					}
          
          					// no supported flags to set yet

另外在阅读DHT协议时发现，2013年3月22日的修订中新增了可选参数"implied_port"

There is an optional argument called implied_port which value is either 0 or 1. If it is present and non-zero, the port argument should be ignored and the source port of the UDP packet should be used as the peer’s port instead. This is useful for peers behind a NAT that may not know their external port, and supporting uTP, they accept incoming connections on the same port as the DHT port.

libtorrent同样有相关的实现

github.com

arvidn/libtorrent/blob/95afba30e9acfd8411076a0b05f7ca69bf33b9bb/src/kademlia/node.cpp#L403


      
          			o->m_in_constructor = false;
          #endif
          			entry e;
          			e["y"] = "q";
          			e["q"] = "announce_peer";
          			entry& a = e["a"];
          			a["info_hash"] = ih;
          			a["port"] = listen_port;
          			a["token"] = p.second;
          			a["seed"] = (flags & announce::seed) ? 1 : 0;
          			if (flags & announce::implied_port) a["implied_port"] = 1;
          			node.stats_counters().inc_stats_counter(counters::dht_announce_peer_out);
          			node.m_rpc.invoke(e, p.first.ep(), o);
          		}
          	}
          }
          
          void node::add_router_node(udp::endpoint const& router)
          {
          #ifndef TORRENT_DISABLE_LOGGING
          	if (m_observer != nullptr && m_observer->should_log(dht_logger::node))

不知BC是否支持？

wxhere15 · 2021年08月22日14:14

可以加到手动检查更新的操作里面

这一版做了NAT检测之后，再考虑如何优化uTP打洞

感谢反馈，暂未支持，后续改进

zhuxiaoying85309 · 2021年08月22日16:33

果然以前的版本对于完整的ipv6添加不上。。。服务器那种短地址倒是可以

zhuxiaoying85309 · 2021年08月22日16:35

libtorrent的话具体我不清楚，我用的是qbittorrent测试，他们用的底层是libtorrent，，，测试qbittorrent并不能支持nat打洞

zhuxiaoying85309 · 2021年08月22日17:05

各位你们检测准吗。。。我Symmetic nat4类型被检测成Port Restricted Cone nat3

还是说使用的 RFC 不同引起的误差？可以确定自身网络是NAT4

hz6615997184904 · 2021年08月22日17:16

PEX和DHT端口替换只是最基本的一步，之后还要考虑一些问题。

·TCP连接不应该替换端口
DHT使用UDP，因此这个问题只跟PEX关联

·不同来源的peer出现重复（IP相同，端口不同）
这时候如果优先选择Tracker来源（无端口替换）的peer的话，除非是固定映射，否则必然无法建立连接
PEX和DHT来源的优先级很有可能比Tracker来源低

·如何判断直连还是打洞
替换端口后的peer，如果对方是NAT1，或者最近（25~30秒内）有过交互的DHT节点，那么可以直接连接，其他情况则需要通过BEP 55来打洞
这个可能需要开发一个判断的机制（先直连，超时后再打洞）

·DHT来源的peer如何打洞
DHT来源的peer虽然也存在中间节点，但BEP 55的消息是基于BT协议的，而DHT协议并不支持
DHT中间节点与目标peer正在进行同一任务的可能性较低，因此DHT来源的peer应该只尝试直连

libtorrent可能并没有解决这些问题

hz6615997184904 · 2021年08月22日17:19

我的是全锥形NAT，检测正确。
如果是对称型NAT，服务器1与服务器2返回的公网端口应该不同。
除非客户端把服务器1和服务器2解析成同一个地址？

更正，我是NAT3（端口受限锥形NAT）。

第一次测试时由于使用BC的监听端口作为本地端口，且与公网端口一致，经过固定映射后误判成全锥形NAT。

第二次测试时本地端口与公网端口不一致，则得出了正确的NAT类型。

zhuxiaoying85309 · 2021年08月22日18:35

估计是BUG，，检测不到是NAT4类型，NAT4会被判断为NAT3，楼上你的检测应该没错，因为你的公网端口没发生变化？我这没有NAT3环境。。
NAT1的情况下，检测正常

hz6615997184904 · 2021年08月22日18:44

我刚也模拟了一个NAT4环境。
NatTypeTester下检测正确，BC中也明确看到服务器1和服务器2的公网端口是不一致的。
然而软件却判断成NAT3

是的，第一次检测成NAT1是由于该端口无条件开放，影响了结果。
第二次端口变化后检测出NAT3，是正确的结果。

zhuxiaoying85309 · 2021年08月22日18:51

洗完澡后突然想起来改nat3的办法了。。只要在nat1网络下，把Windows系统防火墙打开并且不允许程序通过就行
https://ldbbs.ldmnq.com/bbs/topic/attachment/2021-8/b79b52bb-0bdb-41a1-b0ab-5e9c50a20d57.mkv

然后发现个问题，首次打开是nat3，后续就算等待30秒后，，还是被判断为nat1，这种情况下属于错误判断为NAT1