[avahi] Is it possible to customize "#define AVAHI_DEFAULT_TTL_HOST_NAME" and "#define AVAHI_DEFAULT_TTL", rather than embedding them "statically" in the code?

Ajay Garg ajaygargnsit at gmail.com
Tue Jul 10 08:17:17 PDT 2012


Thanks Patrick for the reply.


On Tue, Jul 10, 2012 at 11:38 AM, Patrick Oppenlander <
pattyo.lists at gmail.com> wrote:

>
>
>
> On Tue, Jul 10, 2012 at 4:55 AM, Patrick Oppenlander <
> pattyo.lists at gmail.com> wrote:
>
>>  On 05/07/12 20:19, Ajay Garg wrote:
>>
>> Hi all.
>>
>> I ran into a issue, as described at
>> https://bugs.freedesktop.org/show_bug.cgi?id=51501
>>
>>
>>  This behaviour is not a bug. It's a side-effect of how MDNS is
>> (intentionally) designed.
>>
>> Your bug report states that the callback is not called. It will in fact
>> be called, it just takes a long time.
>>
>
>
> Yes, I think it would.
> But the callback is not called after 120 seconds. May be after 75
> minutes.. but I haven't waited that long enough :)
>
> Also, as per
> https://tools.ietf.org/html/draft-cheshire-dnsext-multicastdns-15#section-10,
> the standard says that the timeout is expected to be 120 seconds.
>
>
> I think you're misunderstanding how the TTLs are used. the 120 seconds
> refers to host specific records -- i.e. records that are available after a
> resolve. A client application is not notified when these records expire as
> they are transient.
>
> The 75 minute TTL is for everything else, including PTR records, which is
> what you are interested in.
>
> I've never used Telepathy so I can't really offer suggestions on how to
> proceed with your issue, but keep in mind that DNS-SD was never designed to
> provide an iron-clad guarantee that a service is available. The only way to
> determine that a service is genuinely available is to first resolve it, and
> if the resolve succeeds attempt to connect.
>


Yes, that's right.

But the use-case we need to handle (getting to know when a client has
disconnected from the telepathy-salut network) wouldn't be solved by this.
Therein, we need to have a mechanism by which the dis-connectivity may be
known. Unfortunately, polling (or pseudo-polling) is the only ultimate way
(since the going-disconnected-buddy doesn't give the "goodbye" signal,
since no network-medium is available).


So, perhaps a client notification *should* get notified, once the
transient-resolved-records expire??!!



Just my 2 cents :)



Thanks and Regards,
Ajay







>         Patrick
>
>
> _______________________________________________
> avahi mailing list
> avahi at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/avahi
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/avahi/attachments/20120710/65f64cca/attachment-0001.html>


More information about the avahi mailing list