Transcript UPNP Device Presentation

The Computer Communication
Lab (236340)
Spring 2005
Universal Plug and Play on
Mobile Phone
With Qualcomm
- Device -
Project Team
• Submitted by:
– Gal Zach
– Einav Bar-Ner
[email protected]
[email protected]
• Instructor: Constantine Elster
• Supervisor: Guy Sela
Project Goal
Port the UPNP technology and develop a
discovery protocol on Qualcomm mobile
phones.
Background
• UPnP is an architecture for pervasive peer-to-peer network
connectivity of intelligent appliances, wireless devices, and PCs of
all form factors. It is designed to bring easy-to-use, flexible,
standards-based connectivity to ad-hoc or unmanaged networks
whether in the home, a small business, public spaces, or devices
attached to the Internet.
• The UPnP Device Architecture defines the protocols for
communication between control points and devices. In order to
establish a UPnP connection the following steps have to be
performed: discovery, description, control, eventing, and
presentation. These steps will be discusses in detail later. UPnP
uses an extended protocol stack to execute those steps.
Steps in UPnP Networking
Step 1 – Discovery
When a device is added to the network, the UPnP
discovery protocol allows that device to
advertise its services to control points on the
network. Similarly, when a control point is added
to the network, the UPnP discovery protocol
allows that control point to search for devices of
interest on the network. The fundamental
exchange in both cases is a discovery message
containing a few essential specifics about the
device or one of its services, e.g., its type,
identifier, and a pointer to more detailed
information.
Steps in UPnP Networking
Step 2 – Description
The information supplied in the discovery step is not
enough for the control point to learn about the device
and its capabilities, or to interact with it. The control point
uses the URL, provided in the discovery step, to retrieve
the required information. The UPnP description for a
device is partitioned into two: a device description
describing the physical and logical containers, and one
or more service descriptions describing the capabilities
exposed by the device. In order to retrieve the
service/device's description, the control point issues an
HTTP GET request to the URL in the discovery
message, and the device returns its description in the
body of an HTTP response
Steps in UPnP Networking
Step 3 – Control
After getting the information about the
device and its services, the control point
can ask those services to invoke actions.
When an action is completed (or failed),
the service returns the action's results or
errors. In case of a non-evented variable
(will be explained in step 4 – eventing), the
control point can poll the service for the
variable's value.
Steps in UPnP Networking
Step 4 – Eventing
• A UPnP service description includes a list of actions the service
responds to and a list of variables that model the state of the service
at run time. If one or more of these state variables are changed
during the service's run time, the service publishes updates, and a
control point may subscribe to receive this information.
• Some state variables may change value too rapidly or may contain
very large values. For this, or other reasons, a service may
designate one or more state variables as non-evented and never
send event messages to subscribers. To determine the current value
for such non-evented variables, control points must poll the service
explicitly.
Steps in UPnP Networking
Step 5 – Presentation
If a device has a URL for presentation, then
the control point can retrieve a page from
this URL, load the page into a browser
and, depending on the capabilities of the
page, allow a user to control the device
and/or view device status.
Project Description
The current implementation contains the root
device and one service that has one action.
The service is a calculator and its action calculates
the cosinus of an angle. The service’s state
variable determines whether the calculation is
performed in degrees or radians.
The service changes the state variable
frequently.
Project Description – Cont.
Note:
The implementation does not perform
multicast transmissions (although defined
in the protocol) since it is not supported in
the Brew simulator.
Project Description – Cont.
The project contains the following modules:
1.
2.
3.
4.
5.
6.
7.
8.
utilities
upnpdevice
parsers
headers
discovery
description
Control
Eventing
Utilities Module
This module contains general functions that
do not depend on the device’s structures.
Examples:
• Printing to the simulator’s screen.
• Common conversions.
Upnpdevice Module
This module contains the basic steps for initializing and
cleaning up the system, and the basic operations for
communicating over the network.
It contains the following structures:
1. STUpnpDevice – This is the structure required by the
Brew simulator for keeping the global variables. There
is only one instance of this structure.
Main members:
•
•
•
•
Socket to listen on TCP incoming messages.
Socket to listen on UDP incoming messages.
Socket to send alive calls.
List of subscribers.
Upnpdevice Module – Cont.
•
2.
STSubscriber –Defines a subscriber. Main members:
•
•
•
•
•
3.
Subscription ID.
IP and port to send events.
The service id the subscriber is subscribed to.
Pointer to the STUpnpDevice structure.
Event key – the number of events sent to the subscriber.
STUserSession – Defines a session. Main members:
•
•
•
4.
List of services.
Pointer to the STUpnpDevice structure.
Pointer to the socket.
Pointer to the message buffer.
STService – Defines a service. Main members:
•
•
•
Service id.
IP and port the service is listening on.
State variable name and value. (Should be )
Parsers Module
This module contains parsers for all kind of
received messages.
Note:
No parsing for xml messages.
Headers Module
This module contains functions to build the
different packets of the protocol.
Discovery Module
This module performs all operations that
required for the Discovery step, i.e. send
alive calls, responses to m-search, and
byebye messages.
Description Module
This module performs operations that
required for the Description step.
Note:
In the current implementation the
description files of the device and service
exist in the project directory and are
loaded from there.
Control Module
This module performs operations that
required for the Control step, i.e. invoking
action and querying state variable.
Eventing Module
This module performs operations that
required for the Eventing step.
Note:
The implementation supports multisubscribers.
Modules Relations
parsers
discovery
description
upnpdevice
utilities
control
headers
eventing
Data Structures
STUpnpDevice
STSubscriber
STService
STSubscriber
STService
STSubscriber
STService
STStateVar
STStateVar
Demonstration
The demonstration uses a control point stub
and contains 2 demos.
Each message that the control point
receives from the device is written into a
file corresponding to the type of the
message.
Messages from the same type are
concatenated to the same file.
Demo 1
1.
2.
3.
4.
5.
6.
The control point waits for alive calls.
The device starts and automatically sends alive
messages every minute.
The device receives m-search message and sends
response.
The device receives request for the device description
and sends the device description to the control point.
The device receives request for the service description
and sends the service description to the control point.
The device receives request to invoke action and
sends the result to the control point.
Demo 1 – Cont.
7.
8.
9.
10.
11.
The device receives query of state variable and sends the
response to the control point.
The device receives subscription request for 20 seconds. Update
with SID = 1.
The device sends event messages to the subscriber every 15
seconds.
After 10 seconds the device receives re-subscription request from
the same subscriber for 40 seconds. The device continue sending
event messages to the subscriber.
40 seconds later the device removes the subscriber from the
subscribers list and stop sending him event messages.
Demo 2
1.
2.
3.
4.
5.
6.
7.
8.
The control point waits for alive calls
The device sends alive messages every minute.
The device receives subscription request for 60 seconds. Update
with SID = 2.
The device receives subscription request for 60 seconds. Update
with SID = 3.
Both subscribers receive event messages.
After 20 seconds the device receives un-subscribe message from
the subscriber with SID = 2. The device removes this subscriber
from the subscribers list and stop sending him event messages.
After 60 seconds the device removes the subscriber with SID = 3
from the subscribers list and stop sending him event messages.
The device sends byebye message to the control point and
disconnect.