[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [dsdp-tm-dev] autodetect
|
I have played with ZeroConf outside Eclipse and have not seen any time delay, so I don't believe there is any inherit delay in the protocol. In the simplest form, ZeroConf is using multicast to communicate, so on a very busy network it might be some delay if the first multicast packet is dropped.
Felix
> -----Original Message-----
> From: dsdp-tm-dev-bounces@xxxxxxxxxxx
> [mailto:dsdp-tm-dev-bounces@xxxxxxxxxxx] On Behalf Of Martin Oberhuber
> Sent: Friday, May 05, 2006 12:28 AM
> To: Target Management developer discussions
> Subject: Re: [dsdp-tm-dev] autodetect
>
> Hello Javier,
>
> I'm wondering if there is some sort of time delay until config
> information gets populated to the
> network with Zeroconf. When I've tested ECF discovery at
> EclipseCon, I
> noticed that it took
> several minutes until certain services showed up. But that was just
> personal impression and I
> could be wrong.
>
> When you've converted these mailinglist discussions into
> Bugzilla, could
> you share the bug #
> so that we can continue discussions there? [the earlier you
> do it, the
> less mails you'll have
> to convert by copy & paste]
>
> thanks,
> Martin
>
> javier.montalvoorus@xxxxxxxxxxx schrieb:
>
> >
> > Hi Greg,
> >
> > Sorry for the last email :)
> > The Zeroconf implementation on the device can be customised
> to provide
> > the necessary information to the Eclipse client.
> > Extra information of the device can be provided by the server, for
> > example, using TXT records as pairs of "name=value" (ie
> "version=2.1")
> >
> > The chapter 6 of
> > http://files.dns-sd..org/draft-cheshire-dnsext-dns-sd.txt
> (Data Syntax
> > for DNS-SD TXT Records) provides complete information about
> TXT records.
> >
> > Regards,
> >
> > Javier Montalvo Orús_
> > __Engineering Tools_
> > <http://smglinx.intra/twiki/bin/view/PTD/EngineeringTools>
> > Symbian Software Limited.
> >
> > Tel: +44 (0)207 154 1091
> >
> >
> > *Greg Watson <g.watson@xxxxxxxxxxxx>*
> > Sent by: dsdp-tm-dev-bounces@xxxxxxxxxxxx
> >
> > 03/05/2006 15:41
> > Please respond to
> > Target Management developer discussions <dsdp-tm-dev@xxxxxxxxxxx>
> >
> >
> >
> > To
> > Target Management developer discussions
> <dsdp-tm-dev@xxxxxxxxxxx>
> > cc
> >
> > Subject
> > Re: [dsdp-tm-dev] autodetect
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > I'm no Zeroconf expert by my understanding is that it is used to
> > discover interfaces and network services on remote
> machines. Do you
> > know if it can be used to discover of other types of configuration
> > information (e.g. architecture information, installed
> packages, etc.)?
> >
> > Greg
> >
> >
> > On May 3, 2006, at 7:50 AM, javier.montalvoorus@xxxxxxxxxxx wrote:
> >
> > >
> > > Hi,
> > >
> > > I have been taking a look at the ECF for Service
> Discovery and, as
> > > Scott and Martin suggested, we could use it for the TM
> autodetect
> > > process.
> > > Testing it with the Apple's Bonjour SDK ( http://
> > > developer.apple.com/bonjour ), that contains a sample
> application
> > > to register Bonjour/Zeroconf services, the Dynamic Service
> > > Discovery View from ECF correctly displays the registered
> services
> > > in the same network. This facility it what we want in the
> > > autodetect process, so using ECF should be fine.
> > >
> > > For those interested on how Bonjour / Zeroconf works,
> there is a
> > > quite interesting tech talk from Stuart Cheshire at:
> > > http://video.google.com/videoplay?
> > > docid=-7398680103951126462&q=Google+techtalks
> > >
> > > Although Zeroconf seems a good solution for autodetect, does
> > > anybody have other alternatives worth to be considered or any
> > > inconvenient using Zeroconf ?
> > >
> > > Regards,
> > >
> > > Javier Montalvo Orús
> > > Engineering Tools
> > > Symbian Software Limited.
> > >
> > > Tel: +44 (0)207 154 1091
> > >
> > >
> > > "Oberhuber, Martin" <Martin.Oberhuber@xxxxxxxxxxxxx>
> > > Sent by: dsdp-tm-dev-bounces@xxxxxxxxxxxx
> > > 27/04/2006 10:56
> > > Please respond to
> > > Target Management developer discussions <dsdp-tm-dev@xxxxxxxxxxx>
> > >
> > >
> > > To
> > > "Target Management developer discussions"
> <dsdp-tm-dev@xxxxxxxxxxx>
> > > cc
> > > Subject
> > > 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:
> > > http://www.dns-sd.org/ServiceTypes.html
> > >
> > > 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
> > > _______________________________________________
> > > dsdp-tm-dev mailing list
> > > dsdp-tm-dev@xxxxxxxxxxx
> > > https://dev.eclipse.org/mailman/listinfo/dsdp-tm-dev
> > >
> > >
> > >
> > >
> > >
> > >
> *******************************************************************
> > > *** Symbian Software Ltd is a company registered in England and
> > > Wales with registered number 4190020 and registered office at 2-6
> > > Boundary Row, Southwark, London, SE1 8HP, UK. This message is
> > > intended only for use by the named addressee and may contain
> > > privileged and/or confidential information. If you are not the
> > > named addressee you should not disseminate, copy or take
> any action
> > > in reliance on it. If you have received this message in error
> > > please notify postmaster@xxxxxxxxxxx and delete the
> message and any
> > > attachments accompanying it immediately. Neither Symbian
> nor any of
> > > its Affiliates accepts liability for any corruption, interception,
> > > amendment, tampering or viruses occurring to this message in
> > > transit or for any message sent by its employees which is not in
> > > compliance with Symbian corporate policy.
> *************************
> > > *********************************************
> > >
> > > _______________________________________________
> > > dsdp-tm-dev mailing list
> > > dsdp-tm-dev@xxxxxxxxxxx
> > > https://dev.eclipse.org/mailman/listinfo/dsdp-tm-dev
> >
> > _______________________________________________
> > dsdp-tm-dev mailing list
> > dsdp-tm-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/dsdp-tm-dev
> >
> >
> --------------------------------------------------------------
> ----------
> >
> > *
> > *******************************************************************
> > *** Symbian Software Ltd is a company registered in England and
> > Wales with registered number 4190020 and registered office at 2-6
> > Boundary Row, Southwark, London, SE1 8HP, UK. This message is
> > intended only for use by the named addressee and may contain
> > privileged and/or confidential information. If you are not the
> > named addressee you should not disseminate, copy or take any action
> > in reliance on it. If you have received this message in error
> > please notify postmaster@xxxxxxxxxxx and delete the message and any
> > attachments accompanying it immediately. Neither Symbian nor any of
> > its Affiliates accepts liability for any corruption, interception,
> > amendment, tampering or viruses occurring to this message in
> > transit or for any message sent by its employees which is not in
> > compliance with Symbian corporate policy. *************************
> > *********************************************
> > *
> >
> >-------------------------------------------------------------
> -----------
> >
> >_______________________________________________
> >dsdp-tm-dev mailing list
> >dsdp-tm-dev@xxxxxxxxxxx
> >https://dev.eclipse.org/mailman/listinfo/dsdp-tm-dev
> >
> >
>
> _______________________________________________
> dsdp-tm-dev mailing list
> dsdp-tm-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/dsdp-tm-dev
>
