RDMGR : Peer-to-Peer Connections

I have peer-to-peer connections working for the Roller Derby Manager (RDMGR) software. Now I can send/receive data between clients over the network. For example: a remote scoreboard sending the game clock in real-time to the live streaming computer.

This opens up possibilities as now more computers added to the system can contribute to an improved production for Roller Derby. Future plans include media streams (multiple cameras, replays), remote telestrator and stats for announcers, scorekeepers for current and on-deck skaters.

Thank you to Michelle Bu and Eric Zhang, for their work on PeerJS and PeerServer, two JavaScript/Node.js packages that have made this far easier. I might’ve spent months beating my head against the wall programming all that network code myself.

Normally in peer-to-peer networking, you let the negotiating server connect peers. In RDMGR, I’ve taken a different approach: since I won’t be using a central server, each peer will act as its own server, accepting connections on pre-defined ports and hosts. (RDMGR is a closed system, fully controlled by my configuration.)

This allows peers to connect directly to each other, where the server is the peer itself. Note: this is only possible if you know the IP addresses of the clients (which I have full control over, as RDMGR is a closed system).

How it Works:

  1. Each peer is also a server.
  2. Each peer has a list of peers they can connect to, including port and host.
  3. Each peer can connect to each peer, directly, without a negotiating server.

For example:

  1. Peer A and Peer B know about each other.
  2. Peer A starts its server, accepting connections from any peer that knows of it’s IP, Port, and Path.
  3. Peer B starts its server, just like Peer A.
  4. Peer B connects to Peer A.
  5. Peer A changes the Port and Host that Peer B is connected to.

That last point is a distinction that helped me learn about peer-to-peer programming:

When connecting to a server, the peer that is receiving the peer must connect with that peer on the same port and host that the server connection exists.

Look at this:

  • Peer A Host: 192.168.1.101:20001
  • Peer B Host: 192.168.1.102:20002

For a while, I was accepting the connection from Peer B’s Server when Peer B was connecting to Peer A. However, since Peer A is the server that performed the negotiation, then Peer B is connected to Peer A, and therefore, when I create a peer connection on Peer A, I have to use Peer A’s host and port (which is the localhost).

So, a connection from Peer B to Peer A would be this:

  • Peer A Host: 192.168.1.101:20001
  • Peer B Connection to Peer A: 192.168.1.101:20001