A Web Browser-based Application Interaction Framework for - - PDF document

▶
a web browser based application interaction framework for
SMART_READER_LITE
LIVE PREVIEW

A Web Browser-based Application Interaction Framework for - - PDF document

Mar 31, 2023 562 likes •751 views

10/23/14 Aalto University School of Electrical Engineering A Web Browser-based Application Interaction Framework for Autonomous Neighborhood Networks Marcin Nagy, Arseny Kurnikov, Teemu Krkkinen, Jrg Ott http://www.netlab.tkk.fi/~jo/

slide-1
SLIDE 1

10/23/14 1

Aalto University School of Electrical Engineering

A Web Browser-based Application Interaction Framework for Autonomous Neighborhood Networks

Marcin Nagy, Arseny Kurnikov, Teemu Kärkkäinen, Jörg Ott http://www.netlab.tkk.fi/~jo/ 21 October 2014

Aalto University School of Electrical Engineering

Neighborhood Networking: Decoupling Users from the Cloud

  • Keeping content where is matters
  • Reducing dependencies on remote services

and the network paths to those

slide-2
SLIDE 2

10/23/14 2

Aalto University School of Electrical Engineering

Do-It-Yourself Networking

WLAN Bluetooth … WLAN Bluetooth …

Aalto University School of Electrical Engineering

Mobile devices alone may not be enough

  • Device-to-device communication is tricky

– Mobile OSes and APIs designed for connecting to infrastructure

  • How to bootstrap mobile devices?

– Want to avoid dependency on the web

  • Just using people’s mobiles may not be very reliable

– Fluctuation in device density during the day, week, year – Potentially shorter range, battery constraints

  • More predictable storage locations desirable

– Apps need to keep their data somewhere

slide-3
SLIDE 3

10/23/14 3

Aalto University School of Electrical Engineering

Do-It-Yourself Networking

Aalto University School of Electrical Engineering

1) Networking platform 2) Applications 3) Embracing Legacy Devices

slide-4
SLIDE 4

10/23/14 4

Aalto University School of Electrical Engineering

SCAMPI Networking Platform

  • Message-based interactions

– Self-contained ADUs (arbitrary size) – Metadata – Lifetime

  • Unicast / multicast / broadcast
  • Publish / subscribe
  • Search using metadata
  • Geo-based content sharing

(Floating Content)

AppTag ¡ Service ¡Name ¡ Metadata ¡

Key ¡(string) ¡ Value ¡(string, ¡ number) ¡

… …

Content ¡

Key ¡(string) ¡ Value ¡(string, ¡ buffer, ¡file) ¡

… …

Time-­‑to-­‑Live ¡

Aalto University School of Electrical Engineering

Liberouter

  • Basic features

– WLAN access point – Captive portal – SCAMPI router – Storage node – Can mesh with other liberouters

  • Applications

– Android liberouter distribution – Native SCAMPI (Java) applications – HTML5 SCAMPI-enabled

slide-5
SLIDE 5

10/23/14 5

Aalto University School of Electrical Engineering Aalto University School of Electrical Engineering

1) Networking platform 2) Applications 3) Embracing legacy nodes

slide-6
SLIDE 6

10/23/14 6

Aalto University School of Electrical Engineering

Deploying applications

  • App Stores (native)

– Native apps: access to device features – Store operator as a gatekeeper

+ quality control, trust − Internet dependency, delay, potential censorship

  • Web Apps (HTML5)

– Limitations due to frameworks – Usually require always-on Internet connectivity

  • An app is essentially a (signed) bag of bits

– Use messaging for distribution

Aalto University School of Electrical Engineering

SCAMPI Apps

SCAMPI Router

Search Unicast Pub/Sub Storage Peer Discovery Transport Native API

TCP

Platform-independent (needs JVM) Native Apps Platform- specific HTML5 Shim HTML5 App HTML5 App Distribution

install install

Platform- independent

slide-7
SLIDE 7

10/23/14 7

Aalto University School of Electrical Engineering

SCAMPI Apps

Aalto University School of Electrical Engineering

SCAMPI Apps

slide-8
SLIDE 8

10/23/14 8

Aalto University School of Electrical Engineering

SOME APPLICATIONS

Aalto University School of Electrical Engineering

Simple Messaging & Sharing Apps

slide-9
SLIDE 9

10/23/14 9

Aalto University School of Electrical Engineering

nearbyPeople

  • Exploiting ephemeral communities
  • Share a personal profile with interests in

the background

  • Observe how information from others

comes in

  • Exchange messages with people of

interest

  • Organize get-togethers around a

common event

Aalto University School of Electrical Engineering

Distributed “Google People Finder”

slide-10
SLIDE 10

10/23/14 10

Aalto University School of Electrical Engineering

Common Application Properties

  • Applications label object with AppTag and Service Name
  • Exchange identifiable objects
  • Objects carry (and may accumulate) (full) state
  • Objects may be aggregated by the application
  • Objects can be grouped (name, thread, …)
  • Objects can be processed and acted upon individually
  • There is no required ordering relationship

– Timestamps for ordered display, overriding older data

Aalto University School of Electrical Engineering

What we have now…

+

slide-11
SLIDE 11

10/23/14 11

Aalto University School of Electrical Engineering

1) Networking platform 2) Applications 3) Embracing Legacy Nodes

Aalto University School of Electrical Engineering

Reaching out…

slide-12
SLIDE 12

10/23/14 12

Aalto University School of Electrical Engineering

Reaching out…

Aalto University School of Electrical Engineering

Reaching out…

slide-13
SLIDE 13

10/23/14 13

Aalto University School of Electrical Engineering

Reaching out…

Aalto University School of Electrical Engineering

  • Legacy nodes = all nodes that don’t (yet) run a SCAMPI router

Embracing “Legacy” Nodes

Getting people to participate… Content Interaction for for Legacy Nodes …and benefit from their movement Instrumenting Legacy Nodes for Forwarding [Nagy et al., CHANTS 2014]

slide-14
SLIDE 14

10/23/14 14

Aalto University School of Electrical Engineering

Simple Application Model

M V C M’ C V’ m m’ Encoding Creation logic Presentation

Aalto University School of Electrical Engineering

Content Interaction

AppTag ¡ Service ¡Name ¡ Metadata ¡

Key ¡(string) ¡ Value ¡(string, ¡ number) ¡

… …

Content ¡

Key ¡(string) ¡ Value ¡(string, ¡ buffer, ¡file) ¡

… …

Time-­‑to-­‑Live ¡ ADU (or Application) new() present() respond() summary()

+

HTML5 [Nagy et al., under submission]

slide-15
SLIDE 15

10/23/14 15

Aalto University School of Electrical Engineering

Content interaction

  • Web-based access to locally

stored unecnrypted messages

– Content overview – Individual message rendering – Creating “responses” – Creating new messages

  • Summary

– App icon – Thumbnail or similar – Topic / threading – App-specific grouping

Aalto University School of Electrical Engineering

Forwarding with Legacy Nodes

  • Browsers = modestly powerful storage devices

– Cookies: 4096 bytes per cookie, ~150 cookies per domain – Web storage: 2.6 – 5.2 MB per domain

  • All liberouters form one domain

– Cookies will be sent and accepted – Web storage will be accessible

  • Translate messages into

– Cookies (if they are small) – Storage objects (if they are larger) – Use SHA-1 hashes of content for unique naming Yields a “Backbone” Between liberouters

[Nagy et al., CHANTS 2014]

slide-16
SLIDE 16

10/23/14 16

Aalto University School of Electrical Engineering

Quick Look at Evaluation

3 scenarios in ONE simulator

  • 1. Random Waypoint

– 1x1km area – {10, 20, 50} DTN nodes – 8 or 16 APs

  • 2. Shortest Path Map Based Movement (SPMBM)

– Helsinki downtown area [Pitkänen et. al. 2010] – {50, 100, 200} pedestrians (restless tourists) – 11–325 stationary APs

  • 3. OPP

– like 2. above with {10, 20, 50, 100}% of devices acting as APs

Number of legacy nodes: Nl∈ {0, 1, 5, 10} × Nd

Aalto University School of Electrical Engineering

Quick Look at Evaluation

0.6 0.8 1 1.2 1.4 0.8 1 1.2 1.4 1.6 1.8 2 Relative mean delivery delay Relative mean delivery probability RWP L1 RWP L5 RWP L10 MBM L1 MBM L5 MBM L10 OPP L1 OPP L5 OPP L10

slide-17
SLIDE 17

10/23/14 17

Aalto University School of Electrical Engineering

Conclusion

  • DIY networking with less dependency on the Internet
  • Creating a somewhat autonomous ecosystem
  • Lowering the barrier for participation: web browsers

– Content interaction and forwarding

  • Currently exploring

– Updating our software distribution (see below) – More diverse (outdoor) applications – Application authoring – Mutable contents, distributed editing, and merging [Kärkkäinen et al., CHANTS 2014] http://www.ict-scampi.eu/results/scampi-liberouter/