Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
FW: [dsdp-tm-dev] autodetect
FYI,
 
comments from Scott Lewis (ECF) regarding autodetect, Zeroconf / Bonjour, DNS-SD and ECF.
 
 
From: Scott Lewis [mailto:slewis@xxxxxxxxxxxxx]
Sent: Thursday, April 27, 2006 2:53 AM
To: Oberhuber, Martin
Subject: Re: FW: [dsdp-tm-dev] autodetect

Hi Martin,

No, you've got everything right!  And thanks!!

See a couple of supporting comments inline.

From: dsdp-tm-dev-bounces@xxxxxxxxxxx [mailto:dsdp-tm-dev-bounces@xxxxxxxxxxx] On Behalf Of Oberhuber, Martin
Sent: Wednesday, April 26, 2006 4:01 PM
To: Target Management developer discussions
Subject: RE: [dsdp-tm-dev] autodetect

Hello Javier,
 
these are very interesting pointers and ideas.
 
I had a look at http://www.dns-sd.org and I got the feeling that it is an extension of what
Apple's Zeroconf / Bonjour does on the LAN, to the wide area network through the DNS
transport mechanisms.

Yes...that's right.  Zeroconf/Bonjour uses dns-sd service type/service naming conventions though...so that everything will work beyond the lan environment at the appropriate time.

 
What I found most interesting on the page, was the list of standardized protocol names
which they use in their descriptive strings for the services:
 
I guess we could definitely use those to publish existence of services, regardless of what
sort of protocol / transport we finally choose to use.
 
In fact, I've already seen these specifiers before in the ECF discovery. ECF already has
a provider implementation for Zeroconf / Bonjour, which uses the same strings.
Consequently, looking at the ECF Discovery API might be the next logical step for us.

Yes...ECF abstracts the dns-sd service type info (represented as String by jmdns) as an org.eclipse.ecf.core.identity.ServiceID (of sub-type defined by the jmdns Namespace extension...i.e. JMDNSServiceID).

 
What I'm not so sure about is, if running a DNS server on the device is the right thing to
do. There are already devices like printers etc. implementing Zeroconf / Bonjour, and I
don't think they run full-blown DNS servers. When I'm not mistaken, it's a very simple
protocol.

Yes, Zeroconf/Bonjour is a very simple protocol.   If you are only interested in a lan-based discovery via zeroconf, it's not even necessary to run DNS anywhere...and I think you can make up service types/service names with anything you want (i.e. you don't have to have a dns-sd name).  For example, I defined an _ecftcp service type.  But if you want to do dns-sd discovery across lans, then DNS (at least some DNS server) and dns-sd names does become necessary.

But you can use ecf discovery with the jmdns provider protocol to publish services and receive asynch callbacks about the network availability of those services easily enough right now with ECF. 

For example:

IContainer container = ContainerFactory.getDefault().createContainer("ecf.discovery.jmdns");
container.connect(null,null);
IDiscoveryContainer dc = (IDiscoveryContainer) container.getAdapter(IDiscoveryContainer.class);
// use dc to register services or to setup service listeners

Also, there's example code in the org.eclipse.ecf.example.collab plugin that sets up a little ECF Discovery view that shows services discovered on the LAN via zeroconf.  See org.eclipse.ecf.example.collab.DiscoveryStartup.setupDiscovery().    The view class is: org.eclipse.ecf.example.collab.CollabDiscoveryView.  The 'setDiscoveryController' method gets called in the CollabDiscoveryView constructor.

Scott

Back to the top