Hey, you guys, I’m trying to swim with everyone else in the public relay pool. You can see me on the Relay Pool Data as: 70.27.24.176:22067.
I’ve opened port 22067 on my router and on my desktop running relaysrv. However, I’m having trouble making contact with anyone. I have the -debug=true flag set and I’m getting a lot of messages. One of the most common messages that I’m receiving is something like: “Listener failed to accept connection from [ADDRESS]: Possibly a TCP ping.”
Do you know what could be causing this and why my relay server doesn’t seem to be working?
Oh, okay. But, why am I getting no traffic through the relay server I’m hosting and why does the Relay Stats page have no statistics for me: http://relays.syncthing.net/. My relay server has been up for over an hour, now.
It will take 12 to 24 hours to get any appreciable traffic. You need to wait for people’s Syncthing devices to be turned on, and connect to your relay. Then you need to wait for other devices to be turned on, and want to talk to those first devices over a relay.
Alright, I have been running the server for a few days. I’ve collected some good data, now. I have stored ~5 GB of data in a log file that I will link below. I understand this is large so I’m also including a link for the first 1000 lines of this log file (~120k). Let me know if I can do more work. I’m still having the issue and the server has been up for 5 days, now.
I can only put one link per post since I’m a new user. Above is the link to the ~5 GB log file.
Also, I checked my network traffic using nethogs. Apparently, the relay server is pulling ~5.6 MBit/s and pushing roughly the same amount. Again, this is running on my desktop at home on a domestic/consumer internet with a standard no-frills router. So, I understand my contribution to the relay network should be smaller than those with a Gigabit connection or a VPS but the whole idea of relaysrv is that it’s a P2P relay network so I should be able to contribute something.
Relays don’t work in quite the distributed way which you probably expect. Syncthing only connects to one relay at a time, and it doesn’t check how much available bandwidth that relay has before connecting. Therefore if there’s a relay with a bad internet connection, all devices which happen to connect to it will receive a bad quality of service.
It’s therefore not like bittorrent where every little helps: relays which are significantly worse than average will bring down the quality of the network.
5.6MB/s is a pretty substantial contribution though: the dedicated VPSs typically aren’t exceeding that due to monthly transfer limits.
@AudriusButkevicius: I agree that by inspecting the logs it seems that everything is working as expected. However, the stats for this server are still not listed on http://relays.syncthing.net. I would like to see on that little map how big my circle is. I would also like to see my ``contributed-by tag (a little vanity).
@canton7: That is different than what I expected. Without reading the specification (sorry) do devices which need to communicate have any way of determining which relays are the best at the time of making the connection? Also, do devices with established connections to a given relay have the opportunity to switch to a better relay (lower latency and/or higher throughput) at any time?
A relay is chosen based on the latency between that device and the relay, plus a random factor: that’s what the pings you describe at the top of this thread are doing. Once a relay is chosen, that’s it: syncthing won’t switch to another one (unless a disconnection occurs, etc).
I haven’t looked at your logs (I’m on mobile) but relays.syncthing.net foes take something like 5-10 minutes to refresh: there’s a caching layer in front of it.
Alright, I restarted the server. I opened up port 22070. We’re all good, now. I can see my -provided-by tag and the amount of data I’ve proxied. Thanks, everyone.
Would it not be trivial to start a timer at startup and, say every 12 hours, attempt a retest of the best relay at the time. This should slowly allow better distribution of relay usage I would think while minimizing the re-connections or hammering relays with unnecessary packets.
.
Also I would think the best true path would be a combination of the lowest sum latency between both ends of the relay connections.
Example:
Client A has 3 possible relays 10ms, 200ms, 300ms but client B has 500ms, 150ms, 100ms to those same 3 relays (respectively). Clearly the best overall path is #2 right (350ms total)? But neither side will see that and pick a worse relay.
Seems like the relay choosing algo could use some tweaking. Let me know if I’m missing something here, or it’s already been tried and found to be very problematic.
Relay selection does that (sum of RTT) today. But this stuff in general is very young - just introduced 10 patch releases ago - and in the usual Syncthing spirit starts out as the simplest possible thing that could possibly work. There’s lots of tweak potential. People are considering all kinds of improvements.