Thomas Eizinger

> Customer reporting this still to be an issue. If we buffer the connection intent I _think_ that would solve it, assuming the underlying TCP connection is able to get...

> Wondering if it just makes sense to extend the idle timeout to something like 8 hours for desktop clients and gateways. That should solve this issue immediately and the...

SGTM. If the keep-alive doesn't fix it or they don't want to use it, we can implement an configuration value for the idle connection timeout?

I have no idea what is going on with the perf tests. Why would this suddenly be slower than us depending on it? Upstream has a different LTO setting (`true`...

> Hmm I need to think about this one. I'm not sure it is good to completely detach from upstream here. Last time we talked about this you agreed to...

> If we're likely to vendor other deps, can we have those under a `rust/vendored` subdir? My question would be, at what point does a vendored dependency become so modified...

> Curious to hear @thomaseizinger's thoughts on this. I had a similar idea. Depending on how many different DNS servers we have, with #6181 we are now sending a lot...

If this is the problem, then this issue can also come up if a customer has many gateways and it might present a problem for https://github.com/firezone/firezone/issues/6109 where we would talk...

The DNS servers may not be the bottle neck here. Instead, we should maybe allocate a new socket for each relay (which will give us different server-reflexive addresses for each...

> Careful not to spam this - might to limit it to 1x per week. Show a badge next to the gateway too?