Adobe Cirrus: Quickest way to deliver a chunk of data to a single peer with known id

Question

Adobe Cirrus offers a number of options for transferring data from peer to peer: Directed Routing, Object Replication and Multicasting to name a few.

I just want to send the data to one specific peer, its fine for other peers to 'see' it in transit.

My experiments with Directed Routing (the obvious answer) have not gone well. all the sendto... methods fail, while NetGroup.post works fine on the same netgroup. I am concerned about using direct connections because of reliability.

Has anyone successfully implemented a one to one messaging strategy (not one to many), which can still message between non-connected peers - (Directed Routing) or solved this problem successfully?

I am considering various workarounds, but I am quite perplexed that these NetGroup methods: sendToNearest, sendToNeighbour & sendToAllNeighbours just seem to fail, for no apparent reason.

Answer 1

Well, here's your problem, NetGroup isn't made for single peer 'send'. As the documentation says "Instances of the NetGroup class represent membership in an RTMFP group" and all those send methods are pertaining to the protocol neighbors (you'll need to read more into how RTMFP works; it's a really ingenious decentralized p2p protocol).

Your only viable option is to use Direct Connection and it is just as reliable as using NetGroup. The only 'reliability' issue is with the connection to the peer. If you want something more robust, you'll need a 3rd party server but in my experience this is not needed. You just need to have a client listening for an incoming stream and have the other connect to the other peer using their peer id (you should already know the peer id through your own server implementation). When the connection is established, you just need to do netConnection.send('whatever');.

Answer 2

netGroup.sendToNearest should be the fastest, but it takes a little more work to get it going. To handle the message, you need to listen for the NetGroup.SendTo.Notify event. However, it's possible that you may receive the message, but NOT be the final destination for it... in other words, you could just be a middle-man in the P2P network, and need to forward the message on to the next nearest node. So, when handling the NetGroup.SendTo.Notify event, you need to check to see if you're the final destination first. You do this by checking event.info.fromLocal. If it's true, you're the final destination and you should do whatever you want with it. If it's false, you must take an active role in forwarding the message onwards. To forward the message, you'll need to know what the final destination's ID is, so you'll have to actually include that in the original message. You can forward the message with something like...

if (!event.info.fromLocal)
    netGroup.sendToNearest(event.info.message, event.info.message.destination)

From what I understand, directed routing should basically be the same speed as posting, but it won't clog up the network with unnecessary data going to everyone when they don't actually need it. Also, directed routing happens over UDP and should have the same pitfalls as posting--delivery is NOT guaranteed. The only way to guarantee delivery over RTMFP is by using object replication.

Here's some more info on directed routing: http://www.flashrealtime.com/directed-routing-explained-flash-p2p/