1 Reply Latest reply on Jan 11, 2010 11:56 PM by Michael Thornburgh

    Matchmaking with Stratus


      I was investigating a possible short term use of Startus for matchmaking, but have been unable to find much info.  Here's what I would considering...


      1. System1 establishes itself on stratus with DevKey1.  This system then sets up a group(*) and stays online continously - acting like a server.
      2. System2 connects to stratus with DevKey1 and attempts to link with System1 through the use of group and without acquiring System1's peerID.
      3. System2 also connects to stratus with DevKey2 and sets up it's own peerID which it communicates to System1.
      4. System3 connects to stratus with DevKey1 and attempts to link with System1 through the use of group and without acquiring System1's peerID.
      5. System3 receives System2's peerID from System1.
      6. System3 then connects to startus with DevKey2 and directly connects with System2 by using System2's peerID.


      *OK, so the big question is can I set up System1 as a stratus group that can automatically allow other systems to connect with it without knowing it's peerID?  Would NetGroups work?  If so, how?




        • 1. Re: Matchmaking with Stratus
          Michael Thornburgh Adobe Employee

          the answer to your Big Question is "yes".  one of the services that Stratus offers is automatic group bootstrap.  when you create your group, if you specify "GroupSpecifier.serverChannelEnabled = true" then Stratus will connect new members to the existing members (if any) of the group.  Stratus uses the group server channel to keep track of the members of the group and sends commands equivalent to NetGroup.addNeighbor() down the channel to tell members about other members.  if you don't enable the server channel for a group, Stratus has no idea that the group even exists, much less who might be in it.


          note that the automatic group bootstrap function will connect you into the group, but not necessarily directly to any specific member (such as System1 in your example).  if the group of your step 1 has N members, the likelihood of being connected directly to System1 is proportional to 1/N.  and without knowing System1's identifier, there's no way to get a message directly to it except to use posting (which sends the message to everyone in the group, which is wasteful and not scalable) or to hope you're directly connected by the bootstrap operation and send something to all of your neighbors (also wasteful and not likely if the group has more than about 15 members).


          one possibility is to build a distributed data structure, such as a Distributed Hash Table (DHT) in the group using directed routing (see NetGroup.sendToNearest() and related methods and events, and google or wikipedia for Distributed Hash Table).  this would be scalable and academically interesting, but directed routing only works reliably in a group if there are no connectivity problems.  in the real Internet, there *will* be certain pairs of peers that can't talk to each other (caused by combinations of NATs and firewalls and occasionally Internet routing issues), and the likelihood that one of those pairs would be needed for completely correct operation of a DHT is high.  that can be mitigated to an extent with replication, but that's annoying and complicated too.  and building a robust DHT with replication and migration is probably a harder problem than you want to tackle right out of the gate.


          presumably you want to map a user name or service name to one or more peer IDs.  you could create a group for each name, and joining that group would get you talking directly to at least O(log n) peers also interested in that name.  if, most of the time, the group only has one member (the holder of the name) or a very small number of other members (less than about 15) then you will be directly connected to the holder of the name.  making more groups (with server channel) increases the resource load on Stratus, though, so this approach should be weighed against the Greater Good.


          i believe the best approach is actually to write a matchmaker service as some kind of web service (like the reg.cgi sample service in the Stratus sample app).  you already need a web server to host your SWF and HTML, so hosting a simple database and cgi script shouldn't be an insurmountable incremental burden.