It seems like this conversation is somewhat at cross-purposes. Martin discusses the general case of multicast from an arbitrary client through an access point serving many clients with a mixture of multicast and unicast traffic. Well known performance problems result. However, Geza proposes a special case (perhaps). In a classroom, it would be nice to be able to have a "projector" to send a stream of video to the stations within that classroom. Now, not every school could have extra hardware for this purpose, but I think many could, just as our schools of yore had that funky projector that got rolled into the classroom on the morning when our teacher wanted us to see (or sleep through :-) a movie about something or other. What might be interesting is to consider the possibiliity of connecting the projector client via a USB ethernet connector to a separate "multicast" access point, that the receiving clients associated with for the time of the "movie". This allows the originator of the stream to use a wired connection to the AP, the AP to be chosen and configured to optimize multicasting, and the whole thing to be somewhat isolated from the unicast traffic happening elsewhere. Not sure if this is workable, but some reading of the papers about multicast performance issues on the Intertubes suggest it might be promising. <div class="gmail_quote">On Sat, Apr 11, 2009 at 3:07 PM, Geza Kovacs <<a href="mailto:gkovacs@mit.edu">gkovacs@mit.edu</a>> wrote: <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Since you apparently have more experience with multicasting over wireless I'll assume it's not a realistic option in this context (though it might nevertheless be an interesting experiment to try if have spare time over the course of GSoC after finishing a unicast-based implementation). Returning to unicasting and simply limiting net bandwidth usage, as I understand the "slowest client sets the speed" issue with the access node switching to Mode1 for broadcast applies only to multicasting. If I have the XO send the video in a single UDP stream to the central XS server (which as I understand has a wired connection to the AP), then have those streams be individually relayed by the XS over the AP to each designated viewer in over unicast UDP, then as I understand the AP will be able to operate near its 56 Mbps net throughput limit, which, factoring in the fact that the effective throughput will be decreased due to noise and that my application of course can't hog all the bandwidth and airtime, means that I will have around 20 Mbps available for unicasting to all clients. Rather than limiting the number of viewers as I originally proposed, I believe that automatically limiting the framerate of the broadcast based on the number of viewers will be a better way to scale for larger numbers of viewers - that is, once the broadcaster gets to the "broadcast" stage and selects the intended viewers, then based on the available bandwidth and network congestion, then an ideal framerate is calculated out and the stream is encoded and broadcast to all of the viewers at that framerate. Given that the most interest has been expressed over the remote desktop broadcasting feature, and given that there's rather little motion overall on a desktop broadcast, the desktop activity should still be easily viewed at very low framerates.