when an xo loses connection, how long does it take to disappear from other's neighbor view?

Thu Nov 8 03:21:05 EST 2007

Yes, i have seen this ticket in the past. To detect whether an XO is
actually there or not, is a simple task to accomplish, and I am currently
working on a simple script that will give a list of the properly connected
XOs, along with the temporarily disconnected.

It is a very useful idea to display this information in the neighbor view,
in terms of a dotted line, or a grey color perhaps.  The problem is that the
bugs are dealt with according to priority, and generally enhancements
although very practical, can cause  other bugs, or take several builds until
they work properly.

Since we are in "code freeze", a quick solution must be implemented to solve
the current situation, ie that it takes up to an hour for a disconnected xo
to dissapear(just reported as #4735).

yani

On Nov 7, 2007 5:49 PM, Eben Eliason <eben.eliason at gmail.com> wrote:

> > > 1. We need to fix the timeout for icons to disappear. Can we try
> Guillaume's
> > > patch?
> >
> > I hope so. I have a tarball with the patch, but I'm still waiting for
> > Update.1 approval (it's unclear whether I can build RPMs for Joyride
> > before I get Update.1 approval or not). If you're at 1CC, could you
> please
> > annoy the ApprovalForUpdate people in person until they either look at
> their
> > bugs, or confirm whether I'm still allowed to build RPMs in Koji?
>
> Just a mention, since this thread is getting a lot of attention. There
> is an added visual element which should be in play here, according to
> the design.  There should be an intermediate state before XOs
> disappear from the view, as outlined in:
>
> http://dev.laptop.org/ticket/3657
>
>
> > > 2. We need to be able to restart PS. As you say this is not possible,
> but if
> > > we restart sugar will PS restart as well?
> >
> > Yes, that's right (the D-Bus session bus will exit, which causes
> > D-Bus services like PS to exit too unless they've specifically asked not
> to).
> >
> > I see you assigned the bug about "need to be able to cope with PS
> restarts" to
> > yourself. Unless you're planning to implement the necessary Python code
> > in sugar.presence yourself, please don't.
> >
> > I don't think it's feasible to implement correct handling of PS restarts
> in
> > sugar.presence for Update.1, so unless the release engineering team
> > specifically tell me to, I won't be addressing that bug until a later
> > release.
> >
> > > 3. We need to force gabble to run. We have several instances of 4193
> (almost
> > > all XOs connected to schoolserver,AP are running salut). Or at least
> to
> > > force trying to connect to jabber server.
> >
> > Please see my comments on #4193 regarding steps to take to debug (I
> think
> > it's #4193 I commented on - I can't remember bug numbers, and Trac is
> > down at the moment).
> >
> > In summary:
> >
> > * try resolving the server with "getent hosts jabber.laptop.org"
> > * try pinging it with "ping jabber.laptop.org"
> > * try connecting via TCP with "telnet jabber.laptop.org 5222"
> >   (type "hello" and press Enter, if all goes well you should get
> disconnected
> >   with an error message that mentions "XML not well formed")
> >
> > If any of these steps fail, Gabble won't be able to connect either, and
> > there's nothing Gabble can do about it - talk to the Network Manager
> > maintainer instead, since that's the component responsible for getting
> > network connectivity and DNS on the XO.
> >
> > If you check the Gabble log you'll probably find that Gabble is trying
> > to connect, but failing because either it can't resolve
> > jabber.laptop.org in DNS, or it can't get a TCP connection there. That
> was my
> > diagnosis of two of the cases you mentioned in your bug with 3 sets of
> logs
> > (which may have been #4193?). In the third case it looked as though you
> hadn't
> > waited long enough for the log to indicate success or failure.
> >
> > > 4. The process of trying to connect to the jabber server, is done by
> > > telepathy-gabble, or by the presence
> >
> > Depends what you mean. The Presence Service is responsible for choosing
> when
> > to try to connect (at which time it calls the Connect() D-Bus method
> > on Gabble), but it's Gabble that actually opens a TCP socket to the
> Jabber
> > server and tries to talk to it. You can see this in the PS log, for
> > instance:
> >
> > 1194431620.966651 DEBUG s-p-s.telepathy_plugin: <ServerPlugin object at
> > 0x85f1e14 (telepathy_plugin+TelepathyPlugin at 0x82c8fb0)>:
> connecting...
> > 1194431620.967008 DEBUG s-p-s.telepathy_plugin: <ServerPlugin object at
> > 0x85f1e14 (telepathy_plugin+TelepathyPlugin at 0x82c8fb0)>: Connect()
> > succeeded
> >
> > (note that "Connect() succeeded" is a bit misleading - it just means
> > that the connection manager has said "OK, I'll try", rather than that it
> > has actually been able to connect.)
> >
> > In the telepathy-gabble log you'll then see something like this:
> >
> > ** (telepathy-gabble:25330): DEBUG: do_connect: calling
> lm_connection_open
> > Going to connect to olpc.collabora.co.uk
> > Trying 195.10.223.134 port 5222...
> > ** (telepathy-gabble:25330): DEBUG: tp_base_connection_change_status:
> > was 4294967295, now 1, for reason 1
> > ** (telepathy-gabble:25330): DEBUG: tp_base_connection_change_status:
> > emitting status-changed to 1, for reason 1
> >
> > (here status 4294967295 means "haven't tried to connect yet", status 1
> means
> > "connecting", reason 1 means "by user request")
> >
> > If the TCP connection succeeds, in the telepathy-gabble log you'll see:
> >
> > Connection success.
> > SEND:
> > - -----------------------------------
> > <?xml version='1.0' encoding='UTF-8'?>
> > - -----------------------------------
> >
> > Some XMPP handshaking will follow.
> >
> > Finally, when Gabble has finished doing its initial setup on the
> > connection, it will signal that it's become connected:
> >
> > ** (telepathy-gabble:25330): DEBUG: tp_base_connection_change_status:
> > was 1, now 0, for reason 1
> > ** (telepathy-gabble:25330): DEBUG: tp_base_connection_change_status:
> >  emitting status-changed to 0, for reason 1
> >
> > (here status 0 means "connected")
> >
> > and the Presence Service will receive the StatusChanged signal via
> D-Bus:
> >
> > 1194431621.473412 DEBUG s-p-s.telepathy_plugin: <ServerPlugin object at
> > 0x85f1e14 (telepathy_plugin+TelepathyPlugin at 0x82c8fb0)>: connected
> >
> >     Simon
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.4.6 (GNU/Linux)
> > Comment: OpenPGP key: http://www.pseudorandom.co.uk/2003/contact/ or
> pgp.net
> >
> > iD8DBQFHMaGcWSc8zVUw7HYRAjPOAKDuLi+Vp04s8aGs9pbGQ8Lkr8fwzgCgxaza
> > ipqZMRnw9vKHTYTJT+e96qg=
> > =vEu4
> > -----END PGP SIGNATURE-----
> > _______________________________________________
> > Devel mailing list
> > Devel at lists.laptop.org
> > http://lists.laptop.org/listinfo/devel
> >
> _______________________________________________
> Devel mailing list
> Devel at lists.laptop.org
> http://lists.laptop.org/listinfo/devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.laptop.org/pipermail/devel/attachments/20071108/32e5ca7d/attachment.html>