The document proposes a network architecture for integrating physical devices and objects into the web. It involves using gateways to ensure device URLs are available, reachable, stable, and discoverable. Gateways queue requests when devices are asleep, cache responses, and update locations when devices move. The architecture addresses issues like energy efficiency, network constraints, mobility, and discovery. A preliminary version was implemented on Sun SPOT devices to demonstrate integrated physical and web resources.
Unraveling Multimodality with Large Language Models.pdf
A Network Architecture for the Web of Things
1. A Network Architecture for the Web of Things
Vipul Gupta, Ron Goldman, Poorna Udupi
{vipul.x.gupta, ron.goldman}@oracle.com, poorna@netflix.com
Second International Workshop on the Web of Things (WoT 2011), Pervasive 2011
1
2. Web Of Things
• What?
“A vision where everyday devices and objects are integrated into the Web
using well-known standards and blueprints (URIs, HTTP, REST).”
“Seamless integration of physical and conceptual resources”
Also: “The physical web”, “the tactile web”
• How?
- Connect device to Internet,
- Embed web server,
- Model resources as URIs
- Manipulate resources via HTTP verbs
2
3. Example
• Read a resource, e.g. read the light sensor reading
GET /sensors/light HTTP/1.1
Client Accept: */*
Sun SPOT
HTTP/1.1 200 OK
Content-Type: text/plain
Content-Length: 3
138
• Update a resource, e.g. change color of LED 4
PUT /actuators/leds/4 HTTP/1.1
Content-Type: text/plain
Client Content-Length: 7
Sun SPOT
0,255,0
HTTP/1.1 200 OK
3
4. But ...
• Need to ensure URIs are:
• Available -- when a device sleeps
• Reachable -- when the device is
behind a NAT or firewall
• Stable -- even as the device moves
around
• Discoverable -- whether they are local
or remote to the client
4
5. Energy Constraints
• Devices sleep periodically to conserve battery
• Use sleep-proxy to queue requests, cache responses zz
z
Sleep
zz zz
proxy
Sun SPOT
Client
(sleep notification)
GET /spots/01AB/temp HTTP/1.1
Cache-Control: max-age=60
HTTP/1.1 200 OK
Age: 22
Content-Length: 5
86.45
PUT /spots/01AB/leds/5 HTTP/1.1
Content-Length: 7
0,255,0
HTTP/1.1 202 Accepted
Retry-After: 45
Location: spots/01AB/requests/1cqfw 5
7. Network Topology Constraints
• Device could be behind firewall/NAT, might move
• Use relay, with “long-poll” and Reverse HTTP (draft-lentczner-rhttp-00)
Sun SPOT
Client relay.net
POST /spot-5317 HTTP/1.1
Upgrade: PTTH/1.0
Connection: Upgrade
Host: relay.net
HTTP/1.1 101 Switching Protocols
Upgrade: PTTH/1.0
Connection: Upgrade
GET /spot-5317/light HTTP/1.1
Host: relay.net
GET /spot-5317/light HTTP/1.1
HTTP/1.1 200 OK
HTTP/1.1 200 OK Connection: close
Connection: close Content-Length: 3
Content-Length: 3
216
216 7
8. Mobility
• IP address may change due to mobility or expiration of short-term lease
(perceived mobility)
• Mobile IP and dynamic DNS
• not widely deployed
• don’t help when device is on a private network
• Mobile IP home agent and dynamic DNS server can be thought of as
gateways that keep track of the current location.
8
9. Discovery
• Discovering devices -- broadcast (e.g. mDNS) or registry
• Discovering URLs on a device and relationships:
• Bootstrapping: Well defined location for metadata (/.well-known, RFC
5785)
• Typed links: Use the “rel” attribute in links to describe relationships
(draft-nottingham-http-link-header-10), e.g.
Link: </>; rel=“http://example.net/foo’’
See also: http://hueniverse.com/2009/11/the-discovery-protocol-stack-redux 9
11. Clients WoT Gateway, G Geotracker
1. WoT device with IP addr 10.217.217.252 in
location A opens RHTTP channel and notifies
SPOT is awake
gateway of current address and next sleep period.
C1 2. While the WoT device is awake, a request for its current location from C1 is
forwarded to the device. The response is cached at G and returned to C1.
3. Client C2 requests a location reading within
SPOT is asleep
Time
the last 10 mins while the geotracker is asleep
C2 and the gateway returns a cached response.
4. Client C3 requests an alert subscription and
C3 C1 repeats its request for a current location
while the geotracker is asleep and the gateway
queues the requests, sends back status
C1 monitoring URIs to C3 and C1.
5. WoT device wakes up in location B and gets
SPOT is awake
address 10.217.183.21. It reopens RHTTP
channel and notifies gateway of current
address and next sleep period.
6. Gateway forwards queued request, caches 11
response and updates status URIs.
12. Clients WoT Gateway, G Protocol Alert device
translator
SPOT is asleep
1. Client requests a POST to
the `alert URI. Gateway
queues request, returns
status monitoring URI.
2. WoT device wakes up,
notifies the protocol
translator of its next
sleep period and its
WoT gateway using its
native (non-HTTP)
protocol.
SPOT is awake
Time
3. Protocol translator opens
up RHTTP channel with
gateway and conveys
the WoT device’s sleep
schedule and its own IP
address as the devices’s
``location”.
4. Gateway forwards queued request to WoT device via the
translator. Device buzzes and blinks LEDs. Gateway caches
returned response, updates status URI.
12
13. Summary
• Outlined a gateway-based network
architecture to ensure URLs are
WebApp1
WebApp2
available, reachable, stable and
/app1
/app2
discoverable ...
• Implemented a preliminary version
MetaApp
on Sun SPOTs, available as a built- /.well-known
in “Web of Things” demo
NanoAppServer
• Plan to make this an integral part
CHTTPHandler
RHTTPHandler
HTTPHandler
of SPOT libraries
...
Nano App server 13