Plug And Play For Network Connected Devices
Download
Report
Transcript Plug And Play For Network Connected Devices
Plug And Play For Network
Connected Devices
Cameron Brodeur and Kristina Hotz
Program Managers
Windows Device Experience Group
Microsoft Corporation
Session Outline
Discusses generic resource discovery
and how to turn a Network Connected
Device (NCD) into a Plug and Play
(PnP) device
Windows Rally Overview
Function Discovery (FD)
Plug and Play Extensions for Network
Connected Devices (PnP-X)
Demo
Questions
Windows® Rally™ Program
Access to
Technologies
Simple Unified
License
Technical
Guidance
Windows® Rally™ Devices
Effortless to
configure and
maintain
Reliable and simple
to manage
More secure and
provide rich
digital
experiences
WindowsRally
RallyTechnologies
Experiences
Windows
Management Interfaces
Function
Discovery
Discovery
Connect
SetupNow
Windows
Wireless
MapMap
Topology
LLTD:
Network
Service
QoSofExtensions
LLTD:
Quality
Applications
Plug
Device
andSpecific
Play Extensions
Drivers
AV UPnP
Devices
IP Network
(IPv4, IPv6)
Ethernet/Wireless
Windows Rally Technologies
Experiences
Device
Networked
Profile
for Web
Devices
Services
Function Discovery
Generic resource detection
Kristina Hotz
Program Manager
Why Function Discovery?
Many flavors of devices and resources
USB
WSD
UPnP
NetBIOS
Etc.
Different protocols
Different discovery
Different metadata acquisition
Need abstraction layer for unification
Function Discovery (FD)
New feature in Windows Vista for
resource discovery
Provides uniform API for resource discovery
and metadata exchange
Is extensible allowing discovery via virtually
any protocol
Can aggregate results from multiple protocols
Find NetBIOS and WSD shares with single query
Find all UPnP and WSD devices with same code
FD Architectural Overview
Client
Function Discovery API
Query Manager
Category
Manager
Registry
Provider
Registry
Registry
PnP
Provider
SSDP
Provider
WSD
Provider
WNet
Provider
3rd Party
Provider
Setup
DI API
SSDP
WSD
WNet
APIs
Native
APIs
Legend:
Client
Internal Components
Client Interface
Underlying APIs
Providers
Discovery: PnP
hDevInfoSet = ::SetupDiGetClassDevs (
NULL,
NULL,
NULL,
DIGCF_ALLCLASSES );
bSuccess = ::SetupDiEnumDeviceInfo (
hDevInfoSet,
dwIndex++,
&sddInfoElement );
if (bSuccess)
{
pRootDevNode = new DevNode;
pRootDevNode->guidClass =
sddInfoElement.ClassGuid;
if (::SetupDiGetDeviceInstanceId(
hDevInfoSet,
&sddInfoElement,
szDevId,
2047,
&dwSizeNeeded ))
{
pRootDevNode->pszName = new
WCHAR[dwSizeNeeded];
wcsncpy(
pRootDevNode->pszName,
szDevId,
dwSizeNeeded );
}
pCurrDevNode = pRootDevNode;
pCurrDevNode->pNext = NULL;
while (::SetupDiEnumDeviceInfo (
hDevInfoSet,
dwIndex++,
&sddInfoElement ))
{
pCurrDevNode->pNext = new DevNode;
pCurrDevNode = pCurrDevNode->pNext;
pCurrDevNode->guidClass =
sddInfoElement.ClassGuid;
if (::SetupDiGetDeviceInstanceId(
hDevInfoSet,
&sddInfoElement,
szDevId,
2047,
&dwSizeNeeded ))
{
pCurrDevNode->pszName = new
WCHAR[dwSizeNeeded];
wcsncpy(
pCurrDevNode->pszName,
szDevId,
dwSizeNeeded );
}
pCurrDevNode->pNext = NULL;
}
*ppDevNodes = pRootDevNode;
}
Discovery: Registry
lResult = RegOpenKeyEx(
HKEY_LOCAL_MACHINE,
pwszSubKey,
0,
KEY_READ,
&hKey);
lResult = RegQueryValueEx(
hKey, achValueName, NULL,
&dwType, pBuffer, &dwBufSize );
}
if ( pBuffer )
delete pBuffer;
}
if( ERROR_SUCCESS == lResult )
lResult = RegQueryInfoKey(
hKey, NULL, NULL,
NULL, &dwSubKeys, NULL,
NULL, &dwValues, NULL,
NULL, NULL, NULL);
for( DWORD i = 0; ( i < dwValues ) && (
lResult == ERROR_SUCCESS ); i++ )
{
WCHAR achValueName[MAX_PATH];
DWORD cchValueName = ARRAY_SIZE(
achValueName );
DWORD dwType;
BYTE* pBuffer = new BYTE[MAX_PATH];
DWORD dwBufSize = MAX_PATH;
lResult = RegEnumValue(
hKey, i, achValueName,
&cchValueName, NULL,
NULL, NULL, NULL );
if( ERROR_SUCCESS == lResult )
{
for( DWORD i = 0; ( i < dwSubKeys ) && (
lResult == ERROR_SUCCESS ); i++ )
{
WCHAR pwszNewSubKey[256];
dwSize = MAX_PATH;
lResult = RegEnumKeyEx(
hKey, i, szName,
&dwSize, NULL, NULL,
NULL, &ftWrite);
if( SUCCEEDED( StringCchPrintf(
pwszNewSubKey, 256, L"%s\\%s",
pwszSubKey, szName)))
{
Result = EnumerateSubKeys(
pwszNewSubKey );
}
}
if( hKey )
RegCloseKey( hKey );
return ERROR_SUCCESS;
Discovery: FD PnP
hr = spDiscovery->CreateInstanceCollectionQuery(
FCTN_CATEGORY_PNP,
NULL,
TRUE,
spNotify,
&spFunQuery );
if ( SUCCEEDED( hr ))
hr = spFunQuery->Execute( &spFunInsts );
Discovery: FD Registry
hr = spDiscovery->CreateInstanceCollectionQuery(
FCTN_CATEGORY_REGISTRY,
NULL,
TRUE,
spNotify,
&spFunQuery );
if ( SUCCEEDED( hr ))
hr = spFunQuery->Execute( &spFunInsts );
Discovery: FD WSD
hr = spDiscovery->CreateInstanceCollectionQuery(
FCTN_CATEGORY_WSDISCOVERY,
NULL,
TRUE,
spNotify,
&spFunQuery );
if ( SUCCEEDED( hr ))
hr = spFunQuery->Execute( &spFunInsts );
FD Feature Overview
Discovery
Query by protocol category instead
of with protocol code
Refine query using properties or constraints
(i.e., PnP Interface IDs)
Define aggregate categories to
Target more than one provider
I.e., NetBIOS and WSD
Always apply constraints
Category will only return network printers
FD Feature Overview
Notifications
Clients receive notifications from category
Send on resource add/remove
Activation
Instantiate and initialize software objects
associated with resource
Application provides the ClassID
and interface desired
FD binds object to resource
The Function Instance (FI)
Single unit of discovery
Represents the discovered resource
Created by the provider in response
to a query
Local resources returned as collection
of Function Instances
Network resources returned as discovered
via notifications
The Function Instance (FI)
Store resource information as properties
Store contains
Metadata
Configuration data
State data
Exposed through IPropertyStore interface
Allow read and write (when supported)
of resource information
PnP-X
Plug and Play for networked devices
Cameron Brodeur
Program Manager
Device Connectivity Options
Windows provides many different options
for device connectivity
Wired buses
USB 1.x and 2.0
IEEE 1394
Wireless personal area network
Bluetooth
Ultra-Wideband (UWB)
IP connected
Wi-Fi
Ethernet
Historically
Dual approach
The IP “bus” is handled differently from other buses
This presents several problems
Disparate programming models
No single end-user experience
The device experience depends on the connector selected
Undefined
experience
when
Well understood
experience
plugging
intointo
thisthis
portport
when
plugging
Fuels
IP
devices
device
limited
adoption
in adoption
Custom support
Lowers
solutions
costs
for integrating
with
Windows
A PnP
device
A non-PnP device
The Future
Single model
Unification of IP and directly connected devices
Users should not have to care about the bus
IP Network
Directly Connected
Benefits
NCDs are simple to discover and use
Installed and managed just like local,
bus-attached devices
Lower support costs
Broader device adoption
NCDs can be enumerated and accessed
using standard Windows application
programming interfaces (APIs)
Allows use of FD API and legacy APIs
Improved end-user experience
Benefits
NCDs benefit from existing Windows
assets for device management
Windows PnP and device management
infrastructure
Windows Update
Discovery
Before a device can be installed,
it must be discovered
Network protocols replace the bus-specific electrical
signals used for physically connected devices
Metadata exchange
Enough information about the device must
be retrieved for installation purposes
Hardware ID
Class ID
Friendly Name
Etc.
Association
With physical connections, the cable itself
establishes the association
For NCDs, the following questions apply
With which PC is the device associated?
Can the device be associated with more than one PC?
Enabling A Single Model Through PnP
The framework for enabling a single connectivity model already
exists today: It’s Windows PnP (Plug and Play)
An IP bus enumerator (IPBusEnum) enumerates NCDs
A PDO is created for each enumerated device
PnP handles the installation of the device like any other device
The enabling components are collectively called PnP-X:
PnP extensions for NCDs
PnP
PCMCIA
1394
USB
PCI
Class Drivers
Physical Discovery
IPBusEnum
Network Discovery
How PnP-X Works
PnPnotifies
User
List
Devices
PnP-X
Network
FD
IPBusEnum
of
begins
opens
device
devices
respond
Explorer
IPBusEnum
device
Network
gathers
FIs
presented
to
returned
adds
install
multicast
data
Explorer
the
service
from
as
to
FI“Installable”
Network
request
toFI
that
the
and
Association
a device
new
Explorer
device
Database,
has
been
added
which
to
is
Association
maintained
as
Database
a FDdevices
category
Multicast
Finds
matching
sent
byINF
discovery
file
providers
Network
FD
User
Creates
creates
selects
PnP
Explorer
a device
device
Function
displays
for
node
Instance
installation
(DevNode)
discovered
(FI)
forLoads
each device
devicedriver and software
Network Explorer UI
PnP
PnP
IPBusEnum
Xbox
Printer Storage
Function Discovery API
FI
FI
FI
Network Discovery Providers
WSD
WSD
Legend:
PnP-X
Function
Discovery
Network
Providers
Driver
SSDP
SSDP
3rd Party
Party
3rd
DevNode
Association
Database
Device
Driver
How PnP-X Works
IPBusEnum
PnP
Applications
Device
DevNode
starts-up
goes
checks
calls
now
offline
recreated
see
PnP
association
the devicedatabase
as available
unavailable
Matching
Sends
Driver
unloaded
WSD
device
Hello
Bye
found
ororSSDP
SSPD
in
database
Bye-Bye
Alive
message
message
Device
Queries
driver
to
PnP
loaded
reflect
offline
online
state
FD creates
PnP
DevNode
FI for
removed
device; IPBusEnum notified
Network Explorer UI
PnP
PnP
IPBusEnum
Storage
Function
Discovery API
FI
Network Discovery Providers
WSD
WSD
SSDP
SSDP
3rd
3rd Party
Party
Storage
Device
DevNode
Association
Database
Device
Driver
Legend:
PnP-X
Function
Discovery
Network
Providers
Driver
Device
Deviceshutdown
startup
Alive
Bye message sent
Status:
Status: OFFLINE
ONLINE
Inbox Protocol Support
Inbox support is provided for the following discovery
protocols in Windows Vista
Web Services Discovery Protocol (WS-Discovery)
Part of the Web Services on Devices suite of protocols
Devices must support WS-Discovery as well as the Device Profile
for Web Services to be installable by PnP-X
Simple Services Discovery Protocol (SSDP)
Used by UPnP for device discovery
Devices must support SSDP as well as Device Description
to be installable by PnP-X
Support for additional protocols can be enabled through
the installation of a FD provider
Must conform to the requirements in the PnP-X
and FD specifications
See PnP-X and FD documentation for details
Device Requirements
Devices must support one of the inbox
protocols or provide a custom provider
Devices must include additional XML
data in the discovery metadata
<HardwareId>
<CompatibleId>
<DeviceCategory>
Allows PnP-X to recognize that the device
is “installable” and create a PnP DevNode
Device-Side XML Example (UPnP)
<?xml version="1.0" ?>
<root xmlns="urn:schemas-upnp-org:device-1-0">
<specVersion>
<major>1</major>
<minor>0</minor>
</specVersion>
<URLBase>http://192.168.0.1:1234</URLBase>
<device>
<pnpx:X_hardwareId>MSFT_MediaPlayer_HWID</pnpx:X_hardwareId>
<pnpx:X_compatibleId>MSFT_MediaPlayer_CPID</pnpx:X_compatibleId>
<pnpx:X_deviceCategory>MediaDevices</pnpx:X_deviceCategory>
<deviceType>urn:schemas-upnporg:device:MediaRenderer:1</deviceType>
<friendlyName>Microsoft Advanced Media Player</friendlyName>
<manufacturer>Microsoft</manufacturer>
...
</device>
</root>
DevNode Creation
IPBusEnum creates a PnP DevNode
for the device
Information discovered about the device is stored
in the DevNode property store, including
IP Address
Hardware IDs and Compatible IDs for the device
Device UUID (GUID)
PnP installs a driver using the “standard” process
Search driver packages (INF files) looking for the best
match based on hardware and compatible IDs
Invoke the specified class installer and optional
co-installer to carry out the installation process
Device Driver Details
Manufacturer can supply a kernel-mode
or user-mode driver for the device
Driver can also be a class driver supplied
by Microsoft
For proprietary devices or devices that are tied
to a single application, the install process can
simply install the application or service
Communicating With Your Device
Base-level functionality for an associated network
connected device simply returns the IP address
of the device
Communication with network connected devices
will go through existing network stacks
.NET Framework
WSD
UPnP
WinSock
Protocol choice left up to the vendor
Industry Adoption
PnP-X adoption is growing
WSD-based printers
Wi-Fi digital cameras
Media Center Extender devices, including
the Xbox 360
Network Attached Storage devices
Adoption is accelerating
The time to consider PnP-X for your networked
devices is now
Maxtor
Network Attached Storage
Call To Action
Evaluate PnP-X and Function Discovery
for your NCDs
Review the PnP-X and Function Discovery
documentation on MSDN
For WSD and UPnP devices, update your
device to provide the information specified
by the PnP-X documentation
For other devices, write a Function Discovery
provider that conforms to requirements
specified by the FD documentation
Additional Resources
Web Resources
Function Discovery Specs
http://msdn.microsoft.com/library/default.asp?url=/library/enus/fundisc/ncd/portal.asp
PnP-X Specs
See the Windows Rally SDK at http://www.microsoft.com/rally
Function Discovery SDK Documentation
http://windowssdk.msdn.microsoft.com/library/default.asp?url=
/library/en-us/fundisc/ncd/about_function_discovery.asp
Whitepapers
http://www.microsoft.com/rally
Related Sessions
Web Services on devices in Windows Vista
Web Services on devices: The protocol now and for the future
Email address for more information
rally @ microsoft.com
© 2006 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries.
The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market
conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation.
MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.