3

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.

Tom
  • 7,994
  • 8
  • 45
  • 62

2 Answers2

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/

sth
  • 222,467
  • 53
  • 283
  • 367
strip-arcade.com
  • 31
  • 4
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');.

J_A_X
  • 12,857
  • 1
  • 25
  • 31
  • I was under the impression that direct connections were not possible between all members of a group, and that directed routing using netgroup was a solution to messaging between such pairs of peers. – Tom Jun 17 '11 at 18:48
  • What do you mean by 'all members of a group'? Don't you just want to message one person? Directed Routing is made for you to send information to your protocol 'neighbors', but from what I've read, if that person is not your neighbor, then you can't send them any information directly. – J_A_X Jun 17 '11 at 19:20
  • Sorry, I thought that might not be 100% clear. What I meant was: From my understanding, direct connections are not always possible between all possible pairs of peers in a group, although messaging between such peers is possible. – Tom Jun 17 '11 at 22:14
  • Well, it's not guaranteed 100%. RTMPT uses udp to communicate, which should work on most networks except for some enterprise firewalls that would block udp. Best thing you can do is just try it out, I'm fairly sure it'll work 99% of the time. If NetGroup works, direct connection should work as well. – J_A_X Jun 20 '11 at 01:34
  • JAX, this: ("If NetGroup works, direct connection should work as well.") - is simply not true. Have you read the link that I posted? – Tom Jun 22 '11 at 09:42
  • "Your only viable option is to use Direct Connection and it is just as reliable as using NetGroup." - In fact I believe there are several options. – Tom Jun 22 '11 at 09:51
  • The link you posted is not conclusive and it's definitely not fact; I have used p2p for quite a few projects and it's worked out pretty well so have. You also have to remember that Cirrus *is not* a commercial product, it's out for tests but isn't made to be used heavily. If you need something more robust, get your own FMS server and implement p2p functionality on there. Plus, your only viable options *is* direct connection if you want to use Cirrus, since it's all p2p. You could use a 3rd party server, but then that wouldn't go through Cirrus and wouldn't be p2p. Pick what you want to do. – J_A_X Jun 22 '11 at 12:55
  • "If one end is a symmetric NAT with a single IP address, then connections to peers behind other symmetric NATs or behind port-restricted cone NATs (or port-restricted firewalls) are impossible. If one end is a symmetric NAT with multiple IP addresses, then connections to peers behind other symmetric NATs or behind address-restricted (and likely port-restricted) cone NATs (or address-restricted or port-restricted firewalls) are impossible. " http://forums.adobe.com/message/1064983#1064983 – Tom Jun 22 '11 at 14:09
  • That sounds pretty authoritative eh? Really glad though to hear that direct connections work fine most of the time in your experience. – Tom Jun 22 '11 at 14:24
  • Tom, that would be the case for *any* p2p connection (including NetGroup). Again, if NetGroup works, direct connection should work as well. The only problems I've seen were for people behind a very strict corporate firewall. If that's the case, you need to use something that goes over http or https. – J_A_X Jun 22 '11 at 15:52
  • Thanks, its great to get the opinion of someone with some real world experience of this. – Tom Jun 22 '11 at 17:41