zeroconf and lisa, Was: removing more stuff for KDE 4 :-)

[Jakub Stachowski]

Dnia poniedziałek, 6 czerwca 2005 18:50, Alexander Neundorf napisał:
> Hi,
>
> On Saturday 04 June 2005 14:35, you wrote:
> > Dnia piątek, 3 czerwca 2005 23:42, Alexander Neundorf napisał:
> > > On Friday 03 June 2005 22:45, Stephan Kulow wrote:
> > > ...
> > >
> > > > So you prefer having something broken and not supported over
> > > > something missing?
> > >
> > > I'd say lanbrowsing should stay for 3.5 (it's not broken, has users,
> > > and works). For 4.0 we'll have something better.
> >
> > For 4.0 I plan to enhance current zeroconf implementation to support
> > several machine and service discovery methods and incorporating bits of
> > lan ioslave as one of 'backends'.
> > Work is being done in branches/work/dnssd/multiengine. It still uses Qt3
> > and is still API compatible with 3.4 version but i'm going to drop that
> > and move over to Qt4 as i don't see any chance of making it usable for
> > 3.5.
>
> What do you exactly plan ?

I plan to have several methods for discovering 'scopes' (not SLP scopes but 
more abstract thing -  can be DNS domain, SLP scope or single machine) and 
publishing/discovering services. Lisa daemon would be good supporting way to 
discover machines that do not announce their presence in any way. Another one 
would be samba based - then scope would be either workgroup or single host.
For KDE4 i can break API so i suppose scopes will be arranged into tree this 
time, for example:
All (abstract)->
	LAN (abstract) ->
		 Workgroup 1 (SMB) ->
			Host 1 (SMB, Lisa)   - this machine was detected by both smb and lisa,
		 Second floor (SLP)	      then combined into one entry
	People (abstract) ->
		Ann (KIMProxy)

kio_lan way (port probing) would be used for discovering services in scopes 
consisting of one machine (detected by lisa or samba). 
> The lisa daemon and kio_lan are quite mature I'd say but have some
> "issues".
>
> Cons:
> -the lisa daemon has to be started with root privileges in order to be able
> to open a raw socket for sending ICMP echo request
> -it has to be configured manually. But I think this is supported quite good
> now in the kcm module.
> -it searches for hosts by sending ICMP echo request regularly. This can
> cause some network load.
>
> Pros:
> -root privileges are dropped immediately after opening the raw socket
> -the update interval increases up to 16 times the standard interval if the
> information isn't accessed
> -if there are more than one lisa daemons running in one network, they
> cooperate and only one of them does the searching, the other get their
> information from this one host
> -works completely without samba
> -it doesn't intermix different functionality like samba does: file sharing
> and "host browsing": file sharing via ssh/ftp/nfs/http, "host browsing" via
> lisa

I don't want to drop all this but unify it under single API and single ioslave 
along with SLP, DNS-SD and not-yet-written KIMProxy-based protocol.
So if you ask for list of http servers in neighbourhood all known (and enabled 
methods) will be used and their results combined.

>
> As far as I understand dnssd (can we come up with a better name ?
> "Buongiorno" or something ;-), 

Yeah, I used DNSSD for namespace and zeroconf:/ for ioslave, but it won't be 
correct for much longer.

> it could provide a tree structure where the 
> root is the service type and the hosts are the leaves. Lisa does the
> opposite: the hosts are the root and each one offers various services. I
> don't know which one is better.
> Using zeroconf every linux/*BSD/Mac/... host could advertize itself as
> "host running something" and then it could be browsed. Or they could
> advertize as "host running ssh" and we could have a "ssh-network" to browse
> and a smb-network to browse (from the smb-ioslave obviously). HTTP and FTP
> should also be supported in some way.

I think it is responsibility of distribution - necessary tools already exist. 
mDNSResponderPosix can read list of services from config file and advertise 
them.  I suppose something like yast or similar tools should manage it. 
However for now there is no single distro doing this so active scanning 
methods like lisa and portscan are still needed.

>
> Please let me know what you plan and if I can support you :-)

See http://arch.hypair.net/TODO (3.5 plans got scrapped btw)

>
> Bye
> Alex