search

yjs / y-webrtc

WebRTC Connector for Yjs
MIT License
448 stars 109 forks source link

add STUN/TURN servers after the provider is made #45

Closed catdevnull closed 1 year ago

catdevnull commented 1 year ago

services like metered.ca require using an API to get the STUN and TURN servers. the problem is that waiting for the API to respond adds unnecessary latency to syncronizing with other peers which might not need TURN.

being able to add servers after it has been created solves this.

dmonad commented 1 year ago

y-webrtc is based on simple-peer. You can add configurations for simple-peer using the peerOpts configuration. This also allows you to configure STUN and TURN servers.

https://github.com/yjs/y-webrtc/#api

dmonad commented 1 year ago

Changing STUN and TURN servers after the provider has been created doesn't make a lot of sense when a connection has already been established. However, you can change the configuration for all future connections using the provider.peerOpts property.

catdevnull commented 1 year ago

yes, i know about peerOpts but i don't want to edit it after the fact precisely for that problem. isn't there any way to update existing connections or force reconnect all non-functioning connections, or at least force reconnect all connections?

dmonad commented 1 year ago

WebRTC is such a weird tech that it is even hard to detect broken connections. It's unrealistic that we will be able to switch connection properties after the fact or while connections are establishing. In any case, the payoff is not worth the trouble. If you are worried about the delay because your request is asynchronous, you can preload your connection info.

catdevnull commented 1 year ago

it's not even necessary to check for broken connections. switching connection properties is most certainty possible through setConfiguration .

If you are worried about the delay because your request is asynchronous, you can preload your connection info.

but if we're offline or in a subway, fetching the API will just take a ton of time and/or timeout. in the subway it doesn't matter because there's no local peers anyway, but things like a dwebcamp or others in which a local network works fine while connection to the internet might be spotty means that the local-first experience is degraded (it won't start connecting to local peers until it timeouts.)

catdevnull commented 1 year ago

hackily worked around it through https://gitea.nulo.in/Nulo/schreiben/commit/866fbfd7ec2533acc48e642c75ba0fa90694dafb. not ideal, hopefully this issue is reopened so an official API is made.