Signalling
As noted in the previous section, for a peer to connect to the host, it needs to find out their IP address and determine how to connect to them. The host could be anyone, anywhere in the world, so it's impossible to know in advance who to connect to. So to allow players to find each other, there is a separate central server called the signalling server.
The signalling server does not host actual games: the first player in to a room hosts the game and transmits game data to the other peers. Signalling is just a central place for players to go to find each other. When a peer wants to join a host, the signalling server relays information such as the IP addresses and connectivity details between the two. Once the peer has successfully connected to the host, the signalling server is no longer involved and the players are communicating between themselves directly.
Scirra host a public dedicated signalling server at wss://multiplayer.construct.net. (wss: indicates a secure WebSocket connection, since signalling data happens to be relayed over WebSockets. The games themselves still run using WebRTC.)
Signalling terminology
The signalling server needs to avoid mixing up players from unrelated games, and allow different groups of players to arrange separate games at the same time. To do this, players join a room in a game instance.
The signalling server separates players first in to each game. Your particular game should have a globally unique name on the server. Then everyone from your game joins the same game on the signalling server. This avoids players for your game getting mixed up with players from unrelated games that work completely differently! For each game you create, you should only use one game on the signalling server. To ensure your game name is unique on the server and never accidentally also chosen by someone else's game, include you or your company's name, e.g. "MyStudio-Asteroids" or "JohnSmith-Asteroids" instead of just "Asteroids". (This name is never displayed anywhere and is only used internally on the signalling server, so feel free to add other details to ensure uniqueness.)
Next the signalling server separates players in to a game instance. This allows you to run different isolated instances of your game. For example you may wish to have a "stable" instance which most players join, but a "beta" instance for testers using the next (and slightly different) version of your game. This would prevent beta testers connecting to the normal players who might have different game mechanics or features. For the same reason instances could be versions, like "v1.0", "v1.1", "v1.2", always ensuring players only see other players with the same version of the game as themselves. Alternatively another good use is having location-based instances, such as "Europe", "North America" and "Asia". Assuming players join the instance for their actual location, they will only see other players in their same location, improving the chance of a good quality connection to them. These purposes could even be combined such as "Europe-v1.1", "Europe-v1.2" etc.
Finally players can join a room. A room represents a group of players who are playing with each other. Players cannot see any other players other than those in the same room. The first player in to a room is assigned the host. Then the signalling server notifies the host of any other players who join the same room. They then connect to each other and can start playing the game, seeing each other's actions in real-time!
In Construct's Multiplayer object, all actions, conditions and expressions relating to the signalling server are in the Signalling category. All the other features relate to the games themselves.