Skip navigation
Alter Ego - Jo
Currently Being Moderated

NetGroup Bug

Sep 3, 2010 5:56 AM

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



  • Currently Being Moderated
    Sep 4, 2010 11:01 AM   in reply to Alter Ego - Jo

    when one side doesn't see the NetGroup.Neighbor.Connect event, does the other side?  in other words, are you missing the event, or are you not joining together at all?

    Mark as:
  • Currently Being Moderated
    Sep 6, 2010 2:01 PM   in reply to Alter Ego - Jo

    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:


    Mark as:
  • Currently Being Moderated
    Sep 19, 2010 2:16 PM   in reply to Alter Ego - Jo

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

    Mark as:
  • Currently Being Moderated
    Oct 12, 2010 3:08 AM   in reply to Alter Ego - Jo

    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.

    Mark as:
  • Currently Being Moderated
    Oct 13, 2010 10:30 AM   in reply to Octavian Naicu

    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.

    Mark as:

More Like This

  • Retrieving data ...

Bookmarked By (0)

Answers + Points = Status

  • 10 points awarded for Correct Answers
  • 5 points awarded for Helpful Answers
  • 10,000+ points
  • 1,001-10,000 points
  • 501-1,000 points
  • 5-500 points