afterconnection

[bilo1967]

First of all: my knowledge of the timing of events in javascript is poor, so please accept my apologies if what I'm asking seems obvious (and sorry if I'm bombarding you with questions).

When a peer A handles the connection of another peer B via DataConnection.on('connection', function() {...}) is that connection ready inside the handler or does it become completely available after the event handler returns? I mean: may A send a data message to B like in this code?

peerA.on('connection', function(c) {
    // do something
    c.send("Welcome! (will this message ever got delivered?)");
    // do something else
});

In case this is not possible, wouldn't it be good to have an 'afterconnection' event to handle these cases? Or maybe the following code is expected to work?

peerA.on('connection', function(c) {
    // do something
    setTimeout(function() {
        c.send("Welcome! (will this message ever got delivered?)");
    }, 0);
});

Thank you.

[kidandcat]

It is ready to be used in the handler. I don't find very usefull an "start conneting" event. In which case do you find it useful for?

[bilo1967]

In the project I'm developing one problem is avoiding unwanted connections.

There are three roles: student, speaker, teacher (I've added a metadata flag indicating the role in the options array when registering the peer). The teacher connects to the server with his ID, which is known, and waits for the speaker and the student. Once they're all connected further connections must be avoided. The rejection you've implemented in v2.0.0 should do the job but it seems to me that the changes in the API are quite radical.

[kidandcat]

Yes, the new version is a mayor one (breaking, no backward compatibility). The old API is quite confusing, and the code has a lot of legacy tricks from its first days in 2013, it is very hard to maintain.

But as it is a breaking change, I'll continue supporting the old version, so I'll implement some way of rejection in v1. Anyway I recommend you to move to v2 if you don't need to support very old browsers. You will gain in stability and you will not need to host a PeerServer.

Rejection in v2 is not yet done, but I'm focusing on v2 development, so that feature will be ready soon.

[bilo1967]

I've given a look at the example you provided for v2 and it really looks impressive: a simple one-to-one chat in a few lines of code! Also, I've tweaked a little that code and I've seen that onRemoteStream is fired on each peer anytime someone joins the room, making it possible to handle all the media connection that your bandwidth may support: wow!!!

Just a few questions:

1. Will it be possible to distinguish who's connecting using a metadata feature like in v1?
2. Will I be able to access remote and local streams to do some (local) audio processing via AudioContext? In my project I've peer A who needs to hear pear B in the L-channel and C in the R-channel of his headset, and to change independently the volume of each of them; and both B and C need a vu-meter connected to their mic to continuously monitor if it's working proprerly (I've already implemented this features in part and need to keep them).
3. I've not tested the data channel but I guess it's the same as the media channel: a 1-1 connection between each peer with onDataStream fired at each connection? And messages will be sent individually to each peer?
4. Nice to hear that a peer-server won't be needed. However, what's that wss://broker.peerjs.com for?

P.S. I've seen that you've updated the roadmap planning to add a maximum number of peers per room and that is something I really need!

[kidandcat]

1. Will it be possible to distinguish who's connecting using a metadata feature like in v1?

Yes! I've just added that feature to the plan, it should be very easy to implement

2. Will I be able to access remote and local streams to do some (local) audio processing via AudioContext? In my project I've peer A who needs to hear pear B in the L-channel and C in the R-channel of his headset, and to change independently the volume of each of them; and both B and C need a vu-meter connected to their mic to continuously monitor if it's working proprerly (I've already implemented this features in part and need to keep them).

You already have access to the streams on the handlers. It is not well documented, but as you said you receive one remote stream per peer, and your own remote stream once, which is reused for all the connections right now, which may be changed in the future if needed.

Do you mean to process the streams before sending them? if so, it can be implemented too.

3. I've not tested the data channel but I guess it's the same as the media channel: a 1-1 connection between each peer with onDataStream fired at each connection? And messages will be sent individually to each peer?

Yes, you receive the raw dataChannels, one per peer connected. It will work well too with the metadata feature mentioned above.

4. Nice to hear that a peer-server won't be needed. However, what's that wss://broker.peerjs.com for?

PeerJS needs a channel to do the initial signaling. But now instead of using a PeerServer, all the logic is made by PeerJS library itself, and it only needs a MQTT broker. So you still need a server, but MQTT is a standard protocol, so you only need to setup a broker, also it doesn't need a database or anything is saved in the server memory (like in v1) so it is completely scalable.

[bilo1967]

Great news! I think I'll definitely switch from v1 to v2. It will make everything much easier. Thank you very much!

[shivarajnaidu]

Thanks for amazing library