[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
RE: [dsdp-tm-dev] autodetect
|
Hello Javier,
these are very interesting pointers and
ideas.
Apple's Zeroconf / Bonjour does on the LAN, to the wide
area network through the DNS
transport mechanisms.
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.
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.
Cheers,
Martin
--
Martin Oberhuber - WindRiver,
Austria
+43(662)457915-85
Hi,
I have been investigating possible solutions for the
services autodetect process. One standard protocol that could be used is the
DNS-Based Service Discovery (http://www.dns-sd.org/)
It provides a mechanism to ask, using DNS queries for
available services to a DNS server and provide the necessary addresses, ports
and extra information for each server.
So, DNS-SD could be useful in the following scenarios:
* Distributed devices: A central
DNS server mapping all the available services in a network.
* Local/Single device: An embedded DNS server in the
device (or host) mapping the available local services.
As an example of how DNS-SD works, you could make some
queries (that works in Win2K):
Step 1: List the available services in dns-sd.org:
nslookup -q=any
_services._dns-sd._udp.dns-sd.org
Step 2: List the available servers for one service (in this case
_ssh):
nslookup -q=any
_ssh._tcp.dns-sd.org
Step 3:
List the server information:
nslookup -q=any Rose._ssh._tcp.dns-sd.org
Then, the sequence diagram of the
Wizard with the autodetect process could be:
So,
has anybody had any experience using DNS-SD ? Would you recommend
another protocol for the autodetect process ?
Many thanks,
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
19/04/2006 16:03
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] initial
discovery service |
|
Hi Javier,
Service Discovery (or "autodetect") is certainly
of interest for us at Wind River, too.
As you might remember from the Toronto meeting, there is a Technology
Sub-Group
for Autodetect, but no
lead has been assigned yet -- would you want to lead this
effort? - See http://wiki.eclipse.org/index.php/DSDP/TM
I think for the
actual autodetect, there are a few flavors:
* Autodetect during system definition (in the wizard),
assuming that detected services remain the same over time
* Autodetect on each connect, allowing to disable
services as needed
The actual detection of services could go
* via network (ECF provides some discovery
services through Zeroconf),
* it
could be through vendor-specific agents running on the remote system,
* or it could be even without
asking the live target, e.g. by looking at a local ELF image of the kernel on
the target or investigating SPIRIT files.
In any case, it
looks like the autodetect would basically create a filter that limits a list
of
possible subsystems for a
given system connection to the list of those that are actually
available; and, for those
subsystems that have been found available, perhaps automatically
set some properties.
I was not sure how
autodetect would relate to a view for hardware actions like restart or
reflash?
Cheers,
Martin
--
Martin Oberhuber - WindRiver,
Austria
+43(662)457915-85
From: dsdp-tm-dev-bounces@xxxxxxxxxxxx
[mailto:dsdp-tm-dev-bounces@xxxxxxxxxxx] On Behalf Of
javier.montalvoorus@xxxxxxxxxxx
Sent: Tuesday, April 11, 2006
5:08 PM
To: Target Management developer
discussions
Subject: [dsdp-tm-dev] initial discovery
service
Hi
All,
Symbian
couldn't attend the phone meeting yesterday, but we would like to raise a
question about the initial discovery of remote embedded systems and how to
manage them.
We
think it would be interesting having a remote system discovery facility,
allowing to retrieve information through a standard protocol such as the
description of the system and the list of available services.
Also
executing basic hardware services on the remote systems (mainly restart and
reflash) could be interesting.
The discovery facility could consist
on:
* A
contribution to the RSE "New Connection" wizard, at the same position where RSE allows checking
if the provided IP exists
* A standard TCP/IP based protocol (to be investigated) to report
the available services on the embedded system and start them as requested by
the user. At this stage possibly the SPIRIT information could also be
retrieved.
* A
view to manage registered embedded systems and perform basic hardware actions
as restart or reflash.
As in the current release only the IP address is checked, possibly
an early handshake with the embedded system could be useful.
Is anybody else interested
in this feature ?
Javier Montalvo Orús
Engineering Tools
Symbian
Software Limited.
Tel: +44 (0)207 154 1091
*******************************************************************
***
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
*******************************************************************
***
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.
*************************
*********************************************