CS434/534: Topics in Networked (Networking) Systemszoo.cs.yale.edu/classes/cs434/cs434-2017-spring/lectures/22-mobil… · 3 Recap: Making Bluetooth Conn. Underlying technology Nodes

CS434/534: Topics in Networked (Networking) Systems

Mobile Networking System: Making Connections: Cloud; NFC

Yang (Richard) YangComputer Science Department

Yale University208A Watson

Email: [email protected]

http://zoo.cs.yale.edu/classes/cs434/

Admin.❒ Project planning

❍ Checkpoint II: Apr. 20• Initial design; feedback from instructor/TF

❍ Checkpoint III: Apr. 27• Design refined; key components details

❍ Final due: May 4• No more than 6 page write up

2

3

Recap: Making Bluetooth Conn.❒ Underlying technology

❍ Nodes form piconet: one master and upto 7 slaves• A node makes itself discoverable• The slaves discover the master and follow the

pseudorandom jumping sequence of the master❍ Higher-layer introduces profiles to provide specific functions

❒ Android Bluetooth software API❍ Configuration: Announce Bluetooth permission❍ Intent to request systems service: turn on BT, become

discoverable❍ Obtaining bonded devices: query, register broadcast

receiver❍ Connection:

• Server: mBluetoothAdapter.listenUsingRfcommWithServiceRecord(SNAME,MY_UUID); …

A piconet

Recap: Making WiFi Direct Conn.

4http://www.it.uc3m.es/pablo/papers/pdf/2012_camps_commag_wifidirect.pdf

WiFi Direct Software Framework (Android)❒ Setup permission in Manifest❒ Create IntentFilter and Broadcast Receiver to obtain related updates

❍ intentFilter.addAction• WIFI_P2P_STATE_CHANGED_ACTION• WIFI_P2P_PEERS_CHANGED_ACTION• WIFI_P2P_CONNECTION_CHANGED_ACTION• WIFI_P2P_THIS_DEVICE_CHANGED_ACTION

❍ /** register the BroadcastReceiver with the intent values to be matched */@Overridepublic void onResume() {

super.onResume();receiver = new WiFiDirectBroadcastReceiver(mManager, mChannel, this);registerReceiver(receiver, intentFilter);

}

@Overridepublic void onPause() {

super.onPause();unregisterReceiver(receiver);

}

❒ Initiate action❍ Call discoverPeers

mManager.discoverPeers(mChannel, new WifiP2pManager.ActionListener() {…

❍ Call connect ❍ Create group

5

6

Recap: Making Cellular Conn. ❒ Issue: Given the large overhead to set up radio

resources, UMTS implements radio resource control (RRC) state machine on mobile devices

❒ How to best design this framework (or more generally power management framework for wireless) is not fully solved.

Channel Radio Power

IDLE Not allocated

Almost zero

CELL_FACH Shared, Low Speed

Low

CELL_DCH Dedicated, High Speed

High

7

Outline❒ Admin❒ Android

❍ Platform overview❍ Basic concepts❍ Inter-thread: execution model with multiple threads❍ Inter-process: component composition❍ Inter-machine: network-wise composition

• Service discovery• Make connections

– Bluetooth– WiFi Direct– Cellular– Mobile cloud

Discussion: Mobile Cloud Connections

❒ What are some reasons (services) you can think of involving mobile-cloud connections?

8

Example Mobile Cloud Services

❒ Push notification service❒ Storage and sync, e.g.,

❍ Syncing and storage service (iCloud)❍http://blog.udinic.com/2013/07/24/write-

your-own-android-sync-adapter/❒ Compute and split architecture, e.g.,

❍ Siri, Amazon silk (http://docs.aws.amazon.com/silk/latest/developerguide/introduction.html)

9

10





» Cloud push notification

Setting: Data Refresh❒ A typical design pattern is that a device

updates/receives data (e.g., news) from publisher

❒ A first solution is mobile pull, but this can create large overhead

11

Shared Push Service

❒ A single persistent connection from device to a cloud push service provider

❒ Multiple application providers push to the service provider

❒ Service provider pushes to a device using the persistent connection

❒ Two examples❍ Apple Push Notification Service (APNS)❍ Firebase (Google) Cloud Messaging (FCM/GCM)

12

Design Requirements of a Shared Push Service

❒ Security/Authorization❍ Do not allow arbitrary app to push to a device

❒ Scalability❍ A large scale system may have millions of clients

❒ Fault tolerance❍ Client/device, push servers all can fail

❒ Generality❍ Can be used by diverse applications 13

Design Point: Authorization/Sub-Pub Management

❒ Many options, e.g.,❍ Open group, e.g., publishers push topics and

devices subscribe to topics❍ Closed group

14

App Device

Registration(DEV_ID, App_ID)

Device notifies registration ID to its server;

Design Point: What to Push?

❒ Option 1: Just push signal (data available) to devices and then devices fetch from app servers

❒ Option 2: push app data

15

App

Device

Apple Push Notification Service

16

❒ iOS device maintains a persistent TCP connection to an Apple Push Notification Server (APNS)

A push notification from a provider to a client application

Multi-providers to multiple devices

APNS Authorization: Device Token

17

❒ Device token Contains information that enables APNS to locate the device❍ Client app needs to provide the token to its app provider❍ Device token should be requested and passed to providers

every time the application launches

Apple Push Notification Data

❒ Each push notification carries a payload❍ 256 bytes maximum❍ Best effort delivery

❒ App provider provides a JSON dictionary object, which contains another dictionary identified by the key aps

❒ App specifies the following actions• An alert message to display to the user• A number to badge the application icon with• A sound to play

18

APNS Example: Client

19

1. - (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions

2. {3. // Let the device know we want to receive push notifications4. [[UIApplication sharedApplication] registerForRemoteNotificationTypes:5. (UIRemoteNotificationTypeBadge | UIRemoteNotificationTypeSound |

UIRemoteNotificationTypeAlert)];6.7. return YES;8. }

9. - (void)application:(UIApplication*)application didReceiveRemoteNotification:(NSDictionary*)userInfo

10. {//userInfo contains the notification11. NSLog(@"Received notification: %@", userInfo);12. }

13. - (void)application:(UIApplication*)application didRegisterForRemoteNotificationsWithDeviceToken:(NSData*)deviceToken

14. {15. NSLog(@"My token is: %@", deviceToken);16. }

APNS Example: Server

20

1. $devicetoken ='f05571e4be60a4e11524d76e4366862128f430522fb470c46fc6810fffb07af7’;

2. // Put your private key's passphrase here:3. $passphrase = 'PushChat';4. // Put your alert message here:5. $message = ’CS434: my first push notification!';

1. $ctx = stream_context_create();2. Stream_context_set_option($ctx, 'ssl', 'local_cert', 'ck.pem');3. stream_context_set_option($ctx, 'ssl', 'passphrase', $passphrase);

4. // Open a connection to the APNS server5. $fp = stream_socket_client(6. 'ssl://gateway.sandbox.push.apple.com:2195', $err,7. $errstr, 60, STREAM_CLIENT_CONNECT|STREAM_CLIENT_PERSISTENT, $ctx);

8. if (!$fp)9. exit("Failed to connect: $err $errstr" . PHP_EOL);

10. echo 'Connected to APNS' . PHP_EOL;

APNS Example: Server (cont’)

21

16. // Create the payload body17. $body['aps'] = array(18. 'alert' => $message,19. 'sound' => 'default'20. );

21. // Encode the payload as JSON22. $payload = json_encode($body);

23. // Build the binary notification24. $msg = chr(0) . pack('n', 32) . pack('H*', $deviceToken) . pack('n', strlen($payload))

. $payload;

25. // Send it to the server26. $result = fwrite($fp, $msg, strlen($msg));

27. if (!$result)28. echo 'Message not delivered' . PHP_EOL;29. else30. echo 'Message successfully delivered' . PHP_EOL;

31. // Close the connection to the server32. fclose($fp);

Firebase Cloud Messaging

❒ Very similar to APNS

22

FCM Servers

https://developers.google.com/cloud-messaging/FCM is a newer version of GCM

23





» Basic use» Thialfi as an implementation example

Example Implementation: Thialfi

❒ Deployed in Chrome Sync, Contacts, Google Plus

❒ Goals❍ Scalable: tracks millions of clients and objects❍ Fast: notifies clients in less than a second❍ Reliable: even when entire data centers fail

24

Thialfi Overview

Thialfi client library

Register X Notify X

ClientData center

X: C1, C2

Client C1 Client C2

Thialfi Service

Update XRegister

Register

Update XApplication backend

Notify X Notify X

25

26






» Overview, abstraction

Thialfi Abstraction

❒ Objects have unique IDs and version numbers, monotonically increasing on every update

❒ Delivery guarantee❍ Registered clients learn latest version number❍ Reliable signal only: cached object ID X at version Y

• Why signal only: For most applications, reliable signal is enough

27

Thialfi Client API

28

API Without Failure Recovery

Thialfi Service

Publish(objectId, version)

ClientLibrary

Register(objectId)Unregister(objectId)

Notify(objectId, version)

29

Architecture

ClientBigtable

• Matcher: Object ID à registered clients, version• Registrar: Client ID à registered objects, notifications

Client

Registrar

MatcherObjectBigtable

Data center

Notifications Application Backend

Registrations, notifications,acknowledgments

Client library

30

• Each server handles a contiguous range of keys• Each server maintains an in-memory version• Bigtable: log structured, fast write

C1: x, v7C2: x, v7C1: x, v5C2: x, v5

x: v5; C1, C2x: v7; C1, C2x: v7; C1, C2

x

Life of a Notification

ClientBigtable

C1: x, v7

C2: x, v7

Notify: x, v7

Client C2


Data center

Publish(x, v7)x, v7

Ack: x, v7

31

Registrar

32






» Overview, abstraction» Failure recovery

Data center lossServer state loss/schema migrationPartial storage unavailability

Possible Failures

ClientLibrary

ClientBigtable Registrar


ClientBigtable Registrar


. . .

Data center 1 Data center nThialfi Service

ClientStore

Client restartClient state loss

Publish Feed

Network failures

33 3/5/12

Failures

❒ Client restart❒ Client state loss❒ Network failures❒ Partial storage unavailability❒ Server state loss / schema migration❒ Publish feed loss❒ Data center outage

34

How to Handle Failures❒ Principle: Soft state only, where a state at the third

party is soft state if the the entity who sets up the state does not refresh it, the state will be pruned at the third party

❒ Thialfi has two types of states, and both are soft state❍ registration state❍ notification state

❒ State recovery❍ Registration state

• registratinoReissueRegistrations() at client• Registration Sync Protocol to propagate to server

❍ Notification state recovery• allow NotifyUnknown()

35

Recovering Client Registrations

36

Registrar


x

y

x yReissueRegistrations()

Register(x); Register(y)

Registrar


Register: x, y

Syncing Client Registrations

x

y

Hash(x, y) x y

• Goal: Keep client-registrar registration state in sync• Every message contains hash of registered objects• Registrar initiates protocol when detects out-of-sync• Allows simpler reasoning of registration state

Reg sync

37

Hash(x, y)

Merkle tree for syncing large number of objects

Recovering From Lost Versions

❒ Versions may be lost, e.g. schema migration

❒ Inform client with NotifyUnknown(objectId)❍ Client must refresh, regardless of its current state

38

Notification Latency Breakdown

0

100

200

300

Notification latency (ms)

Matcher to Registrar RPC (Batched)Matcher Bigtable Read

Matcher Bigtable Write (Batched)Bridge to Matcher RPC (Batched)App Backend to Bridge

Batching accounts for significant fraction of latency39

Thialfi Usage by Applications

40

Application Language Network Channel

Client Linesof Code(Semi-colons)

Chrome Sync C++ XMPP 535

Contacts JavaScript Hanging GET 40

Google+ JavaScript Hanging GET 80

Android Application

Java C2DM + Standard GET

300

Google BlackBerry Java RPC 340

Pointers to Additional Work

❒ See Facebook Wormhole pub/sub design

❒ See Sapphire automatic mobile/cloud split design

41

42




– Bluetooth– WiFi Direct– Cellular– Mobile cloud– Near Field Communication (NFC)

43

RFID (Radio Frequency Identification)

❒ The initial development of NFC is RFID, with many applications, e.g., ❍Secure Entry

cards ❍Supply chain

management

RFID Basic Architecture

44

RFID Tag

❒ Tag is a device used to transmit information such as a serial number to the reader in a contact less manner

❒ Classified as❍ Passive – energy from reader ❍ Active - battery battery❍ Semi-passive – battery and energy

from battery and energy from reader

45

RFID Reader

❒ Also known an interrogator ❒ Reader powers passive tags with RF energy

(for passive tags)❒ Consists of:

❍ Transceiver❍ Antenna❍ Microprocessor❍ Network interface

46

Nexus Hardware

47

1.Front-facing camera2.Earpiece3.Power button4.Volume buttons5.Headset jack6.Speaker7.USB Type-C port8.Laser auto focus & dual-LED flash9.Rear-facing camera10.NFC11.SIM card tray12.Fingerprint sensor

RFID Passive Receiver: Foundation

48

https://en.wikipedia.org/wiki/Faraday%27s_law_of_induction#/media/File:Faraday_emf_experiment.svg

Near Field RFID

❒ <= 100 Mhz 49

How far can a passive tag be read?❒ Assume distance limited by power available

to run the tag’s circuits

50

Maximum Distances to Read UHF Passive Tag

51

Example NF Use: Contactless Smart Card

❒ Proximity Smart Cards (13.56 MHz)❍ Range = 4 inches (10 centimeter)❍ Baud rate = 106 kilobaud❍ ISO/IEC 14443

❒ Vicinity Smart Cards (13.56 MHz)❍ Range = 3 feet (1 meter)❍ Baud rate = 26.48 kilobaud❍ ISO/IEC 15693

❒ Animal Identification (134 KHz, 125 KHz@US)❍ ISO 11784/11785

❒ VeriChip as human plantable RFID tag (134 KHz)

52

Far Field RFID

53

RFID MAC Protocol

❒ Select phase ❍ Single out particular tag population with one or more bits with query tree protocol protocol

❒ Inventory phase– identify individual tag using Q protocol (slotted-aloha based)❍ Reader sends Query with parameter Q and Session number (Q=4 is suggested

default) ❍ Reader creates slotted time ❍ Tags pick random 16-bit number as handle❍ Tags in requested session pick a random number in the range [0,2^Q-1] for

slot_number❍ If slot_number = 0, backscatter handle ❍ If slot_number != 0, wait that number of slots to backscatter ❍ Reader ACKs individual tag with handle and goes to access phase. All other tags wait. ❍ If more that one tag answers, reader can send same Q again or send modified Q

❒ Access phase❍ Reader interacts with tags requesting EPC number and any other information

54

Select Phase: Query Tree

55

Select Phase: Query Tree

56

Inventory Phase (Q Protocol; Slotted Aloha)

57

Android NFC User Programming API

❒ System discovers NFC tag❒ Key issue: how to determine the application

to be invoked❍ Implication: need a tag dispatch system

❒ Android tag dispatch design❍ Parsing the NFC tag and figuring out the MIME type or a URI that

identifies the data payload in the tag.❍ Encapsulating the MIME type or URI and the payload into an intent. ❍ Starts an activity based on the intent.

58

https://developer.android.com/guide/topics/connectivity/nfc/nfc.html

Tag to MIME/URI

❒ Requires tag uses NDEF (NFC Data Exchange Format), which consists of a sequence of NDEF records❍ First record provides 3-bit TNF (type name

format)

59

Intent Dispatch❒ ACTION_NDEF_DISCOVERED: This intent is used to start an

Activity when a tag that contains an NDEF payload is scanned and is of a recognized type. This is the highest priority intent, and the tag dispatch system tries to start an Activity with this intent before any other intent, whenever possible.

❒ ACTION_TECH_DISCOVERED: If no activities register to handle the ACTION_NDEF_DISCOVERED intent, the tag dispatch system tries to start an application with this intent. This intent is also directly started (without starting ACTION_NDEF_DISCOVERED first) if the tag that is scanned contains NDEF data that cannot be mapped to a MIME type or URI, or if the tag does not contain NDEF data but is of a known tag technology.

❒ ACTION_TAG_DISCOVERED: This intent is started if no activities handle the ACTION_NDEF_DISCOVERED or ACTION_TECH_DISCOVEREDintents.

60

Backup Slides

61

Documents

CS434/534: Topics in Networked (Networking) Systemszoo.cs.yale.edu/classes/cs434/cs434-2017-spring/lectures/22-mobil… · 3 Recap: Making Bluetooth Conn. Underlying technology Nodes