6 Replies Latest reply on Aug 17, 2011 6:12 PM by Pablo P.

    Netstream.send() message order and events

    Pablo P.

      I want to split a file to 64K chunks and to use Netstream.send() to send it to another peer.

      I understand that I need to set dataReliable to true and bufferTime to 0.

       

      Is it guaranteed that the messages will arrive in order

      or do I need to implement custom logic in which the receiver peer acknowledge each chunk

      by sending back for example {success: true, chunk_index: 5} ?

       

      Are there events when a chunk was successfully sent?

       

      Is there a reason why NetGroup have much more advanced functionality in terms of sending data and object replication?

       

      Thanks

        • 1. Re: Netstream.send() message order and events
          Michael Thornburgh Adobe Employee

          messages will arrive in order with those settings.  at this time, there are no settings that would have NetStream.send() messages arrive out of order.

           

          there is no event when a chunk is sent.

           

          note that at this time, NetGroup directed routing messages (sendToNearest(), sendToNeighbor(), sendToAllNeighbors()) are always sent with full reliability but may be received out of order.

           

          i believe as of Flash Player 10.2 (but maybe 10.3), we increased the low-level RTMFP receive flow buffer advertisements so that very large messages would stream efficiently over the network (prior to that, messages larger than 127KB would bog down after the first 127KB, sending only about 1KB every round trip).  i believe there's an internal Flash Player message size limit of about 10MB, but messages up to that size will now stream efficiently and at full speed over RTMFP P2P in any mode (1:1 NetStreams, directed routing, object replication, and even posting as long as the message can be sent to the peer in less than 5 seconds).

           

          note also that there is a bug with sending large amounts of data rapidly over 1:1 or client-server RTMFP NetStreams. this bug can cause stalls at the sender side for NetStreams that don't have any video or audio.  this is because the higher-level message queues are routed to the low-level RTMFP flows up until the flow's send buffer is filled. after that, the higher-level queue isn't checked again until a new message is enqueued at the higher level (such as a new video or audio frame, or another NetStream.send()).  this bug will be fixed in a future release of Flash Player.  this bug only affects NetStream.send(); all of the NetGroup modes i mentioned take different paths from ActionScript to RTMFP's guts.

          • 2. Re: Netstream.send() message order and events
            Pablo P. Level 1
            i believe as of Flash Player 10.2 (but maybe 10.3), we increased the low-level RTMFP receive flow buffer advertisements so that very large messages would stream efficiently over the network

            Does this means that I can send a large file (up to 10 MB) without splitting it to 64KB chunks?

            What about files larger than 10MB?

             

            note also that there is a bug with sending large amounts of data rapidly over 1:1 or client-server RTMFP NetStreams. this bug can cause stalls at the sender side for NetStreams that don't have any video or audio.

            Does this means that until the bug is fixed I have to split a large file to 64KB chunks but in a future version I will be able to send a large file without splitting it?

            Do you have a link to the bug?

             

            Thanks

            • 3. Re: Netstream.send() message order and events
              Michael Thornburgh Adobe Employee

              Does this means that I can send a large file (up to 10 MB) without splitting it to 64KB chunks?

              What about files larger than 10MB?

               

              yes, you could send up to about 10MB in one NetStream.send() without splitting it up into 64KB chunks. something larger than about 10MB would need to be split into about 10MB chunks.

              Does this means that until the bug is fixed I have to split a large file to 64KB chunks but in a future version I will be able to send a large file without splitting it?

              no. this means that until this bug is fixed*, if you send more than about 127KB of data at once (either one big message, or two 64KB messages, or 127 1KB messages), you would need to occasionally poke at the NetStream as transmitted data drained out over RTMFP to get it to (re)notice that there's more RTMFP buffer capacity to hold new messages, and to take them from the higher-level queues.  when you have regular messages like audio/video from your microphone/camera, the regular queuing of those messages accomplishes this.

               

              one way to accomplish this on a data-only NetStream for a large data transfer would be to send large messages (multiple MB) one message at a time, and have the receiver send back an acknowledgement message to trigger queuing the next one at the sender.  this is definitely not ideal, since you'd have at least one round-trip time with no data transfer and potentially a new congestion window ramp-up, but it would avoid the big stall.

               

              another way to accomplish your file transfer would be to make a privete two-member NetGroup (just the sender and receiver) and use directed routing (NetGroup.sendToNearest() or sendToNeighbor()).  note that messages could be received out of order (but that's only likely when the messages are small, smaller than about 2-3x the expected congestion window, which would probably be on the order of 30-200K in today's Internet); however, i *believe* (you should try this) that for directed routing the 10MB-per-message limit doesn't apply.  so you could send your entire file with one sendTo* call (assuming it fits into memory all at once of course).

               

              Do you have a link to the bug?

               

              *no. the bug itself is fixed internally (has been for a while) and is just waiting for the next major release of Flash Player. Flash Player 11 beta on Adobe Labs should contain the fix already.

              • 4. Re: Netstream.send() message order and events
                Pablo P. Level 1

                What about showing upload/dowload progress to the sender and receiver?

                 

                Is there a way to do this with Netstream.send() or NetGroup?

                • 5. Re: Netstream.send() message order and events
                  Michael Thornburgh Adobe Employee

                  you can't show upload/download progress if you send the entire file in one message.  the only reasonable way to do that is by sending smaller chunks.

                   

                  neither the NetStream.send() or NetGroup directed routing methods provide flow control back to ActionScript, so the sender can't display upload progress without doing application-layer feedback from the receiver.