Browser multiplayer without server

A lot has been written about WebRTC technology recently. It allows the interaction of two clients without a specialized server between them, but the need for a server disappears only after a connection is established. And at the stage of installing the connection itself, some server resources are still needed. Can I get rid of the need for a server? A small experiment in this direction under the cut.

The need for a server for rtc connection arises for two purposes. The first is a signal server that provides the exchange of technical messages necessary to support the protocol itself. Fortunately, there are several ready-made implementations of the signal server and they are already open on the network for everyone's pleasure. For example, the handy peer.js library in the kit also offers a cloud signal server.
Accordingly, you can not really worry about this part of the question. Of course, the cloud server contains a bunch of restrictions on the number of connections, but to start this is quite enough.

But there is a second part. Before working with the signal server for connection via the rtc protocol, participants must exchange identifiers. The identifier will allow the signaling server to select the necessary participant among the set of potential recipients. And the delivery of identifier information rests with the developer. For example, peer.js tells us, “You're in charge of communicating the peer IDs between users of your site.” I did not find a ready-made solution to this problem.

But what if we want to establish a connection with a random subscriber? For an online game, this may be just what you need. A typical solution for this case is the creation of a special server that will store a database of registered identifiers. It is not too difficult, but I want to get rid of this server. After all, no one bothers to ensure the transfer of this identifier through an rtc connection open with a fixed identifier. The idea is this:

• First, the client tries to connect (using peer.js) with another user using a predefined identifier. This identifier is needed only for auxiliary temporary connection:
  
  

  signalPeer = new Peer(peer.options);
  signalConnection = signalPeer.connect('initial_peer');
  

  
  
  
• If we were able to connect, then we send the cherished identifier of our peer through this rtc channel, which will be used for the main connection:
  
  

  signalConnection.on('open',
       function() {signalConnection.send(mainPeerId); }
  );
  

  
  
  
• If it failed to connect, then after some timeout, we ourselves create a channel with a predefined identifier and wait for someone else to come to us:
  
  

  setTimeout(function(){
       if(!сonnected){
            signalPeer = new Peer('initial_peer', peer.options);
       }
  }, 3000);
  

  
  
  
• And finally, after a successful connection, you must, of course, remember to close the auxiliary communication channel.
  

All code fits in fifty lines. After registration in the form of a mini-library (you can download it here: github.com/bay73/puzzleduel/blob/master/randompeer.js ) you can use it something like this:

var peer = new Peer({key: key});
connectRandom(peer,
    function(connection) {
           // Сюда попадаем при успешном соединении
          connection.on('data'), function(data){ /* прием данных */});
          connection.send(data); /* отправка данных */
    },
    function() {
          // Сюда попадаем при неудаче соединения
    }
);

You can view the full code and provide load testing of a toy made on its basis on github: bay73.github.io/puzzleduel . Maybe someone will brighten up the expectation of the end of the work week. The main problem is that not all browsers (and not all versions) WebRTC fully support.

But for those who do not want to play, the question is - will such an approach work with a noticeable user load?