Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[BUG] Ungraceful handling of port conflicts for the backend server #428

Open
brandonbloom opened this issue Oct 19, 2021 · 3 comments
Open
Labels
bug Something isn't working

Comments

@brandonbloom
Copy link
Member

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.

@brandonbloom brandonbloom added bug Something isn't working needs triage Incoming request that needs to be triaged and prioritized labels Oct 19, 2021
@brandonbloom
Copy link
Member Author

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.

@BenElgar
Copy link
Contributor

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).

@brandonbloom
Copy link
Member Author

Partial fix here: #430

@brandonbloom brandonbloom removed the needs triage Incoming request that needs to be triaged and prioritized label Oct 20, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants