On 2/13/06, Trent Lloyd <[EMAIL PROTECTED]> wrote: > On Sunday 12 February 2006 22:23, Sebastien Estienne wrote: > > On 2/12/06, Lennart Poettering <[EMAIL PROTECTED]> wrote: > > > On Sun, 12.02.06 13:32, Sebastien Estienne ([EMAIL PROTECTED]) > wrote: > > > > what about doing something like the relaying gateways that i suggested > > > > to fill the need for zeroconf with vpn? > > > > > > > > Would it work? they wouldn't forward the query, but exchange the > > > > browsing list on a regular basis (or something equivalent) > > > > > > > > what are your opinions? > > > > > > I suppose you mean something similar to Samba's "remote browse sync" > > > option? > > > > exactly > > > > > I don't think it is feasible to implement something like this for > > > mDNS. In contrast to SMB servers mDNS responders never compile > > > something like a complete browse list, hence there is nothing two > > > servers could exchange. > > > > the idea would be to periodically browse for all available service > > (like service_type_browser , avahi-browse -a) and transfer the results > > over unicast to the other deamon. > > That's really ugly Sorry for the ugliness, any more constructive idea?
> > a) That would cause excessive network traffic all the time, especially bad > on wireless networks > b) Not all devices advertise the magic needed for the service type browser, > so you wont get everything. > > Cheers, > Trent > > > > > I agree that it may be a bit hackish though... and that uniscat dns-sd > > (wide-area) is a better solution. We just loose the ease of setup as > > wide-area needs a dns server and configuration on each clients > > (unicast domain + key/shared secret for publishing), that's why it's > > not really zeroconf as zero configuration. > > > > As far as i know wide area is already widely used in miscrosoft active > > directory. > > > > > Avahi already does forwarding of mDNS traffic between multiple > > > interfaces. If latency is good enough you may use that to bridge two > > > networks. > > > > > > Unicast DNS is definitely preferable when it comes to high latency > > > links. There's no point in trying to modify mDNS in a way that it is > > > capable of coping with high latency. There is already unicast DNS which > > > is perfectly capable to deal with situations like that. > > > > the idea wasn't to modify mdns, but just implementing a separated deamon > > > > this idea is not really new, some project already did things a bit like > > this: - rendezvousproxy: > > http://ileech.sourceforge.net/index.php?content=RendezvousProxy-News > > - zerospan: > > http://www.zerospan.org/ > > > > > Lennart > > > > > > -- > > > Lennart Poettering; lennart [at] poettering [dot] net > > > ICQ# 11060553; GPG 0x1A015CC4; http://0pointer.net/lennart/ > > > _______________________________________________ > > > avahi mailing list > > > [email protected] > > > http://lists.freedesktop.org/mailman/listinfo/avahi > > > > -- > > Sebastien Estienne > > -- > Trent Lloyd > Bur.st Networking Inc. > _______________________________________________ > avahi mailing list > [email protected] > http://lists.freedesktop.org/mailman/listinfo/avahi > -- Sebastien Estienne
_______________________________________________ avahi mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/avahi
