I'm not all that familiar with the websocket specification but isn't it pretty much just TCP connections? In which case p2p would be very similari to say TCP bittorrent?
No, it's not a TCP connection. It is a persistent, bidirectional communication channel, initiated by the browser, which uses its own protocol on top of TCP. It is basically designed to just be better than AJAX and COMET for things that need long-lived bidirectional communication between the browser and server; it is not intended to be a general purpose TCP API.
> No, it's not a TCP connection. It is a persistent, bidirectional communication channel, initiated by the browser, which uses its own protocol on top of TCP.
So it is a TCP connection. It may have its own protocol on top of TCP but as long as the browsers can create TCP connections between each other then then it can be made to work right?
Yes, it is a TCP connection in the sense that it is its own protocol on top of TCP. But then again, the HTTP request that you make with an XMLHTTPRequest call also uses a TCP connection; however, the mere fact that it creates a TCP connection doesn't mean you can implement a web server using XMLHTTPRequest.
The key is that websockets are limited in what they can do; the API and protocol are fundamentally designed in such a way as to make peer-to-peer communication impossible. It opens up possibilities that XMLHTTPRequest does not, but it does not allow you to do everything you could do with raw socket access.
There main reason it is impossible to do peer to peer with websockets is that you can't listen for incoming websocket connections using the websocket API; you can only initiate outbound connections, which connect to a server not written in a browser, as there are no APIs in the browser for listening for inbound connections.
The websockets speck is still in draft. Nothing is impossible and there is no reason a browser could not implement their own extension of websockets to enable p2p. Have some imagination.
I thought you were talking about websockets as it exists today, not some hypothetical future extension. See my reply in the other thread about why that might not be a good idea.
In the WebSocket spec, it only exists to open a connection to a url on a port, there is nothing about listening to a port for connections. You could open a connection to a server which can relay other websockets data, but you can't open a connection to another client. There is nothing in the spec to create a server basically.
That doesn't make any sense. The browser server just responds to websocket requests the same way a server would. The other browsers acting as clients wouldn't even need to know it was a browser just that it was acting as a websocket server.