perhaps you aren't implementing the timestamp echo facility correctly, such that Flash Player's ERTO (retransmission timer) is very high.
1. When the ERTO is very high and the app logic still keep sending data out in a while loop what will happen?
In my application no more data can be sent out except ack is still sending out .
2. In my opinion ERTO only affect the retransmition data(data that is already sent but not acked ),It will also cause the new
data blocked and not sent out?
3.Is there any relationship between ERTO and congestion control?
Is there any article about the flash client side congestion control and retransmition when dataReliable is false
1. when ERTO is very high and your app is sending data with dataReliable=false, then a lot of that data might time out before it is ever transmitted. however, any data queued within 1 second of bandwidth becoming available will be sent.
2. ERTO affects when data that is outstanding is declared lost, and when the congestion control state is reset to "timed out with loss" (so outstanding is set to 0, the initial congestion window is set to about 1500 bytes, and the packets-between-acks counter is reset to 0). at that point a new transmission will be allowed.
3. yes, ERTO is part of the congestion control algorithm. Flash Player implements all described portions of ERTO calculation and congestion control requirements in
there is no other article about congestion control and behavior of Flash Player beyond the RTMFP spec. when dataReliable is false, the RTMFP messages for those NetStream.sends() are set with "1 second queue lifetime and no retransmissions", so they will be sent a maximum of one time, and might be sent 0 times if they time out before congestion control allows transmission.
note that if your messages are very large, and the round-trip time is high, there might not be enough time after an ERTO and a "timed out initial congestion window" to ramp up the congestion window and transmission rate to get the whole message sent before it times out. if you're using dataReliable=false, you should try to keep your messages small enough to fit in one UDP packet (about 1100 bytes in RTMFP).