1.79测试版

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

hz6615997184904 · 2021年08月22日19:33

我在Linux上用WireGuard搭建VPN服务器，然后用iptables模拟NAT环境。

wxhere15 · 2021年08月23日00:06

我这边测试过其他几种类型NAT，还差Symmetic NAT没测试，准备用iptables模拟一下。你用的路由器是啥固件？功能挺多的

感谢建议。要处理UDP本地端口和外网端口不一致的问题，可能得在协议上略加修改了，还得保持兼容性。等下个版本了。

zhuxiaoying85309 · 2021年08月23日02:04

爱快软路由

NAT3的话，你试一下第二次检测会不会跳NAT1？我上面发了个视频

hz6615997184904 · 2021年08月23日06:46

是不是服务器不太稳？
今天测试显示UDP被阻拦，而且手动更新又没反应了……

wxhere15 · 2021年08月23日09:35

可能和线路有关系。我这边测试是可以访问的。