[avahi] Local only services

[Yavor Goulishev]

Hi Lennart,
It is not that ugly shortcut ;-), but yeah this is a hack.(BTW Bonjour is
doing it in similar way. Nothing goes on the network for local services.
Everything is in memory. I don't know their reasons, but I sure do know
mine.)

Reading through  your  plan for  this  I recall removing the code for
filtering the interfaces.
And I also recall having problems using the loopback interface to do the
multicast.
It might be just me, but I couldn't get this working and I've seen comments
that the kernel doesn't route multicast messages on the loopback interface.
Frankly I haven't confirmed this myself, but definitely couldn't get it to
work.

Another thought just came to my mind. The loopback interface is actually
addressable with index 1.
I'm not sure whether this is is always the case, but at least on my testing
index 1 was always the loopback.

So if the loopback can be used (and I'm wrong about the kernel) and the
loopback is always addressable with index 1 then the avahi-core can use it
if nothing else is available or if explicitly requested. This shouldn't be
hard to code, right?

--Yavor


On Feb 13, 2008 2:57 AM, Lennart Poettering <lennart at poettering.net> wrote:

> On Tue, 12.02.08 12:07, Yavor Goulishev (ygoulishev at gmail.com) wrote:
>
> >  Great!
> > I really need this feature.
> > BTW I tried implementing something, but I'm not that much familiar with
> the
> > avahi internals.
> > I'm attaching my patch. Basically I was able to transfer registered
> local
> > services into the cache without receiving a messages on the network.
> > Of course that is just one step. The cache needs to be kept up to date.
> > I used the following call to test:
> >     avahi_server_add_service(server, group, 1, AVAHI_PROTO_UNSPEC,
> > AVAHI_PUBLISH_NO_ANNOUNCE, "My Service Name", "_daap._tcp", NULL, NULL,
> > 7777, "foo", NULL);
> >
> > I used avahi-0.6.21 source.
>
> Uh. This doesn't look right to me. I think the better way to handle
> this is to change the way Avahi currently deals with interfaces. Right
> now, Avahi ignores all interfaces that are POINTOPOINT, LOOPBACK or
> lack MULTICAST. I think it would be better to not ignore LOOPBACK
> unconditionally. Instead we should deal with it like any other
> interface, howver with the special excpetion, that AVAHI_IF_UNSPEC
> does not match it, unless there it is the only interface available.
>
> I would suggest a solution like this: We add a new definition
> AVAHI_IF_LOOPBACK = -2. Then, if a RR is registered, and a positive
> ifindex is passed, we just do our work as usual on the specified
> interface. If -1 is passed as ifindex (i.e. AVAHI_IF_UNSPEC), we use
> the loopback interface if no real interfaces are known, or the real
> interfaces if they are available but in that case we don't use the
> loopback to avoid duplicate instanes. If -2 is passed this is treated
> like a positive ifindex for the loopack device.
>
> The difficulty of course comes when we have to move a service between
> the loopback device and a real device everytime the network is
> configured/unconfigured.
>
> This scheme would not only fix your problem but also #92. Also, it
> doesn't require any ugly shortcuts etween the zone and the cache.
>
> Patches welcome! Unless they introduce those 36h days I don't think I
> will have the time to implement something like this anytime soon.
>
> Lennart
>
> --
> Lennart Poettering                        Red Hat, Inc.
> lennart [at] poettering [dot] net         ICQ# 11060553
> http://0pointer.net/lennart/           GnuPG 0x1A015CC4
> _______________________________________________
> 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/20080213/2ae746f5/attachment.htm