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

StackOverflow https://stackoverflow.com/questions/1032006

  •  06-07-2019
  •  | 
  •  

Question

Is it 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.

Was it helpful?

Solution

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:

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

OTHER TIPS

UPDATE 10/17/2012: This functionality now exists in Chrome Stable v22. In order to use this functionality in Chrome, one must enable two flags in chrome://flags:

  • Enable MediaStream
  • Enable PeerConnection

Then you can visit the AppRTC Demo Page to try out the demo. See the WebRTC - Running the Demos page for more detailed instructions on setting up Chrome to use the peer to peer functionality and enabling device capture.

UPDATE: The engineers at Ericcson Labs have a proof of concept in a WebKit build that does HTML5 Peer to Peer Conversational Video.

They have demonstrations in their blog of the technology in action, as well as diagrams and explanations on how the technology will work.

They are working on getting this stabilized and committed to the WebKit repository.

Yes, finally.

As of this writing (2017), WebRTC is now a standard part of most modern browsers (around 70% of those in use), and allows for multimedia streaming, peer-to-peer, and hole-punching.

Docs, sample code, and live examples for WebRTC can be found at html5rocks.com.

According to caniuse.com and html5rocks.com, the following browsers support WebRTC:

Full support: Edge 14, Firefox 22, Firefox Android 55
Partial support: Android Browser 56, Chrome 20, Chrome Android 29, Edge 12, Firefox 17, Opera 18, Opera Android 20, Opera Mobile 12, UC Browser Android 11.4
Future support (Q3 2017): Chrome for iOS 11, Safari 11 for iOS 11 and OS X 10.11
No support: IE, IE Mobile, Opera Mini

The saturation rate of WebRTC is limited on Apple devices, since Safari 11 is not yet released and requires iOS 11 or OS X 10.11. Though projecting from past upgrade trends, WebRTC should be available on around 75% of iOS devices by 2018, and 100% by 2020.

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 by 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).

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)

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

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top