Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

PeerJS — True peer-to-peer data in the browser

peerjs.com

Post reply on HN
Print view View original

21–28 of 28 posts

Re: PeerJS — True peer-to-peer data in the browser

#21

Post by venomsnake »

jonknee wrote: post #18
venomsnake wrote: post #5

Is a torrent client for iOS finally possible with that? One that runs in the browser and will piss off apple.

Kind of hard when you can't store to the filesystem.

Direct torrents no, but you can rename the pieces *.fll and download them and send them to registered app for that extension that combines them ... you will have problem with seeding though, but that is also something that can be solved with a little tweaking of the protocol. I think the hacker community has shown that they can scare you with their inventiveness when they work in (stupidly and unnecessarily in that case) constrained environment.

Re: PeerJS — True peer-to-peer data in the browser

#22

Post by jonpaul »

Hupo wrote: post #17

Looks like a nice little library, and very relevant to my interests. My personal "dream scenario" is to have true multisource P2P video streaming in the browser with no extensions required - with WebRTC, this seems quite feasible as implementations mature.

Check out Holla.js for that: https://github.com/wearefractal/holla

Re: PeerJS — True peer-to-peer data in the browser

#23

Post by muyuu »

jonpaul wrote: post #22
Hupo wrote: post #17

Looks like a nice little library, and very relevant to my interests. My personal "dream scenario" is to have true multisource P2P video streaming in the browser with no extensions required - with WebRTC, this seems quite feasible as implementations mature.

Check out Holla.js for that: https://github.com/wearefractal/holla

Any video streaming demo?

Re: PeerJS — True peer-to-peer data in the browser

#25

Post by ericz »

silverlight wrote: post #3

Any reason not to offer support for the video side of things? A lot of the issues in terms of client IDs and whatnot are the same. It would be nice to have a single library that can establish a connection and then send either video ir data or both...

It's in the works!

Re: PeerJS — True peer-to-peer data in the browser

#26

Post by ericz »

huhtenberg wrote: post #7

> Note that no peer-to-peer data goes through the server; The server acts only to broker connections. Q1. Does this support connecting to a peer behind a NAT device? Q2. Does this support connecting two peers each behind its own NAT? Because a vast majority of real world cases will fall into either of these two categories.

ICE/STUN (which is used by WebRTC and thus PeerJS) support NAT traversal in all cases but a pair of symmetric NATs, which means some single digit percentage of connections will not work. For those cases, WebRTC/PeerJS support using a TURN server which proxies the data, not ideal but it allows the library to work.

Re: PeerJS — True peer-to-peer data in the browser

#27

Post by vr000m »

latitude wrote: post #15
vr000m wrote: post #13

Earlier quoted context omitted.

It uses SDP to exchange ICE candidates. At the moment the SDP tries to multiplex video/audio and SCTP (data channel).

Does WebRTC have any sort of extension mechanism whereby I can drop in my own version of NAT traversal logic? Speaking from past experience, STUN and ICE are OK, but they got the whole process fundamentally wrong. They let the clients drive the traversal process. This is substantially inferior to letting a dedicated mediating server do that instead. I did that with one of my past projects and it helped with connectin…

you can add one or more TURN server(s) into the mix, but apart from that there is no other way using just Javascript.

Re: PeerJS — True peer-to-peer data in the browser

#28

Post by vr000m »

ericz wrote: post #26
huhtenberg wrote: post #7

> Note that no peer-to-peer data goes through the server; The server acts only to broker connections. Q1. Does this support connecting to a peer behind a NAT device? Q2. Does this support connecting two peers each behind its own NAT? Because a vast majority of real world cases will fall into either of these two categories.

ICE/STUN (which is used by WebRTC and thus PeerJS) support NAT traversal in all cases but a pair of symmetric NATs, which means some single digit percentage of connections will not work. For those cases, WebRTC/PeerJS support using a TURN server which proxies the data, not ideal but it allows the library to work.

AFAIK, you will be/are able to add TURN server addresses to the mix. It is possible that chrome uses google's TURN servers by default.
Post reply on HN