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.
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.