P2P API Discovered in Latest Builds of Chromium | Hacker News Reader

P2P API Discovered in Latest Builds of Chromium

readwriteweb.com

49 pointsabraham27 comments

The p2p api is really the libjingle used in Chrome Sync, which is used to sync your Chrome/Chromium bookmarks and stuff. And it was introduced to Chrome/Chromium many years ago. If you checked your Chromium error log you can see lots of lines says p2p error.

The real news is now the p2p functionality shows a possible Javascript interface[1] to be used in Chromoting[2]

I guess the next step would be handcraft XMPP envelopes in Javascript. Each browser instance you open on any device would be indentified as a JID/resource string.

[1]: http://code.google.com/p/chromium/issues/detail?id=41776

[2]: http://code.google.com/p/chromium/issues/detail?id=51198

Nope, it's very new and unrelated to libjingle, check this post with links to the commits. Those are real p2p udp sockets:

http://news.ycombinator.com/item?id=2315908

"If NaCl gains enough traction, Chrome could become the next IE6."

Since Chrome and NaCl are both Open Source and Auto Updating, this has to be the dumbest analysis ever.

I hope this is related to an idea I floated about 1.5 years ago on the WHAT-WG working group. Given how mature node.js and evented servers have become this makes even moar sense than it did when I originally tossed the idea about. http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-Jan...

Is there any indication what this API could be useful for? The article really only talks about NaCl in depth.

What does an P2P-API do? Surely, all you need for a P2P application/protocol is a WebSocket. If you invent a new app for P2P you'd want to tailor it to your specific need, no?

Websockets are only useful to talk to a server. At last year google io presentation, they said people wanting to play an html5 game or do a voip call shouldn't have to use a server, especially if they are in the same room. They should be able to connect directly to each other.

More info here:

http://peter.sh/2011/03/css-quotes-mock-ups-of-the-html5-dat...

http://src.chromium.org/viewvc/chrome?view=rev&revision=...

http://www.whatwg.org/specs/web-apps/current-work/multipage/...

Why are websockets only useful to talk to servers? Why wouldn't the be good for p2p?

I don't believe you can open a websocket directly to another user. At least without the use of a server relayer.

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?

You can't run a Websocket server on your browser. Only a client. So you can't get p2p by definition because in a p2p network every node is a server.

Why wouldn't you be able to run the browser as a websocket server? A browser can run everything on a computer a p2p node can.

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.

With the current spec, how would you listen for connections?

The same way that websocket servers currently listen for connections. There are websocket servers in production and they have a standard way to listen for connections. All you would have to do is implement that same functionality.

I don't doubt you can implement that functionality, if you were the browser. But from the specs of Websocket currently in the browser, you cannot.

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.

You can read about it on Wikipedia: http://en.wikipedia.org/wiki/WebSockets Read the API spec: http://dev.w3.org/html5/websockets/ Read the draft protocol spec that was implemented by some browsers, but later pulled due to security concerns: http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol-... And read the current working draft: http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketproto...

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

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.

Because websockets, by definition, can only connect to the same domain as the page was served from (or another domain that opts in using CORS), websockets do not speak raw TCP but instead a special protocol that is designed to not allow them to trick browsers into accessing services that aren't expecting the browser to connect to them (such as using websockets to connect to SMTP servers and send spam, unbeknownst to the user), and because websockets can only be used for connecting from the browser to a server, not for listening for incoming connections.

Don't be fooled by the name. Websockets are not a general socket interface in the web browser. It is simply an API and protocol for establishing a persistent, bidirectional communication channel between the browser and the server in order to better support applications like chat, notifications, live editing features, and the like, without having to resort to COMET techniques like polling, long-polling, and so on.

XHR is restricted by domain and yet browsers provide APIs for extensions to get around this. Just be cause the spec specifies a browser/client <-> server design does not mean that browsers can't also be the server.

And that API could be extended to support p2p design patterns if browsers decided to do so.

Ah. I thought that you were talking about what you could do with the websocket spec as it exists, but you actually seem to be talking about what you could do with some hypothetical future websocket spec.

Yes, it might be possible to extend the websocket spec to handle peer-to-peer applications. But that would be difficult, and would not fit well with the purpose it is designed for, which is creating a persistent, bidirectional communication channel between the browser and the server, securely, in such a way that it can't be used to subvert the user's browser to do malicious things.

The big issue is that when you browse to a web page, the assumption is generally that any scripts on the page should be able to communicate back to the server it came from, or possibly other servers that explicitly opt in, but not to arbitrary other machines on the internet. And even connecting back to the same server, you need to be careful not to allow the script to talk to services that don't expect a (possibly malicious) third-party script to be communicating with them from the user's machine.

The websocket API and protocol are carefully designed to prevent these sorts of problems without the user having to intervene and understand what's going on. If you tacked a peer to peer protocol on, that would add a lot of complexity (since you'd also need to add some sort of peer discovery, NAT traversal, firewall configuration, and the like), and make it even harder to guarantee these properties. Essentially, adding peer to peer support in the browser requires you to solve so many extra problems that it doesn't really make sense to think of it as an extension to websockets, but instead just do it as an entirely different standard.

There's not much detail in the RWW article, but take a look at the link to a thread I started on the WHAT-WG mailing group in Jan 2010. In it I cite a real-life potential use case for P2P in the browser.

Take a look at this spec http://www.whatwg.org/specs/web-apps/current-work/multipage/...

Reply on news.ycombinator.com