7 Replies Latest reply on Jun 29, 2011 12:44 AM by nil.gradisnik


    Stenrap2 Level 1

      I have two users connecting to each other, both with one NetStream for sending and one for receiving (and both play() / publish() the same stream name). When the second user creates his receive NetStream--the last of the four NetStreams to be created--the first user receives a "NetStream.Connect.Success" and immediately uses his sending NetStream to send() the second user a chat message.


      Unfortunately, the second user doesn't always receive that first chat message. However, all future chat messages are delivered back and forth without any problems. It's almost as if the connection between the two is not fully set up when that first chat message is sent.


      Is there some way for the first user to be certain that he can send() to the second user? I thought listening for "NetStream.Connect.Success" would have been enough.




        • 1. Re: NetStream.send()
          Michael Thornburgh Adobe Employee

          at the instant the NetStream.Connect.Success event happens, the flow(s) from the subscriber end haven't been wired up to the publishing NetStream, because the specific stream name hasn't been received and processed at that stage.  once the stream name is received, interpreted, and matched up to a publishing stream, that publishing stream will get a NetStream.client.onPeerConnect() call.  if you do a NetStream.send() before receiving the client.onPeerConnect() call at the publisher NetStream, that .send() won't have anywhere to go and will be discarded.


          also, make sure the receiving NetStream.bufferTime is 0 to receive NetStream.send() in a timely manner, especially if that NetStream is only being used for NetStream.send().

          • 2. Re: NetStream.send()
            Stenrap2 Level 1

            Unfortunately, waiting for onPeerConnect() still didn't work (and I set the receiving NetStream.bufferTime to 0). The very first chat message is still not received by the second user, but all subsequent messages are sent/received without problems.


            I did notice the following in the language reference for onPeerConnect():


            "Before the subscriber is connected to the publisher, call this method..."


            So I'm wondering if calling send() inside onPeerConnect() is still too early. Any other suggestions/ideas?

            • 3. Re: NetStream.send()
              Michael Thornburgh Adobe Employee

              yes, calling NetStream.send() inside onPeerConnect is too early.  the purpose of onPeerConnect is to provide access control on a peer-by-peer basis to a stream. it's only after you return true from onPeerConnect that the permission is granted and the subscriber is hooked up to the publisher.

              • 4. Re: NetStream.send()
                Stenrap2 Level 1

                So how does the publisher know that he has returned true from onPeerConnect and the subscriber is hooked up? In other words, how does the publisher know when it's finally ok to call send()?

                • 5. Re: NetStream.send()
                  Stenrap2 Level 1

                  I think I found an answer to my question. It seems that if I wait for "NetStream.Play.Start", then I can call send() and the newly connected subscriber always receives that first message.

                  • 6. Re: NetStream.send()
                    Stenrap2 Level 1

                    Looks like I spoke too soon. The problem is happening a lot less frequently -- I've seen it twice in the last hour -- but it's still happening. I'm starting to think there's no reliable way to be certain that the very first send() will be received. Please somebody tell me I'm wrong.

                    • 7. Re: NetStream.send()
                      nil.gradisnik Level 1

                      I am experiencing the same issue.

                      The first NetStream.send() is very unreliable, sometimes it's received on the other end, sometimes it's not. This is a big problem when you are trying to create a solid user experience.