Opened 7 years ago

Closed 6 years ago

#3506 closed defect (fixed)

XOs connected to jabber server AND can link local don't share well

Reported by: kimquirk Owned by: dcbw
Priority: blocker Milestone: Future Release
Component: presence-service Version:
Keywords: review+ Cc: jg, morgs, j5, Eben, Collabora
Blocked By: Blocking:
Deployments affected: Action Needed:
Verified: no

Description

Build 581, q2c26

I have three laptops with the same build. I set them up to connect to a local school server mesh; and to 'register' to the jabber.laptop.org server. They are all in the same room, so they can clearly see each other via link local as well.

I booted all three units; two of them can see 8 laptops; the other 2 in the room and 6 others that must also be connecting to jabber.laptop.org.

One of my laptops can only see the other two local laptops; and none of the other laptops. Even though it is also 'registered' to jabber.laptop.org, it doesn't seem to be using that server.

When you try to share in this scenario (connect and memorize, for instance) things don't work properly. All laptops can see the shared activity, can open it, but turns don't happen properly. there is clearly some missing packets somewhere.

I repeated this exact test, but first setting the network manager 'mesh-start' to local; so the laptops never get on the school server mesh or AP. This is the case where the laptops see each other only (like working under a tree). In this case, each of the laptops saw the other two laptops and were able to share a game of connect.

I believe there is a request to turn off link local if there is a jabber server specified. Maybe this is a result of confusion as to whether all the laptops are on link local; or using jabber server.

Attachments (1)

mutually-exclusive-tp-plugins.patch (2.2 KB) - added by dcbw 7 years ago.

Download all attachments as: .zip

Change History (19)

comment:1 Changed 7 years ago by sjoerd

First of all. These things are hard to debug/fix without logs, as we can only guess what happened.

What is clear though is that one of your laptops didn't register correctly to the jabber server and thus wasn't able to see the nodes on the server.. Turning off link-local will only make the behaviour slightly different: If your the only one in a mesh who couldn't reach the jabber server, then you see nobody instead of just the others in your mesh.

What went wrong with the sharing is impossible without more info. Did you share the activity on one of the machines connected to the jabber server or on the one only seeing others on the mesh?

comment:2 Changed 7 years ago by morgs

  • Cc daf morgs added; dafyyd removed

Changed 7 years ago by dcbw

comment:3 Changed 7 years ago by dcbw

  • Status changed from new to assigned

There are two bugs fixed in this patch, one uncovered by the first.

1) Make the plugins mutually exclusive. When Gabble is active, Salut is disabled, and vice versa. Gabble takes precedence.

2) The changes in telepathy_plugin.py fix 3 bugs uncovered by the first fix
2a) When the gabble plugin is stopped when the machines IP address becomes invalid, the disconnected signal was never emitted, causing (1) above not to work correctly.
2b) self._conn must be cleared _after_ removing contacts, since removing the TP handle from the buddy requires self._conn.service_name to be valid
2c) Calling self._contacts_offline(self._online_contacts) passes that value by reference apparently, leading the code in _contacts_offline() to subtract self._contacts_online from itself, but oddly enough since 'handle' was just an alias to self._contacts_online, handle was also cleared by the -= operation, and therefore was blank when the 'contacts-offline' signal got emitted. Work around that by copying the values instead of passing a reference to self._contacts_online.

comment:4 Changed 7 years ago by dcbw

please review and + or - for trial-3 so we can stuff it into builds tomorrow

comment:5 Changed 7 years ago by dcbw

  • Priority changed from high to blocker

comment:6 Changed 7 years ago by dcbw

  • Component changed from network manager to presence-service

comment:7 Changed 7 years ago by gdesmott

  • Cc smcv gdesmott added

comment:8 Changed 7 years ago by morgs

  • Keywords review+ added

Dan, I've reviewed your patch and it looks fine as a short-term fix for T3. However we must relook at this after T3 because it's definitely not optimal.

Both plugins are usually started at the same time (when you are on an AP), and Salut normally connects first. The result could be that you see link local buddies appear who might not be on your server - and then they vanish a few seconds later when gabble connects and salut is stopped. I suppose there's no actual harm in that scenario because you probably aren't going to be able to start a link local shared activity in that time...

Also, PS was designed to run both CMs, and could be a lot simpler if we move away from that in the long term, so we need to figure out the long term plan.

comment:9 Changed 7 years ago by jg

OK, approved to go into Trial-3.

J5; once in, please retarget this to FRS so that we look at the longer term issues. Most likely it will end up being V1.1 fodder, but you never know.

comment:10 Changed 7 years ago by jg

  • Cc j5 added
  • Owner changed from dcbw to J5
  • Status changed from assigned to new

Oh, and reassign it back to dcbw.

comment:11 Changed 7 years ago by smcv

(I should note that turning off Salut like this when we have a server connection doesn't do anything to address any concerns you may have about network traffic caused by Salut - as I explained in an email thread a month or so ago, most of Salut's network traffic will already have happened by the time you connect to the server and turn Salut off.)

The fundamental UI problem here is that we don't give the child any indication or control of whether the activity will be shared locally, or on the server, we don't give them that information about activities they can see, and we don't show them whether they and their buddies can see the server or not; but the observable behaviour is inexplicably different, depending on these things.

I realise hiding irrelevant technical details from the children is a goal, but perhaps for 1.1 it would make things clearer if the sharing UI could distinguish between local and server sharing (People Near Me vs My School perhaps?), and add a badge or other scope indication to activities/buddies, or something?

comment:12 Changed 7 years ago by J5

  • Owner changed from J5 to dcbw

package in latest build

comment:13 Changed 7 years ago by marco

  • Milestone changed from Trial-3 to First Deployment, V1.0

Per Jim comment...

comment:14 Changed 7 years ago by tomeu

  • Cc s joerd Eben added; sjoerd removed

I think Eben would be interested in Simon's last comment.

comment:15 Changed 7 years ago by tomeu

  • Cc sjoerd added; s joerd removed

ups

comment:16 Changed 7 years ago by kimquirk

  • Milestone changed from First Deployment, V1.0 to V1.1

comment:17 Changed 7 years ago by gdesmott

  • Cc Collabora added; sjoerd daf smcv gdesmott removed

Any reason to keep this bug open? The "one CM connected at a time" seems sane and I doubt we'll consider to change it soon.
Objections?

comment:18 Changed 6 years ago by marco

  • Resolution set to fixed
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.