Will Html5 Allow Web Apps to Make Peer-To-Peer Http Connections

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

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

Does HTML5 Support Peer-to-Peer (and not just WebSockets)

See the answers for Will HTML5 allow web apps to make peer-to-peer HTTP connections? However, the content in the WebSockets specification seems to have gone, so I suspect the answer now is "no".

Is it possible to create peer-to-peer connections in a web browser?

Opera Unite allows Peer to peer (basically gives your browser web server, file system and nat-traversal capabilities), but this is Opera only.

How can I make a browser to browser (peer to peer) connection?

Here on Stackoverflow are several topics about P2P connections in browsers:

Will HTML5 allow web apps to make peer-to-peer HTTP connections?
What techniques are available to do P2P in the browser?
Does HTML5 Support Peer-to-Peer (and not just WebSockets)
Can HTML5 Websockets connect 2 clients (browsers) directly without using a server (P2P)
Is it possible to create peer-to-peer connections in a web browser?
Do websockets allow for p2p (browser to browser) communication?
HTML 5 Peer to Peer Video Possibilities?
Is WebRTC implemented in any browsers yet?

As mentioned in most of the topicts, both 2008 HTML5 working drafts were having a section "Peer-to-peer connections":

http://www.w3.org/TR/2008/WD-html5-20080122/#peer-to-peer
http://www.w3.org/TR/2008/WD-html5-20080610/comms.html#peer-to-peer

Since the W3C Working Draft 12 February 2009 the section "Peer-to-peer connections" disappeared. But this P2P connection is not gone. It's back under the name PeerConnection within the WebRTC (Real-Time Communications) specifications:

http://dev.w3.org/2011/webrtc/editor/webrtc.html#peerconnection (W3C Editor's Draft)
http://www.whatwg.org/specs/web-apps/current-work/webrtc.html#peerconnection (Since 5th December 2011 forwarded to W3C Editor's Draft)

Since 31 October 2011, the W3C Editor's Draft is an official Working draft:

http://www.w3.org/TR/2011/WD-webrtc-20111027/#peerconnection

The only implementation of the PeerConnection (UDP based) exists in the modified WebKit by the Ericsson labs (May 2011), which is working quite well. Some patches are in WebKit now (Oct. 2011 -- see updates below!):

https://labs.ericsson.com/apis/web-real-time-communication/
https://labs.ericsson.com/developer-community/blog/update-webkit-contributions

Additionally, the WebRTC initiative is a project by Google, Mozilla and Opera. Thus, they are continuing the specification on PeerConnection:

http://www.webrtc.org/

Probably Chrome (uses WebKit) will be the first major browser supporting WebRTC with PeerConnection:

http://www.webrtc.org/blog/firststeptowardchromeintegration
http://groups.google.com/a/chromium.org/group/chromium-dev/browse_thread/thread/95bf1e2e1de852fc
https://lists.webkit.org/pipermail/webkit-dev/2011-November/018445.html

Since 18th January 2012, Chrome is supporting WebRTC as well. It can be uses in the Dev channel (Windows, OSX, Linux) and the Canary build (Windows and OSX) by enabling it under chrome://flags. It only only supports MediaStream like Video and audio and can be tested with several Demos. Transferring application data like String/ArrayBuffer/... is not supported until now.

Since 16th March 2012, the WebRTC Editor's Draft separates a "Peer-to-peer Data API" to send and receive generic application data (String, ArrayBuffer and Blob). Chromium wants to implement the Data API soon (10th April 2012).

On April, 3rd, Mozilla published a first working example on WebRTC for Firefox as well.

DataChannel is planned for version 25 of Chrome, behind a flag, meanwhile it can be tested in Firefox Nightly/Aurora (12th December 2012):

http://updates.html5rocks.com/2012/12/WebRTC-hits-Firefox-Android-and-iOS

2018: DataChannels are still experimental, but available in current versions of Chrome and Firefox:

https://developer.mozilla.org/en-US/docs/Web/API/RTCDataChannel

Allow only specific/official HTML5 Web Apps to connect to a Websocket host

There is really no way to do this directly because of the openness of code that runs in a browser. You can require APIkeys or some such thing, but if you're using those APIkeys from a browser, they are not a secret so anyone can discover them and use them from their own app.

The most common way sites deal with this is to require user authentication on your websocket connection (can often leverage webpage user authentication that may already have been done via a cookie that is already present). This obviously requires users to have an account on your service and to login to that account. Then, if you see misuse of a particular connection, you can ban that user's credentials from the service.

This does not prevent someone from setting up a rogue server process that uses their own credentials to use your API, but if you detect potential misuse, then you at least have a mechanism for locking them out (at least temporarily until they make a new account).

You can also make sure your service does not accept cross-origin requests. This prevents other browser-based applications from using your API directly from the browser. It does not stop a script (running outside the browser or on a server) from using your API.

You can create terms of service that allow you to ban any access that is not consistent with your terms. This is really just a legal backstop if needed, but doesn't prevent purposeful misuse.

You can build into your API some detection of abnormal usage patterns (such as someone attempting to harvest all data from your site) that would not normally be attempted by your regular client application. This could then lead to an account being flagged that a human might look into further and decide whether to notify or ban the account. Many services like Google services have rate limiting built into the site to keep one particular connection from using more than a fair share of server resources. That path is more of server-protection or load-protection-tactic rather than a prevent-unauthorized-use feature.

Another technique I've seen described which is a deterrent, but not actually used myself is to embed an everchanging code into each of your legitimate web-site pages that uses your API and require that code to be sent with all API requests. This prevents the API from being used entirely on it's own without first making a web page request to fetch the code. If the code itself is not directly embedded in the page, but instead is calculated with some Javascript based on some other things embedded in the web page, then it makes it even more work for a server process to scrape the code out of a web page request. The everchanging code then has some lifetime and your server can tell when it has expired. This is not true security because an enterprising developer can work around it by making a normal web request, getting the tokens needed to then calculate the current version of the everchanging code and to do that regularly to keep their code up to date. But, it does make it enough work that it's a deterrent to the more casual hacker trying to use your API.

And, if you see repeated abuse from a particular source, you can also block IP ranges from your service (at the risk of accidentally blocking some legitimate users too).

Do websockets allow for p2p (browser to browser) communication?

No. Browsers can only initiate WebSockets connections, not receive them. The W3C browser API spec only defines how to start an outbound connection.

You can make an application that would both initiate and accept WebSockets connections, but browsers do not do this.

You might look at Pusher App which you could use to build a WebSockets application with multiple clients. The service provides up to 20 simultaneous WebSockets clients for free (you can pay for higher scaling).

Update:

The WebRTC protocol and API is making rapid progress and allows a Data Channel to be established between two peers (you still may need a STUN/TURN server for the initial NAT traversal and setup).

What kinds of web apps might I want to build with the HTML5 Web Messaging spec?

I recently found a good use case for Web Messaging. Many web apps are starting to authenticate using Facebook, so they open another tab with a Facebook login and communicate with the its contents.

Got a better use case? If so, I'll unselect my answer.

Will Html5 Allow Web Apps to Make Peer-To-Peer Http Connections