1 person found this helpful
for best performance at this time, each message when serialized should not exceed 64KB. future releases of Flash Player and AIR may change this limit (this limit is an artifact of the current size of RTMFP message reassembly buffers; single messages longer than 127KB or back-to-back messages each longer than 64KB may not stream efficiently over real-world networks).
while there is no inherent bandwidth limit for posting in an RTMFP group, messages must be small enough so that they can be sent from one peer to another in a group within approximately 5 seconds, or the message will time out for that hop. example: for a 64KB (~500Kbit) message, there must be at least ~100Kbps of bandwidth between each node in the group in order for the message to make one hop in 5 seconds. obviously for smaller messages the bandwidth needed to transmit the message within 5 seconds is proportionately lower, which is why we recommend small messages.
the available bandwidth of peers determines the maximum achievable bandwidth in the group for both of the multicast-y modes (multicast streams and posting, posting being a multicast of a single message).
if you are going to have one node sending many messages for all nodes to receive, then multicast (using NetStream.send()) is more efficient and appropriate. if every node is going to send a message from time-to-time for all nodes to receive, then posting is more appropriate.
Thank you for your detailed and technical response!
you are going to have one node sending many messages for all nodes to receive, then multicast (using NetStream.send()) is more efficient and appropriate.
Oh, I didn't know it. So, With "send" method of one outgoing NetStream I can "multicast" data packet for a NetGroup (of course if "GroupSpecifer:multicastEnabled" is checked).
But unlike "post method", with "send multicast method" I can't hope to involve 1000 peers (only 30-200) if I understand.
group (p2p multicast) NetStreams are intended to work for any size group. i don't know where the "30-200" figure came from, unless you're thinking of 1:1 P2P NetStreams (where the publisher would send a separate copy to each subscriber).
Mmm exact, sorry, I misunderstood an another post on this forum! (English pb).
However, it says the following thing:
Support for live Application-Level Multicast — Allows a publisher to deliver a live media stream and scale the stream delivery as wide as needed. Application-level multicast reduces the load on a single publisher, and distributes the delivery over multiple peers. This functionality is designed for a small group of peers broadcasting large messages (i.e. higher bitrate data).
If million connections of peer is possible, is it the same thing for 1:million broadcasting? (with NetStream.send)
the wording in that quote is ambiguous, sorry.
Application Layer Multicast is designed for a small number of *publishers* in a group, where each one is publishing a continuous stream of data (such as live video/audio and data with NetStream.send()).
NetGroup.post() is a more appropriate mode when most or all of the members of a group will send messages from time-to-time.
in both cases, the size of the group is (supposed to be) irrelevant. if you have a group with a million members and just one of them is broadcasting/sending/publishing, then NetStream.send() and NetGroup.post() will both work.
there are tradeoffs between the two modes. the per-message overhead is higher for NetGroup.post() than for multicast NetStream.send(). however, there is significant overhead (memory/state at each peer) for each multicast NetStream, which is why it isn't appropriate for the million:million case. NetGroup.post() messages may arrive at peers in a different order than they were sent, whereas NetStream.send() messages are received by each peer in the order they were sent.
Thanx a lot for this rich and really comprehensive response!
You've created a technology that will change the face of the web...