I've just tested this locally, just monitoring signals emitted by telepathy-salut using `dbus-monitor sender=org.freedesktop.Telepathy.ConnectionManager.salut`, and the right signals seem to be emitted when a Salut contact disconnects. (With the caveat that, because I only have one machine on me, the contact is a copy of Pidgin running on the same machine—but it should be equivalent as far as Salut is concerned.)

I'm using Salut 0.8.0 (as you are) and telepathy-glib 0.18.1 (which supposedly has no changes related to this compared to 0.18.0). Could you post your Python code exhibiting the issue?

Here's the dbus-monitor log from doing the following:

• Sign in with Empathy and Pidgin;
• Run `dbus-monitor sender=org.freedesktop.Telepathy.ConnectionManager.salut`;
• Quit Pidgin.

You can see that a presence update to offline and the ContactsChanged signals are all emitted as expected.

signal sender=:1.2265 -> dest=(null destination) serial=178 path=/org/freedesktop/Telepathy/Connection/salut/local_xmpp/wjt; interface=org.freedesktop.Telepathy.Connection.Interface.Presence; member=PresenceUpdate
   array [
      dict entry(
         uint32 2
         struct {
            uint32 0
            array [
               dict entry(
                  string "offline"
                  array [
                  ]
               )
            ]
         }
      )
   ]
signal sender=:1.2265 -> dest=(null destination) serial=179 path=/org/freedesktop/Telepathy/Connection/salut/local_xmpp/wjt; interface=org.freedesktop.Telepathy.Connection.Interface.SimplePresence; member=PresencesChanged
   array [
      dict entry(
         uint32 2
         struct {
            uint32 1
            string "offline"
            string ""
         }
      )
   ]
signal sender=:1.2265 -> dest=(null destination) serial=180 path=/org/freedesktop/Telepathy/Connection/salut/local_xmpp/wjt/ContactList/subscribe; interface=org.freedesktop.Telepathy.Channel.Interface.Group; member=MembersChanged
   string ""
   array [
   ]
   array [
      uint32 2
   ]
   array [
   ]
   array [
   ]
   uint32 0
   uint32 0
signal sender=:1.2265 -> dest=(null destination) serial=181 path=/org/freedesktop/Telepathy/Connection/salut/local_xmpp/wjt/ContactList/subscribe; interface=org.freedesktop.Telepathy.Channel.Interface.Group; member=MembersChangedDetailed
   array [
   ]
   array [
      uint32 2
   ]
   array [
   ]
   array [
   ]
   array [
      dict entry(
         string "contact-ids"
         variant             array [
            ]
      )
   ]
signal sender=:1.2265 -> dest=(null destination) serial=182 path=/org/freedesktop/Telepathy/Connection/salut/local_xmpp/wjt/ContactList/publish; interface=org.freedesktop.Telepathy.Channel.Interface.Group; member=MembersChanged
   string ""
   array [
   ]
   array [
      uint32 2
   ]
   array [
   ]
   array [
   ]
   uint32 0
   uint32 0
signal sender=:1.2265 -> dest=(null destination) serial=183 path=/org/freedesktop/Telepathy/Connection/salut/local_xmpp/wjt/ContactList/publish; interface=org.freedesktop.Telepathy.Channel.Interface.Group; member=MembersChangedDetailed
   array [
   ]
   array [
      uint32 2
   ]
   array [
   ]
   array [
   ]
   array [
      dict entry(
         string "contact-ids"
         variant             array [
            ]
      )
   ]
signal sender=:1.2265 -> dest=(null destination) serial=184 path=/org/freedesktop/Telepathy/Connection/salut/local_xmpp/wjt; interface=org.freedesktop.Telepathy.Connection.Interface.ContactList; member=ContactsChangedWithID
   array [
   ]
   array [
   ]
   array [
      dict entry(
         uint32 2
         string "pidjt@queeg"
      )
   ]
signal sender=:1.2265 -> dest=(null destination) serial=185 path=/org/freedesktop/Telepathy/Connection/salut/local_xmpp/wjt; interface=org.freedesktop.Telepathy.Connection.Interface.ContactList; member=ContactsChanged
   array [
   ]
   array [
      uint32 2
   ]

Thanks Will.
That works on my side as well.

However, the problem  comes up when there are two different physical machines, connected only by a (telepathy-salut) wifi network.

I don't think it is necessary, but when I say that the buddy gets disconnected from the (telepathy-salut) network, I mean to say that there is no link between the (earlier) buddy-machine and the wifi AP. 

Please let me know if any other information is required.

Thanks Will for the reply. I am grateful.

(In reply to comment #2)
> I don't think it is necessary, but when I say that the buddy gets disconnected
> from the (telepathy-salut) network, I mean to say that there is no link between
> the (earlier) buddy-machine and the wifi AP.

Ah, so this is what I was missing. Sure enough, there doesn't seem to be any immediate notification. Avahi doesn't give Salut any indication. I don't know how Avahi is supposed to deal with this—I would personally expect the contacts to disappear after a while, but I don't know what that timeout should be, or whether Avahi does this.

(In reply to comment #3)
> Sure enough, there doesn't seem to be any
> immediate notification. Avahi doesn't give Salut any indication. I don't know
> how Avahi is supposed to deal with this—I would personally expect the contacts
> to disappear after a while

If the contact deliberately goes offline (e.g. Telepathy Disconnect() method or setting their IM status to Offline), you should see them disappear straight away, as Will did, because Avahi sends an mDNS "goodbye" packet. If they just disconnect from wifi, Avahi doesn't get a chance to do that - by the time it finds that connectivity has been lost, it's too late for it to send "goodbye", because it has already lost connectivity!

What ought to happen is that the contact is considered to be present until the TTL (time-to-live) of the mDNS record runs out; then you should see the contact disappear.

https://tools.ietf.org/html/draft-cheshire-dnsext-multicastdns-15#section-10 suggests that the time-to-live of the mDNS record is likely to be 120 seconds, although we might set it to something else in Salut.

(In reply to comment #4)
> https://tools.ietf.org/html/draft-cheshire-dnsext-multicastdns-15#section-10
> suggests that the time-to-live of the mDNS record is likely to be 120 seconds,
> although we might set it to something else in Salut.

Salut doesn't change the TTL from the default. However, PTR records in Avahi seem to get a TTL of 75 minutes, by using AVAHI_DEFAULT_TTL instead of AVAHI_DEFAULT_TTL_HOST_NAME:

/** The default TTL for RRs which contain a host name of some kind. */
#define AVAHI_DEFAULT_TTL_HOST_NAME (120)

/** The default TTL for all other records. */
#define AVAHI_DEFAULT_TTL (75*60)

The Internet-Draft says:

   As a general rule, the recommended TTL value for Multicast DNS
   resource records with [...] a host name contained within the resource
   record's rdata (e.g. SRV, reverse mapping PTR record, etc.) SHOULD be
   120 seconds.

so this is probably an Avahi bug?

(In reply to comment #4)
> (In reply to comment #3)
> > Sure enough, there doesn't seem to be any
> > immediate notification. Avahi doesn't give Salut any indication. I don't know
> > how Avahi is supposed to deal with this—I would personally expect the contacts
> > to disappear after a while
> 
> If the contact deliberately goes offline (e.g. Telepathy Disconnect() method or
> setting their IM status to Offline), you should see them disappear straight
> away, as Will did, because Avahi sends an mDNS "goodbye" packet. If they just
> disconnect from wifi, Avahi doesn't get a chance to do that - by the time it
> finds that connectivity has been lost, it's too late for it to send "goodbye",
> because it has already lost connectivity!

I had exactly the same intuition !!





> 
> What ought to happen is that the contact is considered to be present until the
> TTL (time-to-live) of the mDNS record runs out; then you should see the contact
> disappear.

Me too thought on similar lines. 

That's why, I had enquired that whether we do need the unstable, experimental http://telepathy.freedesktop.org/spec/Connection_Interface_Keepalive.html :)






> 
> https://tools.ietf.org/html/draft-cheshire-dnsext-multicastdns-15#section-10
> suggests that the time-to-live of the mDNS record is likely to be 120 seconds,
> although we might set it to something else in Salut.

(In reply to comment #5)
> (In reply to comment #4)
> > https://tools.ietf.org/html/draft-cheshire-dnsext-multicastdns-15#section-10
> > suggests that the time-to-live of the mDNS record is likely to be 120 seconds,
> > although we might set it to something else in Salut.
> 
> Salut doesn't change the TTL from the default. However, PTR records in Avahi
> seem to get a TTL of 75 minutes, by using AVAHI_DEFAULT_TTL instead of
> AVAHI_DEFAULT_TTL_HOST_NAME:
> 
> /** The default TTL for RRs which contain a host name of some kind. */
> #define AVAHI_DEFAULT_TTL_HOST_NAME (120)
> 
> /** The default TTL for all other records. */
> #define AVAHI_DEFAULT_TTL (75*60)
> 
> The Internet-Draft says:
> 
>    As a general rule, the recommended TTL value for Multicast DNS
>    resource records with [...] a host name contained within the resource
>    record's rdata (e.g. SRV, reverse mapping PTR record, etc.) SHOULD be
>    120 seconds.
> 
> so this is probably an Avahi bug?

Thanks a ton Simon for your technical analysis.

So, what would you suggest ::

a)
Should telepathy change the TTL to "AVAHI_DEFAULT_TTL_HOST_NAME" (if possible) for all  cases ?


b)
Should Avahi change the TTL to "AVAHI_DEFAULT_TTL_HOST_NAME" for all cases ?
If yes, what is the bugtracker/mailing-lists for Avahi?



c)
If either of a) or b) is followed, would it cause one of the exisiting telepathy signals' callbacks to be hit? (for http://telepathy.freedesktop.org/spec/Connection_Interface_Contact_List.html#Signal:ContactsChangedWithID ??)



d)
Any how, if this is a simple fix, please do let me know the approach to be followed. I will be too happy to come up with a patch :D :D


Thanks again Will and Simon for your time.



Regards,
Ajay

Hi all.

Changing the default timeout values to a lesser value (20 seconds) did help.
So, now I am curious as to how these values could be customized on the fly, without rebuilding the RPMS again and again.

Posted the query at avahi mailing-lists at http://lists.freedesktop.org/archives/avahi/2012-July/002153.html


Will be grateful to hear back, in case some angel have a suggestion already :)


Thanks and Regards,
Ajay

Just found about /etc/avahi/avahi-daemon.conf.
That would do it !!! (of course after patching avahi to read-in the two new values).

Wrote the patch to make the TTL values configurable, found at
http://people.sugarlabs.org/ajay/root/freedesktop_bug_51501/common-patch-for-f14-and-f17/


The corresponding Fedora-14 and Fedora-17 rpms can be found at ::
http://people.sugarlabs.org/ajay/root/freedesktop_bug_51501/platforms/f14/RPMS/
http://people.sugarlabs.org/ajay/root/freedesktop_bug_51501/platforms/f17/RPMS/


I will be happy to receive some feedback :) :)

This is what Avahi guys have to say ::

http://www.mail-archive.com/avahi@lists.freedesktop.org/msg01896.html

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/telepathy/telepathy-salut/issues/38.