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.
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:
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:
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: