search

peers / peerjs

Simple peer-to-peer with WebRTC.
https://peerjs.com
MIT License
12.48k stars 1.43k forks source link

Bidirectional Streams? #9

Closed simonlast closed 11 years ago

simonlast commented 11 years ago

When peer 1 connects with peer 2, both update their peer.connections object, but I was only able to get peer 1 to actually send peer 2 data. Peer 2 would not send data to peer 1. After manually connecting peer 2 to peer 1, the situation reverses: peer 1 cannot send messages to peer 2, but peer 2 can send messages to peer 1.

These streams are supposed to be bidirectional, right?

ericz commented 11 years ago

That should definitely not be happening. Do you see the same behavior on http://cdn.peerjs.com/demo/chat.html?

simonlast commented 11 years ago

Yeah, It's the same for me. Here are the exact steps I'm taking:

Peer 1: peer.connect('Peer 2 ID'); Peer 1: peer.connections['Peer 2 ID'].send('hello'); //works properly Peer 2: peer.connections['Peer 1 ID'].send('hello'); //doesn't do anything

michelle commented 11 years ago

I've seen this before--it happens when one peer does not receive all of the ice candidates of the other. But as Eric said, this should not be happening anymore.

Could you paste the logs from the console on both peers when trying to connect on http://cdn.peerjs.com/demo/chat.html?

simonlast commented 11 years ago

Sure!

Peer 1:

PeerJS:  Socket open peer.js:751
> peer.connect('75avj2e30mpzm2t9');
PeerJS:  Creating RTCPeerConnection peer.js:751
PeerJS:  Listening for ICE candidates peer.js:751
PeerJS:  Listening for `negotiationneeded` peer.js:751
PeerJS:  Creating data channel peer.js:751
DataConnection {_events: Object, _options: Object, open: false, id: "fwdh6ly7pvmzehfr", peer: "75avj2e30mpzm2t9"…}
PeerJS:  `negotiationneeded` triggered peer.js:751
PeerJS:  Created offer peer.js:751
PeerJS:  Set localDescription to offer peer.js:751
PeerJS:  Received ICE candidates peer.js:751
PeerJS:  Set remoteDescription: ANSWER peer.js:751
PeerJS:  Added ice candidate peer.js:751
PeerJS:  Data channel connection success peer.js:751
> peer.connections['75avj2e30mpzm2t9'].send('hello'); //this works
    undefined

Peer 2:

PeerJS:  Socket open peer.js:751
PeerJS:  Creating RTCPeerConnection peer.js:751
PeerJS:  Listening for ICE candidates peer.js:751
PeerJS:  Listening for `negotiationneeded` peer.js:751
PeerJS:  Listening for data channel peer.js:751
PeerJS:  Added ice candidate peer.js:751
PeerJS:  Received data channel peer.js:751
PeerJS:  Set remoteDescription: OFFER peer.js:751
PeerJS:  Created answer peer.js:751
PeerJS:  Set localDescription to answer peer.js:751
PeerJS:  Received ICE candidates peer.js:751
PeerJS:  Added ice candidate peer.js:751
PeerJS:  Received ICE candidates peer.js:751
PeerJS:  Data channel connection success peer.js:751
> peer.connections
    Object {fwdh6ly7pvmzehfr: DataConnection}
> peer.connections['fwdh6ly7pvmzehfr'].send('hello'); //this does nothing
    undefined
michelle commented 11 years ago

Awesome, thanks :). I will see if I can reproduce it. You're on latest Canary, using two tabs?

simonlast commented 11 years ago

Yup!

On Thu, Feb 14, 2013 at 4:26 PM, Michelle Bu notifications@github.com wrote:

I will see if I can reproduce it. You're on latest Canary, using two tabs?

Reply to this email directly or view it on GitHub: https://github.com/peers/peerjs/issues/9#issuecomment-13579466

whytheplatypus commented 11 years ago

I wound up just treating it like readonly writeonly streams and opening a connection back on a "connection" event It's up and running here

in some ways this might be considered a feature rather than a bug? Although I can't think of a good use case off the top of my head.

michelle commented 11 years ago

That's really weird. I still haven't been able to reproduce this single directional connection bug. Any more details on OS, exact Chrome build, etc?

The fact that the 'Data channel connection success' message logs means that the DataChannel is in the open state, at which point the transfer of data is no longer in PeerJS's control. That being said, you guys should try out some of the other demos, like 'http://sharefest.peer5.com/' that DON'T use PeerJS to see if you have similar issues.

Edit: Actually there's very few 2-way DataChannel demos that would actually test this kind of functionality, but it seems that similar one-way problems are happening with WebRTC media streams as well, so we'll just keep up to date with commit logs and see what happens.

michelle commented 11 years ago

@whytheplatypus We just tried it and it works! Cool stuff. I also cloned it myself and took out the extra connection when a 'connection' event is fired. This also worked for me, so this is still a pretty weird bug.

whytheplatypus commented 11 years ago

Little more info on the bug:

Uncaught Error: InvalidStateError: DOM Exception 11 peer.js:1315
(anonymous function) peer.js:1315
fr.onload peer.js:795

it looks like this has something to do with self._dc.send(str); but I haven't dug deep enough to know what yet. Oh this is also with running a local PeerServer.. no idea if that makes a difference.

glad you liked the chat thing :P this stuff is so much fun to work with

michelle commented 11 years ago

@whytheplatypus Does the 'open' event on that connection object ever fire? What is connection._dc.readyState? Using a local PeerServer should not matter. I actually just ran some connection speed benchmarks today using the latest version of the server on npm and the connections seemed to be just fine.

It seems to be happening to only a handful of people; really wish I could repro.

simonlast commented 11 years ago

Could it be due to firewalls?

whytheplatypus commented 11 years ago

Alright well it looks like there's no bug after all.. at least for me.. I just wasn't listening for the data event in the right place. There's no new 'connection' event on the peer that called peer.connect(id) so it wasn't listening for any 'data' events.

adding

conn.on('data', function(data){
  //code
});

after 

var conn = peer.connect(id);

was all that I needed...

michelle commented 11 years ago

Glad to hear it :)

michelle commented 11 years ago

I believe this is just due to firewalls and is not a bug in PeerJS, so I'm closing this for now.

pfifo commented 7 years ago

I see this is a really old issue, however this problem is occuring for me on the official chat demo http://cdn.peerjs.com/demo/chat.html

Chromium Version 58.0.3029.110 Built on Ubuntu , running on Ubuntu 16.04 (64-bit)

I have a standard NAT setup, and can get bidirectional data working just fine with WebRTC itself.

Edit: I was just thinking this could be an issue with Peer 1 sending to my local private IP address, and peer 2 trying to send to my public IP address that has not been hole punched yet. Just a thought.