1. the P2P multicast (group NetStream) system treats all NetStream data the same, so audio, video, and NetStream.send() messages all use the normal push/pull methods that Matthew described in his session at MAX 2009. short answer to your question: "yes".
2. i assume this is happening in the DIRECT_CONNECTIONS case. this is a known bug that will be addressed in a future release of Flash Player. the problem is that the NetStream.send() queue backs up when the corresponding RTMFP flow buffers fill up. once that happens, the NetStream queue(s) aren't polled again until a new event adds something to one of them. normally when you have a camera or microphone attached, the periodic video and audio frames provide a continuous poke at these queues to keep data moving into the RTMFP flows as the flows drain. i believe the RTMFP flow for NetStream.send() has a buffer size of 128KB.
the near-term workaround for this problem is to ensure that you periodically add new things to the NetStream in order to poke at the queue processor. without a camera or microphone, the best bet is to use a timer to drive the NetStream.send()s.
note that NetStream.dataReliable is true by default; that means NetStream.send() data will be sent with full reliablility on DIRECT_CONNECTIONS NetStreams.
multicast NetStreams are always partially reliable; the reliability is controlled by the NetStream.multicastWindowDuration parameter. if it takes longer than that to send your data, some must be discarded. example: the default window duration is 8 seconds. imagine you have one peer and your link to that peer is 100kbps. in 8 seconds you can send 800kb, or 100kBytes. if you send more than 100kB in 8 seconds, not all of the data will have gotten through before the window moves past and it is abandoned.
note also that as a new multicast stream starts up in the P2P mesh, the first few messages may be discarded in the interest of keeping latency low.
Great, thank you for your answer.It's very helpful to my project. Here are my further questions
1. According to what you said, does it mean all data that NetStream.send() delivers maybe arrive at each peer disorderly?
2. Currently, can my solution achieve the shortest latency for a live streaming application?
3. Will new version of FP be able to support live streaming function from non-webcam source in the near future?
4. I'm also considering perform p2p vod using object replication. But little details have been reported in any materials ever mentioned.
Can you tell me about the mechanism object replication uses? This may help me know what else should I implement such as
bitmap exchange and so on.
5. And can you give some advices or something that I should pay particular attention to when developing p2p vod?
Thank you very much for your help.
1. NetStream.send() data is delivered in the order it was sent, whether in client-server, DIRECT_CONNECTIONS, or multicast mode.
2. the lowest latency will be achieved with DIRECT_CONNECTIONS. however, that isn't scalable to large numbers of recipients. the P2P multicast system trades low latency for scalability.
3. there are no plans to support a natural NetStream streaming source that's not a camera/microphone. Flash Media Server can perform that function.
4. you should never need to implement "bitmap exchange"; the object replication system handles all the communication needed to accomplish its function. typically you will divide a file into segments, giving each one an index number. object replication uses ranges internally, so the index numbers should be contiguous. nodes that have indices use NetGroup.addHaveObjects(). nodes that want indices they don't have use NetGroup.addWantObjects(). nodes that have objects will send them to nodes that want the objects. when a node receives an object, it's automatically removed from its "want" set; once the node decides the object is acceptable, it adds it to its "have" set, at which point it can answer requests from other nodes who still "want" it. eventually every node will have all the pieces and not want any. for an example, please see Tom Krcha's articles on using object replication:
5. please see Tom Krcha's articles. for VOD you will probably want to use the "LOWEST_FIRST" replication strategy, as that may allow you to start playing earlier. for general file replication you'll get better sharing if you use RAREST_FIRST.
Now my main concern is whether my solution can meet the needs for live streaming. If I set NetStream.send() to FALSE, it will retransmit data for a limited time. How much is the limited time interval for FP to decide to retransmit data?
presumably you mean "if [you] set NetStream.dataReliable to false...". that setting is only effective for client-server or DIRECT_CONNECTIONS RTMFP NetStreams. when dataReliable is set to false, (currently) the reliability parameters are similar to "UDP-like best effort". specifically, the data will remain in the transmit queue for one second (or it won't be transmitted at all), and will not be retransmitted if lost after the first transmission.
NetStream.send() reliability for P2P multicast is determined by the NetStream.multicastWindowDuration property (just like all other multicast data). that setting controls how long the system will try to get pieces before giving up and moving on.
Sorry for my wrong typing. Now I have understand it. Thank you very much.