mike , you said :
" in Flash Player 10, lost or slow Speex audio frames, when sent in "live, unbuffered" mode, can be discarded in favor of newer data. at the current time, no other data is sent using the partial reliability capability of RTMFP, including NetStream.send().
in Flash Player 10, can use the partial reliability capability for NetStream.send() ?
1 person found this helpful
in Flash Player 10.0, P2P NetStream.send() is fully reliable and congestion controlled. there is effectively unlimited (limited by memory available to Flash Player) buffering for these messages.
in Flash Player 10.1, P2P NetStream.send() will have the option for partial reliable transmission (still congestion controlled). when "partial reliability" is selected, messages are not retransmitted if there is loss, and they may expire while waiting in the transmission queue if there is not enough network capacity. that is, when partial reliability is selected, the packets for the messages may be sent one or zero times depending on the congestion state. messages are received in the order they were sent regardless of loss or network packet reordering.
thank you mike, I still have three questions
1. in Flash Player 10.0,each NetStream has a send buffer or only NetConnection has a send buffer(all NetStream blongs the NetConnection shared the buffer) ?
2. in Flash Player 10.0,since the buffer is unlimited . the application(send side) how to dectect congestion ?
3. in Flash Player 10.1, if the transmission queue is unlimited ? ( or like TCP's cwnd , can detect network capacity)
1. since the buffers are effectively infinite, it doesn't matter if there's one per NetStream or one for the whole NetConnection. it is an implementation detail that doesn't affect the semantics. it happens that every RTMFP flow has its own buffer, and NetStreams can have multiple flows (video, audio, and data are all separate).
2. there is no ActionScript API to query the size of a NetStream's transmit queue(s).
3. there is still no ActionScript API to query the size of a NetStream's transmit queue(s). partial reliability is necessarily a time-oriented constraint, so it shouldn't matter to the application how much capacity you have. you would use partial reliability to try to get time-sensitive information to the receiver in a timely fashion. all the information won't make it to the receiver if there isn't enough capactity for it to be delivered in short order. if you need the information to get to the receiver, you should use full reliability.
thanks mike , I understood . but still not clearly for question 3
time-sensitive information is like rtt , srtt .. ?
with partial reliability ,in which case the data would be discard ? If the application(send side) can know this .
my originally plan is : the application can make a async stream channel using TCP arithmetic , use NetStream.send() for lower IO, if packet is lost, I can detected by ack or sack , and I can controll the my cwnd and buffer