|
Ah. I thought that you were talking about what you could do with the websocket spec as it exists, but you actually seem to be talking about what you could do with some hypothetical future websocket spec. Yes, it might be possible to extend the websocket spec to handle peer-to-peer applications. But that would be difficult, and would not fit well with the purpose it is designed for, which is creating a persistent, bidirectional communication channel between the browser and the server, securely, in such a way that it can't be used to subvert the user's browser to do malicious things. The big issue is that when you browse to a web page, the assumption is generally that any scripts on the page should be able to communicate back to the server it came from, or possibly other servers that explicitly opt in, but not to arbitrary other machines on the internet. And even connecting back to the same server, you need to be careful not to allow the script to talk to services that don't expect a (possibly malicious) third-party script to be communicating with them from the user's machine. The websocket API and protocol are carefully designed to prevent these sorts of problems without the user having to intervene and understand what's going on. If you tacked a peer to peer protocol on, that would add a lot of complexity (since you'd also need to add some sort of peer discovery, NAT traversal, firewall configuration, and the like), and make it even harder to guarantee these properties. Essentially, adding peer to peer support in the browser requires you to solve so many extra problems that it doesn't really make sense to think of it as an extension to websockets, but instead just do it as an entirely different standard. |