New members also receive onPeerJoin event

[andres-kovalev]

Hi there,

Looks like new joiners also receive onPeerJoin event for every old peer. With the example code below:

console.log('joining...');
const room = joinRoom(
  { appId: 'app', password: 'password' },
  'chat_root'
);

room.onPeerJoin((peerId) => {
   console.log('joined', peerId);
});

room.onPeerLeave((peerId) => {
  console.log('left', peerId);
});

When two peers join the room they see the following in their console:

// first peer
joining...
joined second_peer_id

// second peer
joining...
joined first_peer_id

Because of this there is no way to find out who is the new peer and who is the older one - both peers consider themselves as first peer.
Also, because of this the following example code from the docs doesn't make much sense:

...
// we don't need to call this one because the onPeerJoin subscription below will do the same work
// since newjoiner have it triggered for every old peer in the room
sendName('Oedipa')

room.onPeerJoin(peerId => sendName('Oedipa', peerId))
...

Is this behaviour expected?

[dmotz]

I think this might be a misunderstanding about what onPeerJoin means: it simply indicates "a new peer has connected to you". I think maybe the confusion arises from the notion of a room. Since there is no central server keeping track of state, there is no persistent notion of a room and no sense of "who joined first" — Trystero is just facilitating direct peer to peer connections between users and the idea of a room is just so they can find each other via a common name. The same set of peers will all connect to each other in different orders so again there's no concept of a "first peer", it's dependent on each peer's frame of reference.

The sendName example works because whenever you connect to a new peer, you immediately send your name to them, and they immediately send theirs to you (note the second peerId argument which only sends to a single peer).

Does this clear things up? Is there a use case you have that's limited by this?

[andres-kovalev]

Thanks for the quick response.

It makes perfect sense and I understand the room is something virtual. I just expected Trystero abstracts it under the hood and gives me something like real room interface with all the features. I think I was confused because of two things:

1. Method room.getPeers() makes me think there is a way to get a full list of a room, but in fact this method returns a list of peers I already connected via the same room (it returns empty array when called right after calling joinRoom())
2. By some reason I thought the example in the doc I recommends me to call sendName() right after making a room to notify "everyone in the room" when in fact it won't take any effect at that moment

Now I understand that room.onPeerJoin(id => sendName(myName, id)) does the thing.

WDYT, maybe it worth mentioning in the doc? I mean, for the getPeers() method the description may look like "Returns a map of RTCPeerConnections for the peers we have connections established present in room". And for the targetPeers argument it worth to change it to "Either a peer ID (string), an array of peer IDs, or null (indicating to send to all peers in the room we have connections established at the moment).

UPD
BTW, maybe you have an advice for my case - I would like to implement something like p2p chat and at the moment I'm try to fix the name collision issue. Initially, I was thinking about rejecting new peers in case their name is already taken by someone who is in the room already. But looks like I can't do that)

[jlcvp]

@andres-kovalev What I'm experimenting in my use case of an online game lobby is that the room creator assumes the role of "host" and is responsible for keeping track of players names.

Whenever a new peer/guest joins the room and identifies itself (I needed to implement a host check mechanism to see if the host is listening to the "guest" before broadcasting the name), the host updates its [peerID:Name] map and broadcasts to all peers to update their lists.

[andres-kovalev]

room creator assumes the role of "host"

@jlcvp sounds reasonable, I was thinking about the same. But how you define "room creator" if there is no "room" and there is no way to find out who was the first calling joinRoom()? Or you mean something different by "room" (not a joinRoom() thing)?

[jlcvp]

@andres-kovalev Yeah, I mean, this is defined in the business logic of your application.

I basically did it by implementing a "host claim" event after the "host-to-be" joined the room (in my logic, he should be the only one that "knows" the id of the room at the moment). If no peer contest the host role, the announcer becomes the host and listen to this same host announce event to contest it if any other peer tries to announce itself as a host in the future.

It all depends on your logic, but the goal is to try to make it as distributed as possible and the complexity will, surprisingly, decrease.