does this problem happen if you're using the Codename Cirrus servers or Adobe Media Server?
"NetGroup.Neighbor.Connect" is sent locally in response to a connection from a neighbor in the group. if you're not seeing the event, then a neighbor isn't connecting.
when you enable the "server channel" in a group, the server can help bootstrap groups together by sending commands to clients with the server channel to connect to other clients in the same group. the clients will then try to connect to the peers so commanded. if the connections are successful, you'll get the connect event. if the connections aren't successful, you won't get the event.
Yes, I'm getting the same results with Cirrus.
I can also reproduce this issue with this RTMFP connection tester.
In some cases on certain PC / browser combination, the NetGroup.Neighbor.Connect event is not triggered. As mentionned before, the peers are on the same LAN so it's not a firewall issue. Also, it might work on a PC with Chrome but not IE.
I have enabled the serverChannelEnabled flag on the group specifier, but it did not help.
perhaps you have a local firewall on the PC that's having problems? it's possible that Flash Player in Chrome on this computer is a combination of local firewall and "can't tell what the local network interface addresses are" which is disrupting the NAT/firewall UDP hole punching that RTMFP servers try to help with. it could be that Flash Player in a different browser doesn't have this problem -- if i remember correctly, FP in Chrome might be using a different plug-in API that might night give it access to some information. it's possible that the plug-in API in Chrome doesn't give access to the local interface addresses. if that's the case you might have trouble connecting if there's a NAT between the clients and the server.
if you weren't using the server channel before, how were you bootstrapping your groups together?
I have the same problem. Been spending days on this only to find this bug...
I'm running the peers within the same app in a standalone desktop debugging flash player.
I confirm that it’s not a firewall / NAT issue. The problem can occur for some players with Chrome or IE, it’s not really consistent among the community.
I can replicate this issue on a PC when running the application in Chrome 100% of the time but it will work with IE on the same PC. Also, a different PC will not have the issue with Chrome but will have it with another browser (IE or Firefox).
“if you weren't using the server channel before, how were you bootstrapping your groups together?” I have always used the server channel.
Do you have any hints on how I could debug this issue, advanced logging I could enable, packet sniffing or other method you recommend for me to get more information on this bug ?
go to http://cc.rtmfp.net/ on the computer that has a problem and another computer on the same LAN that does not have the problem, and let me know the results. ideally please also send the "Public IP" (including port) so i can look up your results in cc's logs. if you like you can send the "Public IP" addresses to me in a private message, if you don't want to post your IP addresses publicly in this forum.
unfortunately, someone is misusing the connectivity checker server, and the log file overflowed (actually, the hard disk filled up). if you would, please re-run the tests so i can see the logged data. you don't need to re-post screen shots if the public IP address is the same.
based on the results from cc you posted, it appears that your computers are behind a symmetric NAT. P2P connections will not be possible between computers behind different symmetric NATs, and won't be possible behind the same symmetric NAT if the behind-NAT addresses aren't sent to the server. if i can find your entries in the logs, i can see whether your behind-NAT addresses are being sent to the server.
i found new entries in the log with your IP address. there were two connections: the first did not report any local (behind-NAT) addresses. the second connection reported one local (behind-NAT) address.
in general, successful P2P connections will be rare when symmetric NAT is involved (where there's a different translation for each new destination). with symmetric NAT and no behind-NAT addresses, a P2P connection behind the NAT will be difficult to achieve. it should be possible to connect from the computer that doesn't report local addresses to the one that does, but not the other way around.
for P2P groups, you can use IP multicast neighbor discovery to find peers in the same group on the same LAN. on your GroupSpecifier, set ipMulticastMemberUpdatesEnabled=true, and addIPMulticastAddress with something like 220.127.116.11:30000 (as an example -- feel free to choose any appropriate IP multicast address and port number >=1024).
I have been trying to reproduce this issue but it's hard to repro and I can't say for sure that enabling the IP multicast neighbor discovery has fix the issue.
I entered a bug on this. Please see bug id 3684283: https://bugbase.adobe.com/index.cfm?event=bug&id=3684283
unfortunately, the Chrome Pepper API doesn't give Flash Player a way to discover its local IP address(es), so it can't give that information to a server to help with P2P connections when you're behind the same NAT with someone else, and that NAT is symmetric or doesn't do hairpinning. the problem can't be fixed until the Chrome Pepper API exposes a way for a plugin to discover its local interface addresses.
the ip multicast neighbor discovery should either work 100% of the time or 0% of the time. if it's working at all it should work reliably.
Thanks for your help Michael.
Happy New Year BTW
From the bug reported @ https://bugbase.adobe.com/index.cfm?event=bug&id=3684283
Jing Yuan said he was able to reproduce with IE10. We also, had the issue with IE and Chrome here...
Im confident it's not a Chrome only issue.
I am developing a mobile app for sharing files on local network (using AIR and RTMFP of course) and I noticed that there is sometimes very long delay between NetGroup.Connect.Success and NetGroup.Neighbor.Connected events (so I can start an actual P2P communication).
Sometimes it takes a second and sometimes even minutes on the same network.
Tested on ADL <-> Android and ADL <-> ADL (Windows 10), even all of those sample RTMFP chat apps behaves the same.
So my question is - Is this a common issue and is there a way I can deal with it?