On Mon, Oct 5, 2009 at 2:58 PM, Stefan Langer <[email protected]>wrote:
> Shouldn't the underlying transportation protocol take care of congestion > control? > I think the server should simply indiciate overload and reduce the number > of packets it can accept. > Now I'm not too familiar with the XMPP protocol but I would assume that it > has build in features to indicate overload. > > Overload can happen at different points depending on clients, right now we are seeing waves with 500+ blips, it is not unlikely that the future will bring waves with 100's of concurrently editing participants of a wave, to what extent we just 'give up' on that scenario I don't know. The issue not so much a question of server overload as client overload, thats a boat load of bandwidth and processing demand especially for mobile devices. We could end in a situation where we narrow the fidelity of the information of the larger wave and focus on blips that are in proximity to our viewport. Since blips are waves and vice versa (right?) we may be able to come up with a general solution. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Wave Protocol" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/wave-protocol?hl=en -~----------~----~----~----~------~----~------~--~---
