[avahi] Resolving many ( > 200 ) items seems to lead to apparent congestion in the dbus
Daniel Wynne
daniel.wynne at mobotix.com
Fri Oct 16 00:03:11 PDT 2009
Hey Guys!
Really dont want to be annoying, but it would be really nice if we could
get at least one reliable statement from somebody responsible regarding
the issue below.
Thanx
Daniel
> Hi again!
>
> Is there anyone responsible available who is capable of answering my
> previous question? Everybody on vacation? ;-)
>
> Kind Regards
>
> Daniel
>
>
>
> Daniel wrote:
>
>> Hi Folks,
>>
>> just returning from my summer vacation I reflected about past projects.
>>
>> Thereby I also wondered about our little conversation concerning Avahi
>> cache sizes.
>>
>> Trent, you made those promising hints that you will loosen the strict
>> limitations to meet requirements of larger network implementations.
>>
>> Could you, or any other responsible person please make a definite
>> authorative statement about this issue so we can proceed with development?
>> Me and my boss would be very appreciated about this ;-)
>>
>> Kind Regards
>>
>> Daniel
>>
>>
>> Daniel wrote:
>>
>>
>>> Hi Trent!
>>>
>>> These are great news for us! :-)
>>> We were seriously concerned about the issue, that the Avahi mDNS
>>> implementation prevented us from developing Linux camera management
>>> applications for huge setups.
>>>
>>> In the following I provide a short calculation to give you a hint of
>>> what we need:
>>>
>>> - Right now we have setups with deployments of up to 800 devices We
>>> do not think that deployments with even more devices in one network make
>>> sense, as this already can be considered as a individual feasibility
>>> study. But lets calculate with this worst case scenario and for the sake
>>> of convenience we even round it up to N = 1000 devices per network.
>>>
>>> - Since every device typically comes up with 2-3 ip addresses, we
>>> have to reserve cache entries for N*( 3 A's, 1 PTR, 1 SRV, 1 TXT. ) =>
>>> AVAHI_CACHE_ENTRIES_MAX >= 6*N = 6000 entries.
>>>
>>> - As the dbus limitations are concerned the maximum number of dbus
>>> objects per client will have to be increased, too. Since we have to
>>> create N*3 AddressRecordBrowsers, N*1 ServiceResolver, 1 Client, 2
>>> ServiceBrowsers => OBJECTS_PER_CLIENT_MAX >= 4*N + 3 = 4003 ~ 4000 entries
>>>
>>> As I do not have that much insight into the Avahi-code there might be
>>> even more limits that might have to be adapted to achieve a coherent
>>> configuration.
>>>
>>> If you need any additional information, let me know.
>>>
>>> Thank you Guys for the great support so far!
>>>
>>> Kind Regards
>>>
>>> Daniel
>>>
>>>
>>> Trent Lloyd wrote:
>>>
>>>
>>>
>>>> FWIW, I've always felt this was a little restrictive as well but never
>>>> really ran into it in production.
>>>>
>>>> I am personally keen on upping them a little - Daniel, can you tell us
>>>> what values seem to work well for you?
>>>>
>>>> Thanks,
>>>> Trent
>>>>
>>>> On 27/06/2009, at 12:04 AM, Daniel Wynne wrote:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> Hi Lennart!
>>>>>
>>>>> After a short interrupt I am back in avahi-business ;-)
>>>>>
>>>>> PLaying around a little bit with parameters I boiled it down to
>>>>> AVAHI_CACHE_ENTRIES_MAX
>>>>> OBJECTS_PER_CLIENT_MAX
>>>>>
>>>>> These Parameters are slightly tight I think when it comes to bigger
>>>>> networks i.e. more than 100 Services.
>>>>>
>>>>> You said these limitations are implemented to avoid misuse, i.e.
>>>>> DOS-Attacks.
>>>>>
>>>>> Do you think it is possible in future releases of Avahi to loosen
>>>>> these
>>>>> limitations a little bit, to enable more comprehensive usage of Avahi,
>>>>> even for professional applications like ours ;-)
>>>>> DOS Attacks are way above the limitations of 500, even way above
>>>>> 5000. I
>>>>> think when talking about DOS we are in millions and above.
>>>>>
>>>>> What do you say?
>>>>>
>>>>> Kind Regards
>>>>>
>>>>> Daniel
>>>>>
>>>>>
>>>>>
>>>>> On Sun, 2009-06-07 at 01:47 +0200, Lennart Poettering wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> On Thu, 28.05.09 13:43, Daniel Wynne (daniel.wynne at mobotix.com)
>>>>>> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> But I think thats exactly the problem in our case. In our
>>>>>>> Testnetwork
>>>>>>> reside about 250 cameras we want to find and resolve via Avahi. So
>>>>>>> the
>>>>>>> cache is way big enough.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> No. The limit of 500 entries in the cache that Avahi enforces is for
>>>>>> RRs, not services or hosts.
>>>>>>
>>>>>> For each service you need (at least) one A, one PTR one SRV and one
>>>>>> TXT RR. Usually even more. I.e. if you register 250 services and want
>>>>>> to browser for them all at the same time you need as absolute minimum
>>>>>> space for 1000 entries, and practically even more.
>>>>>>
>>>>>> Lennart
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> _______________________________________________
>>>>> avahi mailing list
>>>>> avahi at lists.freedesktop.org
>>>>> http://lists.freedesktop.org/mailman/listinfo/avahi
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>> _______________________________________________
>>>> avahi mailing list
>>>> avahi at lists.freedesktop.org
>>>> http://lists.freedesktop.org/mailman/listinfo/avahi
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>> _______________________________________________
>> avahi mailing list
>> avahi at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/avahi
>>
>
> _______________________________________________
> avahi mailing list
> avahi at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/avahi
>
--
---------------------------------------------------------------------
Daniel Wynne, Softwareentwicklung
MOBOTIX AG - Security Vision Systems
Kaiserstrasse, 67722 Langmeil
---------------------------------------------------------------------
daniel.wynne at mobotix.com, http://www.mobotix.com
---------------------------------------------------------------------
Vorstandvorsitzender: Dr. Ralf Hinkel
Vorstandsmitglieder: Lutz Coelen
Aufsichtsratsvorsitzender: Dr. Thomas Hoch
Registergericht: HRB Kaiserslautern 3724
More information about the avahi
mailing list