I've experimented last couple of days with P2P and it's getting very frustrating that a basic functionality is not working.
The scenario it's simple, connect to server and setup a NetGroup and the NetGroup.Neighbor.Connect status is not dispatched every time(real application scenario, not locally).
I've tested online (http://dl.dropbox.com/u/4605534/face/P2PMonitor.swf) with 2 clients(me and a client from another network).
Conclusions: - if I am connected and the other connects the status sometimes isn't dispatched(record only 1 time was dispatched if the user hit Reconnect)
-if the other was connected and i connect after, the status is dispatched
As I see there is no logic in this bug and I don't know any other ways to debug this.
I would appreciate any help and explanation for this.
if you're not seeing the event, it means you're not joining with the neighbor (and therefore not in a group together).
this is most likely caused by a NAT or firewall issue. there are two possibilities i can think of:
1) if the other person is out in the Internet somewhere (not behind a common NAT somewhere), then your report that connections seem to work from one direction but not the other suggests a buggy consumer router/NAT/firewall, either on your end or the other person's end. i wrote something up about this possibility; please read this thread:
and be sure that your router's firmware (and that of your associate) is up-to-date. if you and your associate are both out in the open Internet, it shouldn't be the case that a connection could work reliably in one direction but fail in the other if the routers, NATs, and firewalls between you are behaving in the correct manner.
2) both of you are behind a common NAT, one of you is behind another NAT inside the first translated domain (the "double NAT" case), and the outer NAT doesn't do "hairpinning". this is the hardest P2P case to make work. for a detailed description of the kinds of problems you can run into with NATs, please see Matthew Kaufman's post on the subject:
This means that is a BUG because I have to make assumtions/ to rely on
uncertainties in the case the user cann't (technologicaly) to use my software, and as a developer cann't customize the user experience,
making users easily to believe that the application is broken(lose them).
Programmatic: NetGroup.Connect.Success beeing dispatch although the user doesn't joined the group(NetGroup.Neighbor.Connect missing) for whatever reason is a BIG BUG.
Is there a method/way to find out if the user is legitimate for P2P, to avoid the exceptional case/bug above ?
i think the problem is that "NetGroup.Connect.Success" doesn't mean what you think it means.
an RTMFP Group is a cooperative, distributed construct. it's not an external service to which peers connect; it is the cooperative system that the peers in the group all form together.
a NetGroup object (or a group NetStream object) is a handle to the low-level local group network endpoint in that peer. "NetGroup.Connect.Success" indicates that the NetGroup object is connected to your local group endpoint (and that, if needed, the user has authorized "Peer Assisted Networking" via the permission dialog). but the existence of the group endpoint for a group specification and one or more NetGroup or NetStream handles to it is only half of the picture. the other half is joining together with the other peers that think they're in the same group. this is indicated when "NetGroup.Neighbor.Connect" happens. until then, you *are* in a group, but you're the only one in it.
unfortunately there is no reliable way (other than "trying") to predict whether any particular peer will be able to make peer-to-peer connections, or even a particular P2P connection. even the tests that cc.rtmfp.net does can't be used to reliably predict the behavior of all possible P2P scenarios. for example, if there are two peers that want to be in a group, and cc.rtmfp.net indicates they're both behind a symmetric NAT, the most likely prediction is they won't be able to join together. but if they're behind the same symmetric NAT, they *would* be able to join with each other. likewise, buggy consumer network equipment and the vagaries of Internet inter-domain routing (among numerous other factors) can result in two peers with favorable CC test results still not being able to reach each other.
note that for groups of peers that are in disparate consumer/home networks, the likelihood of being able to join the other peers of the group goes up as the size of the group increases.
I have a similar issue:
While testing over LAN if I connect first tothe group and then my partner , the NetGroup.Neighbor.Connect is triggered after a few minutes for both of us.
If my partner connects first and I connect second the NetGroup.Neighbor.Connect is triggered right away for both of us.
most likely your LAN is behind a NAT, and your partner has a firewall enabled on his computer. when a second member joins the group, Cirrus commands the first member to add the second as a neighbor. if the second joiner has a firewall AND both of you are behind a NAT, the first joiner's behind-NAT address will not be passed as an introduction to the second, so the second won't poke a hole through its firewall for the first.
after a few minutes, the automatic group partition healer will command the second joiner to connect to the first, which is a direction that (apparently) works.
if your partner was not behind the same NAT or did not have his firewall enabled, you wouldn't have that initial delay.