Bidirectional Streams?

[simonlast]

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]

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

[simonlast]

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]

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]

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]

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

[simonlast]

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:
#9 (comment)

[whytheplatypus]

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]

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]

@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]

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]

@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]

Could it be due to firewalls?

[whytheplatypus]

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]

Glad to hear it :)

[michelle]

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

[pfifo]

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.