pg
pg copied to clipboard
sigcn
Another p2p network library in Go 🌍
2024/06/30 18:54:18 Using existing driver 0.14 2024/06/30 18:54:18 Creating adapter 2024/06/30 18:54:34 Timed out waiting for device query: 等待的操作过时。 (Code 0x00000102) 2024/06/30 18:54:34 Failed to setup adapter (problem code: 0x38,...
经过几天的试用，效果确实很好，不过我发现了一个问题，通过UDP方式组网流量如果稍稍一大，就容易被运营商限速，我想问下有计划基于TCP打洞来实现TCP组网吗？ > 打洞原理可以参考这个项目：[NatMAP](https://github.com/heiher/natmap) 在我这里，UDP容易被限速，使用TCP模式进行STUN协议打洞后很稳定，基本上同一个端口打洞后可以维持3-4天内不发生变化。这对传输大量数据时很有帮助。
例如添加一个 --client_name 的参数，启动时传入这个参数，在有这个参数的时候日志中打印类似: ``` [UDP] Ping client=ABCDE addr=10.11.69.207:59901 ListenUDP addr=27.47.130.177:11862 for=ABCDE ``` 否则还是显示 ``` ListenUDP addr=27.47.130.177:11862 for=2QQzoQZgwLxMfcjLjW8CZmS4MH9VRHc2gNB8ff3UZrSB [UDP] Ping peer=2QQzoQZgwLxMfcjLjW8CZmS4MH9VRHc2gNB8ff3UZrSB addr=10.11.69.207:59901 ``` 因为现在出了问题要开启调试模式时，使用PEERID的话每次重启PEERID都会变化，追踪问题的时候很不方便。
能实现这个功能不。 无 TUN 模式 （免 Root 权限） 使用无 TUN 模式组网时，节点可以通过虚拟 IP 被访问（TCP、UDP 和 ICMP 都支持）. 参考这个Rust实现哈 https://www.easytier.top/guide/network/no-root.html
``` goroutine 4465 [sleep]: time.Sleep(0x14101bc0) /usr/lib/go/src/runtime/time.go:315 +0xf7 github.com/sigcn/pg/disco/udp.(*UDPConn).RunDiscoMessageSendLoop.func1(0xc000094488, 0xc002953350?, 0xc0016428f8) /home/rkonfj/Documents/pg/disco/udp/udp.go:232 +0x18b created by github.com/sigcn/pg/disco/udp.(*UDPConn).RunDiscoMessageSendLoop in goroutine 4327 /home/rkonfj/Documents/pg/disco/udp/udp.go:291 +0x7fb goroutine 4586 [sleep]: time.Sleep(0xd87bec0) /usr/lib/go/src/runtime/time.go:315 +0xf7 github.com/sigcn/pg/disco/udp.(*UDPConn).RunDiscoMessageSendLoop.func1(0xc0005302a8, 0x0?, 0xc0016428f8) /home/rkonfj/Documents/pg/disco/udp/udp.go:232...
这个功能如何使用，要配合forward来使用么。没试出功能。 服务器A 使用tun ,另一台服务器B 连A服务器，使用--proxy-listen . A除了能ping通B服务器，A不能访问B服务器 任意端口
The solution is very simple and less intrusive. Rule 1: Don't close all dataCh, let GC handle. Rule 2: Make sure when ctx.Done() is triggered, all senders and receivers will...
https://github.com/sigcn/pg/blob/3b97d1c8c0c0e0d05f973a36a479d82d94d178cb/disco/udp/udp.go#L56-L70 https://github.com/sigcn/pg/blob/3b97d1c8c0c0e0d05f973a36a479d82d94d178cb/disco/udp/udp.go#L177-L180 `c.natEvents` may be already closed, right? For the dynamic added producer situation, I'm afraid WaitGroup is not enough.