1 / 39

Lecture 13 Mobile Data Services in Wireless Environments

Wireless and Mobile Systems Design. Lecture 13 Mobile Data Services in Wireless Environments. 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

wentworth
Download Presentation

Lecture 13 Mobile Data Services in Wireless Environments

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Wireless and Mobile Systems Design Lecture 13Mobile Data Services inWireless 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 Mobile Data Services in Wireless Environments 2

  3. 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. Mobile Data Services in Wireless Environments 3

  4. 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++ Mobile Data Services in Wireless Environments 4

  5. 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 Mobile Data Services in Wireless Environments 5

  6. 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 Mobile Data Services in Wireless Environments 6

  7. 1 1 1 1 1 1 2 2 2 2 2 2 3 3 3 3 3 3 4 4 4 4 4 4 5 5 6 6 7 7 8 8 9 9 10 10 5 5 6 6 7 7 8 8 9 9 10 10 Server Broadcast Program hot cold • 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 access probability ratio of hot to cold is 3:1 Disk 1 Disk 2 Chunk 1 Chunk 2a Chunk 2b Chunk 2c minor cycle 1 2a 1 2b 1 2c Broadcast cycle Mobile Data Services in Wireless Environments 7

  8. 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 Access probability ratio of hot to cold is 3:1 hot cold 1 2 3 4 5 6 7 8 9 10 1 2 3 4 5 6 7 8 9 10 Broadcast cycle vs. minor cycle 1 2 3 4 5 6 1 2 3 4 7 8 1 2 3 4 9 10 Broadcast cycle Mobile Data Services in Wireless Environments 8

  9. I a2 a1 a3 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 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 Mobile Data Services in Wireless Environments 9

  10. Indexing in Air: Another Example I Index tree is built based on Huffman code with a specified fanout The index tree on the right has a fanout of 3 a1 0.2 0.4 0.4 R1 R2 a2 a3 0.09 0.06 0.05 R3 number of index probes = 1 for R1, R2 number of index probes = 2 for R3 number of index probes = 3 for R4 – R9 R7 .02 R8 .02 R9 .02 R4 .05 R5 .02 R6 .02 An index tree with fanout d=3 I R1 R2 a1 R3 a2 R4 R5 R6 a3 R7 R8 R9 A corresponding data broadcast sequence Mobile Data Services in Wireless Environments 10

  11. Algorithm CF for Constructing a Huffman Index Tree with Constant Fanout d • 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 I a1 0.2 0.4 0.4 R1 R2 a2 0.08 R3 .05 R4 .05 R5 .02 R6 .02 R7 .02 R8 .02 R9 .02 An index tree with d=4 Mobile Data Services in Wireless Environments 11

  12. 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: I a1 0.2 0.4 0.4 R1 R2 a2 0.08 R3 .05 R4 .05 R5 .02 R6 .02 R7 .02 R8 .02 R9 .02 An index tree with d=4 Mobile Data Services in Wireless Environments 12

  13. Performance Metric: Number of Index Probes vs. Index Probing Cost • 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 fanout of aj Mobile Data Services in Wireless Environments 13

  14. Index Probing Cost I a1 0.2 0.4 0.4 R1 R2 a2 0.08 R3 .05 R4 .05 R5 .02 Check it yourself: For the index tree with d=3, the index probing cost is 4.05 R6 .02 R7 .02 R8 .02 R9 .02 An index tree with d=4 Mobile Data Services in Wireless Environments 14

  15. r Algorithm VF for Constructing an Index Tree with Variable Fan-outs • Use index probing cost as performance metric • NP complete problem • Use greedy heuristics r hx … … Ri R1 R2 Rm … R1 R2 Initially, all nodes are sorted in descending order In access probability Ri+1 Ri+2 Rm Split at the node at which the cost gained is maximized Mobile Data Services in Wireless Environments 15

  16. 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 Mobile Data Services in Wireless Environments 16

  17. 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 Mobile Data Services in Wireless Environments 17

  18. 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- wL,T] • GIR is used to invalidate the remaining objects whose group has been updated during [T-WL,T], W > 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- wL,T] OIR [T-WL,T] GIR Mobile Data Services in Wireless Environments 18

  19. Dual-Report Strategies: Example • Example: T = 34, L =4, w = 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 invalidated Disconnected at time= 23 34(T) 10 26 [T- wL,T] OIR [T-WL,T] GIR Mobile Data Services in Wireless Environments 19

  20. “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 GIR OIR (G1,24,NUL) (G2,22,Ptr) (G3,20,Ptr) (o7, 26) (o8, 32) (o12, 30) Tc=22, so G1 is invalidated; G2 is not invalidated but after following the pointers, o7 and o8 within G2 are invalidated Mobile Data Services in Wireless Environments 20

  21. 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 Mobile Data Services in Wireless Environments 21

  22. 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 Mobile Data Services in Wireless Environments 22

  23. Read-Only Transaction Processing in Data Broadcast Environments Bcycle Bcycle • 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 consistentstate IR+ Data IR+ Data Invalidation reports and data items are broadcast periodically Updates are performed at the server Mobile Data Services in Wireless Environments 23

  24. 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 Mobile Data Services in Wireless Environments 24

  25. 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 y If y is invalidated then abort Time 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 Mobile Data Services in Wireless Environments 25

  26. 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. Mobile Data Services in Wireless Environments 26

  27. 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 Mobile Data Services in Wireless Environments 27

  28. 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 Mobile Data Services in Wireless Environments 28

  29. 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 Mobile Data Services in Wireless Environments 29

  30. 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 OR TI shut-out cases: Mobile Data Services in Wireless Environments 30

  31. 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 bCycle TI of T2: IR broadcast time instant at which x is invalidated in the IR and T2 is the last transaction who updated x Serialization order: T1; T2 Mobile Data Services in Wireless Environments 31

  32. c1 r1(x) w1(x) T1 c2 w2(x) r2(x) T2 T3 r3(x) c3 Timestamp Ordering for Transaction Processing: Example 2 • Example 2: Consider T3 is the mobile transaction and T1, T2 are server-side transactions TI of T2: IR broadcast time at which x is invalidated in the IR and T2 is the last transaction who updated x Serialization order: T1; T3; T2 Mobile Data Services in Wireless Environments 32

  33. c1 r1(x) w1(x) T1 r2(x) c2 w2(x) T2 T3 r3(x) w3(x) c3 Timestamp Ordering for Transaction Processing: Example 3 • Example 3: Consider T3 is the mobile transaction and T1, T2 are server-side transactions TI of T3: due to w3(x) TI of T3 shuts out and no serialization is possible: T3 is aborted. Mobile Data Services in Wireless Environments 33

  34. 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; } } } Mobile Data Services in Wireless Environments 34

  35. 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 Mobile Data Services in Wireless Environments 35

  36. 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 time for (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)); Mobile Data Services in Wireless Environments 36

  37. Example: Server-Side VS C++ Code for Broadcast-Based Data Services • Broadcast-based data services through UDP struct 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 out int 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); Mobile Data Services in Wireless Environments 37

  38. 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 } Mobile Data Services in Wireless Environments 38

  39. 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 i if(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)); Mobile Data Services in Wireless Environments 39

More Related