Abstracting the transport layer
gurupras opened this issue · comments
The entire set of timing* libraries that you have created have been extremely easy to use and get media synchronization up and running. However, I'm wondering if it would be possible to abstract out the WebRTC aspect of this.
I'm happy to try and contribute in this area, but I'm new to typescript and rxjs so it's going to be a pretty steep challenge for me 😕
Hi @gurupras, I'm actually working on this already. I realized that a package with the generic name timing-provider should not really depend on my service. At least not without an option to change it. I would love this to become a package which can be used with many different backends/strategies to synchronize the vector.
If possible can you talk a bit about your use case and what you want to use as a replacement?
I'm assessing the ease of video synchronization using this package. Setting up a simple demo was extremely easy. I did run into some puzzles with seek, but I'm working on that.
My issue with WebRTC is that many universities and work places block UDP and WebRTC(?). It's also possible that I've misconfigured my STUN/TURN servers and/or the WebRTC configuration.
Regardless, in large 'rooms', it might not be feasible to have a participant's browser connect to every other participant present in the 'room'. In such cases, a backend-based model is preferable, where the backend takes on the responsibility of dealing with all of the connections and passing messages across.
I think that WebRTC blocking became less usual lately because WebRTC is so ubiquitous by now. But that's just my personal assumption. In case UDP is blocked WebRTC can also use a TCP connection if necessary. But you're right the more clients you have the more likely it gets that there will be at least one which has problems. But a TURN server should usually solve these problems.
I think switching to a WebSocket comes with other tradeoffs. It's for example a single point of failure and doesn't scale very well.
Long story short, I still believe that making the network layer swappable is a good idea. I just need to find some time to do it ... :-)