Ticket #185 (closed defect: fixed)

Opened 1 year ago

Last modified 1 year ago

Avahi drops service browser events

Reported by: MathiasHasselmann Assigned to: lennart
Priority: major Milestone: Avahi 0.6.22
Component: avahi-client Version:
Keywords: Cc:

Description

Avahi drops service browser events when re-anouncing services. Attached there is a minimal test case demonstrating the problem. Current behavior is: 

mathias@pergamaunz:~/Desktop$ ./avahi-bug2 
/usr/bin/gcc avahi-bug2.c -o avahi-bug2 -Wall -D_REENTRANT -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -lavahi-glib -lglib-2.0 -lavahi-common -lavahi-client
service_browser_cb: b=0x804bd70, e=2(cache-exhausted), n=(null), t=_yadda._sub._test._tcp
service_browser_cb: b=0x804bd70, e=0(new), n=YaddaTest, t=_test._tcp
service_browser_cb: b=0x804bd70, e=3(all-for-now), n=(null), t=_yadda._sub._test._tcp
kill_cb: using immediate strategy

mathias@pergamaunz:~/Desktop$ IDLE=1 ./avahi-bug2 
service_browser_cb: b=0x804bd70, e=2(cache-exhausted), n=(null), t=_yadda._sub._test._tcp
service_browser_cb: b=0x804bd70, e=0(new), n=YaddaTest, t=_test._tcp
service_browser_cb: b=0x804bd70, e=3(all-for-now), n=(null), t=_yadda._sub._test._tcp
kill_cb: using idle strategy

mathias@pergamaunz:~/Desktop$ DELAY=1 ./avahi-bug2 
service_browser_cb: b=0x804bd70, e=2(cache-exhausted), n=(null), t=_yadda._sub._test._tcp
service_browser_cb: b=0x804bd70, e=3(all-for-now), n=(null), t=_yadda._sub._test._tcp
service_browser_cb: b=0x804bd70, e=0(new), n=YaddaTest, t=_test._tcp
kill_cb: using delay strategy
service_browser_cb: b=0x804bd70, e=1(remove), n=YaddaTest, t=_test._tcp
service_browser_cb: b=0x804bd70, e=0(new), n=YaddaTest, t=_test._tcp

The cases with immediate and idle strategy do not see the AVAHI_BROWSER_REMOVE and the AVAHI_BROWSER_NEW event, whereas they should.

Attachments

avahi-bug2.c (2.8 kB) - added by MathiasHasselmann on 12/05/07 18:28:47.

Change History

12/05/07 18:28:47 changed by MathiasHasselmann

  • attachment avahi-bug2.c added.

12/17/07 14:44:52 changed by lennart

  • status changed from new to assigned.

I think the current Avahi behaviour on this is the correct behaviour. The service browser will inform you only about services coming and going, not about changing service data. It will collapse as many events as possible to minimize traffic, which is what you are seeing here: instead of seperate REMOVE and NEW ther two events are merged and dropped because redundant. If you want to subscribe to changes of the service data itself, then use AvahiServiceResolver? and keep it open.

The background of this:

The AvahiServiceBrowser? looks only for PTR RRs, and how they come and go. The AvahiServiceResolver? looks for SRV, TXT, A, and AAAA RRs. If the latter RR change, the browser will not be notified about that. The whole point of the separation of the "browsing" and "resolving" step is to minimize traffic. If we'd modify the browser to signal service data changes as well, then we'd have to look for all mentioned RR types all the time, which would have detrimental effect on the generated traffic.

I will add some text about this to the documentation, in the hope to void further confusion.

12/17/07 15:14:40 changed by lennart

  • status changed from assigned to closed.
  • resolution set to fixed.

(In [1597]) rework documentation a bit, and explain the issues pointed out in #185 by Mathias Hasselmann, Closes #185