[abraham]

> 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?

[lambda]

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.

[abraham]

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.

[lambda]

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.

[abraham]

Of course I'm talking hypothetical. The original article is about an experimental p2p feature in an open source browser that is several months at a minimum from even being in a beta release of Chrome.