The Real Ad Multi hop Peer to peer Content sharing Social...

11.11.2013 – Mobilware ‘13 CIRI‐ICT – Università di Bolognaviale Risorgimento, 2 – 40136 Bologna

The Real Ad‐hoc Multi‐hop Peer‐to‐peer (RAMP) Middleware:

Content sharing and Social Networking

Paolo BellavistaCarlo GiannelliStefano Poli

Bologna, Italy ‐ 11.11.2013 Stefano Poli – Mobilware ’13

Scenario Smart devices and spontaneous networking Online social networks, social relationships, and content sharing

RAMP middleware Solution for spontaneous networking and content sharing

Resource access filtering based on social relationship tightness

Preliminary experimental results

1

Agenda


Widespread availability of smart devices(smartphones, tablets, notebooks, smart TVs, etc.)

heterogeneous wireless connectivity powerful computing capabilities exploited to access services and generate/sharecontent

Scenario: Smart Devices

2


Widespread use of Online Social Networks (OSNs) Creating relationships between users Interaction between users

Message exchanging, photo tagging, etc.

User‐generated content sharing

Sensitive issue: users lose control on resources when uploaded on OSNs

Scenario: Social Networks

3

SharingUploading

OSN servers


Resource sharing Middleware solution allowing to share content and services in a peer‐to‐peer way while fully preserving content ownership

Content sharing based on legacy protocols such as HTTP and UPnP

Visibility Filtering Resource filtering system based on relationships Issue: OSN relationship does not allow to discriminate among friends

Social Relationship Tightness evaluation to tune/differentiate access to shared resources

4

Challenges


Resource sharing without centralized servers OSN only to advertise the new content Resources sent from storing device to requesting one Resource ownership maintained by resource owner

5

Resource Sharing

A

Alice Bob

B

Internet

OSN1. Publish

content location

2. Get content location

3. Get content


Automatic creation of Spontaneous Networks (SNs) Impromptu interconnection of mobile and fixed nodes Node cooperation (single/multi‐hop connectivity, P2P services)

Example: node A interacts with node E via intermediate nodes C and D

6

Real Ad‐Hoc Multi‐hop Peer‐to‐peer (RAMP) middleware


Automatic creation of User Centered Networks (UCNs) based on OSN identities

7

RAMP: User Centered Network (UCN)

D

FE

A B

C

InternetGW2GW1

Bob

Bob’s home SN Bob’s office SN

Bob’s UCNBob’s OSN identityBob’s OSN identity

Bob


Home to home resource sharing Dynamic federation of UCNs based on social relationships

8

RAMP: Federation of UCNs

D

FE

A B

C

InternetGW2GW1

OSN relationship (e.g. Facebook friendship)OSN relationship (e.g. Facebook friendship)Bob Alice

Bob’s UCN Alice’s UCN

UCNs Federation Alice’s OSN accountBob’s OSN account


Filtering system to control access to resources E.g. Bob and Alice are friends on Facebook; node A of Bob requests a resource to node E of Alice: requests will be accepted or denied

9

Filtering System

Bob Alice

A B

C

GW1

D

FE

GW2

Resource access control

Bob’s UCN Alice’s UCN


Very coarse grained filtering Checking only the relationship type (e.g. Facebook relationship, Twitter relationship)

E.g. Alice specifies a rule for Facebook relationships: that rule will be applied to all requests coming from her Facebook friends

10

Current Filtering System: limitations

Alice

A

Bob

BCarl

C

Facebook friend

Twitter friend

• Facebook friends: allowed• Twitter friends: denied

Rules


Idea: if two users are close friends, it is likely they are willing to share services and resources one another

Close friends should be able to access more resources Filtering rules based on relationship tightness or specific friend ID

11

New Filtering System: insights

Alice

ABob

BCarl

C

Facebook close friend

• Twitter friends: allowed• Facebook close friends: allowed• Facebook regular friends: denied• Carl: denied

RulesDeb

DEd

E Facebook regular friend

Twitter regular friend

Facebook close friend


Dynamically evaluated relationship tightness Well‐defined grammar to specify high‐level filtering rules Runtime visibility tuning of shared resources

12

RAMP: new Filtering System

TightnessEvaluator

VisibilityTuner

OSNN

OSN2

OSN1 social data

relationshiptightness

RAMPPacket

Dispatcher

packet fromprevious node

packet tonext node

packetmonitoring

Web GUI

Web GUI

Gathering social meta/data from OSNs

Social relationship tightness evaluation

Active monitoring of RAMP traversing packets

Runtime enforcement of filter rules

Users can customize the middleware behavior


Idea: if two users interact very frequently on a OSN, it is likely that their relationship is tight

Three tightness categories: “tight”, “regular”, “loose”

E.g. Alice and Bob have exchanged more than 50 messages => tight between 5 and 50 messages => regular less than 5 messages => loose

13

Tightness Evaluator


Users typically exploit OSN interaction tools in different ways (private/public message exchanging, quotes in texts, photos, videos, etc.) E.g. Alice exploits only private messages to interact with her tight friends, while Bob is used to exploit public posts

Survey (20 Facebook users, 10 Twitter users) to identify useful data and build to decision model

Weka to analyze gathered data

14

Tightness Evaluator

Bologna, Italy ‐ 11.11.2013 Stefano Poli – Mobilware ’13 15

Tightness Evaluator

TIGHTREGULARLOOSE

# sent messages

# instances

Tightness: Single attribute is not enough to classify relationships

Intersection of different attributes

Five most significant Facebook attributes1. # of messages friend has sent to the user2. # of messages user has sent to the friend3. # of user’s photos friend is tagged in4. # of user’s posts friend is tagged in5. # of posts friend has sent to the system user


Default Decision Tree Model useful for the first evaluation

Users can improve the Decision Tree Model specifying the tightness of (part of) their relationships

16

Tightness Evaluator


Tightness Evaluator: implementation insights

Social meta/data gathered from OSNs

Producing suitable information to support Decision Tree Generator

Periodic data updating

Decision tree based on gathered information

J48 (C4.5) algorithm Weka APIs to perform classification

Usage pattern computation to customize the decision tree

User’s direct customization

Specific OSN APIs


Packet monitoring and runtime enforcement of visibility rules Discovery Filter: to hide/expose nodes and services Browse Filter: to tune the visibility of shared contents Action Filter: to tune the access to supported features and

resources

18

Visibility Tuner: Packet Filters

Smart TV

InternetNAS1GWA

Alice's UCNCate's UCN

GWC

NAS2

service discovery

service response

Smart TV

InternetNAS1GWA GWC

NAS2

a)

b)

Ingress packet filtering (dropping a request)

Egress packet filtering (selective forwarding of only replies coming from given devices)


Discovery rule:1. DF_FacebookFriend_tight = /, 5545 [/, +FS]2. DF_GenericSocial_loose = /

Browse rule:3. BF_TwitterFriend_tight = *4. BF_TwitterFriend_57349 = /, 5545 [/, FS ".*?\.(mp3|divx)$"]

Action rule:5. AF_FacebookFriend_regular = /, 5545 [/, FS [/, +get]]6. AF_Generic = *, 124878 [/, Light [/, +SwitchPower]]

19

Visibility Tuner: Rules grammar

Service visibility

Node ID

Default service visibility on each node

Default service visibility on node 5545

Filter type OSN type Tightness


Visibility Tuner: implementation insights

Performing filtering actions at runtime applying filter objects

Storing Java objects implementing actual filters

Adding/removing filters and de/activating them

Ex: Discovery Filter for RAMP‐based File Sharing service, Action Filter for UPnP devices


Required times to evaluate tightness Required times to filter packets

21

Experimental results: testbed

RAMP‐based File Sharing client

GW UPnP AV packets

RAMP‐based File Sharing server UPnP Media Server

UPnP Control Point

Facebook


Experimental results: Tightness Evaluator

1

10

100

1000

10000

100 150 200 250 300 350 400 450 500

Per‐ph

ase Upd

ating Time [s]

Relationships

User

Friends list

Friends' data

0

500

1000

1500

2000

2500

3000

3500

4000

0 100 200 300 400 500 600

Time requ

ired to classify

[ms]

Amount of friends

Required time to process User, Friend List and Friend Data

Friend Data sub‐phase greatly influences the total time

Required time to classify relationshipslinearly grows with the amount of friends


Experimental results: Visibility Tuner

0

2

4

6

8

10

12

14

0 500 1000 1500 2000

Average Filte

ring Time [s]

Packet Rate [packets/s]

File Sharing

UPnP

0

2

4

6

8

10

12

14

16

0 500 1000 1500 2000

Avrage

Filtering Time [s]

Packet Rate [packets/s]

Filtering of ingress “browse” request packets (File Sharing 53 bytes; UPnP 52 bytes)

Filtering of egress “browse” packets (responses to “browse” requests; 60 bytes) for the File Sharing service

Parsing and modification of responses Almost linear growing with the packet rate


Automatic creation of SNs and UCNs

Federation of UCNs based on Social Relationships

Automatic Social Relationship tightness evaluation

Feature and resource visibility tuning based on Social Relationship Tightness ( Packet Filters)

Ongoing work GUI to facilitate rules definition Support to NAT‐T environment Hybrid cloud‐based deployment to improve availability

24

Conclusions and ongoing work

11.11.2013 – Mobilware ‘13 CIRI‐ICT – Università di Bolognaviale Risorgimento, 2 – 40136 Bologna

The Real Ad‐hoc Multi‐hop Peer‐to‐peer (RAMP) Middleware:

Content sharing and Social Networking

Paolo BellavistaCarlo GiannelliStefano Poli

THANKS FOR YOUR ATTENTIONQuestions time…

see alsoP. Bellavista, C. Giannelli , L. Iannario, L. Goix, C. Venezia:"Peer‐to‐peer Content Sharing Based on Social Identities and Relationships", IEEE Internet Computing (accepted for publication)

Date post:	10-May-2020
Category:	Documents
Upload:	others
View:	1 times
Download:	0 times

The Real Ad Multi hop Peer to peer Content sharing Social...

Documents