Thomas Eizinger
Thomas Eizinger
> I suppose that could fail if there is a network partition and since the resolution is centralized it would affect all users. > > Would it not be more...
> My assumption would be that a name resolution in the portal per-request would hit some local DNS cache and thus is not very expensive. Resolution for this: Hardcode the...
> When you send an invalid message the channel process (used to `join` the topic) dies so all it state is erased. In such cases you need to re-send the...
> @thomaseizinger does the connlib already handles those messages? We can try to fix them on portal end and kill both processes when one dies but it would be pretty...
> For unknown message types, I think it would be overall more resilient if you could just ignore those and not crash the process. Is that feasible? I am open...
Another downside of the current design (and an upside of what is proposed here): Currently, we don't run any static-analysis on the `tun_android.rs` code because it is cfg'd to `android`...
I still need to test this on an actual device.
Draft PR for reference: https://github.com/firezone/firezone/pull/4697
With the changes proposed in https://github.com/firezone/firezone/issues/4548, we can actually detect our NAT status early, i.e. before the first connection because we already receive a list of relays in `init`.