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

Run a separate STUN infrastructure server #3479

Closed
Tracked by #3842
abe-njama opened this issue Mar 21, 2024 · 5 comments · Fixed by holochain/holochain-infra#75 or holochain/holochain-infra#101
Closed
Tracked by #3842
Assignees
Labels
automation Continuous integration issues and other automation improvements

Comments

@abe-njama
Copy link
Collaborator

abe-njama commented Mar 21, 2024

Run a separate STUN infrastructure server so that it can keep running and connecting folks that are able even if our TURN server is overloaded / offline.

  • Pick a STUN server:
    • coturn venerable, but lightly maintained
    • eturnal fresh but written in erlang
  • DISABLE TURN IN THE CONFIG
  • Make it fast and reliable:
    • webrtc connection setup time is highly dependent on how quickly we get back the required data. I vote for redundant geosteered load balancing. Perhaps starting with two zones: America, and Euro, something like:
      • stun-1.holo.host geo steered load balance = [stun-1-america.holo.host, stun-1-euro.holo.host]
      • stun-2.holo.host geo steered load balance = [stun-2-america.holo.host, stun-2-euro.holo.host]
      • then set STUN config for RTC connections to ["stun:stun-1.holo.host", "stun:stun-2.holo.host"]
      • for a total of 4 stun servers
@steveej
Copy link
Member

steveej commented Apr 16, 2024

in light of holochain/sbd#20 this will become a no-op for existing deployments, as their existing coturn will subsequently only be used for STUN.

@neonphog
Copy link
Contributor

@steveej - this is not a no-op. please see the updated description.

@neonphog
Copy link
Contributor

@steveej - I'm pretty sure this got closed in error. From what I can tell there are no STUN servers separate from TURN servers. Happy to be wrong though : )

@neonphog neonphog reopened this Apr 25, 2024
@steveej
Copy link
Member

steveej commented Apr 25, 2024

thanks @neonphog, i indeed didn't intend to close this 😃

@neonphog neonphog mentioned this issue May 16, 2024
4 tasks
@steveej steveej added the automation Continuous integration issues and other automation improvements label May 23, 2024
@steveej
Copy link
Member

steveej commented May 24, 2024

as a first step, two URLs for STUN are now available at stun:stun-0.main.infra.holo.host:443 and stun:stun-1.main.infra.holo.host:443. they both point to the same coturn instance as of now. it allows us to put both in the default conductor configurations already before having the infrastructure fully built out.

in addition to successfully testing with https://icetest.info/ i also ran the following simple test:

$ nix shell nixpkgs#stuntman --command stunclient stun-0.main.infra.holo.host 443
nix shell nixpkgs#stuntman --command stunclient stun-1.main.infra.holo.host 443
Binding test: success
Local address: 192.168.24.192:36616
Mapped address: 80.218.43.120:24265
Binding test: success
Local address: 192.168.24.192:47718
Mapped address: 80.218.43.120:37638

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
automation Continuous integration issues and other automation improvements
Projects
Status: Done
3 participants