Ricardo, That is the current situation, and the chatter generated by Salut multiplied by mesh multicast really does prevent laptops from connecting through gabble. We did a recent test here where 20 laptops really melted down a single channel.
wad On Feb 14, 2008, at 2:39 PM, Ricardo Carrano wrote: > I am not sure I was clear. I meant: maybe it is not necessary to > turn it (salut) off _while_ trying to connect to gabble. If > connected to gabble, then stop salut. > Wouldn't this simplify matters? > > On Thu, Feb 14, 2008 at 3:44 PM, Ricardo Carrano > <[EMAIL PROTECTED]> wrote: > (e) make salut less chatty during this period (instead of stopping > it). > But I don't know if this is possible or how to do it. So it maybe > not a valid suggestion. > > But ... > > I think we have a time sensitive problem. Salut clogs the network > if there are many XOs running it. So, if you think of a scenario > where many XOs are _not_ turned on at the same time (or within a > certain time window) each XO will have an opportunity to switch to > gabble without the need to turn salut off. The network will be > naturally salut free. > > Maybe we don't need to turn salut off while trying to connect to > gabble. > > > > On Thu, Feb 14, 2008 at 3:19 PM, John Watlington <[EMAIL PROTECTED]> > wrote: > > On Feb 14, 2008, at 11:52 AM, Jim Gettys wrote: > > > > > On Thu, 2008-02-14 at 16:58 +0200, Morgan Collett wrote: > >> We're testing patches to Presence Service to not start salut (or > stop > >> it) for a while to give gabble a chance to connect to the > >> schoolserver. > >> > >> However, Daf came across what was a very minor problem which > becomes > >> more serious in light of this change. > >> > >> Many activities are calling PS get_preferred_connection() to > interact > >> directly with the appropriate Telepathy Connection Manager, > which was > >> required in the past before we expanded Presence Service's > >> management of > >> setting up channels for activities. > >> > >> However, during the period when we stop salut to let gabble try to > >> connect, this call fails as there is no running plugin in PS. If an > >> activity is launched during this time (and there's no particular > >> UI to > >> show this other than no buddies in mesh view) and it makes this > >> call in > >> __init__ as most of them do, then it will crash with a gray screen. > >> > >> This affects: Calculate, Chat, Pippy, Record, Web and Write (of the > >> activities we bundle) and potentially other non-bundled activities. > > > > Ouch... > > > > Seems like this is something we're going to have to fix pretty > quickly > > no matter what. > > > >> > >> Our options are: > >> > >> (a) Touch all these activities now and port them to the newer > cleaner > >> API offered by PS/Sugar > > > > How big are the diffs? Does this simplify the code? > > > >> (b) Don't do #6299 for Update.1, but do it and (a) for Update1.1 > > > > This would be pretty much immediately, anyway. > > > >> (c) Find some way for the call to get_preferred_connection to fail > >> gracefully (We can't think of one so far) > >> (d) Make a UI change to let the children know not to launch > >> activities > >> during this time period\ > > (d) might be the simplest to implement in the required time frame. > > > Let me ask a different question: what happens to activities already > > running which are running shared? Are they going to fail? > > Presumably, > > yes.... > > It sounds like any activity trying to share until either gable > connect to a server > or gives up and starts salut is going to crash. This either happens > on boot or > when a user manually switches networks. > > wad > > > _______________________________________________ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel > > > _______________________________________________ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel