Using only RTMFP for random matching (Adobe Cirrus)

Question

I'm trying to come up with the best way to do some random match making in a simple game.

While experimenting with netStreams using Adobe Cirrus, I can easily set up direct connections, send data, text, video, sound all using Cirrus which is great. I find it pretty easy to get a simple P2P connection going, and it works just like i need it to.

But I really want to implement a random matchmaking feature using ONLY cirrus so everything is though p2p...

How would I go about grabbing a random peer in the same group...that's not in a direct connection with someone else already?

some ideas:

-I was thinking maybe I could use object replication...and when someone connects to the GroupSpecifier, I could then push another object into this shared array that has the local peerID and their status. then i could just alter the array when theyre in a game. But then im worried there is no guarantee that their entry will get removed if the person just closes the web window.

-I also thought about just doing a "post" to the group containing the nearID, and other peers can get the post...and those that aren't in a game will try and direct connect back. Then that side will then connect to them. so then theyll both be in direct connections with each other. But then i feel like if potentially 100s of people that are "available"...get the post...then they all try and connect to one person, then it could cause problems.

-Also, I thought about just doing sendToNearest...but wouldnt that not be the best way to match people...because you can only have so many neighbors i think... if there were 1000 people in the group. youll only be able to connect to a few peers actually considered your neighbor right? Then basically you could end up just matching up with the same 5-10 people or however are technically considered a neighbor.

Answer 1

I don't think there's any way to avoid timeouts and retries when matching nodes given that 1) there is unknown and variable network latency, and 2) connections may be joining and leaving at unknown times.

So any node attempting to connect to another node must keep the following stateful parameters:

• I am matched with another node
• I have a match request outstanding
  • My outstanding match request is to node X

It must reject incoming match requests if either of the first two is true (unless the incoming request is from node X, and I have an outstanding request to the same node). It may only request a match if both are false.

In addition, once matched, they may need to poll their partner or watch for disconnect messages and respond appropriately (go back into the matching phase, or exit, whatever the application necessitates).

That being the case, you can at least reduce the amount of network traffic required to sync the nodes by creating a sorting algorithm such that all nodes know ahead of time who their best matches are, and attempt to connect directly to their best matches with a minimum of network traffic (no broadcast post messages, not random attempts).

The key to this would be peerID, which every node in a NetGroup automagically gets. When a node receives a NeighborConnect message, it also contains a unique peerID of the neighbor node. In other words, every node has a unique name (that happens to be basically a big random number) and knows the unique names of all other nodes.

This peerID is long, something like 256-bits. You can create a sorting order with it -- perhaps something like: considering the first 32-bits as an int, XOR the remote node peerID with your own peerID, and sort the remote nodes from lowest to highest.

So now every node has roughly the same idea of who they're going to connect to (even though there will be differences, for example, based on dis/connection messages propagating through the group). Nodes would traverse the sorted list attempting to connect to their best matches, probably with some random timeout between failed connection attempts.

This probably isn't the ideal solution - there probably exists a better one, but I imagine it's better than trying nodes at random or using broadcast messages.