[BUG] Ungraceful handling of port conflicts for the backend server
brandonbloom opened this issue · comments
via @coderberry
If the backend, gui, or syslog ports conflict, the backend fails without any good way of communicating this to the user except in the exod logs.
We currently binding 4000 (daemon tcp) and 4500 (syslog udp) by default, which are probably very likely to conflict. 3000 is also bound, but not in release builds.
@BenElgar what do you think about binding 0
to allow the OS to assign a port & then we cache that in our state file? I think that should be safe for the syslog/supervisor needs (though it should report a sensible error if the port is not set by the daemon). I worry about the daemon running on a random port though, since then users can't easily share urls between machines.
Aside: I wonder if we can configure DNS SRV records so that users can go to something like https://exo.localhost
or https://local.exo.deref.io
or something like that.
Binding to 0 seems reasonable to me — though I think I'd prefer just binding to a much less common port. That would mean that our URLs were stable.
It's my understanding that no mainstream browser supports DNS SRV records but, even if they did, I'm not clear on how they would help us. Every solution to the port number problem I can envision involves either running some other service on some constant port (thus defeating the point) or relying on some centrally hosted service (thus breaking the offline functionality).
Partial fix here: #430