Martin Langhoff wrote: > Either way, this is going to be a nasty RF hog. How do we handle this > hogginess?
RealVNC's vncviewer seems to have a fairly smart adaptive congestion control, stepping down the frequency of updates as available bandwidth decreases. It doesn't solve the problem, but it might allow things to keep working without totally falling over. I've also looked at reducing the resolution, but haven't quite gotten client and server scaling in harmony. > - can we use multicast frames... and get the APs speeds bumped up to > do a "fast multicast" so as to not use up all the airtime? This would be really cool... but what happens if you miss a packet? VNC requires a reliable transport. I haven't looked into the multicast VNC implementations, so I don't know if they implement some sort of "reliable multicast". An obvious alternative would be to use a video codec (e.g. Theora) and do a live screencast. Video streams have keyframes so they can resync after lost packets. I tried this on an XO, and it was a bit slow, but it did work. > - if in the presence of an XS (with or without a reflector...) we can > use a simple "soft lock" so that only one session runs at any given > time? I suppose this helps when combined with multicast. With unicast VNC, it doesn't really matter. >> However, it is worth noting that WatchMe would be >> impossible to implement as an activity in a more secure Sugar system. > > Ah, so won't run with Rainbow, right? No, it runs fine with Rainbow. I'm merely noting that in a hypothetical "complete Bitfrost", it would require a special privilege boost, because otherwise it would not be able to see the pixels produced by Sugar and all the other activities.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
