1 Reply Latest reply on Apr 6, 2011 10:51 PM by shooding2011

    sendToNearest not working

    shooding2011

      //I was trying to send message to a peer named "collector".

      //I have read some documents online and some said there should be a random part in the message object

      // , and therefore i'm using a random string as the message id.

       

      var message:Object = new Object();
      message.destination = netGroup.convertPeerIDToGroupAddress("collector");
      message.id = Helper.generateRandomString(32);
      message.msg = "Hello! my peer ID is john1234";
      netGroup.sendToNearest(message, message.destination);

       

      // Also, every peer helps to forward the message if not his, doing the following

      case "NetGroup.SendTo.Notify":

          if(event.info.fromLocal == true){
               // We have reached final destination
               trace("Received Message: "+event.info.message.msg);
               writeText("Received Message: "+event.info.message.msg);
          }else{
          // Forwarding
               writeText("Not mine.");
               netGroup.sendToNearest(event.info.message, event.info.message.destination);
          }

       

      //The above code is not working, WHY?

      //I have tried posting and it works. But i prefer directed routing instead of flooding.

        • 1. Re: sendToNearest not working
          Michael Thornburgh Adobe Employee

          "collector" isn't a peerID.  the peerID is a 32 digit hex string.  your peerID is your NetConnection.nearID.  NetGroup.convertPeerIDToGroupAddress() only takes hex strings with an even number of digits; i suspect message.destination is empty or null, or it could be SHA256(<empty>) (i'd have to fire up Flash Builder to check :).

           

          also, in order to route messages recursively through a group (necessary when there isn't a full mesh), NetGroup.receiveMode must be set to NetGroupReceiveMode.NEAREST.

           

          postings must be unique; directed routing messages don't need to be unique.

           

          correct operation of directed routing requires a correct ring topology. "correct ring topology" means that for EVERY member of the group:

           

              member.nextIncreasingPeer.nextDecreasingPeer == member.nextDecreasingPeer.nextIncreasingPeer ( == member)

           

          RTMFP Groups try to maintain this topology, which might not be possible in the Real Internet with NATs and firewalls and stuff.

          1 person found this helpful