0

I made a Chat mainly inspired by the Cirrus Sample
Chat works fine, but on some cases, the "NetStream.Connect.Success" doesn't get triggered.
Both connections pass the ports check

Before switching to a NetGroup architecture and presuming that these problems are related to the connection process, I'd like to know :
- Would NetGroup act differently on NetStream connection process over a NetStream Direct Connection ?
- What are the limitations of NetGroup ? I read there was more latency when using it.

younes0
  • 2,288
  • 1
  • 25
  • 34

1 Answers1

1

ok, so first and foremost, NetStream.Connect.Success fires on the NetConnection and not the NetStream. That is the biggest misconception and frustration for people trying to get this all set up. Adobe did this for legacy (historical) reasons. So check that first to make sure you are listening in the proper spot.

if you are sure you have the listener in the right spot, you may have NAT or firewall comms issues that prevent one peer from seeing the other in certain circumstances.

Now regarding groups:

NetGroup does not introduce latency (necessarily). In groups with less than 14 members, you have a full mesh (all members have a direct peer connection to all others). using a less than 14 member group will still net you a blazingly fast p2p connection provided you use sendToAllNeighbors(). Where you hear about latency is regarding post(). post runs a bunch of stuff that introduces new latency since it tries to contact my 3 descending, 3 ascending, my fractional connections, my 6 least latent and my 1 random every 10 seconds... and then tries to forward the message on to be distributed to the rest of the group. Even in small groups this can take a second or two.

Here is a link to a video from MAX that goes through all the nitty gritty (so to speak) on rtmfp and its ring based architecture Cool In-Depth Video About RTMFP

Jason Reeves
  • 1,716
  • 1
  • 10
  • 13
  • Thanks Jason. I did understand the first point but thanks to mention that. I'll rebuild my chat system with a NetGroup architecture then and keep you informed. – younes0 Dec 03 '12 at 13:34
  • Update: okay so I switched to a NetGroup architecture, it worked fine with in ALL cases, but still not working with my Cumulus server (which runs in a virtualbox session). So I moved Cumulus out of my VirtualBox and set it on a external hosting server, and everything worked fine: netstream AND netgroup. – younes0 Dec 06 '12 at 12:47
  • BTW NetGroup does introduce a latency for some seconds, even when using post(), but then gets back to normal. – younes0 Dec 06 '12 at 12:49
  • that's why I suggested using sendToAllNeightbors() instead of post(). post() is slower for sure. sendToAllNeighbors is only milliseconds slower that direct 1-1 p2p... only because it is direct 1-n p2p. – Jason Reeves Dec 06 '12 at 15:47
  • Sorry , I was talking about sendToAllNeightbors / sendToNearest :) The higher latency occurs in the beginning, for like 30 seconds and then gets to the same latency with a netStream Direct Connection – younes0 Dec 06 '12 at 15:52
  • interesting... I've never seen it take that much time to "speed up". I has witnessed a second or two before... but that is never noticeable to end users. I would be interested to hear what you discover is causing that. Sounds like a network related problem? Maybe try manually assigning positions on the ring to remove any discovery latency? – Jason Reeves Dec 06 '12 at 16:21
  • I didn't take further investigations since I made it work with netstreams which fullfills my requirements. All I can say is that my netgroup tests were made on the same computer/os with two differents browsers. – younes0 Dec 11 '12 at 11:53