From: Juliusz Chroboczek <jch@irif.fr> To: "Toke Høiland-Jørgensen" <toke@toke.dk> Cc: galene@lists.galene.org Subject: [Galene] Re: Logging Date: Fri, 08 Jan 2021 16:34:05 +0100 [thread overview] Message-ID: <87mtxj789e.wl-jch@irif.fr> (raw) In-Reply-To: <87turrh6y2.fsf@toke.dk> >> The direct connection was successful, so the TURN server was never >> contacted. > Right, I see. What are the conditions where a direct connection fails? > Is it just when the client is behind a NAT? If only one side is behind NAT, you should get a direct connection with no outside help. If both sides are behind NAT, they will attempt to establish a paired set of NAT mappings by synchronising through a STUN server, and then establish a direct connection (TURN is a superset of STUN, no need to set up a dedicated STUN server if you've got TURN). This is usually successful, but might occasionally fail due to packet loss. If there is a firewall in the way that drops UDP traffic, or traffic to high-numbered ports, then the peers will fall back to TURN. TURN supports both UDP and TCP proxying, since some networks allow outgoing UDP only to some ports (typically 1194 for OpenVPN and 10000 for the Cisco VPN client). ICE-TCP adds an additional step by allowing direct connections over TCP. It is not designed for peer-to-peer communication, only for client-server communication, so it should be a perfect fit for Galène. Once a functioning pair is found, ICE will stick to it. In Galène, we restart ICE whenever the connection fails, and also when the user types "/renegotiate". (I'd like to detect client-side network changes and restart ICE automatically, but current browsers don't give me a suitable event handler.) All of this happens in parallel, with arbitrary timeouts, so the actual behaviour tends to be non-deterministic and next to impossible to debug. See for example https://github.com/pion/ice/issues/305 > As for just logging, Galene does propagate JSON parsing errors from the > Go JSON parser, but because the files are not read on startup you can > start up the daemon and everything looks fine until someone tries to > connect... Hmm... I'm actually using the current behaviour, by using undefined fields in my JSON files ("contact" and "comment"). But I think you're right. This will happen in background, so you'll only get warnings in the log. After 0.2 is out, though, since Galène is frozen right now. -- Juliusz
next prev parent reply other threads:[~2021-01-08 15:34 UTC|newest] Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-01-07 21:38 [Galene] Logging Juliusz Chroboczek 2021-01-07 22:45 ` [Galene] Logging Michael Ströder 2021-01-08 0:35 ` Antonin Décimo 2021-01-08 12:40 ` Toke Høiland-Jørgensen 2021-01-08 13:28 ` Juliusz Chroboczek 2021-01-08 13:52 ` Toke Høiland-Jørgensen 2021-01-08 14:33 ` Michael Ströder 2021-01-08 15:13 ` Juliusz Chroboczek 2021-01-08 17:34 ` Michael Ströder 2021-01-08 18:00 ` Juliusz Chroboczek 2021-01-08 15:34 ` Juliusz Chroboczek [this message] 2021-01-08 19:34 ` Toke Høiland-Jørgensen 2021-01-08 19:56 ` Juliusz Chroboczek 2021-01-09 0:18 ` Toke Høiland-Jørgensen 2021-01-09 13:34 ` Juliusz Chroboczek 2021-01-10 13:47 ` Toke Høiland-Jørgensen 2021-01-10 15:14 ` [Galene] Congestion control and WebRTC [was: Logging] Juliusz Chroboczek 2021-01-10 15:23 ` [Galene] " Juliusz Chroboczek 2021-01-10 22:23 ` Toke Høiland-Jørgensen 2021-01-10 22:44 ` Dave Taht 2021-01-11 0:07 ` Juliusz Chroboczek 2021-01-11 0:20 ` Toke Høiland-Jørgensen 2021-01-11 0:28 ` Juliusz Chroboczek 2021-01-11 0:30 ` Dave Taht 2021-01-11 6:23 ` Dave Taht 2021-01-11 12:55 ` [Galene] Multichannel audio [was: Congestion control...] Juliusz Chroboczek 2021-01-11 17:25 ` [Galene] " Dave Taht 2021-01-11 13:38 ` [Galene] Re: Congestion control and WebRTC [was: Logging] Juliusz Chroboczek 2021-01-11 15:17 ` Toke Høiland-Jørgensen 2021-01-11 17:20 ` Dave Taht 2021-01-12 1:38 ` Juliusz Chroboczek 2021-01-10 15:17 ` [Galene] Re: Logging Juliusz Chroboczek
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style List information: https://lists.galene.org/postorius/lists/galene.lists.galene.org/ * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=87mtxj789e.wl-jch@irif.fr \ --to=jch@irif.fr \ --cc=galene@lists.galene.org \ --cc=toke@toke.dk \ --subject='[Galene] Re: Logging' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox