Skip to main content
Jeff__Ward
Inspiring
June 7, 2013
Question

RTMFP Multicast memory leak - feature or bug?

  • June 7, 2013
  • 3 replies
  • 1265 views

When using a NetGroup in multicast mode with posting enabled, all _net_group.post() messages are never released (aka - they stay in memory forever - see my Scout screenshot below - oddly in the Memory-Other category.)

But, is this a feature of a multicast group (the nodes hold onto all messages so that any new group member will receieve all group messages, even prior to the time it joined the group), or is it a bug?

If it's a feature, this seems like a serious handicap.  This means that multicast groups would probably be fine for basic chat (though they'll crash eventually), but if you're sending across large data like images or audio or video, the app will crash in a short amount of time.

Am I missing a setting that would disable this "feature"?  Is there a purge interval?  Currently I've resorted to destroying and re-creating the group on a timer, which fixes the memory problem, but it makes the communication unreliable.

Code and scout screenshot below.  Note that the rate of data doesn't matter, but I've set this to post 2MB every 0.2 seconds (i.e. imagine a screen-cast app), so it crashes on my Android device at 300MB utilized in ~45 seconds:

package
{
  import flash.events.NetStatusEvent;
  import flash.net.GroupSpecifier;
  import flash.net.NetConnection;
  import flash.net.NetGroup;
  import flash.utils.setInterval;
  import flash.utils.clearInterval;
  import flash.utils.ByteArray;
  import flash.utils.getTimer;

  public class MulticastTest
  {
    protected var _nc:NetConnection;
    protected var _ng:NetGroup;

    private static var UNIQUE:int = 0;

    public function MulticastTest():void
    {
      setup_network();

      // Send 2MB every 0.2 seconds, watch memory in Scout
      setInterval(function():void {
        if (_ng) { // wait until group created
          trace(" Sending 2MB");
          // i.e. mimic a large-ish ByteArray, like an image
          var b:ByteArray = new ByteArray();
          b.length = 2000000;
          _ng.post({ byt: b, cc:(UNIQUE++)});
        }
      }, 200);
    }

    private function setup_network():void
    {
      _nc = new NetConnection();
      _nc.addEventListener(NetStatusEvent.NET_STATUS, netStatus);
      _nc.connect("rtmfp:");
    }

    protected function netStatus(e:NetStatusEvent):void
    {
      switch (e.info.code) {
      case "NetGroup.Connect.Rejected":
        trace("Multicast error, no wifi?");
        break;

      case "NetGroup.Connect.Success":
        trace("Multicast group successfully created! "+getTimer());
        break;

      case "NetConnection.Connect.Success":
        setup_group();
        break;

      case "NetGroup.Neighbor.Connect":
        break;

      case "NetGroup.Neighbor.Disconnect":
        break;

      case "NetGroup.Posting.Notify":
        break;
      }
    }

    protected function setup_group():void
    {
      var groupspec:GroupSpecifier = new GroupSpecifier("test/test");
      groupspec.postingEnabled = true;
      groupspec.ipMulticastMemberUpdatesEnabled = true;
      groupspec.addIPMulticastAddress("225.225.0.1:38745");

      trace("Setting up multicast group...");
      _ng = new NetGroup(_nc, groupspec.groupspecWithAuthorizations());
      _ng.addEventListener(NetStatusEvent.NET_STATUS,netStatus);
    }

  }
}

This topic has been closed for replies.

3 replies

Inspiring
January 27, 2016

jeffward

Did you ever resolve your problem? I'm running into the same issue.

Jeff__Ward
Inspiring
February 1, 2016

No, we haven't implemented such a system in production.

Just speculating, perhaps separate NetGroups for (small) control vs. (large) data channels may be the way to go?

Inspiring
February 2, 2016

We are now using NetStream for bigger streams, this resolves the problem. Nevertheless, I would also like to know if the accumulating memory is a feature or a bug. I guess it's a bug, since I was not able to fetch as a new user all older messages.

Participating Frequently
June 8, 2013

If anyone else is having this problem, I found that mine was taking ~7 hours to complete, the problem was I had a series of large arrays for my levels, each with tons of elements around 10,000 lines. Parsing these in from a file solved the publishing time issue and lowered it to 2 minutes

Jeff__Ward
Inspiring
June 7, 2013

Hmm, I see that NetStream has a few potentially relevant properties, multicastRelayMarginDuration and multicastWindowDuration, but I only have a NetGroup / NetConnection.  I assume NetGroup is using a NetStream under the hood for its post capability.

Ah, doing a quick test (with low usage settings), memory accumulates for exactly 5 minutes before flatlining.  This indicates that the NetStream created by NetGroup has a multicastWindowDurationvalue of 300 seconds.  This is obviously good for maintaining stability in group creation and maintenance, but very bad for sending large volumes of data.

Interesting, I'll be investigating workarounds.