This content has been marked as final. Show 4 replies
there are two close cases, and it's not clear from your message which one you mean, so i'll address both.
if the publisher stops publishing but the subscribers don't unsubscribe, then when the publisher re-publishes it *should* get the onPeerConnect calls again for the subscribers, and the subscribers should see the newly published stream. this behavior is consistent with client-server publishing and subscribing through FMS.
if a subscriber unsubscribes (by saying netStream.close()), the publisher sees a NetStream.Connect.Closed event. if the publisher unpublishes and at a later time publishes again, it appears to see onPeerConnect calls for subscribers even if they unsubscribed. i have verified that the underlying RTMFP P2P network connection between the publisher and subscriber is torn down (after a 5 minute idle period), but the NetStream objects representing them in the publisher persist. that seems like a bug to me.
it appears that these objects will disappear when the garbage collector runs, and calls to onPeerConnect for them will stop.
What you have described in the second part is exactly the behavior I was attempting to refer to. As you mentioned, the peer subscribed netstreams that aren't really opened anymore will get eventually garbage collected.
It does seem like a bug.
If I would be to create a publisher that is able to "kick" subscribing streams, the only way I managed to get the connection to properly disconnect from the publisher (and instantly, without timeout) is to call .close() on the subscribed netstream (from the publisher's code) and then call .play(false); wish seems to actually make the connection be triggered as closed. But I can't seem to work this hack for a netstream that has triggered the NetStream.Connect.Closed.
you can read "that seems like a bug to me" as "that is a bug". it should be fixed in a future release of Flash Player.
A quick workaround for this is to validate the incoming peer netstream with the netconnection.unconnectedPeerStreams entries. If the onPeerConnect subscriber is in the unconnectedPeerStreams list, it's the good one, or else, ignore.
Thanks for the confirmation though!