Ignoring messages that are not directed to each participant in a call is required when broadcasting to a room

[magestican]

Ignoring messages that are not directed to each participant in a call is required when broadcasting to a room

[nathanoehlman]

Hi @magestican - that'd definitely make sense.

A lot of the functions across rtc-quickconnect do perform a check to see whether a message is intended for them or not - for instance the a peer will ignore /ready messages from the signaller unless it comes from a peer with the expected peer id (see https://github.com/rtc-io/rtc-tools/blob/master/couple.js#L209) - however this is done at each peer (which means you will still be sending more messages than needed), as opposed to at the switchboard itself - where it probably should be done.

What messages in particular were you having trouble with? I can add in checks where they don't already exist to rtc-quickconnect and rtc-tools to discard messages that shouldn't be handled.

And are you using the rtc-switch as the basis for your switchboard design, or is it a custom implementation?

Cheers,
Nathan

[magestican]

What I am seeing is /ready messages being passed around randomly by peers who are already connected, probably in response to messages which were not intended for them which is why this issue arouse in the first place.

I have put together rtc-quickconnect, rtc-capture, rtc-swtich and rtc-signaller-socket.io.
I built the extra requirements we had for distributed network of servers on top of rtc-switch with socket.io if this answers your question.

No custom implementation or modification of any of your libraries has taken place.

[nathanoehlman]

Hi @magestican - thanks for that info.

I've tried to replicate using the same rtc-quickconnect, rtc-switch, and rtc-signaller-socket.io stack and I can't get the behaviour you've indicated to occur.

The example test I was using is at https://github.com/rtc-io/rtc-signaller-socket.io/blob/long-poll-example/examples/client-manyclients.js - /ready messages only get exchanged as expected, and /ping messages get sent only according to the /to message target.

Even if they do receive an unxpected /ready message, they should do the following behaviour:

1. If it's from a peer that it was not expecting a ready message from, the message will be discarded
2. If it's from a peer that it is listening for a ready message from that peer but it has already received a ready message from that peer, then the targetReady property should be set, and the message will be discarded
   (https://github.com/rtc-io/rtc-tools/blob/master/couple.js#L209)

In addition, rtc-switch should by default only send /to/ messages on to the peer that is targeted, otherwise the message should be dropped and not rebroadcast (https://github.com/rtc-io/rtc-switch/blob/master/index.js#L48)

I'm kind of stumped as to what could be happening. Without being able to replicate it, I'm at a dead end for the moment.

A few more questions:

• What versions of the various rtc-* libraries are you using?
• Is there any chance that the erroneous behaviour is being caused by the distributed network of servers?

If you've got any more data that could help in debugging, that'd be greatly appreciated (ie. websocket logs - a reproducible test case that replicates the error would be ideal)

Cheers,
Nathan

[magestican]

Nathan thanks for the response, I am currently using the latest version of quickconnect and i dont see this issue