Will HTML5 allow web apps to make peer-to-peer HTTP connections?

Question

This is probably a dumb question, but I have to ask it anyway. I'd like to know if it is at all possible to create a web app that, with the help of a central server, could create direct connections with other users of the same web app. I'm imagining a process similar to UDP hole punching.

I've read about the new WebSockets API in HTML5, but it appears you must initiate the connection with a WS-compatible server before the fully-duplexed connection can begin. I'm thinking moreso about a process to make direct connections between clients, with a server getting involved only in the initial handshake.

NOTE: Java applets don't count. I'm interested only in standard browser technologies.

Answer 1

Such peer-to-peer connection would probably be regarded as XSS (Cross Site Scripting) and will be blocked by browsers.

Answer 2

I don't think HTML5 is made for that, but I suggest you to look at Opera Unite

Answer 3

Instead of intelligent guesses, here is an informed answer:

HTML 5 plans to allow peer to peer connections from javascript, but these connections WILL NOT BE RAW TCP.

The complete spec can be found at http://dev.w3.org/html5/websockets/

jrh

EDIT: with specific reference to peer to peer connections, check out these links:

• Regarding peer to peer connections: http://www.w3.org/TR/2008/WD-html5-20080122/#peer-to-peer
• Regarding broadcast connections to the local network: http://www.w3.org/TR/2008/WD-html5-20080122/#broadcast
• Regarding TCP connections (in the encoded protocol): http://www.w3.org/TR/2008/WD-html5-20080122/#tcp-connections
• Complete proposed spec: http://www.w3.org/TR/2008/WD-html5-20080122/#network

Its important to note that the capabilities are still being negotiated. It will be nice to be able to create "local chat" web apps :)

jrh

Answer 4

Also: the problem with pure peer-to-peer problems is, they don't work through a NAT-router. To solve that, you need a server between those peers. Maybe you can use Opera Unite for that.

Answer 5

There are a number of reasons why this would be tricky:

1. Firewalls (even just plain NATs) would make this kind of connection difficult at a much lower protocal layer than even HTTP. With my IT security hat on, this seems like a wonderful way to open arbitrary ports on a machine, just by visiting a website - and so it would be aggressively blocked my virtually all corporate IT systems.
2. HTTP is inherently a client-server protocol. While it is reasonably easy to simulate duplex communications using long polling (as well as a couple of other techniques), it is not particularly efficient.
3. This would open a large hole for XSS attacks.

WebSockets is designed to solve the second of these issues, but (deliberately, I expect) not the other two. When they talk about peer-to-peer in the HTML5 spec, they are talking about full duplex communications between the server and the client, not between one client and another.

However, it would be simple to implement a proper network stack on top of websockets - with the proviso that all communication would still have to be done through the server. I have seen this done using long polling (a friend of mine at Uni wrote a full TCP/IP stack using long polling).

Answer 6

I second harshath.jr: you could very well have a server acting as a directory (exposing "origins" of each connected agent; origin being scheme+host+port as in draft-abarth-origin, with the scheme being either "ws" or "wss"). You could then initiate peer-to-peer WebSocket connections; the SOP being worked through thanks to CORS. Of course, this means that each agent (i.e. browser) would have to embed its own WebSocket server (à la Opera Unite).

In the mean time, do it the XMPP/IRC/etc.-way: no peer-to-peer connection but WebSocket connections to a central server (or network!) to pass messages to the connected agents (eventually using some specific WebSocket "subprotocol")

EDIT: note that all of this is actually outside the scope of HTML5 (all of those things were once part of HTML5 but have been split away into their own specs)

Answer 7

The Whole idea of Web Sockets was to solve the problems with Firewalls and proxies http://www.kaazing.org/confluence/display/KAAZING/What+is+an+HTML+5+WebSocket