[avahi] limit on dbus client objects
lennart at poettering.net
Fri Oct 12 15:42:44 PDT 2007
On Fri, 12.10.07 09:58, Brian Gerkey (brian at gerkey.org) wrote:
> On Oct 11, 2007, at 5:02 PM, Lennart Poettering wrote:
> > On Thu, 04.10.07 10:13, Brian Gerkey (brian at gerkey.org) wrote:
> >> - Independent of the Zeroconf implementation that's being used, are
> >> there drawbacks in general to registering and browsing large numbers
> >> of services?
> > Yes. They cost resources, mostly in network traffic. The less you have
> > the less traffic is generated.
> > May I ask you to elaborate a little why you need so many services per
> > client?
> I'm adding service discovery to the Player robot device server, part
> of the Player Project (http://playerstage.sf.net), which I maintain.
> Each robot will advertise a handful of services (usually sensors,
> like lasers and cameras), so with real robots the resource limits are
> not a big deal: a few services per machine. But when working in
> simulation, I might have hundreds of simulated robots on a single
> machine, in a single process.
> I'd like to use the same service discovery scheme with real and
> simulated robots, so I need to resolve this service discovery
> resource issue somehow. Any advice? I could save a bit by bundling
> each robot's sensors into a single service per robot, but that won't
> be enough. I could save a lot by bundling all the (simulated) robots
> controlled by a single process into a single service. But then I
> have to implement a second-tier discovery mechanism to drill down
> inside each monolithic service to find out exactly what it's offering.
If you do this only for simulation it should be fine to increase the
limit in the dbus config file, wouldn't it?
Note however, that if you emulate this all on a single Avahi instance
only you well get different results then when running this with
multiple Avahi instances, because Avahi will be a lot more effecient
if it can merge as many messages as possible into a single packet then
if it would send them in seperate packages.
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
More information about the avahi