Lecture 13 Mobile Data Services in Wireless Environments Wireless and Mobile Systems Design.

Lecture 13Mobile Data Services inWireless Environments

Wireless and Mobile Systems Design

Mobile Data Services in Wireless Environments 2

Lecture Objectives

● Understand data management issues of providing data services to mobile applications in wireless networks

■ Data access model: on-demand vs. broadcast■ Scalability issue■ Power conservation

○ Response time vs. tuning time ■ Caching on mobile devices and invalidation protocols■ Mobile transactions

● Understand how to implement broadcast-based data service applications in wireless client-server environments


Sources

● E. Pitoura and P. K. Chrysanthis, “Multiversion data broadcast”, IEEE Trans. Computers, Oct. 2002, pp. 1224-1230.

● V. C. S. Lee, K. W. Lam, S. H. Son and E. Y. M. Chan, “On transaction processing with partial validation and timestamp ordering in mobile broadcast environments,’’ IEEE Trans. Computers, Oct. 2002, pp. 1196-1211.

● K. L. Tan, J. Cai and B. C. Ooi, “An evaluation of cache invalidation strategies in wireless environments,” IEEE Trans. Parallel and Distributed Systems, Aug, 2001, pp. 789-807.

● S. Acharya, R. Alonso, M. J. Franklin and S. Zdonik, “Broadcast disk: data management for asymmetric communications environments,” ACM SIGMOD International Conf. On Management of Data, 1995, pp. 199-210 (downloadable from http://citeseer.nj.nec.com/45388.html).

● M. S. Chen, K. L. Wu and P. S. Yu, “Indexed sequential data broadcasting in a wireless computing environment,’’ 7th IEEE International Conf. on Distributed Computing Systems, 1997, pp. 124-131.


Agenda

● Approaches of providing database services to mobile applications

● Broadcast-based data services■ Server broadcast program: flat versus broadcast disk■ Indexing in air■ Caching and cache invalidation strategies■ Support for transaction executions

○ Transactional semantics○ Support for read-only transactions○ Support for update transactions

● Example code for client-server data services in MS Visual Studio .NET C++ and EVC++


Database Services to Mobile Applications

● On-demand database services■ A mobile client sends a query to the server■ The server processes the query and returns a response to

the mobile client■ Not scalable to a large number of mobile devices since the

communication channel/server would be overloaded

● Broadcast-based database services ■ Data are broadcast on a public wireless channel■ When a mobile device receives a query from its user, it

“tunes” into the broadcast channel and “filters” out the data requested by the query

■ Updates are still sent to the server on-demand ■ Scalable


Performance Metrics in Data Services: Response Time vs. Tuning Time

● Response time (access time): Average time elapsed from the moment a client requests for a data item to the receipt of the value of the data item

● Tuning time: The amount of time the mobile device is powered-on

■ For broadcast-based data services, this is the amount of “connection time” spent by the mobile device listening to the broadcast channel and retrieving the data item

■ When the server’s broadcast structure (e.g., indexing in air) is known to mobile devices, it is possible for a mobile device to go to “doze” mode and then only “wake-up” at the right time to retrieve the data item requested by the user

● Response time = Tuning time if the mobile device is always on● Minimizing the tuning time is important for conserving the

battery life of mobile devices


Server Broadcast Program

● Flat: broadcast one data item at a time sequentially

● Broadcast disk organization:■ Items of the broadcast are

divided in ranges of similar access probability

■ Each of these ranges is placed on a separate disk

■ Disks are split into smaller equal-sized units called chunks, s.t. the number of chunks per disk is inversely proportional to the access probability of the disk

■ Each broadcast cycle is generated by broadcasting one chunk from each disk and cycling through all the chunks sequentially over all disks

■ A minor cycle is a subcycle that consists of one chunk from each disk

1 2 3 4 5 6 7 8 9 10

hot cold

1 2 3 4

5 6 7 8 9 10

Disk 1 Disk 2

1 2 3 4

5 6 7 8 9 10

Chunk 1 Chunk 2b Chunk 2cChunk 2a

1 2 3 41 2 3 41 2 3 4 5 6 7 8 9 10

1 112a 2b 2c

minor cycle

Broadcast cycle

access probability ratio of hot to cold is 3:1


Server Broadcast Program (cont.)

● Average access time

■ Flat:

(3/4)*(10/2) +

(1/4)*(10/2) = 5

vs.

■ Broadcast Disk:

(3/4)*(6/2) +

(1/4)*(18/2) = 18/4 = 4.5

1 2 3 41 2 3 41 2 3 4 5 6 7 8 9 10

minor cycle

Broadcast cycle

Access probability ratio of hot to cold is 3:1

1 2 3 4 5 6 7 8 9 10

hot cold

1 2 3 4 5 6 7 8 9 10

vs.

Broadcast cycle


Indexing in Air

● Air indexing is used to save battery power of mobile devices

● The server builds an index tree based on access probabilities of broadcasting data items such that a data item with a high access prob. is at a shallow level

● The server interleaves index information with data items on the broadcast channel

● By searching the index, a mobile client can predict the desired data’s arrival time, stay in doze mode and tune in when the requested data arrives

● Tuning time can be limited to the number of index probes + data

I

a2a1 a3

R1 R2 R3 R4 R5 R6 R7 R8 R9

An index tree with fanout of 3 holding nodes with equal access probabilities

I a1 R1 R2 R3 a2 R4 R5 R6 a3 R7 R8 R9

Index probing scenario to data item R5 for which the number of index probes = 2


Indexing in Air: Another Example

I R1 R2 a1 R3 a2 R4 R5 R6 a3 R7 R8 R9

A corresponding data broadcast sequence

Index tree is built based onHuffman code witha specified fanout

The index tree on the right has afanout of 3

I

a2

a1

a3R1 R2

R4

.05

R5

.02

R3

R6

.02

R7

.02

R8

.02

R9

.02

0.09 0.06 0.05

0.20.40.4

An index tree with fanout d=3

number of indexprobes = 1 for R1, R2

number of indexprobes = 2 for R3

number of indexprobes = 3 for R4 – R9


Algorithm CF for Constructing a Huffman Index Tree with Constant Fanout d

An index tree with d=4

I

a2

a1

R1 R2

R4

.05

R3

.05

R5

.02

R6

.02

R7

.02

R8

.02

R9

.02

0.08

0.20.40.4

● Initially, we have a forest of n subtrees, each of which contains a single node with an access probability

● Attach the d subtrees with the smallest access probabilities to a new node

● Label the resulting subtree with the sum of all access probabilities from its d subtrees

● Continue the tree merging process until there is only a single tree


Goal of Building Index Tree with Fixed Fanout: Minimizing Number of Index

Probes● Algorithm CF is

guaranteed to construct an index tree (given a constant fanout) that would minimize the average number of index probes, computed as:

28.14302.0202.02205.0214.0 probeN


I

a2

a1

R1 R2

R4

.05

R3

.05

R5

.02

R6

.02

R7

.02

R8

.02

R9

.02

0.08

0.20.40.4

])()Pr([1

iprobe

n

iiprobe RNRN


Performance Metric: Number of Index Probes vs. Index Probing Cost

])()Pr([)(1

jRPatha

n

iiprobe adRC

ij

fanout of aj

● Number of index probes■ may not properly account for the index probing cost

because it assumes the cost of visiting each index node is the same

Note that we can always construct a two-level tree with all data nodes located at the bottom level

– The number of index probes would be only 1

● Index Probing Cost■ Let the cost of visiting an index node be proportional to the

fan-out d of that index node


Index Probing Cost


I

a2

a1

R1 R2

R4

.05

R3

.05

R5

.02

R6

.02

R7

.02

R8

.02

R9

.02

0.08

0.20.40.4

12.4

4)443(02.0

)43(02.0

2)43(05.0

234.0

])()Pr([)(1

jRPatha

n

iiprobe adRC

ij

Check it yourself:For the index treewith d=3, the index probing cost is 4.05


Algorithm VF for Constructing an Index Tree with Variable Fan-outs

● Use index probing cost as performance metric ● NP complete problem

■ Use greedy heuristics

R1

r

Rm

…R2

Rm

r

hx

R1 R2

Ri+2Ri+1

Ri

…

…

Initially, all nodes are sorted in descending orderIn access probability

Split at the node at which the cost gained is maximized


Data Caching

● Data is cached at the mobile client● When the client receives a query, the mobile first

searches its cache■ If there is a “valid” copy, the mobile client returns an answer■ If not, the mobile client obtains a copy through on-demand

or from broadcast

● Caching is particularly important in mobile environments

■ Save power■ Improve access latency■ Improve data availability in case of disconnection

● Cache consistency: the server sends invalidation reports to mobile clients


Cache Invalidation Design in Mobile Database Applications

● Stateful-based: The server knows the data items cached by the mobile clients and will send invalidation messages to the affected clients when there is any update to the database

■ Not scalable

● Stateless-based: the server broadcasts information on objects that are most recently updated and the clients listen and use the reports to invalidate their caches

■ Scalable■ Asynchronous: once a data item is updated, the server

broadcasts immediately – not useful for clients who may be disconnected for a period of time

■ Synchronous: periodic broadcasting of invalidation reports


Dual-Report Strategies for Periodic Broadcasting of Invalidation Reports

● The server broadcasts in every L time units a pair of invalidation reports, i.e., an object invalidation report (OIR) and a group invalidation report (GIR):

■ OIR is used to invalidate individual objects■ The content of OIR is a list (oid, tid), where oid is the object id and tid

is the timestamp at which the object was updated during [T- L,T]■ GIR is used to invalidate the remaining objects whose group has

been updated during [T-WL,T], W > ■ The content of GIR is a list (Gid, Tid), where Gid is the group identifier

and Tid is the most recent timestamp at which the group is valid■ GIR excludes objects already reported in OIR

T

[T- L,T]

[T-WL,T]OIR

GIR


Dual-Report Strategies: Example

● Example: T = 34, L =4, = 2, W = 6● Suppose objects are initially split into 4 groups: G1{o1, o2, o3, o4},

G2{o5, o6, o7, o8}, G3{o9, o10, o11, o12}, G4{o13, o14, o15, o16)● At time T=34, the server broadcasts

■ OIR = { (o7, 26), (o8, 32), (o12, 30), (o16, 28) }■ GIR = { (G1, 24), (G2, 22), (G3, 20), (G4, 12) }

● Suppose the mobile client disconnects at time 23 and reconnects at T=34, and the timestamp of the last valid report is at time 22

● Suppose the query is Q = {o1, o2, o6, o7, o9, o12, o14}■ From OIR, o7 and o12 are invalidated■ From GIR, G1 is invalidated, so o1 and o2 (members of G1) are also

invalidated34(T)

[T- L,T]

[T-WL,T] OIR

GIR

2610Disconnectedat time= 23


“Selective” Dual-Report Strategiesfor Power Saving

● Selective Dual-Report is designed to minimize the tuning time● GIR is broadcast before OIR in the form of (group-id, time-stamp, ptr),

where “ptr” is a pointer to point to the starting position of the objects within this group in OIR

● For each group queried, the client first selectively tunes to the GIR● The timestamp of the last valid report Tc is compared against the

timestamp of the group Tid, if Tc < Tid, all objects in that group are invalidated

● For the remaining objects in the query, the mobile client selectively tunes to the respective position in the OIR

● The pair (oid,tid) of the queried object is retrieved and the timestamp Tc is compared against tid, if Tc < tid, the object is invalidated; otherwise the cached object is valid

(G2,22,Ptr)(G1,24,NUL) (o12, 30)

GIR OIR

Tc=22, so G1 is invalidated; G2 is not invalidated but after following the pointers, o7 and o8 within G2 are invalidated

(o7, 26) (o8, 32)(G3,20,Ptr)


Transaction Processing: Background

● A transaction consists of a sequence of read/write operations followed by a commit operation, e.g., a mobile e-commerce transaction

● The (generally accepted) transactional semantics requires that ■ All operations in a transaction be executed “atomically”

○ Meaning all operations are executed as if they are one indivisible operation

■ Results generated by concurrent transactions be “serializable”○ Meaning the result of concurrent transactions would be the

same as that generated from executing concurrent transactions one at a time in some serial order

● In the following example, T1 and T2 will both be allowed to commit as T1 and T2 both read the same x value and T1 commits before T2

■ T1: Read(x) ……… commit■ T2: …….Read(x) ……... Write(x) …… commit■ The serialization order is T1 followed by T2, i.e., T1;T2


Transaction Processing: Background (2)

● In the following example, T1 and T2 both read the same x value but T2 changes the value of x and commits (at the server) before T1 commits:

■ T1: Read(x) …………………................……… commit■ T2: …….Read(x) ….. Write(x) …… commit

● Should we abort or commit T1?■ When the commit time must follow chronological time order

○ The only action can be taken is to abort T1 when we process T1’s commit because if we allow T1 to commit after T2 commits, that is, T2; T1, then T1 should read the new x value updated by T2 to satisfy the serializability requirement

■ When the commit time does not have to follow chronological time order

○ One possibility is to commit T1 but make T1’s commit time before T2’s commit time, i.e., the serialization order is T1; T2 to satisfy the “serializability” requirement


Read-Only Transaction Processing in Data Broadcast Environments

● Architecture for supporting read-only transactions

■ All updates are performed at the server who broadcasts data items in the database periodically

○ A transaction may read data items over several broadcast cycles

■ Versioning: Data items are broadcast along with their time-stamps or versions

■ Invalidation: Optionally an invalidation report (IR) can also be broadcast by the server at the beginning of each broadcast cycle

○ The invalidation report lists data items that have been updated since the last invalidation report was broadcasted

● Correctness requirement is serializability: The set of data item values that have been read by a transaction must form a consistent state

Updates areperformed atthe server

Invalidation reportsand data itemsare broadcastperiodically

Bcycle

IR+ Data IR+ Data

Bcycle


Versioning Method

● With versioning, a version number is broadcast along with the value of each data item

● The version number corresponds to the broadcast cycle at the beginning of which the item had the value

● Let Vo be the broadcast cycle at which the transaction performs its first read.

● For each subsequent read (of another item), if the item read has version number larger than Vo then the transaction is aborted.

A transaction in the Versioning method reads values that correspond to the database state at the beginning of the broadcast cycle at which the transaction performs its first read


Invalidation Report Method

● With the invalidation report method, an invalidation report is broadcast at the beginning of each broadcast cycle

■ Listing data items that have been updated since the previous invalidation report was broadcast

● At the client end, a read set (RS) is maintained for each transaction to include all data items read so far

■ A read-only transaction is aborted if an item in RS that has been read is invalidated in the invalidation report

Read x Read yTime

A transaction in the Invalidation Report method reads values that correspond to the database state at the beginning of the broadcast cycle at which the transaction commits

If y is invalidated then abort


Multiversion Data Broadcast

● With multiversioning, the server maintains and broadcasts multiple versions for each data item

■ Versions correspond to different data item values at the beginning of each broadcast cycle

■ Version numbers correspond to the broadcast cycle numbers

■ Let Vo be the broadcast cycle at which the transaction performs its first read at which it reads the largest version of the data item

■ In subsequent cycles, for each item the transaction must read the version with the largest version number Vc smaller than or equal to Vo

○ If such a version exists in the multiversion broadcast data, the transaction proceeds; otherwise, it is aborted.


Multiversion + Invalidation Report

● With multiversioning + invalidation report, the server broadcasts multiple versions of each data item in each broadcast cycle along with an invalidation report at the beginning of each broadcast cycle

■ Let Vi be the broadcast cycle at which the transaction is invalidated for the first time, i.e., a value that the transaction has read is updated

■ After Vi, the transaction attempts to read the version with the largest version number Vc such that Vc is smaller than Vi

○ If such a version exists in the multiversion broadcast data, the transaction proceeds; otherwise, it is aborted.

A transaction in the multiversion + Invalidation Report method reads values that correspond to the database state at the beginning of the broadcast cycle of its first invalidation Vi


Read/Write Transaction Processing in Data Broadcast Environments

● Consider a mobile transaction running on a handheld can also possibly update items which it has read

● Invalidation report based: if a data item read or written by the mobile transaction is subsequently invalidated in an invalidation report, then abort the transaction

● Timestamp ordering based: adjusting the serialization order of update transactions such that the “commit time” of a mobile update transaction is moved up to a time point prior to the current time if doing so will not violate the transactional semantics

■ Partial validation performed at the client side■ Final validation performed at the server side


Timestamp Ordering for Transaction Processing in Broadcast Environments

● Each transaction maintains a timestamp interval TI with an upper bound TIub and a lower bound TIlb

■ Initialliy TIlb =0 and TIub = , i.e., [0, )● On processing a read operation on a data item x at the mobile

client, TIlb is adjusted to the commit time of the last committed transaction who updated x

● On processing a write operation on a data item x at the mobile client, TIlb is adjusted to the commit time of the last committed transaction who read x

● On learning write-by-committed-transaction (x) from broadcast on a data item x previously read, TIub is adjusted to the commit time of the last committed transaction who updated x

● On learning read-by-committed-transaction (x) from broadcast on a data item x previously written, TIlb is adjusted to the commit time of the last committed transaction who read x


Timestamp Ordering for Transaction Processing in Broadcast Environments (2)● A mobile transaction will be aborted when:

■ It receives write-by-committed-transaction (x) from broadcast on a data item x it has previously written, or

■ Its timestamp interval TI shuts out

● In these cases, serializability through time-stamp ordering is not possible

ORTI shut-out cases:


Timestamp Ordering for Transaction Processing: Example 1

● Revisiting the following example: T1 and T2 both read the same x value but T2 changes the value of x and commits (at the server) before T1 commits:

■ T1: Read(x) …………………................…………… c1■ T2: …….Read(x) ….. Write(x) …… c2

● Consider T1 the mobile read-only transaction and T2 the server-side update transaction

IR broadcast time instant at whichx is invalidated in the IRand T2 is the last transactionwho updated x

Serialization order: T1; T2

bCycle

TI of T2:



● Example 2: Consider T3 is the mobile transaction and T1, T2 are server-side transactions

Serialization order: T1; T3; T2

T2

T3

T1

r3(x)

r1(x)

w2(x)

c1

r2(x)

w1(x)

c3

c2

TI of T2:

IR broadcast time at whichx is invalidated in the IRand T2 is the last transactionwho updated x



● Example 3: Consider T3 is the mobile transaction and T1, T2 are server-side transactions

TI of T3 shuts out and no serialization is possible: T3 is aborted.

T2

T3

T1

r3(x)

r1(x)

w2(x)

c1

r2(x)

w1(x)

c3

c2

w3(x)

TI of T3:

due to w3(x)


Example: Server-Side VS C++ Code for On-Demand Data Services

// On-demand data services through XML Web services as in L4[SoapRpcService]public class StockQuoter:System.Web.Services.WebService{

…. [WebMethod]public double getQuote(string symbol){ if (symbol.Length!=4 || (symbol[0]!='C' && symbol[0]!='c') )

return -1; try {

int id = System.Int32.Parse(symbol.Substring(1,3));return (id % 80)*(1 + new System.Random().Next(-10,10)/100.0);

} catch (Exception) { return -1; }

} }


Example: Client-Side eVC++ Code for On-Demand Data Services

● A user runs a loop of sending queries to the web service and receiving responses for 5 seconds using PocketSOAP as in lab 4, in a routine called “query_thread”

● Part of the code in “query_thread” looks as follows:DWORD start = GetTickCount();

while (GetTickCount() - start < 5000){

t1 = GetTickCount();

SendRequest(); // through SOAP

GetResponse(); // through SOAP

total_time += GetTickCount() - t1; // total_time holds the sum of RT

TotalRequests ++; // TotalRequests holds the number of queries

}

average[thread_index] = total_time/TotalRequests; // Avg. Response time


Example: Client-Side eVC++ Code for On-Demand Data Services (2)

● To test the scalability, multi-threading has been used to simulate multiple users requesting data simultaneously with the objective of measuring response timefor (i = 0; i<N; i++)

CreateThread(query_thread); // Simulate a user by a concurrent thread

Sleep(10000); // Wait until all threads end

// Calculate the “grand” average response time

// Here average[i] holds the average response time from user i

for ( i = 0; i<N; i++) sumResponseTime += average[i];

CListBox * resList = (CListBox *)GetDlgItem(ListBox_Label) ;

sprintf(buf,"%d\t%f",n,sumResponseTime/N);

// display in a ListBox the average response time per user per request

resList->InsertString(0, CString(buf));


Example: Server-Side VS C++ Code for Broadcast-Based Data Services

● Broadcast-based data services through UDPstruct sockaddr_in broadcast_addr;…SOCKET sock = socket(AF_INET,SOCK_DGRAM,IPPROTO_UDP); // Create a UDP Socket // set broadcast option

BOOL fBroadcast = TRUE; setsockopt ( sock, SOL_SOCKET, SO_BROADCAST, &fBroadcast, sizeof ( BOOL ));broadcast_addr.sin_addr.s_addr = htonl ( INADDR_BROADCAST ); // 255.255.255.255…broadcast_addr.sin_port = htons(PORT); // PORT=8888

// prepare a packet containing 100 data items and broadcast it outint index = 0; char buf[80]; char packet[1024]; while (TRUE){

strcpy(packet, "");for (int i = 0; i<100; i++) { // put 100 data items into each packet in order sprintf( buf, "C%03d\t%2.1f|",index, (index % 80) *(1 + (rand() % 20 -10)/100.0)); strcat(packet, buf); index = ++index % 1000; }sendto(sock,packet, (int)strlen(packet),0,&broadcast_addr, sizeof (broadcast_addr));sleep(100); } // sleep time is based on the specification so as not to flood the channel

closesocket(sock);


Example: Client-Side eVC++ Code for Broadcast-Based Data Services

while(GetTickCount()-starter < 5000){ // Simulate N users to access data round by round for 5 seconds

for (int i = 0;i<N;i++) { // simulate N queries for N users in each round

s[i]= GetTickCount();sprintf(symbols[i],"C%03d", rand() % 1000);

}

// Code to answer query from listening to broadcast data // and calculate the response time per user in this round }


Example: Client-Side eVC++ Code for Broadcast-Based Data Services (2) // In each round

ntemp = N; sumResponseTimeOneRound = 0;while ((bytes = recvfrom(sock,buf,sizeof(buf),0,

(sockaddr *)&peer_addr,&addr_len)) > 0) { buf[bytes] = '\0';

for (int i = 0;i<N;i++) // index i stands for user iif(symbols[i][0]!=0 && strstr(buf,symbols[i]) !=NULL) // found

{ sumResponseTimeOneRound += GetTickCount() - s[i] ; symbols[i][0]='\0'; if (--ntemp==0) break; }if (ntemp==0) { // all user requests are satisfied

sumResponseTime += sumResponseTimeOneRound;numberOfRounds++;break; // from the while loop

} … sprintf(buf,“Average response time (when N=%d) = %f",N,(float)sumResponseTime/(numberOfRounds*N));

Lecture 13 Mobile Data Services in Wireless Environments Wireless and Mobile Systems Design.

Documents

Transcript of Lecture 13 Mobile Data Services in Wireless Environments Wireless and Mobile Systems Design.