5 ms·
On principle we keep the server simple, echoing messages back and forth between clients. In practice it's quite hard for two browsers to connect directly to ea
by ianb 13y ago
On principle we keep the server simple, echoing messages back and forth between clients. In practice it's quite hard for two browsers to connect directly to each other, and while we want to support that kind of architecture in order to get it working we still need to simulate P2P using a server.
- derefr 13y ago> In practice it's quite hard for two browsers to connect directly to each other Isn't this the problem WebRTC abstracts away? Your server should just be a TURN server (http://en.wikipedia.org/wiki/Traversal_Using_Relays_around_NAT http://en.wikipedia.org/wiki/Traversal_Using_Relays_around_N...), shouldn't it?
- k__ 13y agoAFAIK WebRTC just works with the latest Firefox/Chrome and needs a STUN and/or a TURN server.
- ianb 13y agoWebRTC makes it possible, but not easy, nor abstracted. You still have very long connection strings to establish the connection, and those strings change as you move around, so it's not something we'd want to ask users to send to each other in order to establish a connection. The approach usually used is a server where the two people rendezvous to exchange the connection strings. That server is kind of like what we have – but then once it's in place, changing over to WebRTC just doesn't seem as exciting. (And even then the connections are slower to establish and less reliable than WebSockets.)