6 Replies Latest reply on May 5, 2010 3:29 PM by CodeFinder

    What to do with stale unconnectedPeerStreams

    CodeFinder

      I have a situation where I'm entering into a new P2P connection but have a few stale NetConnection.unconnectedPeerStreams entries. Mostly from failed earlier connect attempts.

       

      Does anyone know if there is a  way to flush these entries without having close and reconnect the NetConnection object.

       

       

      Regards,

       

      Kevin.

        • 1. Re: What to do with stale unconnectedPeerStreams
          Michael Thornburgh Adobe Employee

          you can do NetStream.close() on any NetStream (including the ones in the NetConnection.unconnectedPeerStreams array).  that will disconnect the NetStream.

          • 2. Re: What to do with stale unconnectedPeerStreams
            CodeFinder Level 1

            Hi Michael,

             

            Thanks for answering.  I'm not sure that my problem can be fixed by merely closing the streams. Doing that seems to raise other issues.

             

            One other issue, that I have, is easily shown by the following trace of a modified videophone app.

             

            There seem to be two incoming connections from the other application, both at 19:34:54. I'm not sure why there are two as yet.  This initially brings the unconnected peer stream count up to 2, of which I presumably connect to one and leave the other dangling.

             

            Presumably the second connection times out and so triggers the hang up at 19:36:40.  Up until that time the call had proceeded normally.

             

            Any ideas on how to differentiate between a close on the stream I'm connected to and the one that I'm not, so that I can prevent spurious call termination.

             

            19:34:50 onRegisterSuccess - ID event: registerSuccess. call state is Call Ready
            19:34:50 completeRegistration()
            19:34:54 NetConnection event: NetStream.Connect.Success
            19:34:54 farID = 78a33567d53ee8c844c82ad739319157536d242fc11cda1bbfa1d82aa24467fc
            19:34:54 Connection from: 78a33567d53ee8c844c82ad739319157536d242fc11cda1bbfa1d82aa24467fc
            19:34:54 ### Connected stream count = 0
            19:34:54 ### Unconnected netConnection count = 1
            19:34:54 farId[0] = 78a33567d53ee8c844c82ad739319157536d242fc11cda1bbfa1d82aa24467fc
            19:34:54 Stopping retry timer and starting call answer timer
            19:34:54 NetConnection event: NetStream.Connect.Success
            19:34:54 farID = 78a33567d53ee8c844c82ad739319157536d242fc11cda1bbfa1d82aa24467fc
            19:34:54 Connection from: 78a33567d53ee8c844c82ad739319157536d242fc11cda1bbfa1d82aa24467fc
            19:34:54 ### Connected stream count = 0
            19:34:54 ### Unconnected netConnection count = 2
            19:34:54 farId[0] = 78a33567d53ee8c844c82ad739319157536d242fc11cda1bbfa1d82aa24467fc
            19:34:54 farId[1] = 78a33567d53ee8c844c82ad739319157536d242fc11cda1bbfa1d82aa24467fc
            19:34:54 Stopping retry timer and starting call answer timer
            19:34:54 c.onPeerConnect: Caller connecting to listener stream: 78a33567d53ee8c844c82ad739319157536d242fc11cda1bbfa1d82aa24467fc
            19:34:54 c.onPeerConnect: callState Call Ready->Call Ringing
            19:34:54 Listener event: NetStream.Play.Reset
            19:34:54     Playing and resetting controlkevin7
            19:34:54 Listener event: NetStream.Play.Start
            19:34:54     Started playing controlkevin7
            19:34:54 Incoming stream event: NetStream.Play.Reset
            19:34:54     Playing and resetting media-caller
            19:34:54 Incoming stream event: NetStream.Play.Start
            19:34:54     Started playing media-caller
            19:34:54 onIncomingCall: Accepted incoming call from: ruby
            19:34:54 Outgoing stream event: NetStream.Publish.Start
            19:34:54     media-callee is now published.
            19:34:54 acceptCall: Sent onCallAccepted to 78a33567d53ee8c844c82ad739319157536d242fc11cda1bbfa1d82aa24467fc
            19:34:54 acceptCall: callState Call Ringing->Call Established
            --- Next line is unexpected ---
            19:36:40 NetConnection event: NetStream.Connect.Closed
            19:36:40 farID = 78a33567d53ee8c844c82ad739319157536d242fc11cda1bbfa1d82aa24467fc
            19:36:40 Hangup from netConnectionHandler() on farId : 78a33567d53ee8c844c82ad739319157536d242fc11cda1bbfa1d82aa24467fc
            19:36:40 Hanging up call
            19:36:40 onHangup: callState Call Established->Call Ready
            19:36:40 Incoming stream event: NetStream.Play.Stop
            19:36:40 Outgoing stream event: NetStream.Unpublish.Success
            19:36:40 NetConnection event: NetStream.Connect.Closed
            19:36:40 farID = 78a33567d53ee8c844c82ad739319157536d242fc11cda1bbfa1d82aa24467fc
            19:36:40 NetConnection event: NetStream.Connect.Closed
            19:36:40 farID = 78a33567d53ee8c844c82ad739319157536d242fc11cda1bbfa1d82aa24467fc

            • 3. Re: What to do with stale unconnectedPeerStreams
              Michael Thornburgh Adobe Employee

              i'm not familiar with the phone call state machine and application logic implemented by VideoPhoneLabs.  i imagine for each direction there's a NetStream used for signaling and one used to stream the video/audio of the call.

               

              if there are extra NetStreams that end up sitting in unconnectedPeerStreams during the call, then the call setup logic should be examined to see what that other NetStream is supposed to be for (coming from the other end).  perhaps there shouldn't be that second NetStream at all?

               

              if there are extra NetStreams left over in unconnectedPeerStreams *after* the call is concluded, then there's almost certainly some other kind of logic bug in the call protocol.

              • 4. Re: What to do with stale unconnectedPeerStreams
                CodeFinder Level 1

                I did notice that usually the first call between peers fails for some, as yet unknown, reason.  There is a connect and then a disconnect directly after. I've been unable to determine the reason why as yet.

                 

                So my problem remains such that in the call hangup phase I may have unconnected peers. So if I close all these and immediately reconnect to the previous partner then one of the closes is likely to shut down my new call.

                 

                Is it possible that I could extend the NetConnection class and just remove these unconnected PeerStreams from the array without taking any further action on them.  Obviously, at this stage, my call is finished and the unconnected peer information is superfluous and needs to be discarded in a way that won't impact future calls.

                 

                Failing this, is it possible to differentiate at the NetStream.Connect.Closed event between farID instance that I am connected to and an instance with the same farID but which, for whatever reason, never (apparently) connected.

                • 5. Re: What to do with stale unconnectedPeerStreams
                  Michael Thornburgh Adobe Employee

                  the point i was trying to make is: there shouldn't be any leftover unconnectedPeerStreams when you're all done.  if there are, then there is an application-level logic problem.  rather than subclassing NetConnection to clean out this array, modify your program so that there are no stale unconnectedPeerStreams.

                   

                  the NetStream.Connect.Closed event's info object should have a "stream" property that is the (sub)NetStream to which the event applies.  that can be compared with other NetStreams for identicalness.

                  • 6. Re: What to do with stale unconnectedPeerStreams
                    CodeFinder Level 1

                    I've not yet been able to resolve why sometimes two connects arrive instead of one.  I'm using the same code as in the videophone sample for initiating a call:

                     

                    // caller subsrcibes to callee's listener stream
                    controlStream = new NetStream(netConnection, identity);
                    controlStream.addEventListener(NetStatusEvent.NET_STATUS, controlHandler);
                    controlStream.play("control" + user);
                                               
                    // caller publishes media stream
                    outgoingStream = new NetStream(netConnection, NetStream.DIRECT_CONNECTIONS);
                    outgoingStream.addEventListener(NetStatusEvent.NET_STATUS, outgoingStreamHandler);
                    outgoingStream.publish("media-caller");

                     

                    Tonight I'll put in more tracing and see if I can't get a better handle on this.