relay server dumb

Support
1

Hi

I set a private relay with these parameters: -ext-address :555 -listen “:22067” -status-srv “:22070” -global-rate 400000 -pools="" -provided-by “Cosas”.

It seems too work but can you explain why devices won’t show same verbose as public relay e.g.:

[MYNIC] 21:12:58 INFO: Joined relay relay://w.x.y.z:555
[MYNIC] 21:13:07 INFO: Joined relay relay://92.222.95.0:443/?id=UOVD33C-QDSZYAO-CKKPMRO-FEZ4B3L-HQF4S3Y-3J23RAG-RGCYFW7-VZIERAE&pingInterval=1m0s&networkTimeout=2m0s&sessionLimitBps=0&globalLimitBps=0&statusAddr=:22070&providedBy=

Although http://rel.srv.wan.ip:22070 or http://rel.srv.lan.ip:22070 shows the status fine:

{
    "bytesProxied": 873223,
    "goArch": "386",
    "goMaxProcs": 2,
    "goNumRoutine": 21,
    "goOS": "windows",
    "goVersion": "go1.5.3",
    "kbps10s1m5m15m30m60m": [
        0,
        0,
        0,
        0,
        0,
        0
    ],
    "numActiveSessions": 0,
    "numConnections": 3,
    "numPendingSessionKeys": 0,
    "numProxies": 0,
    "options": {
        "global-rate": 400000,
        "message-timeout": 60,
        "network-timeout": 120,
        "per-session-rate": 0,
        "ping-interval": 60,
        "pools": [
            ""
        ],
        "provided-by": "Cosas"
    },
    "startTime": "2016-04-02T22:12:34.30525+02:00",
    "uptimeSeconds": 1123389
}

Thank you for your huge job. It’s time for a Budvar

2

What do you mean why devices won't show same verbose

3

All the stuff after Joined relay relay://ip:port in the device console/log (/?id=… and following network specs of the relay … plus ProvidedBy=“pseudo” when provided. Maybe it is intended behaviour for a manual entry for a relay ? … writing this, I feel I can test it with some public entry. I’ll do now. Or it is a specific for a private relay (-pool="")

4

So -pools="" only tells the relay not to be available to public. Syncthing by default has dynamic+https:// address which connects to a relay from a public pool, if you don’t want that, remove that entry.

5

I’m playing around mixed private/public conf for a node*. I gave a try with this pub relay 88.146.209.122:443 (your own maybe) and the connecion was some dumd as my private relay … I guess now I can say only the discovered relays through dynamic+https… speak more to nodes.

  • this way: relay://ip:port, dynamic+https…
6

It’s not the relay, who tells Syncthing this long URL, but the relay pool at https://relays.syncthing.net/endpoint

7

Yes man, well said. Your way to say reminds me a question that yet ran in my mind : there is (are ?) a pool of servers, ok. But is (are) there a server of pool(s) ? If not, then we are sure that the reply verbosity decision relies on each relay depending on it is a pool member or not. If yes, maybe it is just the webserver you say wweich.

Nice discussion with you geeks, it shows me I forgot my initial concern I slowly drift away without realizing, which was NOT about privacy/anonymity but instead about the strength of this network relying only on this pool. It seems something like a related weakness happened 2 days ago, but as a new user with only one pair on the wan (both registered on my own private disco/relay) it appeared minor as only the relays map couldn’t show when relays coordinates were still there in some cache (gathering data from relays seemeed to fail although, maybe leading on a longuer term to an empty pool?). Well I found a workaround, only adding some manual discos + relays entries to the nodes. It’s time now to make my relay public to the default pool (not geek enough to run my own pool server) and have my disco not hanging randomly (this is for another post).

Bye bye you heavy workers, and thanks again for this great work. I really appreciate the way you there give your ears and time to answer… this even gives me the idea to try to have a look to the code… shall I dare … ?

Btw, I translated the wikipedia page into french.

1 Like
8

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.