<%BANNER%>

A Dynamic data/currency protocol for mobile database design and reconfiguration

University of Florida Institutional Repository
xml version 1.0 encoding UTF-8
REPORT xmlns http:www.fcla.edudlsmddaitss xmlns:xsi http:www.w3.org2001XMLSchema-instance xsi:schemaLocation http:www.fcla.edudlsmddaitssdaitssReport.xsd
INGEST IEID E20110109_AAAAWY INGEST_TIME 2011-01-09T14:58:31Z PACKAGE UFE0000619_00001
AGREEMENT_INFO ACCOUNT UF PROJECT UFDC
FILES
FILE SIZE 1813 DFID F20110109_AABLWJ ORIGIN DEPOSITOR PATH xia_y_Page_51.txt GLOBAL false PRESERVATION BIT MESSAGE_DIGEST ALGORITHM MD5
e50ee2e0739527440de161243cb280d9
SHA-1
d250a789362b94ab5ad48a33edcd9a20fdd3a81f
1053954 F20110109_AABLRM xia_y_Page_59.tif
dccafad9ad8a45a271be46b2be5083ce
b9a9d6fc0572a19cb9902f29cb4a13fb10b0b513
100623 F20110109_AABLMP xia_y_Page_74.jpg
3eeb13cdd93396c679e39be722f862a8
156cd3d668b9e0551eb659988330ed9e0780ecb8
1716 F20110109_AABLWK xia_y_Page_52.txt
255990ed355f9cb5abcf16ca752cb649
ab563ae4daf64d022fbe03aac66d790ff7f840fa
F20110109_AABLRN xia_y_Page_60.tif
2e73315aa6542d29028f9b8349e3301f
4abd4f396aa2cb613346946a3c89c900ed93e3a8
82548 F20110109_AABLMQ xia_y_Page_75.jpg
7a9bf8524243ba00a3bd3fda90e1a32a
df4c939937c7dada7d3daa4f007e3154a1947636
1679 F20110109_AABLWL xia_y_Page_53.txt
b15bb034b83a538113e75900dc1d7f8b
f1970287dbf5b1762c4c9d1e8b88d3398dff4a9e
2655 F20110109_AABLHT xia_y_Page_60thm.jpg
bb2955c573c774b30c9e2fc559bd98c7
431bfb40cc049f300bf7db69e290c306a02091cd
25271604 F20110109_AABLRO xia_y_Page_62.tif
1a558760edebf33c217047d7fc3190fd
61048cdc36cbebae34b5ec9359408cb6287e9884
1588 F20110109_AABLWM xia_y_Page_55.txt
dc0d1d936aab4cd4bbe173559f2a1bdd
9e97b84e9e020a659665a567e6d9c1801b303cf5
22015 F20110109_AABLHU xia_y_Page_66.QC.jpg
3dfa1786034b7988a7fbebf0d11e7390
5db1f4ec25f9025fe97aa655ce5af7a36b5b2487
F20110109_AABLRP xia_y_Page_63.tif
a4246d61e2b1e456bc17a0a813f67103
d10d655da19180259641326700c334a3f0669b14
36205 F20110109_AABLMR xia_y_Page_76.jpg
77e8802bc462b752f349ac3ae876d69f
b89230c9bfdb5ebf35b0ce68d5b986f811a27b38
1403 F20110109_AABLWN xia_y_Page_57.txt
5ee553c644582bb6908e9d9033651f58
7a7f3248457e8ea8ac09235fa3e221e3bd9ab05c
5237 F20110109_AABLHV xia_y_Page_63thm.jpg
cb0fdc25b82fe854b42b1178f783cdc2
748b1077b7b0f41d45ac0e7af44988737a06400e
F20110109_AABLRQ xia_y_Page_64.tif
fe3a02240dbd3ea20f361d988377e9c7
83c3661549328d41d41955368dc2ee6fc810485d
23545 F20110109_AABLMS xia_y_Page_01.jp2
6284307b8b9fce0f4f464273331660e6
03388bc06a30b5b9620979dc64b449bd8f12193b
1238 F20110109_AABLWO xia_y_Page_58.txt
5d64b61d5344137e8850918e00b5f5ea
8596982cd591b2e5a62b74024f945c9225baec02
816 F20110109_AABLHW xia_y_Page_76.txt
7649d91945ed784de059239fc1fe6e54
25f95d0dcbc436129b4b32aa3d421b591284f8d7
F20110109_AABLRR xia_y_Page_65.tif
3ef1b603bed40d8ad05ef017a1fbd929
845d8fd0bdfb3d330ec857508d8dc2e1b1ad54fa
5343 F20110109_AABLMT xia_y_Page_02.jp2
925cf6ba634d702228e913d542e4581d
73079db2ed27a347727702b6e5a65693625dddc7
1598 F20110109_AABLWP xia_y_Page_59.txt
628b04872edb507acfa4c4f548d11d0f
f7846a3bd58b7068312102ab4f117cd256655bd9
5997 F20110109_AABLHX xia_y_Page_11thm.jpg
e1aace91cb0f9658f2c7203df695f9b9
e40da45e7ee933c6689d0c755670f1365b750c69
F20110109_AABLRS xia_y_Page_66.tif
dc8d2a45644885ba4a5421a63e997af3
445c4fa1b5bef2721d2eee385805af1cc3be8f9f
1051981 F20110109_AABLMU xia_y_Page_04.jp2
90f9b550cb7ec81aaeaeba447b2a80f7
906e40e635c08a341c33133c9da23de01ac5b7cb
730 F20110109_AABLWQ xia_y_Page_60.txt
b7a51d1782599203035e891621bece49
af09d978495c52244c602a0f6ab0a281951e62b9
22633 F20110109_AABLHY xia_y_Page_59.QC.jpg
2d048dde1f5d0051e0d062ee7c039dba
1ca05ffb42d0a4141e00d00926ba6d8b45d27364
F20110109_AABLRT xia_y_Page_67.tif
70a3c54ceffcd2bf7f2134999254e618
614ca9d3f9b0369e818d906701c8a07e8e0277cd
1051966 F20110109_AABLMV xia_y_Page_05.jp2
f2e6a1408d89dd0886506e60fb5c5d6f
582b5113d7999934dc864d5500ee552f3ff9b29a
1621 F20110109_AABLWR xia_y_Page_61.txt
176d3275d1070d97a89a85c76267578d
669444b9be36c81d3a477a167236fd8240d9131e
41917 F20110109_AABLHZ xia_y_Page_45.pro
299f478976476f2dd252ec219ab36f72
836b502a2a12defd3d8570535d36fc9f26ecba29
F20110109_AABLRU xia_y_Page_68.tif
d47e7c8eeba69cd207bc9a0ef8219782
fd8ada0c37a0f34554f66be89e3831fdcfa80ea6
78092 F20110109_AABLMW xia_y_Page_06.jp2
38145ca2e57bf23a1bb046158ea6fbe5
38705ef086c7c3ed6cd24129c78ad02b872e8735
1192 F20110109_AABLWS xia_y_Page_62.txt
8edcb4c0ad3aba85e6cc40aaa78deebe
64cfc0bec30ac2f3a075e24493256a03d8ec0381
F20110109_AABLRV xia_y_Page_69.tif
27ca52d8a6ddb257ccdec51f7efb8bfe
f2c89c7dc870b618b8da696ec1971fc8ef3f4d9f
59772 F20110109_AABLMX xia_y_Page_07.jp2
6e4ebfbc67f51875fe240e8043d333ce
71f98e9b92c354bd71b31b06b0dcaed183e84980
1696 F20110109_AABLWT xia_y_Page_63.txt
34457478dccd89ee212d593f97e9bc42
efbd82edee46c3a0aed812f25d6d4ad009ae177f
33016 F20110109_AABLKA xia_y_Page_03.jpg
45f4b3c32efe65447762d731ee1dadd1
4841f1577b333519a615f9f0dafc707c542f44d6
94667 F20110109_AABLMY xia_y_Page_08.jp2
195a7977603159225fe6baac1728aab2
42254e8138aef3f2c3d10aac7a0fa9b1944308b5
2010 F20110109_AABLWU xia_y_Page_64.txt
4c87661a5f1ac6e4b4ccec545d6d2d81
e2437d0933659a0fea77a7bc3959c79baa9883bf
F20110109_AABLRW xia_y_Page_70.tif
26b9b2ca83042ede5ead5abf9e6438a7
111c50a54a3387e1a86315c24faa0abccb908151
75336 F20110109_AABLKB xia_y_Page_04.jpg
be06c675b90501f77f7a3643c0d93954
ac509173109047b59c605719f66c70bde66c99af
105520 F20110109_AABLMZ xia_y_Page_09.jp2
165ab822a255f7349f16c3480cba6df4
410ce2b21abe5aeda7e1f83a49ed811d953148b5
2443 F20110109_AABLWV xia_y_Page_65.txt
4c1df9d3006d6653dccd9c9c133d25a7
0e652c42b79c2b7d4a1e05ef98885446417f309d
F20110109_AABLRX xia_y_Page_71.tif
3e972e9d1ad1583db6a7412d02ed8a0e
700629021a9a5701e5073998144d91d35bb809b4
76124 F20110109_AABLKC xia_y_Page_05.jpg
99f1fbecea451de469759dda944b856a
3a072a82aa82c7acfcf3056880e5cb2608f35818
1702 F20110109_AABLWW xia_y_Page_67.txt
b1b1cda4f89d5fd42b9153061a47a969
e0d4567ef1386cb994e4eae69325b42cd4173a68
758126 F20110109_AABLPA xia_y_Page_68.jp2
e0028beb9d20feb12cca78c30e914b40
7ff24c27ba3337d49e6676846c2a1691fabd5572
F20110109_AABLRY xia_y_Page_72.tif
2b494f847503a6856719af38f735e02d
e76d82e85dcde97cc2f795e2b6076b89376d717f
46693 F20110109_AABLKD xia_y_Page_07.jpg
6cede3d94714c263c010a55d1fbc2656
5bf6c1bc77b4b9928f732349431aa804afb140b9
F20110109_AABLWX xia_y_Page_68.txt
1cb9f2d729818caa7b6510bf06535201
dc2bcba866d465b81ca4feee079c8fd31bc06d49
676674 F20110109_AABLPB xia_y_Page_69.jp2
821549101bfc8560ec290f3a2722c554
4b7360646cf22d660f3a7d76d4828d773e956527
F20110109_AABLRZ xia_y_Page_73.tif
ac87ced287f67eecd750f4cfc667af5e
f18ab6611606ea6d18befcf90f4caf17bf6b4bb0
73828 F20110109_AABLKE xia_y_Page_08.jpg
4d18fb627abc71016fe744c78b0b291f
630bea007b6cdb1c3017bcb722c5faa133611b2b
36178 F20110109_AABLPC xia_y_Page_70.jp2
788dfdc39edae614a6a14fadd66ee826
6f7a57665e78e9cb69921b17c2287bac4c411b1a
79686 F20110109_AABLKF xia_y_Page_09.jpg
26de374a1dbc4251b4b34f256ba4f028
bbffc52efd9bbd56188808a7c96ac8ce8ca983e5
1591 F20110109_AABLWY xia_y_Page_69.txt
3977e7a179ae6eb02763c48352919b4c
d0503e6108fc0b034e68d46b211d3bd2b7d75bb4
112727 F20110109_AABLPD xia_y_Page_71.jp2
e836c0ccedb97b08cb632bd735641481
8ffb82a5504de79994629e515abf7a732d2da19f
87731 F20110109_AABLKG xia_y_Page_10.jpg
dde438a099e05eb0f15571288cd3e740
8cc1ee00ff80cbca2fc8f3d7d80a304773c8e0cf
29967 F20110109_AABLUA xia_y_Page_57.pro
8333fc1f0e7fe73ff041e09e1b83ff52
e0caed24e684302dfdb63ee63a88eb06fea6c8c7
640 F20110109_AABLWZ xia_y_Page_70.txt
d7ce70ad7cd50b3289e7c542e1b9b389
31d7ca5c75c7b63e0db6c2623acfbef4dbe4de2b
32745 F20110109_AABLPE xia_y_Page_72.jp2
6d06b27ecb5e30a42750734c74f8a156
7e28a9f36bd67095c66b988c80f66b87fe100fa0
75521 F20110109_AABLKH xia_y_Page_11.jpg
34023ffb4c8536fada3ab2e2e8773789
04021fea5d59ecbd3e449855bc69225c46455ce3
29719 F20110109_AABLUB xia_y_Page_58.pro
6a8d0f7da3b4a076d9f0b199839cfa4d
9fd61e9bf7e7ca2aafc4d80491bfb422715dd712
3740 F20110109_AABMBA xia_y_Page_26thm.jpg
2d2afdb1edff3b2271525feb1acdb8fa
1b7ae52186bd1990c744db999ad395dd6249d58d
111912 F20110109_AABLPF xia_y_Page_73.jp2
7a66bfb2a5f50fab6aae91041cd1446b
ea48f2037b591cefbe1e58587fd16798081daf46
56449 F20110109_AABLKI xia_y_Page_12.jpg
3f77d822118601324f8087cc2c98d983
c32aa7ddf3d3f9c1d1cfbdedee22d1717b32c11b
38362 F20110109_AABLUC xia_y_Page_59.pro
067261b1bd5ba6daed25c84fbf609dd4
29e5b165abc8e5aa054b5a3b836b24c2626ca4bb
4642 F20110109_AABMBB xia_y_Page_27thm.jpg
e722b7031bf1fedc939e309bc3d5dce9
4cfd6fdcefb25ff18f9052c91f43d4c61b5f5202
2799 F20110109_AABLZA xia_y_Page_50.QC.jpg
0673546481774a5164d18f64c4c2c3e0
62c9bdc6d98b88246317a76edca8bd9b1f23d414
131575 F20110109_AABLPG xia_y_Page_74.jp2
1378f1dc74c086a3ba304df403787afe
3084aaa47e078a378e1b3dd1cdb1dc416020ffe4
77342 F20110109_AABLKJ xia_y_Page_13.jpg
16d8c64d92ec532565ffa9997259c94e
2e7bbfb247734055d3afa09a30140d96e1bb870b
18129 F20110109_AABLUD xia_y_Page_60.pro
f6306c81c5d5ad221d873a96469a5e20
f8439df2abc5dcff8629b9541f623dc1cdb1dbcf
15864 F20110109_AABMBC xia_y_Page_28.QC.jpg
96e59e475fda33e7128b6dc609f0273e
d06e545d6ee7ab66017af09bcf56edf133161bfb
9923 F20110109_AABLZB xia_y_Page_60.QC.jpg
dd2a1798daf8c8e6cc85b4129b20f001
054f694e042e37f8c3d9f92655c0145748d701d2
107802 F20110109_AABLPH xia_y_Page_75.jp2
b9dbe5d6df423ac0bd85f3e30b1e8d44
bfeb6f217d391da38353121028e4c8ffe37c1f11
82945 F20110109_AABLKK xia_y_Page_14.jpg
17f2e80878982255fac3277f09f21c36
8e96615cedf294a3691963d95591e77b0ae69e14
37734 F20110109_AABLUE xia_y_Page_61.pro
4c80bc6194288768099fff9cb9d4d0f9
9a11391521bbcf157bc2e5ac1102ed208cf2247a
4347 F20110109_AABMBD xia_y_Page_28thm.jpg
f3ef0a2596aad59fca892c4583cf0e35
8a97c2cb73becee5e6075ebd9b956cdeeb902e79
18118 F20110109_AABLZC xia_y_Page_57.QC.jpg
57d68e1e3329838a341c97de31748ad7
3a820c228ef45e78bf87eb0104569fdb04305a47
46456 F20110109_AABLPI xia_y_Page_76.jp2
40b8c168972d0b69aa12443cdc7c7de8
7afea5533e9ebea7386d53908643f2c20d0202d9
45345 F20110109_AABLKL xia_y_Page_15.jpg
2ff8187c167b3627b8a0513efb4a7b42
8909438f6e319a5616810813c43cf06bfcc9f5ba
28304 F20110109_AABLUF xia_y_Page_62.pro
336137bc7b9ccf8475a5093568818fab
d35999ada0e4e2eb5fe3950d66be10f3bb3d3eef
5617 F20110109_AABMBE xia_y_Page_29thm.jpg
b6bd99add430d419f14753ef150c8b6f
e198ef2c1ceb349fad60e14d0c17d9c3c0691a93
22266 F20110109_AABLZD xia_y_Page_29.QC.jpg
29a020c38ad17a1083c78f1c90ae469c
d2f2ff26dcf2bf313a1d30b845bb29b84701c249
F20110109_AABLPJ xia_y_Page_01.tif
01bc362fa0543a745dcdf2b5df0a0eec
49b28edeef91b0eb4602e5c26991651ba7b9d884
62678 F20110109_AABLKM xia_y_Page_16.jpg
fc4f478776763b6518cd662127c15bdf
61a5ad83ed6b5b6544809c945375fe98a9587f22
39025 F20110109_AABLUG xia_y_Page_63.pro
39df3359532b5d7a800b27cae5d5ce26
d6c60028154f72d87c98d8d7b94981f34fec6f6d
21929 F20110109_AABLZE xia_y_Page_52.QC.jpg
802e5eb5d7e6fc27c20ac3d1acf5710d
3a6e918e71026021345889edbbc271b5a8d13b85
F20110109_AABLPK xia_y_Page_02.tif
cbd517d7b5bb62d2d684e0b81e78847f
0791deb2e2c1c00f7ec7a60b003405ef66968e8a
49670 F20110109_AABLKN xia_y_Page_17.jpg
fa13f670553292aefb2a6dde9e34efb7
1e232deeefe5fe273af4b24f2368237592af31e7
40509 F20110109_AABLUH xia_y_Page_64.pro
4fba105ea2a6bed9a3f9edd1a92628ee
c22c3a93fde26db66f93634773954f04fbe7a120
25029 F20110109_AABMBF xia_y_Page_32.QC.jpg
de92160fa720140635cc32441f150e92
d3ca98f6e7fa23a545c074f2b8070121b93ef077
5668 F20110109_AABLZF xia_y_Page_08thm.jpg
79bb53b477ee20e4f268c3c8860e9996
eb2ec706dff331842331a96bcaa796a8ed1a15c9
69738 F20110109_AABLKO xia_y_Page_19.jpg
ba561d730069f2afc8ee16eb5571b72b
510a4e4b5e4d12eca9aefe717d08fa09b1674eaf
41514 F20110109_AABLUI xia_y_Page_66.pro
2d6a18a9cc166a79a47b0cf0d5294afd
a3f731c76a790b53666ce3a38d450f2209fcb0e2
F20110109_AABLPL xia_y_Page_03.tif
61cf3243345f721ac74b0b282229a331
694d59926480d82c3235979383ca45345de2a34e
20669 F20110109_AABMBG xia_y_Page_34.QC.jpg
2199c78581c2f1727229e7c081b04fbe
69f2e7868f3a2bba456a6680f3d5f5b3829bf990
12715 F20110109_AABLZG xia_y_Page_26.QC.jpg
b10311e34acd1418bc6ea9d90cd699ff
3a423b9e0208f0105767eb9b85ba2862e40ecac3
30235 F20110109_AABLUJ xia_y_Page_67.pro
5b0d295ff77cdf8e4a2582f6a646cde7
85e666a943b115da1a3ef7143ca18abd806091dd
F20110109_AABLPM xia_y_Page_04.tif
60b397c01c61b256ea6a55eaff9de192
710d8f8e3afce033df58d9e3323596a2dc9107e7
5347 F20110109_AABMBH xia_y_Page_34thm.jpg
4e6d44a9a34f7e9d4409161f287ccdb3
7ed3132d3d736d1078ee12f1dfcc1fb1eac698e7
5891 F20110109_AABLZH xia_y_Page_54thm.jpg
7d2fe37235b02cfc0bbfd5ac81938f72
58d8c0250447712072c6e1f0198793c644ef52be
87824 F20110109_AABLKP xia_y_Page_20.jpg
168e5e6a3c64a40a69abedf583dbf151
5dadff9287a788edf8d23db73b527391c764aae8
31500 F20110109_AABLUK xia_y_Page_68.pro
f935c6b469b3bbdf00f5e7b8e24e86d8
ea6ee7e3eab277b5bb5c036bfe798b0ef6b49ea1
F20110109_AABLPN xia_y_Page_05.tif
38296bc2c87948e52b6a28324897c61d
cb7ac9658f6047e17c6cd89a84a15a61dc315a8d
21149 F20110109_AABMBI xia_y_Page_36.QC.jpg
799fa281e4f67071909cc0a0f5f111cb
b1005ed1e13742743a7d706377944bf2e72a10b3
813 F20110109_AABLZI xia_y_Page_50thm.jpg
fb0382deb7805308096c1f9f0c219eac
02c0c40a639cbc6fbbae80e10d1abbbd7068bda8
7120 F20110109_AABLKQ xia_y_Page_21.jpg
27bd8cb4258f6411e2876db17877c953
fcd841c89f826d5780e3c338b5c2cd147dbf33b3
27402 F20110109_AABLUL xia_y_Page_69.pro
17bedf2bc144b7af86c7a09e42282159
109947ebfc804c108052964322b1825321714e5a
F20110109_AABLPO xia_y_Page_06.tif
3ea36a1d5ba560c0154a0d13572dd9c2
8148fc7cc7db90c7a2c2eed7f89a4d7613269117
22049 F20110109_AABMBJ xia_y_Page_37.QC.jpg
8f94f9e05e906c045ce58a54f9e1b0a3
4c1e3f7612c99ed5c51a9a7d5e2858be62fb0cb6
18183 F20110109_AABLZJ xia_y_Page_48.QC.jpg
797e4e469db0759494b9ba5e9b8b5a95
b21c60591563844505a79c597efac2a2753012c7
72607 F20110109_AABLKR xia_y_Page_22.jpg
2ff07e077a123ddfab560b3932b41495
c3e2706c99ffbf18f014420da9adb98d16854eda
14883 F20110109_AABLUM xia_y_Page_70.pro
597eb224caa0f838cf51352ad1feba41
af85716b4ed84f78f3c5d0e1bda08745222ed7fa
F20110109_AABLPP xia_y_Page_07.tif
cfdf835d050f771087b9698790866dc0
a95f3d5b846f0a7e70fb980086d650ea584e5049
21887 F20110109_AABMBK xia_y_Page_38.QC.jpg
31ae8e25b7be30ce8dbbaf358efe55f3
ae3aee17df59d5afb26dceaf41481f085e3249b1
2871 F20110109_AABLZK xia_y_Page_03thm.jpg
03278b1e3585295b0f1eeda557da36d3
eb70850b00f9fbdcd12a3b37772f9746bfcae579
80631 F20110109_AABLKS xia_y_Page_23.jpg
9167f0cdc129f02921cdaefe7b432e9c
89b28d407cd333076c63e5de05d0d8e536af8e5a
53425 F20110109_AABLUN xia_y_Page_71.pro
58d7b46b2081f2eb1be89cfba2bd8be7
17ad650d42baa2fb3f3417de3932ceffacebad0f
F20110109_AABLPQ xia_y_Page_08.tif
5882392d92765d3083ce1e39fb5e8f1f
484650e54d31a274d15f6819d4a970cbfc4c382d
5508 F20110109_AABMBL xia_y_Page_38thm.jpg
ba085da54c18e478e0f0d8452ede53dc
6032e38eae5f2a8e42e871ee49084a3abad60b95
23211 F20110109_AABLZL xia_y_Page_73.QC.jpg
40c47c83facdb68bf6b89fd9a4e913a7
7ef6275a8b684f39647a99eef38a24a2b945ea75
83356 F20110109_AABLKT xia_y_Page_24.jpg
cf3dcb9894dbef40180bcce90807d2ca
b8822b1a0dd24d08e74d2d71efdfbd77631f572a
49826 F20110109_AABLUO xia_y_Page_73.pro
e1e3685604762d0cb29f600944e49dcc
ee14b13fe69a7039c8fca498342693064204c438
F20110109_AABLPR xia_y_Page_09.tif
1c6eb96f248a4748cc128fb99ca7153a
15cc8efaf26de6c0bed73eea04af721a6c10ade4
24153 F20110109_AABMBM xia_y_Page_39.QC.jpg
7873850c20975027e88d937f10560cc7
503f78ee140768fb56eb19144d0919e170bbcc34
22499 F20110109_AABLZM xia_y_Page_42.QC.jpg
a3caaf02cd4ccf965b588ff0a7ebf26e
46f2e9bd7f3dab5df8a7c777eeaafe11318b7ae7
64892 F20110109_AABLKU xia_y_Page_25.jpg
998047ecf55dc55def2975249a83df90
6e7d126594c25829f22214d6ecefa2785036e277
58579 F20110109_AABLUP xia_y_Page_74.pro
358ca5b6fb8a2333e2c27d1946639b33
e00ba4815b46425650ca425a572a0ee219b3030e
F20110109_AABLPS xia_y_Page_11.tif
825a7ccb03bfbb41fd2ead4559dbc44b
4efdc39f48e0a3f186b38db0fc8d167b35c7751b
5974 F20110109_AABMBN xia_y_Page_39thm.jpg
7917e559b6ce683971926dbb1955183b
5c899e9f2a5be66a1af5259d8e4f989845074d24
6994 F20110109_AABLZN xia_y_Page_40.QC.jpg
2f2547dd2dc46bba4330f8bf5c4b0bf1
43233f466e6f2c5cd5a3d8457e5bae04b23658ea
41482 F20110109_AABLKV xia_y_Page_26.jpg
9b8f40d1305769e938dbfa3fe66ad1e6
decccea0bc7f58be0877e1e3148e75049fa29b7d
48092 F20110109_AABLUQ xia_y_Page_75.pro
54a875b16c1c1c1226694f28d3382e94
f7798400304c42ab5579210bace31e8784257f06
F20110109_AABLPT xia_y_Page_12.tif
b06f4a00bb7ad1b5ac0b3c35fc882e73
315ef0f955fe0b7eca64d076ad5912a07515c67c
5463 F20110109_AABMBO xia_y_Page_42thm.jpg
b53612cbf59d742f1170f504254d7d5b
d2af4f8547bdeb604b968f7542a45d2d14570e56
17318 F20110109_AABLZO xia_y_Page_27.QC.jpg
2a1d7d282e947400302dbcb5baf38696
c72e9727d07c252c0ef06efd1ef950f3982675d2
53202 F20110109_AABLKW xia_y_Page_27.jpg
0c31375030b09bf2bb2d86336410dff3
e5ff0257a27e803b2e0cfe35cfb034b2423d8875
19107 F20110109_AABLUR xia_y_Page_76.pro
fd51f838d18e71ed63969d3055cf8f6f
5e1093897794c6dc90ef672e9ef17c93b86b3a26
25675 F20110109_AABMBP xia_y_Page_43.QC.jpg
962b77f5b1f10b2739abfb49e5551e32
7c8587745b075f6a32955e52026ffc5894c39d1c
18126 F20110109_AABLZP xia_y_Page_05.QC.jpg
3f4c489177bad25621a89b6398f5926c
f505c149b964c0f2386304760b02da1cf7ca02dc
50812 F20110109_AABLKX xia_y_Page_28.jpg
fd818dc536f6d274f44f7bc87a71aaec
c40cd001d9672bf7e9e5b28205463d7989476f77
457 F20110109_AABLUS xia_y_Page_01.txt
8293b7e3c2d5e1f606ab3a9c8ea9c312
8a6c33b8a6e78820796225fc9e3f31586aae18b6
F20110109_AABLPU xia_y_Page_14.tif
352eae067a78514ed4bcdc0f6eb4b42e
38aaa1d4512957c4278cd93650de0384948e2ba2
6116 F20110109_AABMBQ xia_y_Page_43thm.jpg
cf07422643a365817a7eb83e21eef884
b5d4141bb6f916e15476c1700bccb27a09a55cdd
19427 F20110109_AABLZQ xia_y_Page_47.QC.jpg
5aae89bf8c4ae587652321d2e996fd25
f916bf1217ec474279a71888e584958ccab667cc
70123 F20110109_AABLKY xia_y_Page_29.jpg
f549679d3ac7f8987081b1d54b24a482
8a5670cc08fd064684d8c0f2ffd59cf2cdb1423c
97 F20110109_AABLUT xia_y_Page_02.txt
82823cef33cef0087ec905383a6f8307
e1c05a9f66f309489fa77464086e2e13ea1d9c7b
F20110109_AABLPV xia_y_Page_15.tif
b97b941bbc96e0490525ed5db330c8ed
7e14b2fbc7e923df29aef343516a91a620cd06b7
22413 F20110109_AABLIA xia_y_Page_44.QC.jpg
5c789dd53cd547708963ce0d3789bdd9
fc24e2582bd62444a1e6082891806ca5c3f7e38b
22286 F20110109_AABMBR xia_y_Page_45.QC.jpg
7538ad97b06fa15ec296df8d787434f2
3cce314d18977fadd789706286181d7960d923e7
6160 F20110109_AABLZR xia_y_Page_32thm.jpg
60673760df4d76bc5e4856aef278d6c9
bbd25e303d078aec329adc9939298cad03a53970
82052 F20110109_AABLKZ xia_y_Page_30.jpg
4235f710c7686ac2489c498c0c290b10
59ef1cd9704b961ca49340839c2947b7a3598b9c
751 F20110109_AABLUU xia_y_Page_03.txt
96cb096f3cc0dfe835ffb392a1169269
16dc5c7e7d50779f7a7ac36fde54288bb66988c4
F20110109_AABLPW xia_y_Page_16.tif
0cb08ad9fa12b2bee0f4f8039dbc451b
29b23ba25622da78a85d7b7eb9ab9ca270e97051
1575 F20110109_AABLIB xia_y_Page_33.txt
ad751c98f209a41128876bcf29cc4342
cb511af85677a62916201e37faecc7c2e52c5a3b
5614 F20110109_AABMBS xia_y_Page_45thm.jpg
0dab74d40b78e77c4802b9960634f589
e51db3ee33b06bd088a0d42222482b345270c495
5406 F20110109_AABLZS xia_y_Page_36thm.jpg
7a1f2cd5478ea78e957d6b78a0f88ae1
1f703ba8db82f14a65cdcac05b40ed44e5b68935
2840 F20110109_AABLUV xia_y_Page_04.txt
6e9a09bf58468ce82c6cefbd0da4be42
f1697ab0f3a9fccc2c74a715b7aa040ed940f2d1
F20110109_AABLPX xia_y_Page_17.tif
9637a263a9d83b2f02dfef3a58b3fdf0
1cb931babf3ba938ae57d69d004653dbce804ac3
46269 F20110109_AABLIC xia_y_Page_39.pro
a2fad1af30a8f22f0d1798bfe34d204d
3aceda3c3ecd1bac6982347673cbe4232cf13ad8
24804 F20110109_AABMBT xia_y_Page_46.QC.jpg
eed3374e825e70d8b1f60476e146bcdb
a5fd8a1a960c4398d6d64fcacdd3cf50a10a929d
4775 F20110109_AABLZT xia_y_Page_12thm.jpg
fc7272060b0d13d1dc7d783c9e7c1aa7
6cf85d014ceb85dea690855ec5b1a8f7d0f41c25
2691 F20110109_AABLUW xia_y_Page_05.txt
bc1213b50370647b98c2086970ca39e6
54b0167177b0ba043f52a1210315c6517bf058b3
113915 F20110109_AABLNA xia_y_Page_10.jp2
9f54c9382a88287da61f3418cab8d583
bf06d0b2bf5e2b4ad388257666c003e1bd6b1d69
F20110109_AABLPY xia_y_Page_18.tif
2bf2f10c0cf31e54e3ee9d796aacba00
32e2d73a55880ef5a3d67a63a144753774c4c1c4
38488 F20110109_AABLID xia_y_Page_33.pro
cc1be5c1d6ee9a60affad9df37edbc5e
efbe8371cd71b33eb56116ab72187db1356519c6
4869 F20110109_AABMBU xia_y_Page_47thm.jpg
be01328ccf63687533aa60e093880160
522c0dc18e85ae1e717dabe689daf4ff94397ad4
6841 F20110109_AABLZU xia_y_Page_20thm.jpg
5a9c1c2868d8903b20c9cf2b0c9217be
e719ec84f81feea297888ea472e44b366e707969
1529 F20110109_AABLUX xia_y_Page_06.txt
b71affdad141076952127d3349a11875
35c26f24486fecc06a7533b6b8879385e8018754
97060 F20110109_AABLNB xia_y_Page_11.jp2
e8b2f79345600f2ebb1813896ecb92f6
ab8c18028ccc40e5bb4d3f3f7184345acc8001f4
F20110109_AABLPZ xia_y_Page_19.tif
7a29029b11a5a4d5d3da4ff08cbe7081
3b4a91be0d63ba75de24ce8317742ace1735de4a
6762 F20110109_AABLIE xia_y_Page_10thm.jpg
0268544865287ac836303bbeca27e15c
cafa451ecfca97a2db75da8af45abce597d9d21d
24882 F20110109_AABMBV xia_y_Page_49.QC.jpg
8c070d518e7804114a2a5f0048e4d333
d4611ed23a1380726f3bc35c8a09e59071006f6c
24285 F20110109_AABLZV xia_y_Page_13.QC.jpg
8ffe73c9c01182ee7f380e9929c9a3bc
623aac48924d05367655eeebd2ecb70e1033ad88
1043 F20110109_AABLUY xia_y_Page_07.txt
d1de7258cae53442236c6e39498c0ee4
89a08a8ef2e44012eb56cf9c212d4703649d4d03
73569 F20110109_AABLNC xia_y_Page_12.jp2
e8145fbf619f6902a84e12d734551209
63b2dfc7ee2b6d11a9a8fd2826906ad3870585b7
1640 F20110109_AABLIF xia_y_Page_56.txt
3c56d0b5243ce0dfe706cdb1096fd8a8
8dd401b3aad30cd7bad4bb5e8f581ac6116ac209
23733 F20110109_AABMBW xia_y_Page_51.QC.jpg
ead28a6d16f111870dc512f685703893
a8a7154e0feb54d8418738cfa2d65bd1fba14b96
9044 F20110109_AABLZW xia_y_Page_70.QC.jpg
24520d2ea4b96a212473c9bbe40dd632
9c2a4a52792e7902707d46df7a2357e4a6a7fe1a
F20110109_AABLSA xia_y_Page_74.tif
48f0c65271a7d5c9feb679ac3eb3f7cf
4ff76a8f77581faae87d305382b1477c7d32afe0
100058 F20110109_AABLND xia_y_Page_13.jp2
3840b31311382da269f486d0a2a8c802
61dee6b5c7fa96598b10dbf0bd976c2afbf3e7fd
11254 F20110109_AABLIG xia_y_Page_76.QC.jpg
8d667afcfb4ec4f12c69b22f4e9a67ac
21e48ccb20288ef4f26040493a921ce5648ddf22
5779 F20110109_AABMBX xia_y_Page_51thm.jpg
7e657bbc62d67dec2abbbc4cd5873162
f8203c8f0121936d12b6fc24c9b2fec0274d392b
10197 F20110109_AABLZX xia_y_Page_03.QC.jpg
a4b0938e4c8d48845ef628a707d40e96
1ad30d9f8ae5e0cb73f1b1a51b4bee8a688a06e6
F20110109_AABLSB xia_y_Page_75.tif
414b1617c7e73ed08702b98946a1fdcd
264c844172fdd8318b8b038bae1a28aeec33b460
1776 F20110109_AABLUZ xia_y_Page_08.txt
02c664f4804099a11f6ce0e064f65ecd
bafe7b1a9b2acd1e387ec1ace9fa9fa477e3a49b
106538 F20110109_AABLNE xia_y_Page_14.jp2
139aa6457663f10d3a026bbccb9acaf9
f85eab883c26f17293581111e3626834e332b706
5020 F20110109_AABLIH xia_y_Page_25thm.jpg
24a150ea70c488c68301dc97198e0150
f6f9f5e3e0286f1967dcaea93961a19a040ba559
22264 F20110109_AABMBY xia_y_Page_53.QC.jpg
205db3f4c40a33853e04821f24447c8a
435d1cc3db7b5a889cce771e91ccf25089ccb474
24240 F20110109_AABLZY xia_y_Page_11.QC.jpg
0bd8beff981310e0194419c582f3f360
2204729c82dfd2e25e039082e76ced0337e7e701
F20110109_AABLSC xia_y_Page_76.tif
f73e86ec7d11791ad3c702a00caec31c
ac003e692ff18e828b9ae259a985261c1ed672c3
57002 F20110109_AABLNF xia_y_Page_15.jp2
f058b8cd79e394bfd53e131d2b89dbf2
b39030410cc299e232df18e3526a7aa9a4fd48d5
934 F20110109_AABLII xia_y_Page_17.txt
d654e3cfdbfbe05e37e9fadf4232d557
aca11d6e1299f781cf558d965166e1210ff6388b
21400 F20110109_AABMBZ xia_y_Page_56.QC.jpg
614e46fb10357b240e1f360c975910f9
919f606570acd39daf52acb9fb413c3e5ab8280e
25337 F20110109_AABLZZ xia_y_Page_09.QC.jpg
6c7a4350b219d2368519c17879daaff0
9b50d1f390fc63c41fe3aa5f5c8696d8555ce33e
7672 F20110109_AABLSD xia_y_Page_01.pro
13e1c0bdb0795f0c3a0a73caa8c8945c
dd2f3774fa9d725db3cf73be8f4312ddaf249ee5
79142 F20110109_AABLNG xia_y_Page_16.jp2
7ae2829e1c1c7b89ad7bba2d28fa4122
a182c942fe29eda0d672538b1c088b8ef6c019d1
2169 F20110109_AABLXA xia_y_Page_71.txt
4ca0f47095be1d62fcc4380c9c4ca739
9f549a7835c46988ee6029953e4e865bd8320ef1
1325 F20110109_AABLIJ xia_y_Page_12.txt
f11a4aa6e358db7dcbd8751cac3074e6
119bf18725753a927369bbc441c069f703a89e7c
1009 F20110109_AABLSE xia_y_Page_02.pro
b7088930f79295a1ab3667ec98bf8276
68cba0f6fa5ba8355cc2e3779637eb0b22b141d9
101397 F20110109_AABLNH xia_y_Page_18.jp2
101cb7a475973b66d51bef84cbe377ed
eb7d784da4405a3e16a9798e58ab515c929efd9f
598 F20110109_AABLXB xia_y_Page_72.txt
050907396bfd6fcb6fdbfed6fda16a38
c8fba61c7df6ef2e852de7cad331cec773a150bd
1968 F20110109_AABLIK xia_y_Page_37.txt
c3ba6414a0f597bd3c41c5b91a62a584
d42a17b189a6b95bffb8f744c55a44829ab3ed55
17209 F20110109_AABLSF xia_y_Page_03.pro
d31091cfc5a6a297216043535ce4ddac
6226c163312f02576289c65e64b20db0dbed61e8
81517 F20110109_AABLNI xia_y_Page_19.jp2
ab6eaf6080634d6ed8d464faa0003a2f
7862b567168350ff3b1bf13de15118de8c1cc65d
1998 F20110109_AABLXC xia_y_Page_73.txt
c131c2ba5d0c278de255c3411fb2a92c
167da6da39b975eebf63db72ae58d7ae53b28e5e
47671 F20110109_AABLIL xia_y_Page_23.pro
b58ef2a6a3c0eaa7ab5066929e697f1e
26903c87a08a395ea4dc18cdc7714aae08390674
67024 F20110109_AABLSG xia_y_Page_04.pro
e9bf7d056f4a66b003df1c6c9453a69e
270a971e9e1437941c9a7bc6d9e66a60511fa0da
112515 F20110109_AABLNJ xia_y_Page_20.jp2
3bf98ec88d5cffbcc98f8272db09b846
ff39a976ced4d58b3f8a909aa514b42a49991b9f
2333 F20110109_AABLXD xia_y_Page_74.txt
a169ebbc4ef7428278e47fb09c820b7c
1bdc04798e9d326d7265a2a2e3adcc8c02a090d0
1537 F20110109_AABLIM xia_y_Page_34.txt
24e14b59a8f31283279ac637e119d769
0ab49c580521f3fba0c3ec5b4fe9352f16b08066
9499 F20110109_AABLNK xia_y_Page_21.jp2
dc9e9ed248c7292a65ec4500b7f1ecea
3df354760885686add9e17fa89a439a173eabf41
1935 F20110109_AABLXE xia_y_Page_75.txt
3ec77aca2ba39ffa3c2a27abb2f3338d
1d8477ae48351bd75a8d8dc03249de51f3719fb2
65737 F20110109_AABLSH xia_y_Page_05.pro
911937d49d4920e418709db2d183543d
80dd372f908d085c83f01778ce253f8058552254
1665330 F20110109_AABLXF xia_y.pdf
896f0ed29e4d828b893dd87be6d53edb
e728f2e95feb12ab7e2ccb5cfe75b9cbc915089b
92403 F20110109_AABLNL xia_y_Page_22.jp2
b538c7d677dc8f7ef0d4d6433ecc5d9e
8bcffc069e155a4c77b8bd5e370f60dd5bc21117
732736 F20110109_AABLIN xia_y_Page_67.jp2
4524b32ae3dd4c4a1761667c77e7b035
159355e89fb34c19fb85e18fac33de80c9c2da85
33482 F20110109_AABLSI xia_y_Page_06.pro
7d1210b913cf96e17156a86a59a7e109
a32ee92abface240aae76d613bdddaca84aecaa6
6003 F20110109_AABLXG xia_y_Page_31thm.jpg
d9e18666c54261289f5d44346da41def
3fbb7196d1ba3a0f239ba4274e330d862c303f91
103610 F20110109_AABLNM xia_y_Page_23.jp2
02b92c1a50e97c4311bcadac01b4480d
937baf2c8ff0f584b82a5646b7a700fbcb73eb23
6153 F20110109_AABLIO xia_y_Page_41thm.jpg
6fc772164c89beea58bb23bb6b29f871
f81dff1f87cd3143fabc92d46484f99c9c8917d1
25589 F20110109_AABLSJ xia_y_Page_07.pro
70c5ebabf9242f54499d4f84b4031f9e
5bc884356f3dbe019bc53c1a5aa4956e8c671915
20277 F20110109_AABLXH xia_y_Page_16.QC.jpg
e3677be4380e39d76ddeb2a9746f7f7e
06deb0a967dcbaa0a5bf72ce5db6e63f8a7310e5
108869 F20110109_AABLNN xia_y_Page_24.jp2
64777a4b04dc6d2d7efdaa4e11ac3e20
f798a63f05f059a0d143d67f0128b07d72403e27
4389 F20110109_AABLIP xia_y_Page_04thm.jpg
94f213dbb1087c56e5c7fac02122e4df
346893596408799f1f5991b91a4187e11ec87312
42132 F20110109_AABLSK xia_y_Page_08.pro
0e1ce08e1a67575fd988e115462122c1
db837f9e2ef28670f392056a340a29da340a271a
5899 F20110109_AABLXI xia_y_Page_65thm.jpg
987c7334269b9fb09b49587959cf71fc
b4fd439a7319e2cf65f43d2df51b4898e72fa74f
81744 F20110109_AABLNO xia_y_Page_25.jp2
04c8fd2ddeb836902ca89631e3d41c7d
e4e79ddf999de4ea0e326e397fd3d5fad637034c
79842 F20110109_AABLIQ xia_y_Page_47.jp2
40c066cab91a4f65e735197824efcbef
19e7697ba05d0b36c18d2fd1215485e6fd067723
48345 F20110109_AABLSL xia_y_Page_09.pro
7a4514aef544189ce46723c9d175909b
547656c2c36d081f4f982d25b2b3484110e74987
16147 F20110109_AABLXJ xia_y_Page_35.QC.jpg
905630bb978e98876443ffdf12382381
396da23a307b8a479cb03a1f4e04572f95099295
51098 F20110109_AABLNP xia_y_Page_26.jp2
852cd153d1f6e15393ee01bc00f99505
d36bcad8c6c7211040f41d2e96926448418a2e39
40733 F20110109_AABLIR xia_y_Page_60.jp2
9ce81fab80fd949a93ef797a68fa8e09
624612322d1b87263b31fcd7772988db2beeb7a8
51661 F20110109_AABLSM xia_y_Page_10.pro
a4d101d5bb6beb7ed7c33e12ca350764
47bdb4722189d6df7111e59f6885253f4aa3f208
18524 F20110109_AABLXK xia_y_Page_55.QC.jpg
40d6d002d55157f3ceb924fcbf0dda99
7d4e93ef4dc234de455dcf17de63fb17e0dc2361
68803 F20110109_AABLNQ xia_y_Page_27.jp2
9d0b34052c235ceb9566243bf6a5b2d6
b74870ef4662ee49611365533f36509481175fae
60852 F20110109_AABLIS xia_y_Page_06.jpg
7221f2f83e967f84b34bc64b5858f164
ddd8af868817b1ebec54cd3cbffba6aaa4fcf278
43404 F20110109_AABLSN xia_y_Page_11.pro
d760c41b4f2883bbada8039aa62f1526
0ff6219142ae7dc08c084032faa55aa0e3ff26ce
5608 F20110109_AABLXL xia_y_Page_66thm.jpg
9f44e42f3064f314b919d205296aed79
99edc14afef914807842a1c9877019e3a15c52d8
62767 F20110109_AABLNR xia_y_Page_28.jp2
76eb798c25895a4b1e72d93adc97f554
89a1033a165d570a9fb4f95bd58a538938e6d13c
22081 F20110109_AABLIT xia_y_Page_19.QC.jpg
787ebcffbdb4b9e0bd9009eaeabbf9ba
fcbe6651afbba879475a78cc09afc5d0a340462b
32032 F20110109_AABLSO xia_y_Page_12.pro
e7a0880feb4958e5e9fabce145f7d252
a939d736cf39e5dbcd8bbc1f90119b571c895188
2269 F20110109_AABLXM xia_y_Page_70thm.jpg
115a49e3cd7f1797f7ad6b5c27807ef1
70fb1d928a3200fbc1e83e851613326bc37224c7
18481 F20110109_AABLIU xia_y_Page_06.QC.jpg
18912d8c6aafedd540a526bd3ba8d0c7
9202796ab4fd0ad049fb7eaecc4c1f8aa637903a
45269 F20110109_AABLSP xia_y_Page_13.pro
91684aab0ce2664aee7697046bb7de9e
02170cca4427bbd1883c0119898d340a30ae9342
6602 F20110109_AABLXN xia_y_Page_30thm.jpg
a2221d0e16b63ba4c57dbb0fc22e55da
0a2e22e1567163824b09f60e5d5b32391b06b482
92787 F20110109_AABLNS xia_y_Page_29.jp2
ea77524af72686357c17a0511bfbd0d4
1df1f36057e15c33e67292f43ea01468e6381572
106558 F20110109_AABLIV xia_y_Page_39.jp2
1a042a75674a5938de6d53680d631ced
c9b59c180714752b7e0e3984cc65c4a2d0009e8c
48488 F20110109_AABLSQ xia_y_Page_14.pro
d088517fe288ee0b7d8eb527c193af6e
36b9348aea91ae51deb5ae282cc00563050a6361
5439 F20110109_AABLXO xia_y_Page_62thm.jpg
e7dfedd84dad5b4ddb808fda0584779b
82d310618ba7458f132affa1da3ae7204dfa6a8f
107047 F20110109_AABLNT xia_y_Page_30.jp2
304cc3860210ee2dfccf3af6eaa4eff4
5eb1ab18904de4ab646dcc06db1248a9afea9c84
14077 F20110109_AABLIW xia_y_Page_72.pro
6fec9b10cc8a4069ddc3c20463896998
89e460bf531b7c1e7b8ca6f67509b4e3bcaf796e
23668 F20110109_AABLSR xia_y_Page_15.pro
ac22f29228743ee1fd1d6162aa4617b4
64142ab0c9171ed75a32992f863c91c9f28eda2e
5513 F20110109_AABLXP xia_y_Page_22thm.jpg
0d7c8b283aa743ab1d29c4162ced5571
c997e3a319c9fe66e1da4259cf9a39f771e81b14
101237 F20110109_AABLNU xia_y_Page_31.jp2
8121b8a7eb5220e5307839d1da7d8c6e
692ff32efab425be439bbcc5d6d0463edd74dc7c
71275 F20110109_AABLIX xia_y_Page_37.jpg
8cafc69d4e8406f2f4a74ee12bca4ba0
0e4b7a407805501640a77a004eb77f90ff3bb0f9
34401 F20110109_AABLSS xia_y_Page_16.pro
573adcc8186045ee6c6d4813ddedf466
0643c5a1c50f799ab28252260c10b3e151577dc6
18075 F20110109_AABLXQ xia_y_Page_12.QC.jpg
069a0fb47b2787cf3d4247f1542627f9
0cd88ee2aad807f5de41565afade869ce1654ba2
85332 F20110109_AABLNV xia_y_Page_33.jp2
827247eb2dd83f83b2ae1ebfbc59ab86
81c958d449cd5c02f408a3bcd043ba9e7ccd6736
5184 F20110109_AABLIY xia_y_Page_67thm.jpg
9688f79fd627c2a1de10d980f602e685
4e961af238edb9d016b05708cf15c222b5ddb22c
20464 F20110109_AABLST xia_y_Page_17.pro
7657533deffdc4db1921c1dd1c3822b4
da167f1b0bc27e946f87dfe37f21d0daaeb99477
4234 F20110109_AABLXR xia_y_Page_35thm.jpg
95d90b8eeb9c09506003bc4a006d708a
cf2d7fd8da7c6c55046317ad3721d7db332ff960
83718 F20110109_AABLNW xia_y_Page_34.jp2
0cf397caa8faa00f567ab11ad286c68d
a74c698ee2772bf007d882ebea004aaee852bde2
F20110109_AABLIZ xia_y_Page_10.tif
96aaec6bf6f9d168b2b3d2c3d469143e
bd01e9f4d9b6259faa32bc7c242479f56b736176
45536 F20110109_AABLSU xia_y_Page_18.pro
2bf1e53ca83ca30be7555a73f7a892a8
4f3fd68493d913aeac5f94edd689d2f722b92cb8
4509 F20110109_AABLXS xia_y_Page_06thm.jpg
9cdffeab923490279473858932a285eb
26d872fbc3bf789c72909846bbea582fe1833c39
61841 F20110109_AABLNX xia_y_Page_35.jp2
9c6d945ff4d49f45a13aa8ea3ae3e0fd
b77a1f65273f83e679aa6dfef197b85497c63905
31999 F20110109_AABLSV xia_y_Page_19.pro
b98cc308e9288cf721b131fff6b17533
a92b8e33996747b1093991f3bd100f52ef93a840
17847 F20110109_AABLXT xia_y_Page_04.QC.jpg
b09784ca1edce0c227121df84f1f1a09
6c3fc42a80a9601d706a3f5291a8980d0f8017df
97449 F20110109_AABLNY xia_y_Page_36.jp2
c7da96e885d1aba9460abe402a0834f4
ca541372dc034900a517f3c37412c6ef52c86ff0
51840 F20110109_AABLSW xia_y_Page_20.pro
94de08244b3d0c148d2d6a8d98d3720e
2b582b5a1b3fd49be17af1fb7617d9dfbbf51c96
77451 F20110109_AABLLA xia_y_Page_31.jpg
975860580a7a19f14427d152a26db6d6
96c3363cc4351c96119a7dde61c35845c09a781d
24352 F20110109_AABLXU xia_y_Page_31.QC.jpg
63470b4a43670520a20306b6b1d55a2f
907526b1467cc6b7a1e48c0d9cd764beeeee8f5c
99335 F20110109_AABLNZ xia_y_Page_37.jp2
c2b34faf02a6a42bc7d18257bc4cc700
19f0f64462479a1af2b467b0e42830a35287dbc1
82272 F20110109_AABLLB xia_y_Page_32.jpg
c79a5c0a5b6786db07f63e2bc23b0070
5ba8bb080270cbc2ea4c35bbc087e82061478387
20334 F20110109_AABLXV xia_y_Page_62.QC.jpg
8e56402799ae2a3d14d66d51acb96cd6
592ff9eb16ccfb252654276995106563e8d86af4
2952 F20110109_AABLSX xia_y_Page_21.pro
f0dbe7b575a5f9f49e36a4cbefb5303d
e80d2ea8fcbcb35bc06b754a80e032473b72d66d
65703 F20110109_AABLLC xia_y_Page_33.jpg
a24aa7089041a92a2e44a42a14933644
51755857eebe326e797a295e089f2e9cb57b87f7
25848 F20110109_AABLXW xia_y_Page_30.QC.jpg
7714ca0b7ab170bb138c57c8eabdc4c1
6733ec3a125672b1ed1df79b17d77749233bb1c1
F20110109_AABLQA xia_y_Page_20.tif
23e8e21ae4914036e54ab6b215e5b76f
ce28c32a4fc4f462f9b4b6b414563cd5a14ee8e0
41099 F20110109_AABLSY xia_y_Page_22.pro
a9eaf4aaa3021b33b75507d88b2c3d8b
7f6a0fea374609715cc042c1ee1aff3a50cdc45d
64876 F20110109_AABLLD xia_y_Page_34.jpg
97f98380a66c03cb5a582a7068d57f0b
beb0bcf632948c3645192dc487d4452605d933b7
6084 F20110109_AABLXX xia_y_Page_44thm.jpg
4694bcd8363a2e8cd86780546ee77961
3c190a5f12160461876eba974cf1e2a94d2722f2
F20110109_AABLQB xia_y_Page_21.tif
8bc0d1f35186e5431454e0561a0ed38d
6c1f579ded7b35d768cf3476b490f28643be8c8d
50255 F20110109_AABLSZ xia_y_Page_24.pro
ffe23418c3d8bb123830b1e6c690ec32
86b54fd083a4d6030b6a38adb25edb1dabe6c355
48666 F20110109_AABLLE xia_y_Page_35.jpg
972a1ffd1ece7a48de884f7161a32867
a8b411a410cb3e766dc964306ee157c0c2f8f91f
25916 F20110109_AABLXY xia_y_Page_14.QC.jpg
091f6777e19879c7f9c2d33375e90fe4
ca4b931f0b0675125c48dfd7e1c1d63274e85731
F20110109_AABLQC xia_y_Page_22.tif
71ead26cc52cb46e672d69db78734ec3
fb13ed94d84d5e6c8d2a2f4a9338e864daf337fe
73685 F20110109_AABLLF xia_y_Page_36.jpg
ab015f9d730c0ec5d18fe062243117c4
67ce0db8d6777e2d24400a54c65289132ddfcbcc
6253 F20110109_AABLXZ xia_y_Page_46thm.jpg
c43ee4b8021a90d0c3e4fb589c77dc93
4f951f23b65e72ada4f270daff0324711f0354d6
1947 F20110109_AABLVA xia_y_Page_09.txt
ad5b213422cadfdcb0e1fd1d0d737eea
50e3229f9668f84e7cda93fb0395347a3e06cb66
F20110109_AABLQD xia_y_Page_23.tif
9879919a3feca036a4f490fe3a25eba5
fe43fd9d5bd46551e4ac22ab62bdbb1f671c10db
73501 F20110109_AABLLG xia_y_Page_38.jpg
f9772001e331adc19d794125f913dbbb
63719470e7ee962f3a202f31d31f1cf3b67a855f
2075 F20110109_AABLVB xia_y_Page_10.txt
b10020222a572c9d2f70a3281b9c19d9
d53f5b3910c908159e82c2d561cee4cae2537e82
F20110109_AABLQE xia_y_Page_24.tif
230a00cc7744a98c19e2d3a4ee75b3c3
1ee1f6761eb75b1e15ad43b2122f9b3e26ffc649
79287 F20110109_AABLLH xia_y_Page_39.jpg
57f9178f4de10eeec08664aafb1f4ffb
d80a300ea4d624fe072d6d48b9f3d377e1a85708
5551 F20110109_AABMCA xia_y_Page_58thm.jpg
b16d2b4432373ac74f293cfc02c6d9f7
2c40f710a8e57d86d75cc080a23c29a8e0b19fb0
1740 F20110109_AABLVC xia_y_Page_11.txt
1a5aef1c67d46a1d26b3a0095c4a8d9d
3adb93e7c630c9943094025faebafe457c44b4f6
F20110109_AABLQF xia_y_Page_25.tif
5f74dbd1d7bfe351938112458db45b88
ee976cdacec614f8d52c3042dd35539360229019
24350 F20110109_AABLLI xia_y_Page_40.jpg
1714b3c3918ebd4b5e83d8124667b58c
7e9170080b2ee6547aa2a1c08c4cfede3e332d2b
5898 F20110109_AABMCB xia_y_Page_59thm.jpg
6b0b4f97ef766c36535aa902bc309a13
d4cce31339a028f6d8f2bd91a5ce5dd2fdf39d05
F20110109_AABLQG xia_y_Page_26.tif
1298ab9fd96eefe124867af842a958cc
418008f9fdf602d1c7a76cddd57268d8ab4bb799
80858 F20110109_AABLLJ xia_y_Page_41.jpg
6a04df323ffc688ecf60a44390074452
806db8d646442b0aed09d8b5d4aff219b7a5438a
1848 F20110109_AABLVD xia_y_Page_13.txt
166be6ea1a9e98550c3219c5ba626ddd
773a431da31af3f5799131d7d7c14ba1b562a706
20228 F20110109_AABMCC xia_y_Page_61.QC.jpg
89c93b99045b7e5d8b6316cb17248212
b60b1e9db0515a3c6d005dbd7f0c6b49875d478b
F20110109_AABLQH xia_y_Page_27.tif
8676b10148fea1774ef54216e21db035
591f8de02c44f4861be482b3458246d72ac8f488
71439 F20110109_AABLLK xia_y_Page_42.jpg
07c573f6e0515ae67e4044f3a8fb96d6
16829b75c4ac41fee4d2d3d9eba46826a5850663
1931 F20110109_AABLVE xia_y_Page_14.txt
d5cf021202d8322fbd76562fc0ad6780
497dab690f9394e25e8eba3809fca57ab36b854a
22501 F20110109_AABMCD xia_y_Page_64.QC.jpg
b7bcb0c2179e1c6f0149bb14c4b4e650
04e52a5ac76ffe447cac4fd107b8738d3c724c6d
F20110109_AABLQI xia_y_Page_29.tif
166580948db13f51b289201ed0fc9f1f
8b233e1a4256c62e5775b70acb3af49c4eb4b231
93334 F20110109_AABLLL xia_y_Page_43.jpg
ff2d031aa804f9559da52013861e4a3c
d0f3658c6d8325109b723070ad25d44072ea4fb1
1302 F20110109_AABLVF xia_y_Page_15.txt
ec41cdfb735b2ec18f2320fc6670a3a8
a10b26724cab2daf1d2434e29e6ee3bc10e41782
5879 F20110109_AABMCE xia_y_Page_64thm.jpg
83d82fabb4fdddeb5c71c46caed6d61e
a355d1d32ae077b5b7dac4025c451e6593d2a443
F20110109_AABLQJ xia_y_Page_30.tif
a967e648e251137bccbda697293c6f9e
bc1369da08a9152a31fcf0d8d98c139672d4043b
72751 F20110109_AABLLM xia_y_Page_44.jpg
afb5075c04d01b58bd4a7fea05ef4fe7
a191432973eb69f58b2aadf99421a2b0f008de3a
1469 F20110109_AABLVG xia_y_Page_16.txt
2bd6e2247c3fc15a9dfa8dd0f72ea9e6
c4ef84ec61805d4fd0b1f8b80fb5cf3b4af7e346
18951 F20110109_AABMCF xia_y_Page_67.QC.jpg
4811f8dc81f83ca3a55a45a75524626d
2a89f66a25bde29a73af1f67428ce10ed4362ccd
F20110109_AABLQK xia_y_Page_31.tif
931d0a23e073bb9a65589c6fec82a681
303b016b2d81ae913ea3c8943ca34ecb0ebb524d
71263 F20110109_AABLLN xia_y_Page_45.jpg
1fbd683fa1e95c2d2fd9706d41f5bd69
9ed6ec58302aec49dee169b3fba6fcc63575222a
F20110109_AABLVH xia_y_Page_18.txt
efacb62fc4f158e4d8735ce42a613d14
99fcffd3e80454d26859d962570e0b5debe924e4
F20110109_AABLQL xia_y_Page_32.tif
a829c2c05ad3b8e8d158601e8548a13d
65526b557b44e3d7373902e5b79562fef85c0376
78825 F20110109_AABLLO xia_y_Page_46.jpg
cfdccddb2f3818565c996e191af1b18e
7b17512c1f99ccdfafaf59c972d0f32b9be70146
1526 F20110109_AABLVI xia_y_Page_19.txt
c7d3b0de09ae1274018acb788f29d226
22d3aa3a91636d25dc20f9053317ac6432f79ed9
27462 F20110109_AABMCG xia_y_Page_74.QC.jpg
07d828e60ee4b850af51a6c06cfde514
8dc61ee662c6cda162038b1c8e8cfca188a5aba4
F20110109_AABLQM xia_y_Page_33.tif
1eb5b182125900956646be7cbcd0446a
9db8249377226a1f4873d18a5a72e50c687f4811
62722 F20110109_AABLLP xia_y_Page_47.jpg
772da36bde21e1ab8db6fd2a9c336306
b5313ebae2ac544063ea2e30bedea2b5e38c3185
2042 F20110109_AABLVJ xia_y_Page_20.txt
210fc32edb56c5b637dd42d4ec82fea9
964a5a0d7f2e327bd95b3fa2c52252dd1f55261a
6645 F20110109_AABMCH xia_y_Page_74thm.jpg
b7d8002264ba0c0b52c53ff74c0edae7
d64d815a0a4c74a81f9fd3b163527cf4dae1c037
F20110109_AABLQN xia_y_Page_34.tif
949f358d010e8e3dc192949aee61c32f
7be3b902f7ca8a130706939821e91475c0361271
163 F20110109_AABLVK xia_y_Page_21.txt
d3ebb9e8065772b25815be0173bbc39e
d7517c4be6dd2baaae420bf7642695eae9077ff5
5810 F20110109_AABMCI xia_y_Page_75thm.jpg
f9729a0a31e3d25a0489550abe713267
f75a20e00e76b52d53173bffa0903eaf1673f246
F20110109_AABLQO xia_y_Page_35.tif
19a794601c2ad966d5d36c2e48281bef
308bed7d7acdc7f490f467708317fc5d47839c25
67681 F20110109_AABLLQ xia_y_Page_48.jpg
cf181097343149d364aec626665f7d87
a2b8a3aa74a8e178fb3f78b5dbda0e5f91581359
1712 F20110109_AABLVL xia_y_Page_22.txt
240940ebbbcca4be11b6fe51837d77e9
7d08a4fab49b23709e238929315429ee608f1ddc
3010 F20110109_AABMCJ xia_y_Page_76thm.jpg
36c8fffe8df08f2295b483dbeb86f8dc
b8b546d68f63fc8f812ef664fcaf3d9a68060de6
F20110109_AABLQP xia_y_Page_36.tif
5e62ff71cec9dfd78ef86e0756ec8083
377180fd42e7b447bec139ae82b455716fa8f0b1
80060 F20110109_AABLLR xia_y_Page_49.jpg
dc5b7bcd8dc644a188390eb6c64b7a67
aa1f481d9da6dc0ed07ee7ce79a56df29a8bcfae
1933 F20110109_AABLVM xia_y_Page_23.txt
c78a4512f020906481de0cc32f9e632a
27f167afe3bb4376686cb100302ce7a07f698471
F20110109_AABLQQ xia_y_Page_37.tif
eb33455881598daf42f3fa50bde190bb
03cae485a1d583d8a1fdd5ea4bbceb2e050c2adc
7718 F20110109_AABLLS xia_y_Page_50.jpg
411ff4b74f3e408c65c827d7f5a58ff7
72e19e4e4092044e47c4313a99f41d0e85fb3a60
2015 F20110109_AABLVN xia_y_Page_24.txt
0772216c636a6b983e6b17c591a523cf
bd516e89ba5d210c7e12881c251a1af0de8223f5
F20110109_AABLQR xia_y_Page_38.tif
0a0aef90f8744762d6ed64b75938dd61
3e2cd41c661424da96614ca134f20ef623f4d4c2
75030 F20110109_AABLLT xia_y_Page_51.jpg
5d29831f552620704bce3e3c46a25c6f
eb0328566888d9827bbd6c334689e282d7ff6260
1509 F20110109_AABLVO xia_y_Page_25.txt
23208f597465b16e8107c8758a83f503
fa22551abdb9ffcf44c22847b4ece11785f49f53
F20110109_AABLQS xia_y_Page_39.tif
1805ee223ad3a2d1dc305508cfbc30f2
4de17469e214f382ecd70e6ecf814ca17c977fb0
71768 F20110109_AABLLU xia_y_Page_52.jpg
1facd68d9056793602320f148d8be86e
9222024049afd2c8aafc197a2dd40e2280f9462f
1121 F20110109_AABLVP xia_y_Page_26.txt
fdae977127431db8f98970999c097a8e
746e18fb440b07849312cbddd4f27b2120a82f0c
F20110109_AABLQT xia_y_Page_40.tif
3748af009502c5485f4548379ce17cf5
657b6513f1145a6ef3e33a1699fc4d5fa1270b30
72195 F20110109_AABLLV xia_y_Page_53.jpg
8c165312c393503d7fe52717de26eeca
3cb7316a34e6a61aaa4a8a7acd318fad0312899c
1620 F20110109_AABLVQ xia_y_Page_27.txt
ff113da1fa98f4d45f06c9d04a70dab1
a3b58781a341b36195678378e6a5bddb92a06e9b
F20110109_AABLQU xia_y_Page_41.tif
1e2812d607a4cd41e7da5b7f3f6eba5b
5347d4f8041814874f4a78437b2edf6d7033e122
73196 F20110109_AABLLW xia_y_Page_54.jpg
83321d58a80a9b0db9ad5e9de38eaa89
1c6da03fd6581723c29d718f92125a0e1e779f6a
F20110109_AABLVR xia_y_Page_28.txt
86662b7a8c5f803eb90061551e71e805
d0099fdf9a7edc016b5eb7eb1a9cc487b595fdf1
57478 F20110109_AABLLX xia_y_Page_55.jpg
9a0888dbd0edee661308fe5080e455eb
481b1d7b5247bf1ca678d2db4539da7166ce9c57
1698 F20110109_AABLVS xia_y_Page_29.txt
0b4bee3318591601105b1dc4e6e3058b
9af358243bd0deb596a79c42d57cb50da6e57029
F20110109_AABLQV xia_y_Page_42.tif
d91126f935efc9ccdd8c68445d61d3f1
462ba22d3cc12070415e07d17e485fec1f98eb10
25180 F20110109_AABLJA xia_y_Page_71.QC.jpg
70eca92e8c0b139d24a9265b479ba39c
cccb1a1ca89b91774f48aa0bf3369afb353ad7af
66277 F20110109_AABLLY xia_y_Page_56.jpg
42aaf5bfe279e831cbc8888bce2a9d54
f31ee6d410b270f797f6670d06b6e5ef5782af6c
1950 F20110109_AABLVT xia_y_Page_30.txt
4bf73eb7adee4b1a72a1a2ce17f8e7e0
8b7ddd40a607b8e48ea1f2c26748684e1cffedc7
F20110109_AABLQW xia_y_Page_43.tif
63fab60c0feeb97122bbc01e96d6d6b8
76772efbf2e9fa5ce4a57dea4d1ca717ce7ab7f1
6132 F20110109_AABLJB xia_y_Page_71thm.jpg
339efbdb91f2795186593ca3605e45e3
c4823ddc3649a04d92e2d9b77750dec6da4d6c66
55833 F20110109_AABLLZ xia_y_Page_57.jpg
8800c1d091e35e104dbb8f8982869105
4e0bd62a8d9196974fc711dce73c8f7addf64a5f
1868 F20110109_AABLVU xia_y_Page_31.txt
f0593ab3f807c4faea359a14c7171f1b
2410f68bafb5cb7d5bde5e60df06f98c53a826fe
F20110109_AABLQX xia_y_Page_44.tif
7f4f614fe06c8026db960d7be7aa224d
78b6840db12af38b03ae39579c6b877e2b4232a1
22713 F20110109_AABLJC xia_y_Page_54.QC.jpg
87acdacf78b6af0ea98d9c5032a4ab6e
f971a9b7ab09366c7e919b5f938924927891cd9d
1967 F20110109_AABLVV xia_y_Page_32.txt
e4b0ff7be70bfb6af3ac76977f79e018
2f420b20457a0b03f8d807cbc4c2959e7fcce759
F20110109_AABLQY xia_y_Page_45.tif
16624ee257c47e46888c23b61c2b9e3b
a4b3d29499fb218b68efef5722a9d4d25c71199e
F20110109_AABLJD xia_y_Page_13.tif
11e7394186362886f5d7353eef01ac81
cdd4e09db38098cf31fba538fc02ec2887fc2052
2026 F20110109_AABLVW xia_y_Page_36.txt
11ccc21b37f38ac0a999819b646e1a3d
831fad2349f5b18b29e8cecc36f27228d237f66a
102049 F20110109_AABLOA xia_y_Page_38.jp2
74d88a536d93ae95827fb15293ddaf35
420562317cdecd5c0b0570237cab147ba5bfc650
F20110109_AABLQZ xia_y_Page_46.tif
4c42779159a9451c0429dbd7635e027b
1ad21c38a26dfa51c02d3c0a95e852ccba6c835a
F20110109_AABLJE xia_y_Page_61.tif
0ff7c6aaac44e1ebe52ebb33138a4579
5356e4e10cd7b29cde1cb409cf800ab504639952
2251 F20110109_AABLVX xia_y_Page_38.txt
a55426f20cfb75544d417b96e9494543
da1f2529a4f64fbbfcd6d6ccbe205d7c754c80d4
31969 F20110109_AABLOB xia_y_Page_40.jp2
051a4d6fd9b0d900056d1b85304a76aa
4a240a644499a51d16e8c06cbb657050dc6b9084
35315 F20110109_AABLJF xia_y_Page_55.pro
ffdcf3a03ef7d287d14680671820c0a9
b140438c013f65d044bc842ae4688a0a9d192e34
1984 F20110109_AABLVY xia_y_Page_39.txt
5d41e3cc6916cf219d534efb8591042d
425ed462e5afc6160bba4c7134c417e6b0c612ce
103846 F20110109_AABLOC xia_y_Page_41.jp2
b11dc557f2906932ea3f234f49eb1c91
fd0c6e1d7adf0aa29aeec0e7cb79105c5a5df15d
624242 F20110109_AABLJG xia_y_Page_17.jp2
d11a2c3244aa63657ea2a6978233153e
f2d459aa3b7417d1dfc32cea0e2bf87e5147d3d3
36915 F20110109_AABLTA xia_y_Page_25.pro
d9c6a07f9a1ac887c27499e7c3a7f4b1
e84a52cb112ce7741dbd9a88e4bf007243ca5d43
622 F20110109_AABLVZ xia_y_Page_40.txt
fdcf1e71c30d354ebe8a438171ed5918
e0b0061e687fe004dcac35b6070634040b918b3d
93631 F20110109_AABLOD xia_y_Page_42.jp2
4f12539aaaff71011ef35a8696871b43
3375e92ce7ab6cbd96133bee1c99aec0703402a4
1770 F20110109_AABLJH xia_y_Page_54.txt
05f90b4716e8368c92a1049106a99e41
c75f4172909d2e039e16f2d53ef6c8e61d57f52a
22999 F20110109_AABLTB xia_y_Page_26.pro
5d72323080058beea35d4b97f0dbf489
517b7b54640efe9e0d2a999a9ad26925f300a6be
116318 F20110109_AABLOE xia_y_Page_43.jp2
9b748faf2da9af60acd80189c347afe2
670f8658e26fab31af4a3acb5ae09a1d323d01f8
24459 F20110109_AABMAA xia_y_Page_65.QC.jpg
a303199693f4788d9e6af2664d2e0c35
bf50bb8b0d57b9bb812fbc7aeb8765b5496a2eeb
52308 F20110109_AABLJI xia_y_Page_65.pro
043041117ed9ab44e45a10087de5f506
0f39c5056b6f3a72605a61ec99326ee7f7f29b4a
25643 F20110109_AABLTC xia_y_Page_28.pro
6abb6d0624ecc6b510c00ceee9c4f0ef
74e60a5554d7dd054b7efc23002d08c626c34059
93964 F20110109_AABLOF xia_y_Page_44.jp2
5f2ce66092cf121ba84ec667f33e6e19
6d5288dbeb8116c4a0c8901468e255502a81a7b9
23587 F20110109_AABMAB xia_y_Page_75.QC.jpg
535142e4a50eedb66f47091e6de6ebd3
617d8293eb75e58a99d0f81a70be115d60ad2328
6444 F20110109_AABLYA xia_y_Page_49thm.jpg
4c95fda6820718ecda53dde916d4b801
d36ba14334f2e87a1e17590f2931374f615245c8
71549 F20110109_AABLJJ xia_y_Page_59.jpg
656c2957fe679ae30cb5cd6aa0a1155e
054d40dd5995d900560a0b419bfac4e366cf304c
41114 F20110109_AABLTD xia_y_Page_29.pro
1bafa7e10c691114a8b2c23977a21d7f
bd28b032fef74c3486acd0c2be055418411827ad
92633 F20110109_AABLOG xia_y_Page_45.jp2
2498397b81e5bc40d90efb761154f140
58cdac32d74cd6ac87294ad1697df1958ece6aa1
5193 F20110109_AABMAC xia_y_Page_68thm.jpg
1de61fa2d8b13f6ba35abb5f5ad427ad
74685098fc26b87d5b37294145913fb3d4dc0f93
1586 F20110109_AABLYB xia_y_Page_01thm.jpg
847929258e726b765b9a3998ed692fe8
60d0ed8053e70ee629cf8902d1ffb5d40c63d5b1
189 F20110109_AABLJK xia_y_Page_50.txt
12dccb9d0a1c9eeba44c1839508827a6
1515b89190afb13a9402a5c7509a22fe3c0d28db
49294 F20110109_AABLTE xia_y_Page_30.pro
5b82c81526e96acb114cfc8db2a19b46
2ea04e5ce6b3e3d46c1e6179fd18333bac0c1f46
102952 F20110109_AABLOH xia_y_Page_46.jp2
bcfc95ccdf2c2f46e66c267f9b23b22e
f852896f69d67580b346a2ff04401708c25ca0bd
19440 F20110109_AABMAD xia_y_Page_68.QC.jpg
d4aede9915e64faedfe71c183aadb0f8
beebab49f756095fe7dfed651cab2d1f6a482754
20666 F20110109_AABLYC xia_y_Page_63.QC.jpg
f91459654480fa1a74802ad0b37f4ea2
4aaeb96cd539663c64ebd55bae6ed6b9e9ec3547
4266 F20110109_AABLJL xia_y_Page_15thm.jpg
8d76c4d43d9342bf4ae3af9781d87aae
e5b45c6e41fced37ce27ea790568488bee557922
46900 F20110109_AABLTF xia_y_Page_31.pro
fb85e4723dbb17974c131d6b837ab8b1
db7c9fb8038a329038da0fb3080608babc8e5440
96753 F20110109_AABLOI xia_y_Page_48.jp2
2b8cee444a7437f2826f7bcd203b35e5
3dec825e5c50176722cba6da975ea0f524fd385a
18770 F20110109_AABLYD xia_y_Page_25.QC.jpg
66cde18cfcd05ad2041c1bc58072f450
4868e4dea221700af5dc678df2fa874085a08fc6
30866 F20110109_AABLJM xia_y_Page_27.pro
48f77dec599cf98f407373862cae1462
ca179036b78d32ea72b2dd706c635e7ff2088de7
49077 F20110109_AABLTG xia_y_Page_32.pro
c9d1de4631be5f208f545a2225929e06
45003b06cbaae44a129f50801a5b0c1bfbd3ee10
102273 F20110109_AABLOJ xia_y_Page_49.jp2
3e932f4549b8c6b74407138a2412f099
58c52e6c871ab7b77b51bc2efd4ed2f42ba2efa3
5847 F20110109_AABMAE xia_y_Page_52thm.jpg
1c168533071a906af246a75c7f86674e
ed0c95654c5c3df1ce31a52b9f335ba690045807
5384 F20110109_AABLYE xia_y_Page_33thm.jpg
714b1436e47c341ec22a5fd2c334b992
e50bfb056c3531c130d952732e2b8dbb35bd75c6
F20110109_AABLJN xia_y_Page_28.tif
dcb7c1ed2c6dbd7a2668501d662fc40f
79b383a5b71ca20111e7ad2698100bc6689f8c99
23928 F20110109_AABLTH xia_y_Page_35.pro
10e12f8eb05c6d93f242f970bfcaef81
d16d6a6b780d931989d9dce7e6d899c7709ef956
10140 F20110109_AABLOK xia_y_Page_50.jp2
2e9b63b4c64dbb26a1218d07268cd915
6789e5834aff769731cc2051fd72a0c02a0d7ae6
5137 F20110109_AABMAF xia_y_Page_55thm.jpg
7b06de94dc709a427336f7a27bb32d8d
0602b9d7eba1574bc622d7b93105d10dc358feeb
775 F20110109_AABLYF xia_y_Page_21thm.jpg
e66bbba7459a7ef55a48050121a72207
b78aad6a7e0e564b00d5f7bbd5d5c81c8907b4ec
42985 F20110109_AABLTI xia_y_Page_36.pro
2bc775954571a83b19fe4fd654ae88cd
e02136b768a37053504b76ea51b57ed7edc35407
96278 F20110109_AABLOL xia_y_Page_51.jp2
e8562403c29cba843e27929bc569705c
3ffeff11cde7c693aef32ea57b9194eba3c41b24
113712 F20110109_AABMAG UFE0000619_00001.xml FULL
c4877e8017b8cf1fc12b91341ed83015
e541728afcea36cbb9083b782285d119c11f9230
6696 F20110109_AABLYG xia_y_Page_72.QC.jpg
7c31ae6aeb0ead41209ba3e01497fb3b
367c102067fca2399eb05daef589946c4a2f24e7
104710 F20110109_AABLJO xia_y_Page_32.jp2
d431932c6b5855fcb13b90d75e6f8f82
4a1303f62540a86f1955cb5c7f3541dd800c36ce
43155 F20110109_AABLTJ xia_y_Page_37.pro
3448b448868b36577ca8759161575459
03e8e0f4a50235faaec3cfc8cf09be88ad739300
92063 F20110109_AABLOM xia_y_Page_52.jp2
c004cd62a3c4b9828dd65de36b66fb32
1e74c6d3589619a14927f0a17cb225e280ce3e92
5822 F20110109_AABMAH xia_y_Page_01.QC.jpg
80d7f49d1f4852ceb80a8a4d6078c25e
4f6331909696c1d1c02c65cee65c1bf96d7cc112
5285 F20110109_AABLYH xia_y_Page_61thm.jpg
243fc6864dd5b93632595cbe11d46e82
4b697d01aa21d504835faa3750d9ea4c464910f7
1703 F20110109_AABLJP xia_y_Page_66.txt
bdecfce2b34c4c7000e41c60af8eafad
400319721d2461dd74c7291cd0f28098675e667d
45620 F20110109_AABLTK xia_y_Page_38.pro
7fbaa6fa332647a871df97404a3c39d4
19e8fa4efbc98be59aa2e188507629b90fd395aa
91292 F20110109_AABLON xia_y_Page_53.jp2
99a236e35dbb7578a1e6aa24ddd772c8
47564229fd1569f498073ce7fd0d7baeeeda692f
1308 F20110109_AABMAI xia_y_Page_02.QC.jpg
692358ef5edbf112a0198e6bdaa8b06b
73d7f8c5bf7f1d3157a4e1a2d582d7bef4b14215
18462 F20110109_AABLYI xia_y_Page_69.QC.jpg
b366cc1b907eff4fb8c880cd13f6ec16
1fbd7f7ebb2fd5894e7e4833cc5fd47bc6af117c
36637 F20110109_AABLJQ xia_y_Page_34.pro
88c68f79cec7d23440d8ba83a80c4ca8
ca2651294a9e10cfd0739220a73468d4e7364110
12321 F20110109_AABLTL xia_y_Page_40.pro
832d5ddf9cbebb30edcf42d06c4043a1
a7710ed4841b729ab858a0ce452c0aeb3aa8deda
93477 F20110109_AABLOO xia_y_Page_54.jp2
08b5724c08edd480d53e30b1faf7b39e
ce55646e33024dc2cd92a8de9c6e10b22cf03290
492 F20110109_AABMAJ xia_y_Page_02thm.jpg
cb92b820a89255ba3b7d1da36fe628ca
ca3cdb79f554466bdbe15ddf6f6e5d3dd1338e34
1778 F20110109_AABLYJ xia_y_Page_72thm.jpg
004c4986c2c72aaf55a25c836bb82a7c
d938f18d15ff0daae359812aa29a3fa401355dce
22431 F20110109_AABLJR xia_y_Page_08.QC.jpg
94e9e8b0ff844a7495bb674b3f33dbc5
9b710b2c7bac28bb58905f52c03851e897962bd4
46576 F20110109_AABLTM xia_y_Page_41.pro
92d52c8e879a3094ad4b13809d4cbb56
595018010a83ac6112e83e70ac6894c188629cae
72440 F20110109_AABLOP xia_y_Page_55.jp2
954a1249bbcf07253590e1c3f27ec55a
e6cd318fb394a15ef47a65aece7527fe3eeb1dd8
4267 F20110109_AABMAK xia_y_Page_05thm.jpg
afc6db729e5c9ef61a3c3ce641398273
1d5e18eb816cb7b9f9e0a6896a3c43aa20a12eea
14583 F20110109_AABLYK xia_y_Page_15.QC.jpg
8a526b38f600377e9fa595897c52af7d
06a207f33e28cf3370e8dbc6faafb0e9ff48de29
43053 F20110109_AABLTN xia_y_Page_42.pro
45f72308225b7d02fa9a1c4ce0966762
99b5088b387a1af95a6916ac1066319c13f95381
86681 F20110109_AABLOQ xia_y_Page_56.jp2
0fb29b70c0b076347f19c6afbc3f0df5
be10fcb7ba99287d4b48b7e51e4c1394d5aee450
1229 F20110109_AABLJS xia_y_Page_35.txt
c82fa753aec1d2daf2f39f181137a180
da63d5749c68bbd230c258e12c2602b79aa09a61
6406 F20110109_AABMAL xia_y_Page_09thm.jpg
eb488ff150423d13a4aec039fbbabef6
ab20b061521d56d1fec626e4cc4f220d77bcffd9
20472 F20110109_AABLYL xia_y_Page_58.QC.jpg
c547339641999240c0133379dc7857f2
55e7d98a3816857da800279c5abdc3a2bdadac41
56649 F20110109_AABLTO xia_y_Page_43.pro
55770f25c3e11bd51f42f60033567558
96d32eaffbb1270889661ce8a26bd1455215360f
72744 F20110109_AABLOR xia_y_Page_57.jp2
bdd8a263c58d8a4cf3322f561c014592
e3e89af7f90724843f7fe8e68814d8a994cb9312
41328 F20110109_AABLJT xia_y_Page_03.jp2
ab49de30148fc013ee19b02525d2fbb3
61f7b236500900458beea611b9ca9d82d0fd7058
27816 F20110109_AABMAM xia_y_Page_10.QC.jpg
6b3318159f282e55f90614c364a032d2
43d8e69d6ecaa7c28c673db0728dcb4b4974864e
5790 F20110109_AABLYM xia_y_Page_37thm.jpg
70677ff6d73f074a56180000fb22a635
faf468a998ef76e2c52ca5b8c7de2a0024f1041c
43114 F20110109_AABLTP xia_y_Page_44.pro
77547274a58718836ed9a6530840ac2e
f02ca81e81492441af37d31ed7368e767ffadd00
82118 F20110109_AABLOS xia_y_Page_58.jp2
6e645a2915f1b596a7c16c357ac92a07
9043b88ebdc66f19e5f886a54db41d5204760a58
78770 F20110109_AABLJU xia_y_Page_18.jpg
6454b776785430628bcc833a42c0a55e
59c90b968475f459f97e4395dc2aefd18140d32f
6134 F20110109_AABMAN xia_y_Page_13thm.jpg
3bd52c257e7c33f4a55e27440a055e95
d8a8f5574c54e44e194c6b6f07dcec0b99d05929
27495 F20110109_AABLYN xia_y_Page_20.QC.jpg
d120f1d7274a34f8a5dc50226442dc6c
b678be2378e8f6ddbf7a709ac8f353b371b97b33
47035 F20110109_AABLTQ xia_y_Page_46.pro
c8a9242b6959f23417a42c489547e118
68f2c4a5cfa9ecc92afb2c20470ceb578885bbf4
88026 F20110109_AABLJV UFE0000619_00001.mets
213e5b14c1f9162de96cc14ba7a3cfbc
883147d0484ad7cf10b6362db248d9cdc7c7fd26
F20110109_AABMAO xia_y_Page_14thm.jpg
543c10081a25dae43b19f056707c1979
4ee6c037bed12982fa37bc7148497788e705560f
5712 F20110109_AABLYO xia_y_Page_53thm.jpg
f1e2a8ed3382fef08e19f35257dd795d
f0403f8eeca7a0b5074cc3413a65e9d54b04e546
39304 F20110109_AABLTR xia_y_Page_47.pro
e23eaa0e16b454e6f2a696387b559101
d4fbe20c7badeb9e65f55777ff1e9b93f2e173ea
92186 F20110109_AABLOT xia_y_Page_59.jp2
4e9def8212fa6d74aef6c38e65e3dcfd
0385def3ed3b0e3de47f3043bf1387713156df7b
5287 F20110109_AABMAP xia_y_Page_16thm.jpg
eb08fdbf3fe4a2c08448d1bc873f5902
5f58aed3e12dfb05e4f16b9a9571dd4e46d1b91d
20738 F20110109_AABLYP xia_y_Page_33.QC.jpg
0a1201f00bd23995b71b73c29375d2e0
d386c0c636bfab88d225fa9b29c982c74b0c248c
42689 F20110109_AABLTS xia_y_Page_48.pro
198e61a0bd9c512ead996a77a80fc5b3
bb1d2fa79d82de91eff242f4bbf6a65c6151cfef
83336 F20110109_AABLOU xia_y_Page_61.jp2
ed737f4a6ac6fdabb1aa1981c1c9e1af
bbe56ae3d540578d2a9e969ff946da827a721fac
16849 F20110109_AABMAQ xia_y_Page_17.QC.jpg
99cb9378430fcedad13dc16144e33cb8
105325a3be7c104ec72609438ba04d75ad37cec1
1883 F20110109_AABLYQ xia_y_Page_40thm.jpg
cfef8fc424aa11b3a01a12351947814f
94d7920011cc6cf4eb5a38928c425c35768d8a44
46868 F20110109_AABLTT xia_y_Page_49.pro
d71df4eb0e39e47b3b51b6cbc20b14d1
4b4ad4c2085d0d8140df6958b4ea1ec39df4ff2e
964057 F20110109_AABLOV xia_y_Page_62.jp2
906fd8b059c88a3aded32b0926f9eae9
8818e1a7c97f6864e3b93cab26f91546b8cee5c1
20084 F20110109_AABLJY xia_y_Page_01.jpg
f6825520519d12cd8f65cf98dfccd958
6685643da338a0fd21b8afcfea045d5fca0401e2
4848 F20110109_AABMAR xia_y_Page_17thm.jpg
7ba563db3987eef2eb525353bec8b73d
3e6feb41fed8952bb28c14d1b9c8c717beaacc4c
3818 F20110109_AABLYR xia_y_Page_07thm.jpg
72678c17216ee07234d03705feb16c07
0c033c869b711df9413d8ed72b51a7c5ef2224b8
3420 F20110109_AABLTU xia_y_Page_50.pro
1b535ba789e64225a31e1be0c4c95cbf
75eaa631c3593e0e666dcf25eac2bf12bfc5ae30
89228 F20110109_AABLOW xia_y_Page_63.jp2
8d0f69617176327507717f84002b36df
cd0534a9479321de2b045ad438b9b7fd58642684
3756 F20110109_AABLJZ xia_y_Page_02.jpg
7ea8c0a7a70b75da99413f5dd5df37df
49b7e4335021750177bbf2746a01f1c71c7a9983
24833 F20110109_AABMAS xia_y_Page_18.QC.jpg
ecfaf01f7f534bed8d4b9a808290042c
241a157ec87eb3cd33140da8b16a8c2291c82890
5017 F20110109_AABLYS xia_y_Page_69thm.jpg
513f6b04dbe5d6cbcfe3c7944924e9d9
c9807e544c8e49831bffc06b7f09db79eeb6737d
43550 F20110109_AABLTV xia_y_Page_51.pro
30f74a81b636e658de7c77733944f78a
b53cedd26e817f8c825795a8a94fd806cf3dcf61
924541 F20110109_AABLOX xia_y_Page_64.jp2
34cee3690eea7d8152ff869c155d83d7
0e4e5c110b85b36b7c5de29e78c58dfc2a1de6cd
6373 F20110109_AABMAT xia_y_Page_18thm.jpg
336b8bf6e79a492efc509121fa883cb0
c0433169cd7a1141f716b2a05f69ec6feb9dc14c
15025 F20110109_AABLYT xia_y_Page_07.QC.jpg
51447d3c48a89033c4b2692098fb8116
dfb77c22cf70a3c3c45fc3cfb45dde7a3649935b
40945 F20110109_AABLTW xia_y_Page_52.pro
b1f411282739645066374c695d679178
ed6e9970850d3428137f06eea3a951770657ee2d
64869 F20110109_AABLMA xia_y_Page_58.jpg
17de4784cd75f5cdf074026445cde289
382c54f978d10710d1c8e80d262bbd1227b20f92
96009 F20110109_AABLOY xia_y_Page_65.jp2
68634f3a1bc0bb52deb84b3ca73defbe
aa329a150ca67399343475cb78800baa11d634a2
5689 F20110109_AABMAU xia_y_Page_19thm.jpg
b659dce3ed9431783be728a86f0d3872
f8655c233fff7e6fa476f2d7cfeee90a88bcc386
5753 F20110109_AABLYU xia_y_Page_56thm.jpg
90f25ca09cf695ffb615674d3cdb9a00
57e33d4965e3e9f3992c1dd20c1f9bbb207746a6
41218 F20110109_AABLTX xia_y_Page_53.pro
72d81c6e151131e5f420a06884cc7c83
07324cca6ef69186766503528d0b20d3e9f6ff96
31939 F20110109_AABLMB xia_y_Page_60.jpg
0a96f9a80fe4013170d7ce2154b1a9ca
8e4f87116afef59987ec0ba56f7e83d7ec0bcab2
91446 F20110109_AABLOZ xia_y_Page_66.jp2
a146af0f326e5c1e569523b25662ee9c
a54aae24f742290d1ee8429f6399a0bea91669e3
2621 F20110109_AABMAV xia_y_Page_21.QC.jpg
6aa63d5db83ef4b09208bc3bdd04e259
7ab7dc30c0ba2c257b5ade504ad68b210f5825fc
5051 F20110109_AABLYV xia_y_Page_57thm.jpg
63cca069688f7ae27968a57831c95afa
92b8984d15b8ea42411c4a9d545a1ed83a154b48
65409 F20110109_AABLMC xia_y_Page_61.jpg
ecf5898bf7ec6e537b9da5f0342c358c
2d16a587e0db8c3bd0b120e8da79692ca4069989
25718 F20110109_AABMAW xia_y_Page_23.QC.jpg
6b6c6966eeb260ae06177718204cb4b2
9b2ee1917dfc78f4b4ba587b0c7e403aaaad22bc
5809 F20110109_AABLYW xia_y_Page_73thm.jpg
373e4d9c9163a0c6e5059b33cfe58a8b
4de26aee509061e000a4141d819f3d2f303067f5
43271 F20110109_AABLTY xia_y_Page_54.pro
fe8178fd03ca27e209f5fb717731287d
5a69159e7d7189d2820791a706d4f13f825c2d6d
65568 F20110109_AABLMD xia_y_Page_62.jpg
d4b7551dcc99e260b90f4503fbf2609f
0036a1fa6f3d5508a77be39256e7531c5dd0aaaf
F20110109_AABLRA xia_y_Page_47.tif
05383367ca54987df68b4b5390117021
b04a9863351fb0dd33a2804f0347d4dff3ca15f7
6514 F20110109_AABMAX xia_y_Page_23thm.jpg
66d13c26a034367621fbc7c94762cef6
2ab27b148fd7fd99b31cb4b491cef8a81b6055fc
25316 F20110109_AABLYX xia_y_Page_41.QC.jpg
d38eaea2de7f4f9ae02c9e47c8b11e47
532091c818a51361b82bc84c16ba807931c158b9
40325 F20110109_AABLTZ xia_y_Page_56.pro
3f556e7a756b19e44ba39308fde87343
156b697ba240318d9ddf4613336aad78fdf1fefe
67530 F20110109_AABLME xia_y_Page_63.jpg
1e7482087d001a47b453dd914d4595e5
ddfa88e831162afe75967319f727c7a13acf89d5
F20110109_AABLRB xia_y_Page_48.tif
29182fdfc2c6d5c4b7a1ffe85ac9034a
5ab0fe3391e8e8f093754a863a0402bd61f23eb6
25777 F20110109_AABMAY xia_y_Page_24.QC.jpg
21cd0fcf46948f9109be0ae3bc6d4e97
f39f72721f939f60f2c5afa5c0dadba8185ad446
4745 F20110109_AABLYY xia_y_Page_48thm.jpg
a3722bab6e76e54ed778491b6175e1be
78e1e1bb84a9f1ab4a909f29131b565549dfecd7
73424 F20110109_AABLMF xia_y_Page_64.jpg
991b828e33bce90806464acc2f5dadde
db7eed8427bacb301b4c6bcd59838b6accefddfd
F20110109_AABLRC xia_y_Page_49.tif
64e62f8be5c8ed5e62c87b39beb87d75
7b237db6cb484e4cb5bfda5cf9086fd88c2337c9
6537 F20110109_AABMAZ xia_y_Page_24thm.jpg
b23844371c683ec561b2ce7af6bd67d4
2bcd258a1c293094017ca3d9be21158078e6466b
22629 F20110109_AABLYZ xia_y_Page_22.QC.jpg
1dc39109dd8b0c9d43c72b0d7b069f8b
134d79f9934be6a68583b230c398dd077e4b88ef
81034 F20110109_AABLMG xia_y_Page_65.jpg
0273c05e28cde4cd80613acaec4292b7
93159ddd736d9865de39f169fb7099715c2c3d98
1889 F20110109_AABLWA xia_y_Page_41.txt
8e06a93e8c4653004aa7750487fef376
3de883d1c5e8d7f1acd072bb8b0a5e24d13824dd
F20110109_AABLRD xia_y_Page_50.tif
6ca3f264d51fadcba634a5f17c8570c9
d7434436c96bdafcd87aa7f2de929678affdc383
70528 F20110109_AABLMH xia_y_Page_66.jpg
50cceb56edba826e871bbf4abb1c614b
3222c2b2ace47d62a15bc96f240df961febb8b23
1786 F20110109_AABLWB xia_y_Page_42.txt
238e992162813f6bedcc6d7b0ed7affd
c55c4fc6456671e2c2596a51fabd5de0dfee8bea
F20110109_AABLRE xia_y_Page_51.tif
953f70be672f5e9eb4aaa03478f3c8cf
ff217ca3377eac51cc1a60d14e1c1e79542eb9e3
59567 F20110109_AABLMI xia_y_Page_67.jpg
00e594a5e26a1a44768bb1f59163a31c
3cc35cad818188b68e52312e73d5e98b601e7c83
2313 F20110109_AABLWC xia_y_Page_43.txt
e78e2a8a0b18e8dbc4c880a8e99e04bc
20ee219a74e5b6459c42d801ecb4b1bb9a743bd8
F20110109_AABLRF xia_y_Page_52.tif
2b60f01d71ef70467221e0456fc36fa9
5dcdf0fc4cf74646d42649cb334e80f240fc1134
61821 F20110109_AABLMJ xia_y_Page_68.jpg
f96541e8c6fa2963ec9f0f6619818a23
fd5f26de6565afd52a728a55892a11402e65c73b
1780 F20110109_AABLWD xia_y_Page_44.txt
6a2fdf4920ced691febf3eb271bc220b
c8ed7b52f169afc75ad9b235e6bef757dd15b488
F20110109_AABLRG xia_y_Page_53.tif
b4ce3186b593faa450df8df468d2a595
0124bd584958d7954e3715098c45349f0ea5f143
54967 F20110109_AABLMK xia_y_Page_69.jpg
0bc58d0c56e7023edddd348da1ca3f6d
81bbdc7bf6b708e0bc6a272bf88e9580433cbba9
F20110109_AABLWE xia_y_Page_45.txt
91a4c21c83bf40a095f642a515eb1456
fb347be01c3fa912cf69057c7e8412dda2e63cf3
F20110109_AABLRH xia_y_Page_54.tif
65d472b35a6e328a3e06fb599a96e1f9
c0f3de3caee8085c3cc4a5379c4efb234a5a3847
27275 F20110109_AABLML xia_y_Page_70.jpg
a87b32b0cf576a4b6e9a549f65430513
015e7a2a0f677c92a4b2bd96e8af6f9629f3d0f2
1870 F20110109_AABLWF xia_y_Page_46.txt
7a89b1eb2023516c728f7199d6c210af
87b97fb29683dbd55c633a7a82dc376fd1d2e56e
F20110109_AABLRI xia_y_Page_55.tif
cdbcafc553abfd842856b2c731807f51
b1ef8d89f5e201bb04ab0923bddc194b0a20052e
86938 F20110109_AABLMM xia_y_Page_71.jpg
5ea1bdbcf550c96032793fe7d305f4ed
c565d08baedcfd335a7b206195639e885616317a
1955 F20110109_AABLWG xia_y_Page_47.txt
23684fe65c7fd38ac814b326d42eb470
4644ef1412550e1ca0590848c04d4ea15d70c234
F20110109_AABLRJ xia_y_Page_56.tif
d0ee829065614af42d8161c4fd659800
b9ef4d1bba4100df3d39245e673487e8b8d52563
26055 F20110109_AABLMN xia_y_Page_72.jpg
6b2d4f620eed6c32df79d8734e45ed63
dc694928c4e52d5ac2f77799ee03b37f30be25d4
2418 F20110109_AABLWH xia_y_Page_48.txt
9b71cc5d17952ea7ce319be8ae07990a
7bb4f96d0226d0edd8e1e6f64ef28d80c87c8205
F20110109_AABLRK xia_y_Page_57.tif
2790898f26e91b21a2bebf0441cd9078
03a60424eda97548b346a15c0c58d6e6f450376c
85596 F20110109_AABLMO xia_y_Page_73.jpg
222fd8d55d935fe831b0b11d9220983c
16627e0f5bcfcd9ff1f60eed32508bc50d7f850a
1864 F20110109_AABLWI xia_y_Page_49.txt
a1f43f80eb0476d1cd947e94f3c80755
c4d7340a29b3bc918861e46da8317a6fcf54f8e6
F20110109_AABLRL xia_y_Page_58.tif
c1e8698d39f8f32d40f3b7960f960659
2e12ace24f0f43d32a73f55b3139297a59c4918b



PAGE 1

A DYNAMIC DATA/CURRENCY PROTOCOL FOR MOBILE DATABASE DESIGN AND RECONFIGURATION By YANLI XIA A THESIS PRESENTED TO THE GRADUATE SCHOOL OF THE UNIVERSITY OF FLORIDA IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF MASTER OF SCIENCE UNIVERSITY OF FLORIDA 2002

PAGE 2

Copyright 2002 by Yanli Xia

PAGE 3

ACKNOWLEDGMENTS I express my sincere gratitude to my advisor, Dr. Abdelsalam (Sumi) Helal, for giving me the opportunity to work on this challenging topic and for providing continuous guidance during my thesis writing. I am thankful to Dr. Joachim Hammer and Dr. Herman Lam for agreeing to be on my supervisory committee. I really appreciate Youssef Kaddouras help in proofreading my thesis. I also thank the other members in the Harris lab for their help. I would like to take this opportunity to thank my parents, my husband and my son, for their continued and encouraging support throughout my period of study and especially in this endeavor. iii

PAGE 4

TABLE OF CONTENTS Page ACKNOWLEDGMENTS ..................................................................................................iii ABSTRACT.......................................................................................................................vi CHAPTER 1 INTRODUCTION ............................................................................................................1 1.1 Challenges in Mobile Databases .....................................................................1 1.2 Related Work ...................................................................................................3 1.3 Organization of the Thesis ..............................................................................5 2 A MODEL FOR MOBILE DATABASES ......................................................................6 2.1 Interface Assumption ......................................................................................8 2.2 Scenarios of Mobile Hosts and Fixed Hosts ...................................................8 2.2.1 Connection Scenarios Between A Mobile Host and A Fixed Host .............8 2.2.2 Connection Scenarios Between Mobile Hosts ............................................9 2.3 Scenarios of Ad-hoc Network to Fixed Network ..........................................10 2.4 A Model for Mobile Databases .....................................................................11 3 GENERALIZED HOARDING AND SYNCHRONIZATION MECHANISMS .........15 3.1 Background ...................................................................................................16 3.2 Data and Currency Hoarding Modes .............................................................17 3.2.1 Currency Hoarding Modes ........................................................................17 3.2.2 Data Hoarding Modes ...............................................................................20 3.3 Currency and Data Synchronization Modes ..................................................22 3.3.1 Currency Synchronization Modes .............................................................23 3.3.2 Data Synchronization Modes ....................................................................25 3.4 Hoarding and Synchronization Algorithms ...................................................27 3.4.1 Definition of Work Sets ............................................................................27 3.4.2 Hoarding Algorithms .................................................................................29 3.4.3 Synchronization Algorithms .....................................................................30 iv

PAGE 5

4 METADATA MANAGEMENT FOR MOBILE DATABASES ..................................34 4.1 Categories of Metadata in Mobile Databases ................................................35 4.1.1 Connectivity ..............................................................................................35 4.1.2 Availability ................................................................................................36 4.1.3 Access ........................................................................................................37 4.1.4 User-defined Constraints ...........................................................................37 4.2 Metadata Collection in Mobile Databases ....................................................37 4.2.1 Focused Subset of Metadata ......................................................................37 4.2.2 Metadata Collection ..................................................................................39 5 DYNAMIC CURRENCY ALLOCATION AND REDISTRIBUTION .......................44 5.1 A Target of Currency Allocation ..................................................................44 5.2 Dynamic Currency Redistribution Referring to Metadata ............................46 5.2.1 Correctness Requirements of Currency Redistribution ............................46 5.2.2 Currency Redistribution ...........................................................................47 5.3 Ad-hoc Database Check-out/Check-in Currency ..........................................51 5.4 Creation and Retirement of Currency and Data ............................................52 6 SIMULATION ...............................................................................................................54 6.1 Simulation Assumption .....................................................................................54 6.2 Simulation Model ..............................................................................................55 6.3 Simulation Settings ...........................................................................................57 6.4 Simulation Results ............................................................................................59 6.4.1 Commit Rate and Commit Percentage ......................................................59 6.4.2 Mean Commit Delay .................................................................................62 CONCLUSIONS AND FUTURE WORK .......................................................................64 LIST OF REFERENCES ..................................................................................................66 BIOGRAPHICAL SKETC H .............................................................................................69 v

PAGE 6

Abstract of Thesis Presented to the Graduate School of the University of Florida in Partial Fulfillment of the Requirements for the Degree of Master of Science A DYNAMIC DATA/CURRENCY PROTOCOL FOR MOBILE DATABASE DESIGN AND RECONFIGURATION By Yanli Xia December 2002 Chair: Dr. Abdelsalam (Sumi) Helal Major Department: Computer and Information Science and Engineering Mobility is changing the way we design databases and their Database Management Systems (DBMS). For example the scenario in which all database users are ad-hoc users has been integrated in the Bayou and Deno projects. Both of them take an asynchronous, epidemic information flow and conflict avoidance-based (i.e., pessimistic) approach to ensure that all committed updates are serialized in the same order at all servers. Bayou uses a primary-copy scheme, while Deno takes a bounded weighted-voting one. In this thesis, we focus on flexible protocols for dynamic database design and reconfiguration. In particular, we introduce protocols and ideas that enable databases to be designed in such a way that their location, replication and even use semantics can be changed dynamically. We believe the flexibility of this approach is necessary given the uncertainty of user mobility. vi

PAGE 7

We introduce a dual data/metadata hoarding and synchronization protocol. We are especially focused on the currency type of metadata, which is a weight (vote) given to a replica. Data are hoarded via a variety of hoarding mechanisms with different hoarding semantics. Metadata record the changing characteristics of mobile hosts and currency is dynamically redistributed to fit the target. Primaries are allowed to be diluted, concentrated and transferred in the system. We borrow a bounded weighted-voting scheme from Deno and use it to do currency synchronization. We also use anti-entropy mechanisms to do data synchronization to eventually bring the database to a consistent state. We include a fixed network as the home of the database. An ad-hoc network checks out its desired data and checks them back in when they are no longer accessed by the mobile users. Finally, we conduct experimental evaluation using simulation to assess the benefits of our protocols. vii

PAGE 8

CHAPTER 1 INTRODUCTION 1.1 Challenges in Mobile Databases Since their emergence in the 1970s, wireless networks have become increasingly popular in the computing industry. This is especially true within the past decade, which has seen wireless networks being adapted to enable mobility. Mobile computing is the merger of advances in portable computing and wireless communication with the aim of providing seamless and ubiquitous services for mobile users. In mobile environments, database applications are enhanced with the useful features of wireless technology. However, mobile computing environments have severe resource constraints and unstable operating conditions. Compared to the wired network, the wireless medium is notable for its high cost, narrow bandwidth and low reliability. The wireless connection is usually weak and intermittent, causing frequent disconnection. Mobile hosts are usually resource poor, battery dependent, and susceptible to accidental damage or loss. Mobility is changing the way we design databases and their DBMS. Many software problems associated with data management, transaction management, and data recovery have their origin in distributed database systems. In mobile computing, however, these problems become more difficult to solve. Large-scale replication is provided to allow anytime/anywhere access. Data interests may change with shifting user context, so a new data management decision is needed. Due to the characteristics of mobile environment, mobile computing exposes key limitations of the traditional computing model [4]: 1

PAGE 9

2 1) Weak connectivity/frequent disconnection: state of wireless communication and cost issues. 2) Large-scale replication: device-local hoarding required due to availability when disconnected. 3) Close user interaction/feedback: allows negotiation, partial and preliminary results. 4) Long-running tasks: always a problem for ACID systems 5) Real-time constraints There are some projects related to databases in ad-hoc networks, such as Bayou [9, 23] and Deno [5, 6, 7, 16]. But homes of databases are usually fixed network. For example, members of a traveling salesman group may dial their head office to get new product information and put sales and order data into the companys home database; a botanist may wish to put her new sighting data into the laboratory database so that others may see it before her return; a UPS delivery needs to report the package information to the home office to make it available to the online searching system for customers. In any situation in which multiple databases in ad-hoc networks are used or in which there is a home-base database, we require replication to synchronize the data and operations between these databases. Users interests in data may change shifting context from time to time, place to place, so we need to track users state, based on position, time, history and workflow to form metadata to adapt to the new user context. In this paper, we focus on flexible protocols for dynamic database design and reconfiguration. We introduce a dual data/currency hoarding and synchronization protocol. Data are hoarded via P-, G-, or C-hoarding and accompanying hoarded currency indicates semantics of data. Metadata record the changing characteristics of mobile hosts and currency is dynamically redistributed to fit the target. Databases are designed in such

PAGE 10

3 a way that their location, replication and even use semantics can be changed dynamically. We believe the flexibility of this approach is necessary given the uncertainty of user mobility. We include fixed network as home of database. Finally, we conduct experimental evaluation using simulation to assess the benefits of our protocols. 1.2 Related Work Many mobile computing issues associated with data management, transaction management, and data recovery have their origin in distributed database systems. A distributed database is defined as a collection of multiple, logically interrelated database distributed over a computer network [22]. The existing distributed database systems are extended to support mobile operations (e.g., disconnection, caching, reconciliation, etc.). The work [12] of Jim Gray et al. showed that replication protocols go along two dimensions: master/group object ownership and lazy/eager update propagation. For master ownership, only primary copy can be updated, while for group ownership, any replica can be updated. Eager update propagation requires all replicas updated in a single transaction, and the lazy one propagates updates asynchronously. They argued that eager schemes are unsuitable for mobility due to frequent disconnections and proposed a two-tier lazy protocol for scalable replication. The solution approaches are as follows: 1) Multiple tiers of hosts: the high connectivity and resource-rich inner ring, land weakly connected, mobile, expendable clients. 2) Two classes of copies: servers retain copies of record and clients cache secondary (soft-state) copies. Reads see weaker-consistency (snapshot isolation) and updates happen without two-phase commit. Synchronization metadata are kept at clients and servers. Jajodia and Mutchler [15] and Jajodia et al. [29, 30, 31] improved Jim Grays approach using an adaptive data replication algorithm, which changes the replication

PAGE 11

4 scheme of the object as changes occur in the read-write pattern of the object. The algorithm continuously moves the replication scheme towards an optimal one, but this algorithm is designed for a distributed, wholly interconnected information environment, which is not proper for mobile environment. Lee and Helal [19] introduced a new mobile transaction model (HiCoMo) applicable to decision-making applications over aggregate data warehoused on mobile hosts. The model allows the aggregate data to be updated in disconnection mode, while guaranteeing a very high rate of commitment on reconnection. Epidemic information flow [2, 8] is used to propagate updates and drive the replicas toward consistency. Epidemic algorithms require few guarantees from the underlying communication system, hence proper to be used in mobile environments. Anti-entropy is an example of epidemic processes, exchanging database content with a peer to resolve any differences between them. CODA [18, 21] is a distributed file system with the ability to support disconnected operation for mobile computing. It employs two-tier data replication to get scalability: server replication and client side persistent caching of files. Write back caching is the scheme to reach consistency. SEER [17] is a predictive hoarding system for disconnected mobile operation. Briefly, it observes the user's file-access patterns while a mobile computer is connected to the network, and uses those to predict what files will be needed when the network is no longer available. It then arranges to have those files stored on the mobile machine in advance of disconnection.

PAGE 12

5 Bayou [9, 23] uses epidemic information flow via anti-entropy sessions. It is a more pessimistic approach and ensures that all committed updates are serialized in the same order at all servers using a primary-copy scheme. Updates can only be committed at the primary-copy server. Deno [5, 6, 7, 16] takes an asynchronous bounded weighted-voting scheme via epidemic information flow such that updates are committed in a decentralized fashion. Deno uses fixed per-object currencies for voting and data movement requires only pair-wise communication. Each replica is assigned a currency and total currency in the system is bounded. 1.3 Organization of the Thesis In chapter 2, we present a model for mobile databases that integrates previously proposed ideas such as ad-hoc and broadcast disks. Then we introduce data and currency hoarding and synchronization in chapter 3. In chapter 4, we give the categories of metadata and work on algorithms to manage metadata. Chapter 5 gives the details of a dynamic currency redistribution protocol based on the metadata. We then present some experiments to evaluate the merits of our protocol in chapter 6. Finally, we conclude our work and list future work in chapter 7.

PAGE 13

CHAPTER 2 A MODEL FOR MOBILE DATABASES Traditional database design is static. The question being addressed is how the database and applications that run against it should be placed across the sites [22]. There are two basic alternatives to placing data: partitioned (non-replicated) and replicated. Respectively, the two fundamental design issues are fragmentation and distribution. No matter which scheme is provided, however, it is static from the angle of the database design. Once data placing is determined, it will not be changed. A directory contains information about data items in the database is maintained. The definition of fragments and their placement determine the contents of the directory. Directory placement and contents influence concurrency control strategies as well as the processing of queries. With directory, data must be located first. The static database design limits flexibility of database applications. Many mobile computing issues associated with data management, transaction management, and data recovery have their origin in distributed database systems. However, mobility of mobile hosts on the network causes static data in stationary networks to become dynamic and volatile in wireless networks. In mobile database everything is dynamic, varying from sporadic accesses by individual users to particular data to continuous access of a particular data by a large group of user. This is the case from disconnected database access to broadcast disks. For broadcast data, due to the mobility of the mobile hosts, the content of any data to be broadcast should be dynamic and adaptive. Moreover, in an ad-hoc network, the users group and data interests are 6

PAGE 14

7 changing from time to time. Data partition, location and replication are always dynamic. These characteristics raise interesting issues for the design of mobile databases. CODA [18, 21] is a distributed file system with the ability to support disconnected operation for mobile computing. The Coda model is that there are many clients and a few servers. Only Coda clients can be used in disconnected and weakly connected mode to support mobile computing. Coda employs server replication and persistent client side caching of files. Directories and attributes are maintained for high performance. Moreover, file-system objects distribution in servers is static in Coda. Broadcast disk [4, 1, 27] is the proactive distribution of relevant data to large number of users. In order to match data/events to user interests and distribute the data to users, reliable delivery especially with movement and disconnection, broadcast scheduling should be dynamic to satisfy the users and adaptive to the changing context. The scenario where all database users are ad-hoc users has been integrated in the Bayou and Deno projects. Both of them take asynchronous, epidemic information flow and conflict avoidance-based (i.e., pessimistic) approach to ensure that all committed updates are serialized in the same order at all servers. Bayou uses a primary-copy scheme, while Deno takes a bounded weighted-voting one. Although there are above significant works on database issues, there is a need to reach a generic solution for dynamic mobile database design to combine distributed databases, broadcast disks and ad-hoc databases. Here we focus on flexible protocols for dynamic database design and reconfiguration involving fixed network. First we give connection scenarios of mobile hosts and fixed hosts, ad-hoc network to fixed network,

PAGE 15

8 then we introduce the concept of mobile databases and specify the configuration used in our system. 2.1 Interface Assumption A mobile host may have four network interfaces: 1) Strong connect interface (dock); 2) Weak connect interface (wireless); 3) Wireless ad-hoc network interface; 4) Broadcast receiver; Interfaces 2 and 3 are different in that interface 2 is used to connect with fixed hosts, while interface 3 is used to connect with other mobile hosts in ad-hoc network. 2.2 Scenarios of Mobile Hosts and Fixed Hosts In this section, the connection scenarios among mobile hosts and fixed hosts are given. 2.2.1 Connection Scenarios Between A Mobile Host and A Fixed Host Strong Connected (Docked) MH FH Weak Connected (Wireless) MH FH Disconnected MH FH Figure 2-1 Connection scenarios of a mobile host with a fixed host

PAGE 16

9 A mobile host may be strong connected (docked) with a fixed host when the mobile host backs home. A docked mobile host is equivalent to a fixed host in that it has access to the resources in the fixed network. Besides, it may perform hoarding directly from fixed hosts. A mobile host may be weak connected (wireless) with a fixed host when there is no existing wired connection, providing that it has wireless network connection interface. Due to cost and battery life, weak connection is normally periodic, lasting not much long. Most of the time, a mobile host is disconnected from the fixed network, working on local data hoarded before planned disconnection. For unexpected disconnection, a mobile host may seek to reconnect with a fixed host after failure recovery. When a mobile host is strong connected, we say the mobile host is homed, otherwise it is said mobile. 2.2.2 Connection Scenarios Between Mobile Hosts A mobile host may be weak connected with or disconnected from another mobile host. We say such mobile hosts are peers. Peer mobile hosts may communicate pair-wise such that each connection session only involves two peers. Weak Connected (Wireless) MH MH Disconnected MH MH Figure 2-2 Connection scenarios between mobile hosts

PAGE 17

10 When a mobile host is weak connected with one of its peers in the ad-hoc network, they may perform hoarding to get desired data, synchronize their updates, anti-entropy to eliminate their differences, etc. But all these should be done in an efficient manner. A mobile host is disconnected from its peer after information exchanges. Then it goes on working based on its local data until next connection. 2.3 Scenarios of Ad-hoc Network to Fixed Network As shown in the figure 2-3, an ad-hoc network may be all docked, half-docked or all undocked to the fixed network. All Docked: Ad-hoc Fixed network Half-Docked Ad-hoc Fixed network All Undocked Ad-hoc Fixed network Figure 2-3 Connection scenarios of ad-hoc with fixed network

PAGE 18

11 When all mobile hosts in an ad-hoc network back home, it is said the ad-hoc network is docked. A docked ad-hoc network joins the fixed network to form a bigger distributed system except that it performs hoarding before next mobile. If some of mobile hosts in an ad-hoc network back home and the others do not, it is said the ad-hoc network is half-docked. The docked mobile hosts are strong connected with the fixed network, while the others are weak connected. Moreover, the weak connected mobile hosts may get information from a broadcast server in the fixed network. The broadcast server continually broadcasts data that mobile hosts are commonly interested in. This way is called pushing. A pushing channel usually has good bandwidth. The scenario where all mobile hosts in the ad-hoc network weak connected with or disconnected from the fixed network is considered as all undocked. In this case, all mobile hosts leave home and they may perform pair-wise connection to exchange information as well as communicate with fixed hosts. Additionally, ad-hoc network may get pushed data from broadcast. 2.4 A Model for Mobile Databases A mobile host in mobile may communicate with only fixed hosts, no connection available between mobile hosts. In this case, data items reside in all such mobile hosts form a disconnected database. This configuration introduces the concept of ubiquitous data access. A mobile host may wish to communicate with other mobile hosts selected randomly or according to some constraints. Pair-wise connection is enough for such case. This gives the concept of ad-hoc databases. A mobile host in an ad-hoc database may connect with fixed hosts to do hoarding or synchronization.

PAGE 19

12 A broadcast server may be integrated into the fixed network and broadcast data that mobile hosts have common interests in. This introduces the concept of broadcast databases. A broadcast database usually contains public information such as weather, stock and financial reports. Mobile hosts grab such information from the air. Traditionally, database distributed in a fixed decentralized network is a distributed database. We envision that a mobile database should be defined as the union of disconnected database, broadcast disks, ad-hoc database and distributed database. This is because the dynamic nature of the mobile environment may require data to be reallocated or replicated. Mobile environment also may require users and replicas to be ad-hoc or disconnected from the network. Figure 2-4 shows the concept of mobile database. Broadcast disks MH MH Distributed Database MH Disconnected Database Ad-hoc Database Figure 2-4 Mobile database: a whole image

PAGE 20

13 For distributed database, there is significant body of previous work [22]. As to disconnected database, there are several projects on ubiquitous database access working on it [13, 20]. There are research efforts in broadcast disks [4, 1, 27]. Bayou and Deno do great work in ad-hoc databases. However, as far as we know, there is no work toward the whole image of mobile databases. In this thesis, our attention is focused on the scope of ad-hoc database and its interaction with distributed database. When the mobile hosts in the ad-hoc network are all docked into the distributed network, they can communicate with the fixed hosts in the distributed network and be treated as part of it. Our focus is on the ad-hoc network half-docked or all-undocked cases, in which databases need to be reconfigured and redesigned to adjust to the dynamic characteristics of the new mobile environment. When the ad-hoc network finished its work, it may return to the distributed network and become all docked again. A motivating example. Ad-hoc users and fixed users may have common interests in some data. For example, IBM salespeople Frank, Joe, and Nancy collectively cover the state of Texas, they might expect to be able to consolidate their sales data when they meet in Austin. While their manager in New York, Ronald, would like to know the results and decide sales in Florida. Bonnie, another manager in New York, needs the sales data to make a financial report. In this case, Frank, Joe, and Nancy may wish to hoard their interested data items and semantics that are able to indicate the primaries. They form an ad-hoc database and since they have the primary semantics, they may make updates commitment decision. Ronald and Bonnie are members of distributed database. They may get information of the up-to-date data from ad-hoc database, or may update the data items they have and inform ad-hoc users to see if the updates are acceptable. After the

PAGE 21

14 three-people team back, they return the primary to distributed database, i.e. primary is back home.

PAGE 22

CHAPTER 3 GENERALIZED HOARDING AND SYNCHRONIZATION MECHANISMS The mobile computing environment contains large number of low powered mobile hosts. The mobile hosts will often be disconnected due to power limitations, inaccessible communication channels, or as mobile hosts move between different cells. Replication will be essential in such environment, increasing data availability to mobile users: when a mobile host is disconnected, it can continue to process data stored locally. At the same time, replicated data can improve performance. In a mobile environment, it is important to have dynamic replicated data management algorithms that allow for the database to be reconfigured due to the dynamic nature of mobile environments. We introduce a dual data/currency hoarding and synchronization protocol to deal with replication and consistency issues in mobile databases. An ideal replication scheme would achieve four goals [12]: 1) Availability and scalability: Provide high availability and scalability through replication, while avoiding instability. 2) Mobility: Allow mobile nodes to read and update the database while disconnected from the network. 3) Serializability: Provide single-copy serializable transaction execution. 4) Convergence: Provide convergence to avoid system delusion. We take a dual data/currency hoarding and synchronization approach. Data hoarding is done by mobile or fixed hosts to hoard data requested by their applications. Currency hoarding accompanies data hoarding and the amount of currency indicates 15

PAGE 23

16 semantics of data. Currency synchronization is a weighted voting process to collect plurality of currency for an update to commit. Data synchronization is performed by anti-entropy information flow, propagating commitment updates in the system. 3.1 Background The concept of currency is introduced by research efforts of [26, 28, 32]. Deno [5, 6, 7, 16] uses currency extensively to data replication and voting scheme in mobile environments. What is currency? Simply, currency is a number associated with each replica as a form of priority. The amount of currency held by a given replica is used as that replicas weight during voting rounds. Anti-entropy is important to avoid system delusion. The goal of anti-entropy is for two replicas to bring each other up-to-date. In Bayou [9, 23], the storage system at each replica consists of an ordered log of writes and a database that results from the in-order execution of these writes. Anti-entropy needs to enable two replicas to agree on the set of writes stored in their log. In Deno, election information flows from voter to voter through anti-entropy sessions. An anti-entropy session is a uni-directional flow of information specifying elections that have been won, and votes in the current election. CODA [18, 21] is a distributed file system with the ability to support disconnected operation for mobile computing. SEER [17] is a predictive hoarding system. Bayou and Deno projects concern only pure ad-hoc scenarios. There is no general hoarding and synchronization mechanisms working on mobile databases. In this chapter, we try to give the generalized hoarding and synchronization mechanisms. The purpose of the mechanisms is to drive data and currency to flow in the mobile databases to dynamically design and reconfigure it.

PAGE 24

17 3.2 Data and Currency Hoarding Modes Why hoarding? For a mobile host, connection is expensive in that it expends bandwidth, battery life, hand off, etc. Moreover, planned and unexpected disconnections are frequent, while some applications require access to data items anywhere/anytime/anyhow. Lack of access to a data item may halt work on a particular task or even make the computer unusable. Therefore, hoarding is very necessary to get good data availability in that requested data items are saved on the local storage prior to disconnection. We use a dual data / currency hoarding scheme, in which semantics of data is indicated by the amount of currency. Data and currency flow in the system to meet different needs of different users. The configuration of the database is dynamic. 3.2.1 Currency Hoarding Modes Any shared data item in mobile databases is replicated as a primary and a set of copies, i.e. logical data X = a physical primary of X + a number of physical copies of X. The primary and copies all hold some amount of currency and may reside in any hosts. The summary of currencies for each data is fixed: 100. Every data hoarding is accompanied with currency hoarding. The amount of currency held by a given primary or copy is used as the weight of that primary or copy during voting rounds. Additionally, the amount of a datas currency indicates the semantics of the data, defined as following: 1) Primary currency: If the amount of currency is greater than 50, it indicates that the replica is a primary. A primary has the majority of currency and hence has the power to commit an update. 2) Updateable-copy currency: If the amount of currency is greater than 0 but less than 50, the copy holding such currency is an updateable copy. An updateable copy may propose a local update and start an election to collect plurality of currency votes to commit the update.

PAGE 25

18 3) Read-only copy currency: If the amount of currency is equal to 0, the replica is a read-only copy. It may be involved in the anti-entropy progress to get the up-to-date copy of the data, but it is not allowed to issue an update locally and it has no voting weight either. 4) Undefined currency: If there is no definition of currency for a data item, it means a host does not hold any copy of the data at all. An undefined currency is represented as . A copy currency is either updateable-copy currency or read-only copy currency. There is no negative currency. An objects currencies are flowed in the network via pair-wise currency hoardings. The total amount of currencies is fixed at any time. Therere three modes of currency hoarding corresponding to data hoarding: currency G-hoarding, currency P-hoarding, and currency C-hoarding. Currency G-hoarding Before hoarding, the sender holds a primary currency. After b (0 b < a) currency goes to the receiver, the sender still owns a primary currency. Since the total currency for each object is fixed, its definitely that the receiver owns a copy currency. Currency P-hoarding Before hoarding, the sender holds a primary currency. After b (b 50 c) currency goes to the receiver, the sender loses the primary currency and only holds a copy currency. The receiver now gets majority of currency and becomes the new primary holder.

PAGE 26

19 Currency G-Hoarding: 50 + a c b( b < a ) 50 + a b c + b Currency P-Hoarding: 50 + a c b(b > max(a, 50 c) 50 + a b c + b Currency C-Hoarding: a c b (b a < 50) a b c + b Figure 3-1 Currency hoarding Currency C-hoarding Before hoarding, the sender holds a copy currency. After b (b a<50) currency goes to the receiver, the sender holds a copy currency. If b is equal to a, then the copy in the sender becomes read-only. The receiver now gets more currency. There are three scenarios involving primaries that worth being noticed: primary dilution, primary concentration and primary transfer. Primary dilution: For a sender with a primary currency, if a currency hoarding-out results in a less than 50 currency left, we say the primary is diluted at the sender. Primary concentration:

PAGE 27

20 For a receiver with a copy currency, if it collects a primary currency after a currency hoarding, as we show above in currency C-hoarding, if (c + b) > 50, we say the primary is concentrated at the receiver. Primary Dilute: 50 + a c b( b > a) 50 + a b c + b Primary Concentrate: a c b(50-c
PAGE 28

21 After hoarding: Sender (object, current sender semantics), Receiver (object, original sender semantics, receiver semantics) Where sender is the host that a primary or copy is hoarded from; receiver is the host that receives the primary or copy; Sender and receiver might be fixed hosts or mobile hosts. Additionally, broadcast server is the sender for hoarding in broadcast disks. Sender/receiver semantics means the sender/receiver holds the primary or a copy of the object. In the figure below, X P is the primary of X and X C is a copy of X. - means no primary or copy of data X is available in hosts. G-Hoarding: P-Hoarding: C-Hoarding: XC XP XC XC XC XC XP XP XP Figure 3-3 Data hoarding General hoarding (G-hoarding): Sender owns the primary of an object, and receiver hoards a copy from the sender. After G-hoarding, sender still owns the primary. Before hoarding: Sender (object, Primary) After hoarding: Sender (object, Primary), Receiver (object, Primary, Copy)

PAGE 29

22 Primary hoarding (P-hoarding): Sender owns the primary of the object, and receiver hoards the primary from the sender. After P-hoarding, the primary is transferred from the sender to the receiver and the one in the sender becomes a copy. Before hoarding: Sender (object, Primary) After hoarding: Sender (object, Copy), Receiver (object, Primary, Primary) P-hoarding can only be done via direct hoarding. It is not allowed to P-hoard data from broadcast. Copy hoarding (C-hoarding): Sender owns only the copy of the object, and receiver hoards a copy from the sender. After C-hoarding, both the sender and the receiver held copies of the object. Before hoarding: Sender (object, Copy) After hoarding: Sender (object, Copy), Receiver (object, Copy, Copy) 3.3 Currency and Data Synchronization Modes Any mobile host or fixed host may issue an update to its local data with an updateable-copy currency. Such an update is called a tentative update. To commit a tentative update, we borrow Denos weighted-voting scheme to perform currency synchronization: a mobile host issues an election to corner plurality of currency to commit its update. Data synchronization is done by anti-entropy sessions. In terms of data synchronization, an anti-entropy session is a unidirectional flow of information specifying elections that have been won and propagating the winner updates. Version vectors are used to compare the differences between the communicating hosts. The state of database will reach consistence eventually via anti-entropy.

PAGE 30

23 3.3.1 Currency Synchronization Modes The idea of currency synchronization comes from that of quorum in distributed databases. Replication of data is commonly used in distributed databases to increase the availability of services. In most cases, the consistency of the data must be maintained despite node failures and/or network partitions. This can be achieved by requiring that, in order to succeed, read and write operations obtain permission from certain sets of replicas. These sets, called read and write quorums, are defined in such a way that any two write quorums as well as any read and write quorums have at least one node in common. Then, no two writes can succeed simultaneously thus excluding the possibility of write conflicts. In addition, if every write performs on all replicas from a quorum, a successful read operation is guaranteed to see at least one most recent replica of the data. A currency quorum for an object consists of a set of replicas whose currency summary is the majority of total fixed currency. An update should be accepted by a currency quorum to get commitment. In this way, no two updates can succeed simultaneously thus avoiding the possibility of conflicts. A primary has the currency greater than 50, which forms a currency quorum, thus have the super power to commit an update. The definition of a currency quorum may be extended to compose a set of replicas whose currency summary is the plurality of total fixed currency. When the majority currency is unavailable but a set of replicas hold a currency summary that is greater than that of all the other sets of replicas, it is said that the plurality of currency form a currency quorum. Such currency quorum has the same power to commit an update. For example, three sets of replicas get currencies as 40, 30 and 30. None of them can reach a majority

PAGE 31

24 since the total is already 100. Then the set with the plurality currency of 40 gets its update to commit. Voting to collect currency to commit updates: We assume a replication model in which data do not need to be replicated at all hosts and multiple data can be replicated at the same host. A mobile host hoards data before disconnection and reads local data and/or issues tentative updates. A fixed host may issue tentative updates too. If the host holds the datas primary currency, a tentative update may get committed at once. Otherwise, a tentative update seeks being accepted globally by all the other hosts in the system. It is necessary to collect the majority or plurality of total currencies to commit the tentative update. This process is done by asynchronous weighted-voting scheme. We borrow it from Deno and extended it to include cases of distributed database and broadcast disks. An election is issued when a host decides to run to collect currencies to commit its tentative update. Any election may have multiple candidates, which represent logically concurrent tentative updates. Candidates from different elections might exist in the system at the same time. A mobile or fixed host holding a non-zero currency for an object X is a voter for elections of X. A voter becomes a candidate if it has a tentative update and has not voted its currency to other candidates. A candidate always votes its currency for itself. Each voter independently collects votes from other voters and deduces outcomes. Voter V i maintains following information for each object: 1) V i .completed: the number of elections completed locally. 2) V i [j]: index of candidate voted for by V j in V i s current election, or unknown, i.e. V i has not yet seen a vote from V j

PAGE 32

25 3) V i .currency[j]: currency voted by V j in V i s current election, or unknown. A candidate C j wins V i s current election when: 1) votes (V i j) > 50, or // C j gathers majority of voting currencies 2)k j: votes(V i k) + uncommitted(V i ) < votes(V i j), //C j gathers plurality of currencies or: (votes(V i k) + uncommitted(V i ) = votes(V i j)) and (j
PAGE 33

26 comparing the version number of a data item to that of the hosts anti-entropy partner. The one has a larger version number will bring the one with a smaller version number up-to-date. When a tentative update is issued, it gets a locally monotonically increasing tentative version number. Upon this update gets committed via currency synchronization, a globally monotonically increasing committed number is assigned. As it propagated via anti-entropy, all other replicas know the committed update and increase their committed version numbers. A host can choose its anti-entropy partner at random or based on other knowledge, such as network characteristics or hint of location of primary. The pair-wise anti-entropy protocol is designed to be uni-directional. One host brings anther one up-to-date by propagating those updates not yet known to it. The protocol relies on the theory of epidemics to ensure that committed updates eventually propagate to all other replicas [8]. Therefore, the database states will eventually reach consistent. In this way, data synchronization is done. An updates life cycle. From the above description about data/currency synchronization, we can see that the life cycle of an update that survives an election is following: A host issues a tentative update The host becomes a candidate in an election Updates and votes are propagated in a pair-wise fashion Updates gather votes as they pass through hosts

PAGE 34

27 An update commits when it gathers majority or plurality of votes (other tentative updates are aborted) Update commitment information is propagated to reach all hosts eventually via anti-entropy sessions. 3.4 Hoarding and Synchronization Algorithms 3.4.1 Definition of Work Sets We first give definitions of work sets that will be used in pair-wise connection sessions. The Hoarded Set (HS) for a host consists of primaries and copies hoarded, for which currencies are defined, i.e. greater than or equal to 0. The Data Sync Set (DSS) includes primaries and copies with updates committed. For read-only copies with zero currencies, committed updates made elsewhere should bring the read-only copies up-to-date. The Currency Sync Set (CSS) is composed of primaries and copies with tentative updates in election, which hold non-zero currencies. The Request Set (RS) consists of data requested by applications in a mobile host but not hoarded yet, i.e. currencies are undefined. The Currency Redistribution Set (CRS) includes primaries and copies that need adjust their currencies via currency exchange referring to metadata, which will be detailed in chapter 4. The Global Work Set (GWS) is a logical set, which is the union of HS and RS of all hosts in the database system. For a host, there are following relations among its work sets: DSS HS GWS CSS HS GWS CRS HS GWS

PAGE 35

28 HS RS = b DSS, CSS and CRS may or may not have pair-wise intersections. The sets for a host are shown as following: Global Work Set HS DSS CRS CSS RS Figure 3-4 Relation of work sets The above definitions are used in hoarding and synchronization algorithms. Upon each pair-wise connection, there are four tasks to do in order: 1) Data synchronization: propagate committed updates in DSS via anti-entropy. 2) Currency synchronization: collect voting currencies for tentative updates in CSS. 3) Data hoarding and accompanied currency hoarding: hoard requested data in RS, and allocate currency. 4) Currency redistribution: redistribute currencies for data in CRS between peers. Tasks 3 and 4 need to refer metadata, which is the topic of chapter 4. Currency redistribution is focused in chapter 5. For broadcast, only tasks 1 and 3 are performed. Moreover, the hoarding currency is 0 in task 3.

PAGE 36

29 3.4.2 Hoarding Algorithms Data hoarding is always accompan ied by currency hoarding (although in broadcast, the hoarding currency is 0), but not vice versa. The amount of currency dedicates semantics of data. Data semantics may be changed via currency exchange. 3.4.2.1 Direct Hoarding via Pair-wise Communication Assuming that host S is the sender and host R is the receiver in the hoarding session. The algorithm that R hoards data and currency from S is following: For each data item X in R.RS //R.RS: request set of R If X S.HS (hoarded set of S) and R is authorized to hoard X S sends data X to R //R hoards data from S R.X.tentativeVersionNumber = 0 R.X.committedVersionNumber = S.X.committedVersionNumber //currency hoarding R consults S to decide initially allocated currency C S.X.currency -= C //decrease currency from sender R.X.currency += C //increase the same amount of currency //copy election and voting information R.X.completed = S.X.completed //completed # of elections R.X.V i [r] = S.X.V i [s] //R votes for the same candidate as S, or unknown, i.e. not vote yet. r and s are index of R and S, i is the current election that is active. R.RS = R.RS {X} //remove X from request set of R R.HS = R.HS {X} //add X to hoarded set of R In the above algorithm, the same amount of currency is decreased from the sender and increased at the receiver to maintain th e fixed total currency per object. The receiver votes for the same candidate as the sender if sender voted, or unknown if the sender has not done so. The number of completed elections is actually the committed version number of the data.

PAGE 37

30 3.4.2.2 Hoarding via Broadcast Only committed versions of data are allowed to broadcast. Any host hoards data from broadcast can only get read-only copies, i.e. currency of data hoarded from air is always 0. Assuming that host R is the receiver in the hoarding session, R hoards data and currency from broadcast server B using following algorithm: While R is listening to broadcast If the current broadcasted data item X R.RS (request set of R) R grabs data X from the air //R hoards data from broadcast R.X.tentativeVersionNumber = 0 R.X.committedVersionNumber = B.X.committedVersionNumber //currency hoarding R.X.currency = 0 //R is assigned a read-only copy currency //copy version information R.X.completed = B.X.completed //the number of completed elections is actually the committed version number of data X R.RS = R.RS {X} //remove X from request set of R R.HS = R.HS {X} //add X to hoarded set of R There is no need to copy election a nd voting information in hoarding via broadcast, because data copies hoarded from broadcast are read-only copies with zero currencies, which have no right to vote. Read -only copies may change their semantics to updateable copies or even primaries via currency exchanges detailed in chapter 5. 3.4.3 Synchronization Algorithms Data hoarding is always accompanied with currency hoarding, while data synchronization is separated from currency synchronization. Voting scheme is used to perform currency synchronization, and data s ynchronization is done via anti-entropy after currency synchronization is finished. So we talk about currency synchronization first.

PAGE 38

31 3.4.3.1 Currency Synchronization Currency synchronization is performed when two hosts, say sender S and receiver R, get connected. Synchronized currencies flow from S to R and collect more amount if there are compatible currencies in R. It is said currencies are compatible if they vote for the same candidate in current election or at least one of them is unknown. For a data item X, if both S and R know the most recent committed version number of X, and S has voted for current election of X while R has not, then R votes for the same candidate as S. Data synchronization will bring previously committed information from S to R, so we need not worry about that S and R have different most recent committed versions. For each data item X S.CSS // X is seeking currency synchronization j = the index of the candidate that S votes for in the currency election of X If X R.HS // R has a replica of X If R.X.V r [r] is unknown // R has not vote for current eletion R.X.V r [r] = j Get the vote information of other hosts unknown to R from S Update R.X.Votes(V r ,k) =R.X.V =ni1 r .currency[i] s.t. R.X.V r [i] == k, for each k = 1 .. n Update R.X.V r .uncommitted l = max {R.X.Votes(V r k)}, where k = 1 .. n If R.X.Votes(V r l)> 50 //majority of currencies Award l as election winnerof X Else for each other candidate t // find plurality of currencies If R.X.Votes(V r l) > R.X.Votes(V r t) + R.X.V r .uncommitted Award l as election winner of X There are following work to do when l is awarded as election winner of X: R.X.committedVersionNumber ++ R.X.committed[R.X.committedVersionNumber] = l R.X.CSS = R.X.CSS {X} // remove X from currency sync set since currency sync of X is done R.X.DSS = R.X.DSS {X} // add X to data sync set

PAGE 39

32 Currency synchronization cannot be performe d via broadcast, because there is no effective currency flow in broadcast (only zero currencies in broadcast). 3.4.3.2 Data Synchronization Data synchronization is performed via anti-entropy in pair-wise connection or broadcast. Committed updates are propagated instead of committed database contents. The reason is that the amount of data propagated during data synchronization is proportional to the update activity at the re plicas instead of being dependent on the overall size of the data being replicated. Thus, when the database size is much larger than the database updates, the bandwidth required fo r the execution of the protocol is reduced. Furthermore, the propagation of update opera tions avoids any ambiguity introduced by the creation and deletion of replicated objects [23]. Protocols based on the exchange of deltas or differences in data values require additional mechanisms to correctly handle this ambiguity because the existence of a value at one replica and the lack thereof at another cannot correctly identify whether the value is new or it has been deleted. Data synchronization via anti-entropy by pair-wise connection Assuming sender is S and receiver is R. For each data item X S.DSS // X is known by S as committed If X R.HS and R.X.committedVersionNumber < S.X.committedVersionNumber R performs each committed update unknown to it R.X.committedVersionNumber = S.X.committedVersionNumber R.X.CSS = R.X.CSS {X} //election winner got awarded elsewhere Data synchronization via anti-entropy by broadcast Assuming the broadcast server is B and the receiver is R. While R is listening to broadcast If the current broadcasted data item X R.HS R grabs data X from the air

PAGE 40

33 If R.X.committedVersionNumber < B.X.committedVersionNumber R performs each committed update unknown to it R.X.committedVersionNumber = B.X.committedVersionNumber If X R.X.CSS R.X.CSS = R.X.CSS {X} //election winner got awarded elsewhere. Data synchronization by broadcast will si gnificantly speed up the process toward database consistency in that all listeners may get the commitment information at the same time and need not wait for the lazy propagation.

PAGE 41

CHAPTER 4 METADATA MANAGEMENT FOR MOBILE DATABASES Recent advances in wireless networking technologies and the growing success of mobile computing devices are enabling new issues that are challenging to mobile database designers. Mobile hosts have to deal with planned or unexpected disconnections when they mobile; they discover other hosts in ad-hoc manner; they are likely to have scarce resources such as low battery life, slow processor speed and limited memory; their applications are required to react to frequent changes in the environment such as new location, high variability of network bandwidth; their data interests are changing from time to time and from location to location; even data semantics in mobile hosts are varying according to data access patterns, connection duration and disconnection frequencies, etc. All of these require a dynamic database design and reconfigure scheme. In the past decade, there are some technologies like middleware technologies have greatly enhanced the design and implementation of distributed applications [10]. They successfully hide away many requirements introduced by distribution such as heterogeneity, fault tolerance, resource sharing, and etc. But these technologies have been designed for static distributed systems built with fixed networks. They are not suitable for the dynamic characteristics of mobile environment. For example, static distributed systems assume high bandwidth connection and constant availability. While in mobile environments, low bandwidth and disconnection are normal rather than unexpected. Mobile databases have to be aware of and adapt to the varying contexts such as fluctuating network bandwidth, access patterns, decreasing battery power, location 34

PAGE 42

35 changes and so on. In order to dynamic design and reconfigure the mobile databases, it is necessary to use metadata to record the changing context and adjust the data distribution. Metadata is the activity styles and constraints data of mobile hosts. It consists of connectivity, availability, data access patterns and user-defined constraints. The metadata of a mobile host reflects its priority to hoard data in the network and may be mapped to some amount of currency. The roles of metadata include: 1) Identify data user cares about (Domain): What data interests me? 2) Specify relative worth of data (Utility): What is its relative worth? 3) Indicate power of mobile host (Priority): Whats my activity pattern? In this chapter, we first give the general categories of metadata in the mobile databases. Then we focus on a subset of metadata and talk about management algorithms. 4.1 Categories of Metadata in Mobile Databases Generally, metadata in mobile databases is composed of data of connectivity, availability, data access patterns and user-defined constraints. 4.1.1 Connectivity In mobile databases, connectivity of a mobile host is the ability to connect to or communicate with another mobile host or fixed host. There are several aspects related to connectivity: 1) Connection status: strong connected, weak connected or disconnected? 2) Interconnectivity: Is a mobile host connecting with another mobile host or a fixed host? In the past time period, how many hosts did this mobile hosts connect with? 3) Bandwidth: the capacity for data transfer between the two hosts in their communication.

PAGE 43

36 4) Duration: the time during which connection is available. Connection duration in a time period is the summary of connection time. 5) Discontinuity: disconnection frequencies, and periods between connect durations. This parameter represents the lack of connection of mobile hosts. For example, in a one-hour period, two mobile hosts both have 30 minutes connection time, but the one that has 5 disconnections has different connectivity from the other has no disconnection. 6) Time pattern: statistics data about when a mobile is most likely to connect. For example, does it usually connect in weekdays or weekends, am or pm? 4.1.2 Availability Availability shows us what kinds of data are available in a mobile host, how fast and where it is, and the robustness. 1) Data semantics: according to the semantics represented by currencies, there are four levels of data semantics: Primary: the replica has a primary currency. Updateable copy: the replica has an updateable copy currency. Read-only copy: the replica has a read-only copy currency. Unavailability: the amount of currency is undefined at a mobile host, which means no such data is currently hoarded in. 2). Delay: there are two kinds of delays: one is query delay, which is from the time that an application raises a query to the time that it receives reply. The other is update commit delay, which is from the time an application issues a tentative update to the time when the application gets to know the commitment of its update. 3). Locality: where is a mobile host? Is it in the center, edge, or periphery of a particular region? We may use the triangulation teemingness to get coarse location data. Soon every device in the universe will have a GPS, so it is even possible to know the precise location of a mobile host. What a user cares about might changes radically depending on where he or his possessions are. 4). Reliable and failure recovery: is this mobile reliable? Whether and how fast is it able to recovery from failures? 5). Ability: how much is a mobile host able to do? For example, how much is its memory and how long is the battery life?

PAGE 44

37 4.1.3 Access Access represents data interests and satisfactory with the system from the point of view of applications or clients of a mobile host. 1). Hot data: who is the hottest? It may be evaluated referring to the read and write frequencies. 2). Tentative update frequency: the number of tentative updates issued by a mobile host. 3). Update commit rate: the number of tentative updates having got committed in a time period. 4). Update commit delay: the mean time of the commit delay for a mobile host. 5). Query satisfactory: what is the rate of reply to request? 4.1.4 User-defined Constraints Besides the metadata collected from runtime, users may specify some parameters that may affect the database distribution. For example, a user may specify his patience of waiting for a query reply. Another example is a team leader may have more priority in data semantics than his team members when they travel out to support their clients. 4.2 Metadata Collection in Mobile Databases 4.2.1 Focused Subset of Metadata As described in the previous section, there are quite a number of categories of metadata in mobile databases. It is impractical for us to maintain all of them at this time since there is much work to do and it is out of the scope of this thesis. Therefore, we just focus on a subset of the categories and choose those of them that are good enough to show the benefits of metadata and can be maintained with low overhead. Since the cost is low, it is more efficient to refer to the metadata to dynamically design and reconfigure mobile databases. The focused subset of metadata is given below:

PAGE 45

38 1) Connection duration 2) Disconnection frequency 3) Access statistics: query and tentative update frequencies 4) Commit rate, and 5) Commit delay. Here the connection status, duration and disconnection frequencies are metadata of mobile hosts, and the others are metadata of data items, which needs to be maintained for each data item in a mobile host. The chosen subset of metadata has significant impact to behaviors of mobile databases. Due to the weak and intermittent wireless connection, the cost of communication bandwidth and frequent disconnection, static data and currencies assignment will hurt the performance of mobile databases. For example, if a mobile host changes its connection statistics from strong connection, long duration to weak connection, short duration, should it have the same currency as before? No. It is better to give some of its currency to other mobile hosts that have better connection so they have more power to access and commit data, hence improving the database performance. The metadata of connection status, connection duration and disconnection frequency give the connection statistics of a mobile host. It is important to collect such metadata to reconfigure mobile databases. The metadata of access statistics and commit delay plays an important role in database reconfiguration. The hotness of data items is pointed out by access statistics. If the access is becoming more frequent than before, it means the data here is becoming hotter and needed more heavily by applications. The currency of data should flow to the

PAGE 46

39 place where the data are accessed more frequently. Commit delay and commit rate may be used to indicate the satisfaction of applications to the services of mobile databases. A mobile host with high priority needs to commit more updates as much as rapid. Such mobile host should get more currency, i.e. the mobile databases are reconfigured. 4.2.2 Metadata Collection To collect metadata, a monitoring scheme is needed to record what happens in a mobile host. Sliding window scheme is used to implement incremental metadata collection. A sliding window is a time frame with a predefined time interval, and the end point of the frame being the current real time. Window width is the time duration of the sliding window. It might be more precise to use different width of time sliding windows to different metadata since they may have different time characteristics. While for convenience and simplicity, we use the same constant width of sliding window for all metadata involved. Events in a sliding window include connection, disconnection, read, tentative updates and update commitment. Such events are logged in the time order that they occur. Since the capacity of a mobile host is limited, we cannot afford to storage them all from the very beginning. So the metadata collection algorithm is designed to log only the events in the time range of a sliding window. The log is called bounded window log. Sliding windows consume events as well as store them. When an event occurs, if the size of the sliding window has not reach its limit, the event is logged and its effect is reflected to the metadata. If the sliding window grows to its upper limit, an old event is retired and its effect is eliminated from the metadata when the new event is added. In this

PAGE 47

40 way, the metadata always remember the effects of events in the most recent bounded history. Figure 4-1 gives an example of sliding windows for a mobile host. Figur`e 4-1 Time sliding windows t0 t5 t10 t15 t1 t2 t3 t4 t6 t7 t8 t9 t11 t12 t13 t14 | | | | | | | | | | | | time Con H(Y) DisC Q(X) Con H(X) R(X) R(Y) W(X) Com(X) R(X) DisC sliding window wk sliding window wi As shown in Figure 4-1, the x-axis represents time. The two dashed rectangles are marked as sliding windows w i and w k w i is from t 0 to t 10 and w k is from t 5 to t 15 The events are recorded in these two sliding windows as: connect (t 1 ), disconnect (t 3 ), connect (t 6 ), read X (t 8 ), read Y (t 9 ), tentative update X (t 11 ), commit update X (t 12 ), read X (t 13 ), disconnect (t 14 ). In this figure, G-hoarding Y (t 2 ), request X (t 4 ) and C-hoarding X (t 7 ) will not be logged as metadata of the mobile host. They are put there just to show when they occur. The events happened are recorded in a log. Log length is the time duration from the first event to the last one in the log. The algorithm to collect metadata at a mobile host is given as following: While (true) If an event e comes at time t // Log the event add e to the log switch (e) case connect: save connect status and connect start time case disconnect: save connect status and connect end time increment duration by the real connection time

PAGE 48

41 increment disconnect frequency by 1 case read: increment read frequency of the accessed data item case tentative_update: increment tentative update frequency of the updated data item save the issue time of the tentative update case committed-update: increment commit update frequency of the updated data item save the commit time of the tentative update calculate commit delay of this update calculate the mean commit delay calculate commit rate If log length is greater than the length of a sliding window t start1 = the start time of the previous window t start2 = the start time of the current window For an event e happened at time t t [t start1 t start2 ) // Eliminate effects of the event switch (e) case connect: t disconnect = the time of disconnection for e if t disconnect t [t start1 t start2 ) decrement duration by (t disconnect t) delete the disconnection event from the log decrement disconnect frequency by 1 else decrement duration by (t start2 t) case disconnect: decrement duration by (t t start1 ) decrement disconnect frequency by 1 case read: decrement read frequency of the data item by 1 case tentative_update: decrement tentative update frequency by 1 case committed_update: decrement commit update frequency by 1 decrement commit delay calculate the mean commit delay calculate commit rate Delete e from the log In the above algorithm, the mean commit delay for each data item is maintained as the total commit delay divided by the commit update frequency in the current time sliding window. The metadata that is used in currency redistribution includes connection

PAGE 49

42 duration, disconnect frequency, read frequency, tentative update frequency, update commit rate and the mean commit delay. It is clear from the algorithm that the overhead to collect metadata for a mobile host is trivial. The main overhead is the I/O cost to store the event and update metadata when an event occurs. The storage of the metadata and events needs only a couple of disk pages that is very small comparing to the capacity of the mobile hosts. Other overhead is just some CPU cycles. There is no message cost since it happens totally locally. Therefore, the overhead to collect metadata for mobile hosts is very small and the potential benefits may well worth the effort. So far we have talked about local metadata for mobile hosts. Logically, global metadata is the union of all local metadata and it is decentralized. To form global metadata, local metadata may be piggybacked with anti-entropy messages to get to be known by all the hosts in the system. For ad-hoc databases, it is performed in a decentralized manner to collect metadata and redistribute currency via pair-wise communication. While in distributed databases, global metadata is more powerful to do reallocation in the point of the view of the whole system. For a fixed host in the distributed network, the focused subset of metadata mainly includes access statistics, the rate and delay to commit updates. The algorithms to get such information are similar to those for mobile hosts. Such local metadata is maintained for each data item at each fixed host and the union of local metadata is the global metadata. The union operation may be performed explicitly at request of a fixed host, or local metadata may be piggybacked with anti-entropy messages to propagate to other hosts.

PAGE 50

43 Now with the metadata in hand, it is ready to refer it to redistribute currency. It is addressed in the next chapter.

PAGE 51

CHAPTER 5 DYNAMIC CURRENCY ALLOCATION AND REDISTRIBUTION As stated in previous chapters, traditional distributed databases are static in that data allocation is determined and will not be changed. But the dynamic characteristics of mobile environment require that mobile databases are designed and reconfigured in a dynamic manner. The varying characteristics are recorded as metadata. In the mobile databases, the semantics of a data replica is indicated by the amount of currency. Furthermore, the semantics may be changed to adapt to the environment characteristics and database accesses. Metadata is referred to determine the data semantics in that the amount of currency is redistributed and thus data replicas are reallocated. In the previous chapter, metadata is classified and the collection algorithms are given. This chapter is focused on how to do currency redistribution referring to metadata. 5.1 A Target of Currency Allocation There are a large number of categories of metadata in mobile databases as described in section 4.1. This thesis is focused on a subset of them: connection duration, disconnection frequency, statistical data of accesses, update commit delay and commit rate. To allocate currency while taking advantages of metadata, a policy of assigning weights to metadata and mapping it to currency is needed. All the database members have to agree to the weight assignment policy to metadata. Intuitively, positive weights should be given to the metadata of connection duration, read frequency and tentative update frequency. It is obvious that a mobile host with longer connection duration, more 44

PAGE 52

45 frequent read/write accesses and higher commit rate plays a more important role and should get more currency. While the metadata of disconnection frequency and commit delay should be assigned negative weights since they reveal the inability of a mobile host. These numbers of weights may be customized according to the expected performance and requirements of the system. The weight of a replica is the summary of production of metadata weight and the value of metadata, which is composed of two parts: one comes from metadata of the mobile host i.e. connection duration and disconnection frequency, the other consists of weights of metadata of the replica, i.e. read frequency, tentative update frequency, commit update frequency, commit rate, and mean commit delay. Weight of a replica X 1 is defined as W(X 1 ) = where M is the union of sets of metadata for the replica and metadata for the mobile host where the replica resides, and w(m) is the weight of metadata m. tMmmwm)(* The mapping of currency to weight is in direct proportion: a replica with more weight will be given more currency, i.e. for two replicas X 1 and X 2 their total currency is C, and they have weights W 1 and W 2 respectively. Then they should get currencies C 1 and C 2 respectively, calculated as following: C 1 = C W 1 / (W 1 +W 2 ) C 2 = C W 2 / (W 1 +W 2 ) Metadata is collected only after a mobile host has hoarded a replica. It is not available when the data is first hoarded. In this case, expected metadata or user profiles should be given as the initial metadata.

PAGE 53

46 5.2 Dynamic Currency Redistribution Referring to Metadata Metadata records access statistics of databases and connection statistics of mobile hosts, i.e. which data are hot and which sites are hot. Currencies flow in the system dynamically and adapt to the use of databases. They are always going toward the place where they are needed most: hot sites and hot replica. But in order to be correct and efficient, it should be careful to exchange currencies among replicas in mobile and fixed hosts. 5.2.1 Correctness Requirements of Currency Redistribution In the weighted voting scheme, the most important property is that the total currency of an object is fixed for any election. In currency exchanges, this property should be maintained carefully, otherwise if the amount of total currency is not fixed any more, the correctness of the scheme will be hurt: there is no way to determine majority or plurality hence no way to commit updates. The correctness requirements of currency exchange consist of following two items: 1) No more: Any amount of currencies of any replica should not be used more than once in any election. 2) No less: Any amount of currencies of any replica is available to every election, i.e. should be used at least once. From the above two requirements, it is implied that any amount of currencies of any replica will be used exactly once in every election. To satisfy the requirements, the currency exchange policies should be designed carefully to select the elections that the exchanged currencies take effective.

PAGE 54

47 5.2.2 Currency Redistribution In currency redistribution, there are two things to determine: one is how much currency each involved host should get, the other is when or from which election the redistributed currency should take effective? They will be addressed respectively in the following three scenarios: Between two weak connected mobile hosts. In this case, mobile hosts communicate in pair-wise manner. The amounts of currencies are directly proportional to the weights of replicas they have. Assuming both mobile host M 1 and M 2 have replicas of data item X, and hoard currencies C 1 and C 2 respectively. The weights calculated from metadata are W 1 and W 2 respectively. Then the target amounts of currencies of the two mobile hosts should be the following: Currency for the replica in M 1 is C 1 = (C 1 + C 2 ) W 1 / (W 1 + W 2 ), and Currency for the replica in M 2 is C 2 = (C 1 + C 2 ) W 2 / (W 1 + W 2 ). So the transferred currency between these two mobile hosts is as following: C = | C 1 C 2 | = (C 1 + C 2 ) | W 1 W 2 | / (W 1 + W 2 ). These two mobile hosts M 1 (with most recent election e 1 on data X) and M 2 (with most recent election e 2 on data X) would like to exchange (say, from M 1 to M 2 ) currency C of replicas of X in their pair-wise communication. The currency synchronization performed prior to the currency exchange will bring the replica with lower commit version number up to the replica with the higher commit number. The currency exchange is effective in election e, which is defined as following: 1) If e 1 < e 2 then e = e 2 M 1 has not voted for election e (e is unknown in M 1 ), so C can be used in e of M 2

PAGE 55

48 2) If e 1 == e 2 : If both M 1 and M 2 voted for the same candidate or neither of them voted, then e = e 2 If M 1 voted but M 2 did not: if M 2 will vote for the same candidate as M 1 then e = e 2 otherwise, e = e 2 + 1. If M 2 voted but M 1 did not, then M 2 will vote C for the same candidate as the one M 2 voted C 2 for, i.e. e = e 2 If both M 1 and M 2 voted but for the different candidates, then e = e 2 + 1. 3) If e 1 > e 2 : If M 1 voted, then e = e 1 + 1. Since C has been used by M 1 in elections e 2 e 2 + 1, e 1 it can only be used in M 2 s future voting from (e 1 + 1). If M1 has not voted for e 1 then e = e 1 Among fixed hosts and/or strong connected mobile hosts. Assuming replicas of data item X are hoarded by fixed hosts and/or strong connected mobile hosts numbered from 1 to k, their current weights are W 1 W i W k and their currencies before redistribution are C 1 C i C k The amount of currency a replica should get after distribution is directly proportional to its weight: C i = (C =kj1 j ) W i / (W =kj1 j ) The currency redistribution is performed via distributed transactions. Due to the good network communication of fixed hosts and/or strong connected mobile hosts, it can be seen that all of them have the same current election e. For a host i who hoards C =

PAGE 56

49 (C i C i ) from other hosts, the currency exchange is effective in election e, which is defined as following: 1) If C has not been voted or voted for the same candidate as the host i voted, then e = e. 2) If C has been voted but the host i didnt vote: if the host i will vote for the same candidate, then e = e; otherwise, e = e + 1. 3) If C has been voted and the host i voted but for different candidates, then e = e + 1. It is possible that C comes from more than one host, i.e. C = C 1 + C 2 + + C m Then the host i hoards C 1 C 2 C m one by one, using the above algorithm to get effective elections for each of hoarded currencies. Between a weak connected mobile host and a fixed host. In this case, the currency exchange may involve one or more neighbors of the fixed host. Considering the scenario that the currency in the fixed host is not enough to meet the requirement of the mobile host, the fixed host may have to borrow some currency from its neighbors. Or the mobile host may want to return more currency to the fixed network and the currency should be distributed to more fixed hosts. These will cause currency shrink or currency swell in the distributed databases. They are performed via distributed transactions and are transparent to the mobile host. 1) A mobile host hoards currency from a fixed host: It is similar to the case between two weak connected mobile hosts if the fixed host has enough currency to give. Otherwise, the fixed host will borrow currencies from one

PAGE 57

50 or more of its neighbors to cause such neighbors shrink in currencies, as illustrated in the Figure 5-1. Figure 5-1 Currency shrink in fixed hosts to meet the hoarding request of a mobile host C The amount of currency a fixed host shrinks is directly proportional to its weight of the replica: C i = C W i / (W =kj1 j ) If C comes from only the fixed host, the effective election of the currency exchange is defined similar to the case between two weak connected mobile hosts. If C comes from more than one fixed host, i.e. C = C 1 + C 2 + + C m then the mobile host hoards C 1 C 2 C m one by one, and get effective elections for each of hoarded currencies. 2) A mobile host returns currency to a fixed host: In this case, the mobile host gives some or all of its currency to the fixed host. Then fixed host then distributed the currency to its neighbors to cause their currencies swell. There are two steps to go: the first is C go to the fixed host, the second is C get distributed. The amount of currency for a fixed host i should increase is: C i = C W i / (W =kj1 j )

PAGE 58

51 Figure 5-2 Currency swell in fixed hosts when a mobile host returns currency In this case, since the fixed hosts in the fixed network have the same election, the effective election of C is the same for all the involved fixed hosts. It is defined similar to the case among fixed hosts. 5.3 Ad-hoc Database Check-out/Check-in Currency When the mobile hosts are all docked (strong connected), all the mobile and fixed hosts have good communication. The mobile database now becomes a distributed database. When some or all of mobile hosts weak connected, they form an ad-hoc network and their database is an ad-hoc database. The ad-hoc database carries out some or all of currencies and perform database operations in ad-hoc manner. For each individual mobile or fixed host, the currencies are redistributed referring to metadata using the scheme given in section 5.2. Primaries may dilute, concentrate or be transferred in or between ad-hoc database and the distributed database. The scenario of ad-hoc database checking out currency is given in Figure 5-3. C Figure 5-3 Scenario of ad-hoc database checking out currency

PAGE 59

52 When the ad-hoc is all docked, the mobile database is actually a distributed database. So traditional distributed database management can be used to run the system, except that metadata collection is performed. When the ad-hoc is half docked or all undocked, the mobile database now consists of ad-hoc database and distributed database. So the database should switch to dynamic, weighted voting scheme to take the advantages of dynamic redesign and reconfigure via dynamic currency redistribution. The scenario of ad-hoc database checking in currency is shown in Figure 5-4. Figure 5-4 Scenario of ad-hoc database checking in currency When all the mobile hosts return to the fixed network thus the ad-hoc network becomes all docked, the mobile database is now becoming a distributed database again. The dynamic, weighted voting scheme may be switched to the traditional way of distributed database system. 5.4 Creation and Retirement of Currency and Data Assuming that the fixed global work set, once created, will not change. For mobile and fixed hosts, creation of currency and data happens when the hosts hoard a replica. The replica will be allocated some currency while ensuing that the total currency for a data item in the system is always is fixed. Fixed hosts have large capacity, so they can always store data replicas. Even when they have not used a data replica for a long time, the system just leave its currency

PAGE 60

53 as zero to indicate the infrequent use of data, instead retire the data replica from the fixed host. The capacity of a mobile host is limited, so it cannot afford the cost to store a replica that it will not need any more, especially when the replica needs a large storage space. After giving all its currency to one of its peers, now the host has a replica with zero currency. To retire the replica, the host has to retire its currency first, i.e. setting its currency to undefined. Then the replica is deleted from the disk of the mobile host. There is some housekeeping to do: remove the replica ID from HS (hoarded Set), delete its metadata, votes and election information, etc.

PAGE 61

CHAPTER 6 SIMULATION To demonstrate the benefits of the protocols given in previous chapters, a simplified simulation has been implemented. It simulates the behaviors of mobile hosts under two cases: dynamic currency redistribution and static currency allocation. The metrics of our focus are commit rate, commit percentage and commit delay. Before qualifying the performance of the protocols, the simulation assumption and settings are described first. 6.1 Simulation Assumption The simulation has been implemented using Java in a local area network environment, i.e. CISE network. A host is implemented as a process running on a UNIX Solaris machine remotely and UDP data grams are used to communicate among processes. Since UDP is not reliable, in general, we may expect that our data packets could be lost, duplicated or delivered out of order. But in the CISE network, this will not really be a concern. The focus of the simulation is to show the benefits of dynamic currency redistribution among mobile hosts, so the fixed network is concentrated as one fixed host to avoid currency shrink and currency swell in distributed databases. Four mobile hosts are modeled and each of them has an event creator which generates events to simulate the activities of a real mobile host. The main assumptions are: 1). The database is a single object database, i.e. there is only one object shared among these hosts. 54

PAGE 62

55 2). Data hoarding is assumed to be performed prior the simulation, i.e. each host has a non-zero currency of the object when the simulation is started. 3). The generated tentative updates are independent so that the abort or commitment of a tentative update does not have any effect on the other tentative or committed updates. 4). Applications read committed updates only. Tentative updates are unavailable before they commits. 5). The mobile hosts are failure free, so we need not worry about currency loss. The metadata in consideration includes connect duration, disconnect frequency, read and tentative update frequencies, commit rate and commit delay. 6.2 Simulation Model The simulation is designed to be started by an initiator, which takes a configure file and start hosts according to the arguments as configured. Each host is running remotely and working independently with regard to their own configures after being started. The following figure illustrates the scenario of the initiator and the hosts. Figure 6-1 Initiator and hosts in the simulation

PAGE 63

56 The simulation of a mobile host consists of a processor and a listener. The algorithm of a processor is following: Initialize; While the simulation is not yet finished If the message queue is not empty and the host is connected Process messages; Get next event from event creator; Process event; Add event to time sliding window; If the time sliding window is over size Adjust the window; End while A listener is implemented as a thread to receive messages from other hosts and put them to a message queue. The message queue is accessed synchronously by the processor and the listener of a host. There are two types of messages being sent and received: REQUEST messages and REPLY messages. A REQUEST message is composed of committed update table, election, currency and weight of replica. A REPLY message includes committed update table, election and delta currency. The committed update table is used to propagate committed updates among peers in data synchronization. The election is used in voting scheme to collect currencies. The currency and weight of replica are used in currency redistribution. For a mobile host, if the current event is CONNECT, then the host will send a REQUEST message to the selected peer. The peer will perform data synchronization, currency synchronization and currency reallocation according to their weights and send back a REPLY message to inform the results. Messages in the model of a host are shown in the following figure:

PAGE 64

57 REQUEST REPLY REQUEST REQUEST REPLY REPLY Processor: Process event CONNECT Data Synchronization Currency Synchronization Currency Redistribution Data Synchronization Currency Synchronization Currency Redistribution Listener: Message Queue Figure 6-2 Messages in a mobile host 6.3 Simulation Settings In mobile database applications, access of the database items may varies according to the interests of the mobile applications. So the simulator should mimic the activities of mobile applications and generate different events to cause hot spot transferred among the hosts. To get different frequencies of events, intervals between two consecutive events are configured for each host. Roughly the activity patterns of each host are designed as two sections: the fixed host 0 is configured inactive in the first section but active in the second section; mobile host 4 is configured active in the first section and inactive in the second section; the other mobile hosts are configured inactive in both the first and second sections. One of the most important parameters is the tentative update ratio. According to the simulation assumption, all the tentative updates are independent. A tentative update should be issued to win an election to get committed. The election performs currency synchronization among replicas and currencies are intended to be redistributed to flow to the hottest place of the system. It is expected that the tentative update ratio have direct

PAGE 65

58 impact to the commit rate and commit delay. Relative to the frequencies of read events, the tentative update frequency ratios are designed from 0.1 to 0.6. The width of the time sliding window is al so important in that a too wide window causes the metadata data changes slowly thus currency flow slowly so may not catch the hot place in time, while a too narrow window is vulnerable to some false frequent events and lead to unnecessary currency flow hence decrease the efficiency of the system. The scenarios of static currency allocation simulated in this model are uniform currency allocation and primary currency alloca tion. The former is a case of non-primary scheme and the latter is equivalent to the primary-copy scheme. To compare the performance of the dynamic design to the static design, the scenarios of dynamic currency redistribution design are simulated unde r the same initial currency allocations as the static cases. The main simulation parameters and se ttings are summarized in Table 6-1 as follows. Table 6-1 Primary simulation parameters Parameter Setting Description windowWidth 6 seconds Width of time sliding window simuTime 80 seconds The time of simulation running simuSection [0, 40], [40, 80] Simulation time sections updateRatio 0.1, 0.2, 0.3, 0.33, 0.4, 0.5, 0.6 The ratio of tentative updates to read events Hosts Host0 Host1 Host2 Host3 Host4 First section 1.0 1.0 1.0 1.0 0.1 Internals between two consecutive events (seconds) Second section 0.1 1.0 1.0 1.0 1.0 Intervals between two consecutive events in different time sections Uniform 20 20 20 20 20 Initial currency allocation (total = 100) Primary 60 10 10 10 10 These are the initially allocated currencies. For static cases, they are not to be changed.

PAGE 66

59 The settings show that in the first section, the host 4 is very active and the other hosts are not, while in the second section, the hot point transfers to the host 0 and the host 4 becomes cold. The purpose of such setting is to show the most currency is always intended to flow to the hottest host. 6.4 Simulation Results The analysis of the simulation results is focused on the commit rate, commit percentage and mean commit delay. The commit rate is defined as the average number of committed updates per time sliding window. The commit percentage is the ratio of committed updates to the total tentative updates generated in the system. The commit delay of a committed update is defined as the difference from the tentative update issue time to the time that a host knows its commitment. Mean commit delay is the mean delay time of committed updates in the system averaged to all the hosts. The simulation results demonstrate that the dynamic design is more beneficial that the static design. Two scenarios are studied to qualify the performance: one is uniform scenario, i.e. the currencies are initially allocated to each replica uniformly; and the other is primary scenario, in which the primary currency is initially given to one replica. The initially allocated currencies remain unchanged in static cases while dynamically change with weights/metadata of replicas in dynamic cases. 6.4.1 Commit Rate and Commit Percentage The commit rate and commit percentage of dynamic cases versus static cases of uniform scenario are given in Figure 6-3 and Figure 6-4.

PAGE 67

60 02468100.10.20.30.40.50.6update ratiocommit rate dynamic static Figure 6-3 Commit rate of uniform scenario 00.20.40.60.810.10.20.30.40.50.6update ratiocommit percentage dynamic static Figure 6-4 Commit percentage of uniform scenario It can be clearly seen that the dynamic design is much more beneficial than the static design except when the update ratio is rather low. Specifically, when the update ratio is 0.1, little benefit of dynamic design is shown over the static design. But when the update ratio is bigger, the benefit becomes significant: the commit rate of the dynamic design increases while that of the static design remains almost unchanged; the commit percentage of the dynamic is almost constant but that of the static design decrease rapidly. The reason is that in the dynamic design, the currency is always flowing to the hottest replicas thus there are more tentative updates to get plural currency and be committed rapidly. While in the static case, the currency allocation is fixed and there is

PAGE 68

61 no priority for the hottest replica, so the commit rate is almost a constant no matter the number of tentative updates generated. Figure 6-5 and Figure 6-6 illustrate the commit rate and commit percentage of dynamic cases versus static cases of primary scenario: 02468100.10.20.30.40.50.6update ratiocommit rate dynamic static Figure 6-5 Commit rate of primary scenario 00.20.40.60.810.10.20.30.40.50.6update ratiocommit percentage dynamic static Figure 6-6 Commit percentage of primary scenario We can learn from the above figures that in the primary scenario, the difference of dynamic and static cases is not so significant as the uniform one. The reason is that the primary currency happens to be allocated to one of the hottest replicas so the performance of static design is not too bad since a fixed primary currency makes all the local tentative updates committed. It can also be seen from Figure 6-5 and Figure 6-6 that the dynamic case still beat the static case when the update ratio is higher than 0.3 even one of hot replica is lucky to get primary currency in the static case.

PAGE 69

62 It is reasonable that the benefits of the dynamic design will be more significant, even better than the uniform scenario, if the primary currency is unfortunately given to a cold replica. 6.4.2 Mean Commit Delay Figure 6-7 and Figure 6-8 demonstrate the commit delay of dynamic cases versus static cases in uniform and primary scenarios: 051015200.10.20.30.40.50.6update ratiocommit delay dynamic static Figure 6-7 Commit delay of uniform scenario 024680.10.20.30.40.50.6update ratiocommit delay dynamic static Figure 6-8 Commit delay of primary scenario The above figures compare the dynamic design and the static design for uniform and primary scenarios in terms of how fast they commit updates. It can be observed that in the uniform scenario, the commitment of dynamic design is much faster than that of static design except when the update ratio is rather low. But in the primary scenario, the

PAGE 70

63 benefit is not so significant because the fixed primary currency in static design does speed the commitment in the primary replica. The main overhead of the dynamic design is metadata management and currency redistribution. As stated in chapter 4, the overhead to collect metadata is trivial. The main overhead related to currency redistribution is message cost, but the information can be piggybacked with the anti-entropy messages and that is only a few bytes thus save bandwidth of mobile hosts. Therefore, the overhead of the dynamic design is little.

PAGE 71

CHAPTER 7 CONCLUSIONS AND FUTURE WORK This thesis is focused on flexible protocols for dynamic database design and reconfiguration in mobile environments. Traditional distributed database design is static, while mobile environments require a dynamic design to support mobility. In this thesis, the concept of mobile database is given first, and then a dual data/currency hoarding and synchronization protocol is introduced. Metadata is used to allocate currencies dynamically so that the mobile database is reconfigured such that the replica location, replication and data semantics can be changed dynamically via currency redistribution referring to metadata. The benefits of dynamic design versus static design are shown via the simulation results. Mobile databases consist of a large scope of research and application issues. In this thesis, what we addressed is only a small subset of it. There is a lot of future work to do: 1) This thesis is focused on just a small subset of metadata. In order to get better performance adaptive to the system changes, the full set of metadata should be considered. This requires a more completed metadata collection mechanism. 2) Associate rules to predict metadata to build rule-based adaptive currency redistribution. The metadata in this thesis is collected only after the events happen, i.e. it comes from history of the system. If there is a scheme to predict what a mobile host needs in the future and hoard the data in advance, the performance will be brought up significantly. 3) The concept of broadcast databases is introduced and included in the hoarding and synchronization mechanism. Detailed algorithms and more use of broadcast should be explored. It should be more powerful to use broadcast to propagate update commitment, election winner awards and hint of primary location. 4) Data management plays a crucial role in mobile computing. Decades of experience with query processing, transactions, replication, caching etc provide a solid 64

PAGE 72

65 base of technology on which to build. But, mobile computing brings challenges in all aspects of data management. Query processing in mobile databases has new characteristics and should be performed in an optimal way. Mobile transaction models will be built based on the traditional transaction models. For example, the operations in mobile databases include hoarding and synchronization as well as read and write. 5). A complete simulation/implementation is needed to show the benefits of dynamic design of mobile databases.

PAGE 73

LIST OF REFERENCES [1] S. Acharya, R. Alonso, M. Franklin, S. Zdonik, Broadcast Disks: Data Management for Asymmetric Communication Environments, SIGMOD Conference, pp. 199-210, 1995 [2] D. Agrawal, A. El-Abbadi, and R. Steinke. Epidemic algorithms in replicated databases, In Proc. 16th ACM SIGACT-SIGMOD Symposium on the Principles of Database Systems (PODS), pp. 161-172, Tucson, Arizona, May 1997 [3] L. Capra, W. Emmerich and C. Mascolo, Exploiting Reflection and Metadata to Build Mobile Computing Middleware, Advanced Topic Workshop Middleware for Mobile Computing, Heidelberg, Germany, November 2001 [4] M. Cherniack, M. Franklin, S. Zdonik, Data Management for Pervasive Computing, VLDB, Rome, Italy, Sep. 2001 [5] U. Cetintemel and P. J. Keleher, Light-Weight Currency Management Mechanisms in Mobile and Weakly-Connected Environments. Journal of Distributed and Parallel Databases, Vol 11, No1, pp. 53-71, January 2002. [6] U. Cetintemel, P. J. Keleher, M. Franklin, Support for Speculative Update Propagation and Mobility in Deno, The 22nd International Conference on Distributed Computing Systems, Mesa, Arizona, 2001 [7] U. Cetintemel and P. J. Keleher, Light-Weight Currency Management Mechanisms in Deno, In the 10th IEEE Workshop on Research Issues in Data Engineering (RIDE2000), February 2000. [8] A. Demers, D. Greene, A. Hauser, W. Irish, J. Larson, S. Shenker, H. Sturgis, D. Swinehart, and D. Terry. Epidemic Algorithms for Replicated Database Maintenance, In Proceedings of ACM Symposium on the Principles of Distributed Computing pp. 1-12, August 1987. [9] A. J. Demers, K. Petersen, M. J. Spreitzer, D. B. Terry, M. M. Theimer, and B. B. Welch, The Bayou Architecture: Support for Data Sharing among Mobile Users, In Proceedings of the Workshop on Mobile Computing Systems and Applications, pp. 2-7, Santa Cruz, California, December 1994 66

PAGE 74

67 [10] W. Emmerich, Software Engi neering and Middleware: A Roadmap, In the Future of Software Engineeringnd International Conference on Software Engineering (ICSE2000) May 2000 [11] A. Elmagarmid, Database Transaction Models for Advanced Applications, Morgan Kaufmann Publishers, San Francisco, CA, 1999 [12] J. Gray, P. Helland, P. ONeil, D. Shasha, The Dangers of Replication and a Solution, SIGMOD pp. 173-182, Montreal, Canada, 1996 [13] A. Helal, J. Hammer, A. Khushraj and J. Zhang, A Three-tier Architecture for Ubiquitous Data Access, the First ACS/IEEE International Conference on Computer Systems and Applications, pp. 177-180, Beirut, Lebanon, June 2001 [14] A. Helal, B. Haskell, J. Carter R. Brice, D. Woelk, M. Rusinkiewicz, Any Time, Anywhere Computing: Mobile Computing Concepts and Technology Kluwer Academic Publisher, New York, NY, 1999 [15] S. Jajodia and D. Mutchler, Dyna mic voting algorithms for maintaining the consistency of a replicated database, ACM Trans. on Database Systems, Vol. 15, No. 2, pp. 230-280, June 1990 [16] P. J. Keleher, Decentralized Replicated-Object Protocols, in the 18th ACM SIGACTSIGOPS Symposium on Principles of Distributed Computing, pp. 143-151, April 1999. [17] G. H. Kuenning and G. J. Popek, Au tomated Hoarding for Mobile Computers, Proceedings of the 16th ACM Symposium on Operating Systems Principles (SOSP16) pp. 264-275, St. Malo, France, October, 1997. [18] J. J. Kistler, M. Satyanarayanan, Disc onnected Operation in the Coda File System, In Proc. Of the ACM Symposium on Operationg Systems Principles, pp. 213-225, October 1991 [19] M. Lee, A. Helal, HiCoMo: High Commit Mobile Transactions, Journal of Distributed and Parallel Databases, pp. 73-92, January 2002. [20] M. Lanham, A. Kang, J. Hammer and A. Helal, Format-Independent Change Detection and Propagation in Support of Mobile Computing, Proceedings of the XVII Brazilian Symposium on Databases (SBBD) pp. 27-41, Gramado, Rio Grande do Sul, Brazil, October, 2002 [21] Y. W. Lee, K. S. Leung, M. Satyanaray anan, Operation-based Update Propagation in a Mobile File System, Proceedings of the USENIX Annual Technical Conference pp. 1-15, Jun. 1999, Monterey, CA

PAGE 75

68 [22] M. T. Ozsu and P. Valduriez, Principles of Distributed Database Systems Prentice Hall Publisher, Englewood Cliffs, NJ, 1999 [23] K. Petersen, M. J. Spreitzer, D. B. Terr y, M. M. Theimer, and A. J. Demers, Flexible Update Propagation for Weakly Consistent Replication, Proceedings of the 16th ACM Symposium on Operating Systems Principles pp. 288-301, Saint Malo, France, October 1997 [24] E. Pitoura and G. Samaras, Data Management for Mobile Computing Kluwer Academic Publishing, New York, NY, 1998 [25] M. Rennhachkamp, Mobile Database Replication, DBMS pp. 81-84, October 1997 [26] M. Stonebraker, P. M. Aoki, W. Litwin, A. Pfeffer, A. Sah, J. Sidell, C. Staelin, and A. Yu, Mariposa: A Wide-Area Distributed Database System, VLDB Journal Vol. 5, pp. 48-63, 1996. [27] K. Stathatos, N. Roussopoulos, J. S. Baras, Adaptive Data Broadcast in Hybrid Networks, VLDB pp. 326-335, 1997 [28] C. A. Waldspurger, T. Hogg, B. A. Huberman, J. O. Kephart, and W. S. Stornetta, Spawn: A Distributed Computational Economy, IEEE Transactions on Software Engineering Vol. 18, pp. 103-117, February 1992. [29] O. Wolfson, S. Jajodia, and Y. Huang, An Adaptive Data Replication Algorithm, ACM Trans. on Database Systems Vol. 22, No. 2, pp. 255-314, June 1997 [30] O. Wolfson, S. Jajodia, An Algorithm for Dynamic Data Allocation in Distributed Systems, Information Processing Letters Vol. 53, No. 2, pp. 113-119, 1995 [31] O. Wolfson, S. Jajodia, Distributed Al gorithms for Dynamic Replication of Data, in proceedings of the 11th ACM PODS Symposium pp. 149-163, San Diego, Calif., June 1992 [32] C. A. Waldspurger and W. E. Weihl, Lottery Scheduling: Flexible ProportionalShare Resource Management, in Proceedings of the First Symposium on Operating Systems Design and Implementation pp. 1-11, Monterey, CA, November 1994.

PAGE 76

BIOGRAPHICAL SKETCH Yanli Xia was born in Sanyuan, Shaanxi Province, in China. She received a Bachelor of Science degree in computer science and engineering from Nanjing University of Aeronautics and Astronautics, Nanjing, China, in July 1997. Then she entered the graduate program at Nanjing University of Aeronautics and Astronautics and obtained a Master of Engineering degree in computer science in April 2000. She enrolled at the University of Florida in August 2000 in the Department of Computer and Information Science and Engineering. She worked as a teaching assistant, and then research assistant for Dr. Abdelsalam (Sumi) Helal. Her future research interests include mobile databases and distributed systems. 69


Permanent Link: http://ufdc.ufl.edu/UFE0000619/00001

Material Information

Title: A Dynamic data/currency protocol for mobile database design and reconfiguration
Physical Description: Mixed Material
Creator: Xia, Yanli ( Author, Primary )
Publication Date: 2002
Copyright Date: 2002

Record Information

Source Institution: University of Florida
Holding Location: University of Florida
Rights Management: All rights reserved by the source institution and holding location.
System ID: UFE0000619:00001

Permanent Link: http://ufdc.ufl.edu/UFE0000619/00001

Material Information

Title: A Dynamic data/currency protocol for mobile database design and reconfiguration
Physical Description: Mixed Material
Creator: Xia, Yanli ( Author, Primary )
Publication Date: 2002
Copyright Date: 2002

Record Information

Source Institution: University of Florida
Holding Location: University of Florida
Rights Management: All rights reserved by the source institution and holding location.
System ID: UFE0000619:00001


This item has the following downloads:


Full Text











A DYNAMIC DATA/CURRENCY PROTOCOL FOR MOBILE DATABASE DESIGN
AND RECONFIGURATION















By

YANLI XIA


A THESIS PRESENTED TO THE GRADUATE SCHOOL
OF THE UNIVERSITY OF FLORIDA IN PARTIAL FULFILLMENT
OF THE REQUIREMENTS FOR THE DEGREE OF
MASTER OF SCIENCE

UNIVERSITY OF FLORIDA


2002




























Copyright 2002

by

Yanli Xia















ACKNOWLEDGMENTS

I express my sincere gratitude to my advisor, Dr. Abdelsalam (Sumi) Helal, for

giving me the opportunity to work on this challenging topic and for providing continuous

guidance during my thesis writing. I am thankful to Dr. Joachim Hammer and Dr.

Herman Lam for agreeing to be on my supervisory committee.

I really appreciate Youssef Kaddoura's help in proofreading my thesis. I also

thank the other members in the Harris lab for their help.

I would like to take this opportunity to thank my parents, my husband and my

son, for their continued and encouraging support throughout my period of study and

especially in this endeavor.















TABLE OF CONTENTS
Page

A C K N O W L E D G M E N T S ....................................................................... .....................iii

A B STR A C T ............. .... ...................................................................................... vi

CHAPTER

1 IN T R O D U C T IO N .................................................................... .......... ... ........... 1

1.1 Challenges in M obile D databases ........................... ................... .............. 1
1.2 R elated W ork ....................................................................................... .......... 3
1.3 O organization of the Thesis ................................. .......................... ................ 5

2 A MODEL FOR MOBILE DATABASES ..............................................................6

2.1 Interface A ssum ption ................................................................... ... 8
2.2 Scenarios of Mobile Hosts and Fixed Hosts .............................................. 8
2.2.1 Connection Scenarios Between A Mobile Host and A Fixed Host............. 8
2.2.2 Connection Scenarios Between Mobile Hosts ......................................... 9
2.3 Scenarios of Ad-hoc Network to Fixed Network.................... ...... .... 10
2.4 A Model for Mobile Databases .............. ..................... .............. 11

3 GENERALIZED HOARDING AND SYNCHRONIZATION MECHANISMS ......... 15

3 .1 B background .................................................................. 16
3.2 Data and Currency Hoarding Modes........................................ ............ 17
3.2.1 Currency H oarding M odes ................................ ............................... 17
3.2.2 D ata H oarding M odes ........................................................... ... ........... 20
3.3 Currency and Data Synchronization Modes............................................... 22
3.3.1 Currency Synchronization Modes ........................ ................. 23
3.3.2 Data Synchronization Modes ................... .................... ............. 25
3.4 Hoarding and Synchronization Algorithms...................................... 27
3.4.1 D definition of W ork Sets ............................ ........................ ... ........... 27
3.4.2 Hoarding Algorithm s......... ........................................................... 29
3.4.3 Synchronization Algorithm s ................................................................. 30









4 METADATA MANAGEMENT FOR MOBILE DATABASES............................ 34

4.1 Categories of M etadata in M obile Databases ............................................... 35
4.1.1 Connectivity ................................ .......................... .. ......... 35
4.1.2 Availability ................................ .......................... .... ...... 36
4.1.3 A ccess................. ........................................... .......37
4.1.4 U ser-defined Constraints................................ ......................... ....... 37
4.2 Metadata Collection in Mobile Databases .......................... ......... ..... 37
4.2.1 Focused Subset of M etadata............................................ .................... 37
4.2.2 M etadata C collection ......................................................... .............. 39

5 DYNAMIC CURRENCY ALLOCATION AND REDISTRIBUTION ..................... 44

5.1 A Target of Currency A location ............................................. ........ ...... 44
5.2 Dynamic Currency Redistribution Referring to Metadata...............................46
5.2.1 Correctness Requirements of Currency Redistribution ............................ 46
5.2.2 Currency Redistribution ............... ............. .... ... ............... 47
5.3 Ad-hoc Database Check-out/Check-in Currency ................ .............. 51
5.4 Creation and Retirement of Currency and Data.................................... 52

6 SIM ULATION ........... ........................................... ..... ...... ............ 54

6.1 Simulation Assumption ......... .................................... ..... .............. 54
6.2 Sim ulation M odel .......... .. ................................ ........ .......... ........ .. 55
6.3 Sim ulation Settings .................... ................. ...................................... 57
6.4 Sim ulation R results ................... ............ .................................... 59
6.4.1 Commit Rate and Commit Percentage.............. ..... ................. 59
6.4.2 Mean Commit Delay ........... ..... ......... .................. 62

CONCLUSIONS AND FUTURE WORK ..... ..................... ................64

L IST O F R E FE R E N C E S ......... ................. ......................................... ......................... 66

BIOGRAPHICAL SKETCH ................................................................ .............. 69















Abstract of Thesis Presented to the Graduate School
of the University of Florida in Partial Fulfillment of the
Requirements for the Degree of Master of Science

A DYNAMIC DATA/CURRENCY PROTOCOL FOR MOBILE DATABASE DESIGN
AND RECONFIGURATION

By

Yanli Xia

December 2002

Chair: Dr. Abdelsalam (Sumi) Helal
Major Department: Computer and Information Science and Engineering

Mobility is changing the way we design databases and their Database

Management Systems (DBMS). For example the scenario in which all database users are

ad-hoc users has been integrated in the Bayou and Deno projects. Both of them take an

asynchronous, epidemic information flow and conflict avoidance-based (i.e., pessimistic)

approach to ensure that all committed updates are serialized in the same order at all

servers. Bayou uses a primary-copy scheme, while Deno takes a bounded weighted-

voting one.

In this thesis, we focus on flexible protocols for dynamic database design and

reconfiguration. In particular, we introduce protocols and ideas that enable databases to

be designed in such a way that their location, replication and even use semantics can be

changed dynamically. We believe the flexibility of this approach is necessary given the

uncertainty of user mobility.









We introduce a dual data/metadata hoarding and synchronization protocol. We are

especially focused on the currency type of metadata, which is a weight (vote) given to a

replica. Data are hoarded via a variety of hoarding mechanisms with different hoarding

semantics. Metadata record the changing characteristics of mobile hosts and currency is

dynamically redistributed to fit the target. Primaries are allowed to be diluted,

concentrated and transferred in the system. We borrow a bounded weighted-voting scheme

from Deno and use it to do currency synchronization. We also use anti-entropy

mechanisms to do data synchronization to eventually bring the database to a consistent

state.

We include a fixed network as the home of the database. An ad-hoc network

checks out its desired data and checks them back in when they are no longer accessed

by the mobile users.

Finally, we conduct experimental evaluation using simulation to assess the

benefits of our protocols.














CHAPTER 1
INTRODUCTION

1.1 Challenges in Mobile Databases

Since their emergence in the 1970s, wireless networks have become increasingly

popular in the computing industry. This is especially true within the past decade, which

has seen wireless networks being adapted to enable mobility. Mobile computing is the

merger of advances in portable computing and wireless communication with the aim of

providing seamless and ubiquitous services for mobile users. In mobile environments,

database applications are enhanced with the useful features of wireless technology.

However, mobile computing environments have severe resource constraints and unstable

operating conditions. Compared to the wired network, the wireless medium is notable for

its high cost, narrow bandwidth and low reliability. The wireless connection is usually

weak and intermittent, causing frequent disconnection. Mobile hosts are usually resource

poor, battery dependent, and susceptible to accidental damage or loss.

Mobility is changing the way we design databases and their DBMS. Many

software problems associated with data management, transaction management, and data

recovery have their origin in distributed database systems. In mobile computing,

however, these problems become more difficult to solve. Large-scale replication is

provided to allow anytime/anywhere access. Data interests may change with shifting user

context, so a new data management decision is needed.

Due to the characteristics of mobile environment, mobile computing exposes key

limitations of the traditional computing model [4]:









1) Weak connectivity/frequent disconnection: state of wireless communication
and cost issues.

2) Large-scale replication: device-local hoarding required due to availability when
disconnected.

3) Close user interaction/feedback: allows negotiation, partial and preliminary
results.

4) Long-running tasks: always a problem for ACID systems

5) Real-time constraints

There are some projects related to databases in ad-hoc networks, such as Bayou

[9, 23] and Deno [5, 6, 7, 16]. But homes of databases are usually fixed network. For

example, members of a traveling salesman group may dial their head office to get new

product information and put sales and order data into the company's home database; a

botanist may wish to put her new sighting data into the laboratory database so that others

may see it before her return; a UPS delivery needs to report the package information to

the home office to make it available to the online searching system for customers.

In any situation in which multiple databases in ad-hoc networks are used or in

which there is a home-base database, we require replication to synchronize the data and

operations between these databases. Users' interests in data may change shifting context

from time to time, place to place, so we need to track user's state, based on position, time,

history and workflow to form metadata to adapt to the new user context.

In this paper, we focus on flexible protocols for dynamic database design and

reconfiguration. We introduce a dual data/currency hoarding and synchronization

protocol. Data are hoarded via P-, G-, or C-hoarding and accompanying hoarded currency

indicates semantics of data. Metadata record the changing characteristics of mobile hosts

and currency is dynamically redistributed to fit the target. Databases are designed in such









a way that their location, replication and even use semantics can be changed dynamically.

We believe the flexibility of this approach is necessary given the uncertainty of user

mobility. We include fixed network as home of database. Finally, we conduct

experimental evaluation using simulation to assess the benefits of our protocols.

1.2 Related Work

Many mobile computing issues associated with data management, transaction

management, and data recovery have their origin in distributed database systems. A

distributed database is defined as a collection of multiple, logically interrelated database

distributed over a computer network [22]. The existing distributed database systems are

extended to support mobile operations (e.g., disconnection, caching, reconciliation, etc.).

The work [12] of Jim Gray et al. showed that replication protocols go along two

dimensions: master/group object ownership and lazy/eager update propagation. For

master ownership, only primary copy can be updated, while for group ownership, any

replica can be updated. Eager update propagation requires all replicas updated in a single

transaction, and the lazy one propagates updates asynchronously. They argued that eager

schemes are unsuitable for mobility due to frequent disconnections and proposed a two-

tier lazy protocol for scalable replication. The solution approaches are as follows: 1)

Multiple tiers of hosts: the high connectivity and resource-rich inner ring, land weakly

connected, mobile, expendable clients. 2) Two classes of copies: servers retain "copies of

record" and clients cache secondary ("soft-state") copies. Reads see weaker-consistency

(snapshot isolation) and updates happen without two-phase commit. Synchronization

metadata are kept at clients and servers.

Jajodia and Mutchler [15] and Jajodia et al. [29, 30, 31] improved Jim Gray's

approach using an adaptive data replication algorithm, which changes the replication









scheme of the object as changes occur in the read-write pattern of the object. The

algorithm continuously moves the replication scheme towards an optimal one, but this

algorithm is designed for a distributed, wholly interconnected information environment,

which is not proper for mobile environment.

Lee and Helal [19] introduced a new mobile transaction model (HiCoMo)

applicable to decision-making applications over aggregate data warehoused on mobile

hosts. The model allows the aggregate data to be updated in disconnection mode, while

guaranteeing a very high rate of commitment on reconnection.

Epidemic information flow [2, 8] is used to propagate updates and drive the

replicas toward consistency. Epidemic algorithms require few guarantees from the

underlying communication system, hence proper to be used in mobile environments.

Anti-entropy is an example of epidemic processes, exchanging database content with a

peer to resolve any differences between them.

CODA [18, 21] is a distributed file system with the ability to support

disconnected operation for mobile computing. It employs two-tier data replication to get

scalability: server replication and client side persistent caching of files. Write back

caching is the scheme to reach consistency.

SEER [17] is a predictive hoarding system for disconnected mobile operation.

Briefly, it observes the user's file-access patterns while a mobile computer is connected to

the network, and uses those to predict what files will be needed when the network is no

longer available. It then arranges to have those files stored on the mobile machine in

advance of disconnection.









Bayou [9, 23] uses epidemic information flow via anti-entropy sessions. It is a

more pessimistic approach and ensures that all committed updates are serialized in the

same order at all servers using a primary-copy scheme. Updates can only be committed at

the primary-copy server.

Deno [5, 6, 7, 16] takes an asynchronous bounded weighted-voting scheme via

epidemic information flow such that updates are committed in a decentralized fashion.

Deno uses fixed per-object currencies for voting and data movement requires only pair-

wise communication. Each replica is assigned a currency and total currency in the system

is bounded.

1.3 Organization of the Thesis

In chapter 2, we present a model for mobile databases that integrates previously

proposed ideas such as ad-hoc and broadcast disks. Then we introduce data and currency

hoarding and synchronization in chapter 3. In chapter 4, we give the categories of

metadata and work on algorithms to manage metadata. Chapter 5 gives the details of a

dynamic currency redistribution protocol based on the metadata. We then present some

experiments to evaluate the merits of our protocol in chapter 6. Finally, we conclude our

work and list future work in chapter 7.














CHAPTER 2
A MODEL FOR MOBILE DATABASES

Traditional database design is static. The question being addressed is how the

database and applications that run against it should be placed across the sites [22]. There

are two basic alternatives to placing data: partitioned (non-replicated) and replicated.

Respectively, the two fundamental design issues are fragmentation and distribution. No

matter which scheme is provided, however, it is static from the angle of the database

design. Once data placing is determined, it will not be changed. A directory contains

information about data items in the database is maintained. The definition of fragments

and their placement determine the contents of the directory. Directory placement and

contents influence concurrency control strategies as well as the processing of queries.

With directory, data must be located first. The static database design limits flexibility of

database applications.

Many mobile computing issues associated with data management, transaction

management, and data recovery have their origin in distributed database systems.

However, mobility of mobile hosts on the network causes static data in stationary

networks to become dynamic and volatile in wireless networks. In mobile database

everything is dynamic, varying from sporadic accesses by individual users to particular

data to continuous access of a particular data by a large group of user. This is the case

from disconnected database access to broadcast disks. For broadcast data, due to the

mobility of the mobile hosts, the content of any data to be broadcast should be dynamic

and adaptive. Moreover, in an ad-hoc network, the users group and data interests are









changing from time to time. Data partition, location and replication are always dynamic.

These characteristics raise interesting issues for the design of mobile databases.

CODA [18, 21] is a distributed file system with the ability to support

disconnected operation for mobile computing. The Coda model is that there are many

clients and a few servers. Only Coda clients can be used in disconnected and weakly

connected mode to support mobile computing. Coda employs server replication and

persistent client side caching of files. Directories and attributes are maintained for high

performance. Moreover, file-system objects distribution in servers is static in Coda.

Broadcast disk [4, 1, 27] is the proactive distribution of relevant data to large

number of users. In order to match data/events to user interests and distribute the data to

users, reliable delivery especially with movement and disconnection, broadcast

scheduling should be dynamic to satisfy the users and adaptive to the changing context.

The scenario where all database users are ad-hoc users has been integrated in the

Bayou and Deno projects. Both of them take asynchronous, epidemic information flow

and conflict avoidance-based (i.e., pessimistic) approach to ensure that all committed

updates are serialized in the same order at all servers. Bayou uses a primary-copy

scheme, while Deno takes a bounded weighted-voting one.

Although there are above significant works on database issues, there is a need to

reach a generic solution for dynamic mobile database design to combine distributed

databases, broadcast disks and ad-hoc databases. Here we focus on flexible protocols for

dynamic database design and reconfiguration involving fixed network. First we give

connection scenarios of mobile hosts and fixed hosts, ad-hoc network to fixed network,









then we introduce the concept of mobile databases and specify the configuration used in

our system.

2.1 Interface Assumption

A mobile host may have four network interfaces:

1) Strong connect interface (dock);

2) Weak connect interface (wireless);

3) Wireless ad-hoc network interface;

4) Broadcast receiver;

Interfaces 2 and 3 are different in that interface 2 is used to connect with fixed

hosts, while interface 3 is used to connect with other mobile hosts in ad-hoc network.

2.2 Scenarios of Mobile Hosts and Fixed Hosts

In this section, the connection scenarios among mobile hosts and fixed hosts are

given.

2.2.1 Connection Scenarios Between A Mobile Host and A Fixed Host


Strong Connected (Docked)
04----
MH FH

Weak Connected (Wireless)

0*------------q
MH FH

Disconnected


MH FH


Figure 2-1 Connection scenarios of a mobile host with a fixed host









A mobile host may be strong connected (docked) with a fixed host when the

mobile host backs "home". A docked mobile host is equivalent to a fixed host in that it

has access to the resources in the fixed network. Besides, it may perform hoarding

directly from fixed hosts.

A mobile host may be weak connected (wireless) with a fixed host when there is

no existing wired connection, providing that it has wireless network connection interface.

Due to cost and battery life, weak connection is normally periodic, lasting not much long.

Most of the time, a mobile host is disconnected from the fixed network, working

on local data hoarded before planned disconnection. For unexpected disconnection, a

mobile host may seek to reconnect with a fixed host after failure recovery.

When a mobile host is strong connected, we say the mobile host is homed,

otherwise it is said mobile.

2.2.2 Connection Scenarios Between Mobile Hosts

A mobile host may be weak connected with or disconnected from another mobile

host. We say such mobile hosts are peers. Peer mobile hosts may communicate pair-wise

such that each connection session only involves two peers.


Figure 2-2 Connection scenarios between mobile hosts


Weak Connected (Wireless)

0* ------- 1-0
MH MH

Disconnected

MH MH
MH MH









When a mobile host is weak connected with one of its peers in the ad-hoc

network, they may perform hoarding to get desired data, synchronize their updates, anti-

entropy to eliminate their differences, etc. But all these should be done in an efficient

manner.

A mobile host is disconnected from its peer after information exchanges. Then it

goes on working based on its local data until next connection.

2.3 Scenarios of Ad-hoc Network to Fixed Network

As shown in the figure 2-3, an ad-hoc network may be all docked, half-docked or

all undocked to the fixed network.


Figure 2-3 Connection scenarios of ad-hoc with fixed network


All Docked:




Ad-hoc Fixed network

Half-Docked





Ad-hoc Fixed network

All Undocked






Ad-hoc Fixed network









When all mobile hosts in an ad-hoc network back home, it is said the ad-hoc

network is docked. A docked ad-hoc network joins the fixed network to form a bigger

distributed system except that it performs hoarding before next mobile.

If some of mobile hosts in an ad-hoc network back home and the others do not, it

is said the ad-hoc network is half-docked. The docked mobile hosts are strong connected

with the fixed network, while the others are weak connected. Moreover, the weak

connected mobile hosts may get information from a broadcast server in the fixed

network. The broadcast server continually broadcasts data that mobile hosts are

commonly interested in. This way is called pushing. A pushing channel usually has good

bandwidth.

The scenario where all mobile hosts in the ad-hoc network weak connected with

or disconnected from the fixed network is considered as all undocked. In this case, all

mobile hosts leave home and they may perform pair-wise connection to exchange

information as well as communicate with fixed hosts. Additionally, ad-hoc network may

get pushed data from broadcast.

2.4 A Model for Mobile Databases

A mobile host in mobile may communicate with only fixed hosts, no connection

available between mobile hosts. In this case, data items reside in all such mobile hosts

form a disconnected database. This configuration introduces the concept of ubiquitous

data access.

A mobile host may wish to communicate with other mobile hosts selected

randomly or according to some constraints. Pair-wise connection is enough for such case.

This gives the concept of ad-hoc databases. A mobile host in an ad-hoc database may

connect with fixed hosts to do hoarding or synchronization.






12


A broadcast server may be integrated into the fixed network and broadcast data

that mobile hosts have common interests in. This introduces the concept of broadcast

databases. A broadcast database usually contains public information such as weather,

stock and financial reports. Mobile hosts grab such information from the air.

Traditionally, database distributed in a fixed decentralized network is a distributed

database. We envision that a mobile database should be defined as the union of

disconnected database, broadcast disks, ad-hoc database and distributed database. This is

because the dynamic nature of the mobile environment may require data to be reallocated

or replicated. Mobile environment also may require users and replicas to be ad-hoc or

disconnected from the network. Figure 2-4 shows the concept of mobile database.


.......... ....._..._ I Broadcast disks

--I / .--...----. -




MH MH .


I '\ I Distributed Database
/ L ._...._._ ._ .. .. .. ..
-- -- i --------._._--._._ _._._. ._._._ _._._ J

MH ---- -------





I Disconnected Database _Ad-hoc Database


Figure 2-4 Mobile database: a whole image









For distributed database, there is significant body of previous work [22]. As to

disconnected database, there are several projects on ubiquitous database access working

on it [13, 20]. There are research efforts in broadcast disks [4, 1, 27]. Bayou and Deno do

great work in ad-hoc databases. However, as far as we know, there is no work toward the

whole image of mobile databases. In this thesis, our attention is focused on the scope of

ad-hoc database and its interaction with distributed database. When the mobile hosts in

the ad-hoc network are all docked into the distributed network, they can communicate

with the fixed hosts in the distributed network and be treated as part of it. Our focus is on

the ad-hoc network half-docked or all-undocked cases, in which databases need to be

reconfigured and redesigned to adjust to the dynamic characteristics of the new mobile

environment. When the ad-hoc network finished its work, it may return to the distributed

network and become all docked again.

A motivating example. Ad-hoc users and fixed users may have common interests

in some data. For example, IBM salespeople Frank, Joe, and Nancy collectively cover the

state of Texas, they might expect to be able to consolidate their sales data when they meet

in Austin. While their manager in New York, Ronald, would like to know the results and

decide sales in Florida. Bonnie, another manager in New York, needs the sales data to

make a financial report. In this case, Frank, Joe, and Nancy may wish to hoard their

interested data items and semantics that are able to indicate the primaries. They form an

ad-hoc database and since they have the primary semantics, they may make updates

commitment decision. Ronald and Bonnie are members of distributed database. They

may get information of the up-to-date data from ad-hoc database, or may update the data

items they have and inform ad-hoc users to see if the updates are acceptable. After the






14


three-people team back, they return the primary to distributed database, i.e. primary is

back home.














CHAPTER 3
GENERALIZED HOARDING AND SYNCHRONIZATION MECHANISMS

The mobile computing environment contains large number of low powered

mobile hosts. The mobile hosts will often be disconnected due to power limitations,

inaccessible communication channels, or as mobile hosts move between different cells.

Replication will be essential in such environment, increasing data availability to mobile

users: when a mobile host is disconnected, it can continue to process data stored locally.

At the same time, replicated data can improve performance. In a mobile environment, it

is important to have dynamic replicated data management algorithms that allow for the

database to be reconfigured due to the dynamic nature of mobile environments. We

introduce a dual data/currency hoarding and synchronization protocol to deal with

replication and consistency issues in mobile databases.

An ideal replication scheme would achieve four goals [12]:

1) Availability and scalability: Provide high availability and scalability through
replication, while avoiding instability.

2) Mobility: Allow mobile nodes to read and update the database while
disconnected from the network.

3) Serializability: Provide single-copy serializable transaction execution.

4) Convergence: Provide convergence to avoid system delusion.

We take a dual data/currency hoarding and synchronization approach. Data

hoarding is done by mobile or fixed hosts to hoard data requested by their applications.

Currency hoarding accompanies data hoarding and the amount of currency indicates









semantics of data. Currency synchronization is a weighted voting process to collect

plurality of currency for an update to commit. Data synchronization is performed by anti-

entropy information flow, propagating commitment updates in the system.

3.1 Background

The concept of currency is introduced by research efforts of [26, 28, 32]. Deno [5,

6, 7, 16] uses currency extensively to data replication and voting scheme in mobile

environments. What is currency? Simply, currency is a number associated with each

replica as a form of priority. The amount of currency held by a given replica is used as

that replica's weight during voting rounds.

Anti-entropy is important to avoid system delusion. The goal of anti-entropy is for

two replicas to bring each other up-to-date. In Bayou [9, 23], the storage system at each

replica consists of an ordered log of writes and a database that results from the in-order

execution of these writes. Anti-entropy needs to enable two replicas to agree on the set of

writes stored in their log. In Deno, election information flows from voter to voter through

anti-entropy sessions. An anti-entropy session is a uni-directional flow of information

specifying elections that have been won, and votes in the current election.

CODA [18, 21] is a distributed file system with the ability to support

disconnected operation for mobile computing. SEER [17] is a predictive hoarding

system. Bayou and Deno projects concern only pure ad-hoc scenarios. There is no

general hoarding and synchronization mechanisms working on mobile databases.

In this chapter, we try to give the generalized hoarding and synchronization

mechanisms. The purpose of the mechanisms is to drive data and currency to flow in the

mobile databases to dynamically design and reconfigure it.









3.2 Data and Currency Hoarding Modes

Why hoarding? For a mobile host, connection is expensive in that it expends

bandwidth, battery life, hand off, etc. Moreover, planned and unexpected

disconnections are frequent, while some applications require access to data items

anywhere/anytime/anyhow. Lack of access to a data item may halt work on a particular

task or even make the computer unusable. Therefore, hoarding is very necessary to get

good data availability in that requested data items are saved on the local storage prior to

disconnection. We use a dual data / currency hoarding scheme, in which semantics of

data is indicated by the amount of currency. Data and currency flow in the system to meet

different needs of different users. The configuration of the database is dynamic.

3.2.1 Currency Hoarding Modes

Any shared data item in mobile databases is replicated as a primary and a set of

copies, i.e. logical data X = a physical primary of X + a number of physical copies of X.

The primary and copies all hold some amount of currency and may reside in any hosts.

The summary of currencies for each data is fixed: 100. Every data hoarding is

accompanied with currency hoarding. The amount of currency held by a given primary or

copy is used as the weight of that primary or copy during voting rounds. Additionally, the

amount of a data's currency indicates the semantics of the data, defined as following:

1) Primary currency: If the amount of currency is greater than 50, it indicates that
the replica is a primary. A primary has the majority of currency and hence has the power
to commit an update.

2) Updateable-copy currency: If the amount of currency is greater than 0 but less
than 50, the copy holding such currency is an updateable copy. An updateable copy may
propose a local update and start an election to collect plurality of currency votes to
commit the update.









3) Read-only copy currency: If the amount of currency is equal to 0, the replica is
a read-only copy. It may be involved in the anti-entropy progress to get the up-to-date
copy of the data, but it is not allowed to issue an update locally and it has no voting
weight either.

4) Undefined currency: If there is no definition of currency for a data item, it
means a host does not hold any copy of the data at all. An undefined currency is
represented as "I".

A copy currency is either updateable-copy currency or read-only copy currency.

There is no negative currency.

An object's currencies are flowed in the network via pair-wise currency

hoardings. The total amount of currencies is fixed at any time. There're three modes of

currency hoarding corresponding to data hoarding: currency G-hoarding, currency P-

hoarding, and currency C-hoarding.

* Currency G-hoarding

Before hoarding, the sender holds a primary currency. After b (0 < b < a) currency

goes to the receiver, the sender still owns a primary currency. Since the total currency for

each object is fixed, it's definitely that the receiver owns a copy currency.

* Currency P-hoarding

Before hoarding, the sender holds a primary currency. After b (b 2 50 c)

currency goes to the receiver, the sender loses the primary currency and only holds a

copy currency. The receiver now gets majority of currency and becomes the new primary

holder.






























Figure 3-1 Currency hoarding

* Currency C-hoarding

Before hoarding, the sender holds a copy currency. After b (b< a<50) currency

goes to the receiver, the sender holds a copy currency. If b is equal to a, then the copy in

the sender becomes read-only. The receiver now gets more currency.

There are three scenarios involving primaries that worth being noticed: primary

dilution, primary concentration and primary transfer.

* Primary dilution:

For a sender with a primary currency, if a currency hoarding-out results in a less

than 50 currency left, we say the primary is diluted at the sender.

* Primary concentration:


Currency G-Hoarding:
50
O b(b 50 +a-b c+b
Currency P-Hoarding:

O O
50 +a c
Sb(b > max(a, 50 c) 'O
50 +a-b c+b
Currency C-Hoarding:

0 O
a c
O b (b a-b c+b









For a receiver with a copy currency, if it collects a primary currency after a

currency hoarding, as we show above in currency C-hoarding, if (c + b) > 50, we say the

primary is concentrated at the receiver.


Primary Dilute:

O O
50 + a c
O b(b >a) O
50 +a-b c+b
Primary Concentrate:

O O
a c
p b(50-c a-b c+b


Figure 3-2 Primary dilution and concentration

* Primary transfer:

If both primary dilution and primary concentration happened in one hoarding

session for the same data, we know it is currency P-hoarding, in which the primary is

transferred from the sender to the receiver.

3.2.2 Data Hoarding Modes

There are two channels for a mobile host to hoard data: one is direct hoarding

from another host via pair-wise communication or docked connection, the other is

hoarding from broadcast. Data hoarding implies currency hoarding since currency is

always accompanying data. Data hoarding releases currency, therefore changes object

semantics.

The following notation is used to specify object status when hoarding an object:

Before hoarding: Sender (object, original sender semantics)









After hoarding: Sender (object, current sender semantics), Receiver (object,

original sender semantics, receiver semantics)

Where sender is the host that a primary or copy is hoarded from; receiver is the

host that receives the primary or copy; Sender and receiver might be fixed hosts or

mobile hosts. Additionally, broadcast server is the sender for hoarding in broadcast disks.

Sender/receiver semantics means the sender/receiver holds the primary or a copy of the

object.

In the figure below, Xp is the primary of X and Xc is a copy of X. "-" means no

primary or copy of data X is available in hosts.


G-Hoarding:




P-Hoarding:




C-Hoarding:







Figure 3-3 Data hoarding

* General hoarding (G-hoarding):

Sender owns the primary of an object, and receiver hoards a copy from the sender.

After G-hoarding, sender still owns the primary.

Before hoarding: Sender (object, Primary)

After hoarding: Sender (object, Primary), Receiver (object, Primary, Copy)









* Primary hoarding (P-hoarding):

Sender owns the primary of the object, and receiver hoards the primary from the

sender. After P-hoarding, the primary is transferred from the sender to the receiver and

the one in the sender becomes a copy.

Before hoarding: Sender (object, Primary)

After hoarding: Sender (object, Copy), Receiver (object, Primary, Primary)

P-hoarding can only be done via direct hoarding. It is not allowed to P-hoard data

from broadcast.

* Copy hoarding (C-hoarding):

Sender owns only the copy of the object, and receiver hoards a copy from the

sender. After C-hoarding, both the sender and the receiver held copies of the object.

Before hoarding: Sender (object, Copy)

After hoarding: Sender (object, Copy), Receiver (object, Copy, Copy)

3.3 Currency and Data Synchronization Modes

Any mobile host or fixed host may issue an update to its local data with an

updateable-copy currency. Such an update is called a tentative update. To commit a

tentative update, we borrow Deno's weighted-voting scheme to perform currency

synchronization: a mobile host issues an election to corner plurality of currency to

commit its update.

Data synchronization is done by anti-entropy sessions. In terms of data

synchronization, an anti-entropy session is a unidirectional flow of information

specifying elections that have been won and propagating the winner updates. Version

vectors are used to compare the differences between the communicating hosts. The state

of database will reach consistence eventually via anti-entropy.









3.3.1 Currency Synchronization Modes

The idea of currency synchronization comes from that of quorum in distributed

databases. Replication of data is commonly used in distributed databases to increase the

availability of services. In most cases, the consistency of the data must be maintained

despite node failures and/or network partitions. This can be achieved by requiring that, in

order to succeed, read and write operations obtain permission from certain sets of

replicas. These sets, called read and write quorums, are defined in such a way that any

two write quorums as well as any read and write quorums have at least one node in

common. Then, no two writes can succeed simultaneously thus excluding the possibility

of write conflicts. In addition, if every write performs on all replicas from a quorum, a

successful read operation is guaranteed to see at least one most recent replica of the data.

A currency quorum for an object consists of a set of replicas whose currency

summary is the majority of total fixed currency. An update should be accepted by a

currency quorum to get commitment. In this way, no two updates can succeed

simultaneously thus avoiding the possibility of conflicts. A primary has the currency

greater than 50, which forms a currency quorum, thus have the super power to commit an

update.

The definition of a currency quorum may be extended to compose a set of replicas

whose currency summary is the plurality of total fixed currency. When the majority

currency is unavailable but a set of replicas hold a currency summary that is greater than

that of all the other sets of replicas, it is said that the plurality of currency form a currency

quorum. Such currency quorum has the same power to commit an update. For example,

three sets of replicas get currencies as 40, 30 and 30. None of them can reach a majority









since the total is already 100. Then the set with the plurality currency of 40 gets its update

to commit.

Voting to collect currency to commit updates:

We assume a replication model in which data do not need to be replicated at all

hosts and multiple data can be replicated at the same host. A mobile host hoards data

before disconnection and reads local data and/or issues tentative updates. A fixed host

may issue tentative updates too. If the host holds the data's primary currency, a tentative

update may get committed at once. Otherwise, a tentative update seeks being accepted

globally by all the other hosts in the system. It is necessary to collect the majority or

plurality of total currencies to commit the tentative update. This process is done by

asynchronous weighted-voting scheme. We borrow it from Deno and extended it to

include cases of distributed database and broadcast disks.

An election is issued when a host decides to run to collect currencies to commit

its tentative update. Any election may have multiple candidates, which represent logically

concurrent tentative updates. Candidates from different elections might exist in the

system at the same time. A mobile or fixed host holding a non-zero currency for an object

X is a voter for elections of X. A voter becomes a candidate if it has a tentative update

and has not voted its currency to other candidates. A candidate always votes its currency

for itself.

Each voter independently collects votes from other voters and deduces outcomes.

Voter V, maintains following information for each object:

1) V1.completed: the number of elections completed locally.

2) Vlj]: index of candidate voted for by Vj in V,'s current election, or unknown, i.e. V, has
not yet seen a vote from Vj.









3) V1.currency[]: currency voted by Vj in V,'s current election, or unknown.

A candidate C, wins V,'s current election when:

1) votes (V, j) > 50, or // C gathers majority of voting currencies

2) v k j: votes(V,, k) + uncommitted(V) < votes(V, j), I/C, gathers plurality of currencies
or: (votes(V,, k) + uncommitted(V) votes(V,, j)) and (i
Where votes (Vy, j) is the summary of currencies known to V, voting for C,, and

uncommitted (V) is the summary of currencies unknown to V, for C,.

When Cj is awarded as the winner of V,'s currency election, the tentative update

issued by C, gets committed at V,. Currency synchronization for this update finished. The

commitment will be propagated to other votes via data synchronization.

3.3.2 Data Synchronization Modes

When a candidate update wins an election, it is committed at the host that awards

the election. Then the commitment information is propagated via anti-entropy sessions to

other hosts eventually. Version vectors are used to decide which host has the up-to-date

version in an anti-entropy session.

Version vectors. Every data item has a tentative local version number and a

finalized/committed global one. Any tentative update will cause the tentative version

number increase, while only committed updates lead to finalized version number

increment. All the finalized version numbers of all the shared data items form the version

vectors. For a host, if data item X has not been hoarded, its version vector is undefined.

Otherwise, version vectors compactly represent the set of updates known to a host.

Anti-entropy. The goal of anti-entropy in terms of data synchronization is for

two replicas to bring each other up-to-date. Version vectors are used in anti-entropy

session to enable a host to correctly determine which updates are unknown to the host by









comparing the version number of a data item to that of the host's anti-entropy partner.

The one has a larger version number will bring the one with a smaller version number up-

to-date.

When a tentative update is issued, it gets a locally monotonically increasing

tentative version number. Upon this update gets committed via currency synchronization,

a globally monotonically increasing committed number is assigned. As it propagated via

anti-entropy, all other replicas know the committed update and increase their committed

version numbers.

A host can choose its anti-entropy partner at random or based on other

knowledge, such as network characteristics or hint of location of primary. The pair-wise

anti-entropy protocol is designed to be uni-directional. One host brings anther one up-to-

date by propagating those updates not yet known to it. The protocol relies on the theory

of epidemics to ensure that committed updates eventually propagate to all other replicas

[8]. Therefore, the database states will eventually reach consistent. In this way, data

synchronization is done.

An update's life cycle. From the above description about data/currency

synchronization, we can see that the life cycle of an update that survives an election is

following:

A host issues a tentative update

The host becomes a candidate in an election

Updates and votes are propagated in a pair-wise fashion

Updates gather votes as they pass through hosts









An update commits when it gathers majority or plurality of votes (other tentative

updates are aborted)

Update commitment information is propagated to reach all hosts eventually via

anti-entropy sessions.

3.4 Hoarding and Synchronization Algorithms

3.4.1 Definition of Work Sets

We first give definitions of work sets that will be used in pair-wise connection

sessions.

The Hoarded Set (HS) for a host consists of primaries and copies hoarded, for

which currencies are defined, i.e. greater than or equal to 0. The Data Sync Set (DSS)

includes primaries and copies with updates committed. For read-only copies with zero

currencies, committed updates made elsewhere should bring the read-only copies up-to-

date. The Currency Sync Set (CSS) is composed of primaries and copies with tentative

updates in election, which hold non-zero currencies. The Request Set (RS) consists of

data requested by applications in a mobile host but not hoarded yet, i.e. currencies are

undefined. The Currency Redistribution Set (CRS) includes primaries and copies that

need adjust their currencies via currency exchange referring to metadata, which will be

detailed in chapter 4. The Global Work Set (GWS) is a logical set, which is the union of

HS and RS of all hosts in the database system.

For a host, there are following relations among its work sets:

DSS cHS cGWS

CSS cHS cGWS

CRS cHS c GWS









HS n RS = 0

DSS, CSS and CRS may or may not have pair-wise intersections.

The sets for a host are shown as following:


Global Work Set


HS
CSS
DSS
CRS





Figure 3-4 Relation of work sets

The above definitions are used in hoarding and synchronization algorithms. Upon

each pair-wise connection, there are four tasks to do in order:

1) Data synchronization: propagate committed updates in DSS via anti-entropy.

2) Currency synchronization: collect voting currencies for tentative updates in
CSS.

3) Data hoarding and accompanied currency hoarding: hoard requested data in
RS, and allocate currency.

4) Currency redistribution: redistribute currencies for data in CRS between peers.

Tasks 3 and 4 need to refer metadata, which is the topic of chapter 4. Currency

redistribution is focused in chapter 5.

For broadcast, only tasks 1 and 3 are performed. Moreover, the hoarding currency

is 0 in task 3.









3.4.2 Hoarding Algorithms

Data hoarding is always accompanied by currency hoarding (although in

broadcast, the hoarding currency is 0), but not vice versa. The amount of currency

dedicates semantics of data. Data semantics may be changed via currency exchange.

3.4.2.1 Direct Hoarding via Pair-wise Communication

Assuming that host S is the sender and host R is the receiver in the hoarding

session. The algorithm that R hoards data and currency from S is following:

For each data item X in R.RS /R.RS: request set ofR
IfX E S.HS (hoarded set ofS) andR is authorized to hoard X
S sends data X to R /R hoards data from S
R.X tentativeVersionNumber = 0
R.X.committedVersionNumber = S.XcommittedVersionNumber

//currency hoarding
R consults S to decide initially allocated currency C
S.X.currency -= C /decrease currency from sender
R.X.currency + C /increase the same amount of currency

/copy election and voting information
R.X.completed = S.X.completed //completed # of elections
R.X V,[r] = S.X Vf[s] /R votes for the same candidate as S, or
unknown, i.e. not vote yet. r and s are index of R and S, i is the
current election that is active.

R.RS = R.RS {X} //remove Xfrom request set ofR
R.HS = R.HS u X} //add X to hoarded set ofR

In the above algorithm, the same amount of currency is decreased from the sender

and increased at the receiver to maintain the fixed total currency per object. The receiver

votes for the same candidate as the sender if sender voted, or unknown if the sender has

not done so. The number of completed elections is actually the committed version

number of the data.









3.4.2.2 Hoarding via Broadcast

Only committed versions of data are allowed to broadcast. Any host hoards data

from broadcast can only get read-only copies, i.e. currency of data hoarded from air is

always 0.

Assuming that host R is the receiver in the hoarding session, R hoards data and

currency from broadcast server B using following algorithm:

While R is listening to broadcast
If the current broadcasted data item X E R.RS (request set ofR)
R grabs data Xfrom the air /R hoards data from broadcast
R.X tentativeVersionNumber = 0
R.X.committedVersionNumber = B.X.committedVersionNumber

//currency hoarding
R.X currency = 0 R is assigned a read-only copy currency

/copy version information
R.X completed = B.X completed //the number of completed
elections is actually the committed version number of data X

R.RS = R.RS {X} //remove Xfrom request set ofR
R.HS = R.HS u {X} //addX to hoarded set ofR

There is no need to copy election and voting information in hoarding via

broadcast, because data copies hoarded from broadcast are read-only copies with zero

currencies, which have no right to vote. Read-only copies may change their semantics to

updateable copies or even primaries via currency exchanges detailed in chapter 5.

3.4.3 Synchronization Algorithms

Data hoarding is always accompanied with currency hoarding, while data

synchronization is separated from currency synchronization. Voting scheme is used to

perform currency synchronization, and data synchronization is done via anti-entropy after

currency synchronization is finished. So we talk about currency synchronization first.









3.4.3.1 Currency Synchronization

Currency synchronization is performed when two hosts, say sender S and receiver

R, get connected. Synchronized currencies flow from S to R and collect more amount if

there are compatible currencies in R. It is said currencies are compatible if they vote for

the same candidate in current election or at least one of them is unknown. For a data item

X, if both S and R know the most recent committed version number of X, and S has voted

for current election of X while R has not, then R votes for the same candidate as S.

Data synchronization will bring previously committed information from S to R, so

we need not worry about that S and R have different most recent committed versions.

For each data item X S. CSS // Xis seeking currency synchronization
j = the index of the candidate that S votesfor in the currency election ofX
IfX E R.HS //R has a replica ofX
IfR.X Vr[r] is unknown //R has not vote for current election
R.X. V[r] j
Get the vote information of other hosts unknown to Rfrom S

Update R.X Votes(Vr,k) = X R.X Vr.currency[i]

s.t. R.X Vr[i] ==k, for each k = 1.. n
Update R.X V. uncommitted
I = max {R.X Votes(Vr, k)}, where k = 1.. n

IfR.X Votes(Vr, 1)> 50 //majority of currencies
Award I as election winnerofX
Else for each other candidate t //findplurality of currencies
IfR.X Votes(Vr, 1) > R.X Votes(Vr, t) + R.X V,.uncommitted
Award I as election winner ofX

There are following work to do when I is awarded as election winner of X:

R.X.committedVersionNumber ++
R.X.committed[R.X.committedVersionNumber] = 1
R.X CSS = R.X CSS {X} // remove Xfrom currency sync set since
currency sync ofX is done
R.X.DSS = R.X.DSS u {X} //add X to data sync set









Currency synchronization cannot be performed via broadcast, because there is no

effective currency flow in broadcast (only zero currencies in broadcast).

3.4.3.2 Data Synchronization

Data synchronization is performed via anti-entropy in pair-wise connection or

broadcast. Committed updates are propagated instead of committed database contents.

The reason is that the amount of data propagated during data synchronization is

proportional to the update activity at the replicas instead of being dependent on the

overall size of the data being replicated. Thus, when the database size is much larger than

the database updates, the bandwidth required for the execution of the protocol is reduced.

Furthermore, the propagation of update operations avoids any ambiguity introduced by

the creation and deletion of replicated objects [23]. Protocols based on the exchange of

deltas or differences in data values require additional mechanisms to correctly handle this

ambiguity because the existence of a value at one replica and the lack thereof at another

cannot correctly identify whether the value is new or it has been deleted.

Data synchronization via anti-entropy by pair-wise connection

Assuming sender is S and receiver is R.

For each data item X E S.DSS /X is known by S as committed
IfX E R.HS and
R.X committedVersionNumber < S.X.committedVersionNumber
R performs each committed update unknown to it
R.X.committedVersionNumber = S.XcommittedVersionNumber
R.X CSS = R.X CSS {X} //election winner got awarded elsewhere

Data synchronization via anti-entropy by broadcast

Assuming the broadcast server is B and the receiver is R.

While R is listening to broadcast
If the current broadcasted data item X E R.HS
R grabs data Xfrom the air









IfR.X committedVersionNumber < B.X committedVersionNumber
R performs each committed update unknown to it
R.X.committedVersionNumber = B.X.committedVersionNumber
IfX E R.X CSS
R.X.CSS = R.X.CSS X}
//election winner got awarded elsewhere.

Data synchronization by broadcast will significantly speed up the process toward

database consistency in that all listeners may get the commitment information at the same

time and need not wait for the lazy propagation.














CHAPTER 4
METADATA MANAGEMENT FOR MOBILE DATABASES

Recent advances in wireless networking technologies and the growing success of

mobile computing devices are enabling new issues that are challenging to mobile

database designers. Mobile hosts have to deal with planned or unexpected disconnections

when they mobile; they discover other hosts in ad-hoc manner; they are likely to have

scarce resources such as low battery life, slow processor speed and limited memory; their

applications are required to react to frequent changes in the environment such as new

location, high variability of network bandwidth; their data interests are changing from

time to time and from location to location; even data semantics in mobile hosts are

varying according to data access patterns, connection duration and disconnection

frequencies, etc. All of these require a dynamic database design and reconfigure scheme.

In the past decade, there are some technologies like middleware technologies have

greatly enhanced the design and implementation of distributed applications [10]. They

successfully hide away many requirements introduced by distribution such as

heterogeneity, fault tolerance, resource sharing, and etc. But these technologies have been

designed for static distributed systems built with fixed networks. They are not suitable for

the dynamic characteristics of mobile environment. For example, static distributed

systems assume high bandwidth connection and constant availability. While in mobile

environments, low bandwidth and disconnection are normal rather than unexpected.

Mobile databases have to be aware of and adapt to the varying contexts such as

fluctuating network bandwidth, access patterns, decreasing battery power, location









changes and so on. In order to dynamic design and reconfigure the mobile databases, it is

necessary to use metadata to record the changing context and adjust the data distribution.

Metadata is the activity styles and constraints data of mobile hosts. It consists of

connectivity, availability, data access patterns and user-defined constraints. The metadata

of a mobile host reflects its priority to hoard data in the network and may be mapped to

some amount of currency.

The roles of metadata include:

1) Identify data user cares about (Domain): What data interests me?

2) Specify relative worth of data (Utility): What is its relative worth?

3) Indicate power of mobile host (Priority): What's my activity pattern?

In this chapter, we first give the general categories of metadata in the mobile

databases. Then we focus on a subset of metadata and talk about management algorithms.

4.1 Categories of Metadata in Mobile Databases

Generally, metadata in mobile databases is composed of data of connectivity,

availability, data access patterns and user-defined constraints.

4.1.1 Connectivity

In mobile databases, connectivity of a mobile host is the ability to connect to or

communicate with another mobile host or fixed host. There are several aspects related to

connectivity:

1) Connection status: strong connected, weak connected or disconnected?

2) Interconnectivity: Is a mobile host connecting with another mobile host or a
fixed host? In the past time period, how many hosts did this mobile hosts connect with?

3) Bandwidth: the capacity for data transfer between the two hosts in their
communication.









4) Duration: the time during which connection is available. Connection duration
in a time period is the summary of connection time.

5) Discontinuity: disconnection frequencies, and periods between connect
durations. This parameter represents the lack of connection of mobile hosts. For example,
in a one-hour period, two mobile hosts both have 30 minutes connection time, but the one
that has 5 disconnections has different connectivity from the other has no disconnection.

6) Time pattern: statistics data about when a mobile is most likely to connect. For
example, does it usually connect in weekdays or weekends, am or pm?

4.1.2 Availability

Availability shows us what kinds of data are available in a mobile host, how fast

and where it is, and the robustness.

1) Data semantics: according to the semantics represented by currencies, there are
four levels of data semantics:

Primary: the replica has a primary currency.

Updateable copy: the replica has an updateable copy currency.

Read-only copy: the replica has a read-only copy currency.

Unavailability: the amount of currency is undefined at a mobile host, which
means no such data is currently hoarded in.

2). Delay: there are two kinds of delays: one is query delay, which is from the
time that an application raises a query to the time that it receives reply. The other is
update commit delay, which is from the time an application issues a tentative update to
the time when the application gets to know the commitment of its update.

3). Locality: where is a mobile host? Is it in the center, edge, or periphery of a
particular region? We may use the triangulation teemingness to get coarse location data.
Soon every device in the universe will have a GPS, so it is even possible to know the
precise location of a mobile host. What a user cares about might changes radically
depending on where he or his possessions are.

4). Reliable and failure recovery: is this mobile reliable? Whether and how fast is
it able to recovery from failures?

5). Ability: how much is a mobile host able to do? For example, how much is its
memory and how long is the battery life?









4.1.3 Access

Access represents data interests and satisfactory with the system from the point of

view of applications or clients of a mobile host.

1). Hot data: who is the hottest? It may be evaluated referring to the read and
write frequencies.

2). Tentative update frequency: the number of tentative updates issued by a
mobile host.

3). Update commit rate: the number of tentative updates having got committed in
a time period.

4). Update commit delay: the mean time of the commit delay for a mobile host.

5). Query satisfactory: what is the rate of reply to request?

4.1.4 User-defined Constraints

Besides the metadata collected from runtime, users may specify some parameters

that may affect the database distribution. For example, a user may specify his patience of

waiting for a query reply. Another example is a team leader may have more priority in

data semantics than his team members when they travel out to support their clients.

4.2 Metadata Collection in Mobile Databases

4.2.1 Focused Subset of Metadata

As described in the previous section, there are quite a number of categories of

metadata in mobile databases. It is impractical for us to maintain all of them at this time

since there is much work to do and it is out of the scope of this thesis. Therefore, we just

focus on a subset of the categories and choose those of them that are good enough to

show the benefits of metadata and can be maintained with low overhead. Since the cost is

low, it is more efficient to refer to the metadata to dynamically design and reconfigure

mobile databases.

The focused subset of metadata is given below:









1) Connection duration

2) Disconnection frequency

3) Access statistics: query and tentative update frequencies

4) Commit rate, and

5) Commit delay.

Here the connection status, duration and disconnection frequencies are metadata

of mobile hosts, and the others are metadata of data items, which needs to be maintained

for each data item in a mobile host.

The chosen subset of metadata has significant impact to behaviors of mobile

databases. Due to the weak and intermittent wireless connection, the cost of

communication bandwidth and frequent disconnection, static data and currencies

assignment will hurt the performance of mobile databases. For example, if a mobile host

changes its connection statistics from strong connection, long duration to weak

connection, short duration, should it have the same currency as before? No. It is better to

give some of its currency to other mobile hosts that have better connection so they have

more power to access and commit data, hence improving the database performance. The

metadata of connection status, connection duration and disconnection frequency give the

connection statistics of a mobile host. It is important to collect such metadata to

reconfigure mobile databases.

The metadata of access statistics and commit delay plays an important role in

database reconfiguration. The hotness of data items is pointed out by access statistics. If

the access is becoming more frequent than before, it means the data here is becoming

hotter and needed more heavily by applications. The currency of data should flow to the









place where the data are accessed more frequently. Commit delay and commit rate may

be used to indicate the satisfaction of applications to the services of mobile databases. A

mobile host with high priority needs to commit more updates as much as rapid. Such

mobile host should get more currency, i.e. the mobile databases are reconfigured.

4.2.2 Metadata Collection

To collect metadata, a monitoring scheme is needed to record what happens in a

mobile host. Sliding window scheme is used to implement incremental metadata

collection.

A sliding window is a time frame with a predefined time interval, and the end

point of the frame being the current real time. Window width is the time duration of the

sliding window. It might be more precise to use different width of time sliding windows

to different metadata since they may have different time characteristics. While for

convenience and simplicity, we use the same constant width of sliding window for all

metadata involved.

Events in a sliding window include connection, disconnection, read, tentative

updates and update commitment. Such events are logged in the time order that they

occur. Since the capacity of a mobile host is limited, we cannot afford to storage them all

from the very beginning. So the metadata collection algorithm is designed to log only the

events in the time range of a sliding window. The log is called bounded window log.

Sliding windows consume events as well as store them. When an event occurs, if

the size of the sliding window has not reach its limit, the event is logged and its effect is

reflected to the metadata. If the sliding window grows to its upper limit, an old event is

retired and its effect is eliminated from the metadata when the new event is added. In this






40


way, the metadata always remember the effects of events in the most recent bounded

history. Figure 4-1 gives an example of sliding windows for a mobile host.



I- .. .. _.. _... ... ... ... ... .. _.. 1
S-........._. ............. io
tl t2 t3 t4i t6 t7 t t9 Itll tl2 tl3 t14i
il l I li I I I- I I- I I il time
Cn H(Y) DisC Q(X): Con H(X) R(X) R(Y) W(X) Com(X) R(X) ]isC


sliding window Wk
~ sliding hr-d -- -... .. .

Figure 4-1 Time sliding windows

As shown in Figure 4-1, the x-axis represents time. The two dashed rectangles are

marked as sliding windows w, and wk. w, is from to to tio and wk is from t5 to t15. The

events are recorded in these two sliding windows as: connect (ti), disconnect (t3), connect

(t6), read X (ts), read Y (t9), tentative update X (tn1), commit update X (t12), read X (t13),

disconnect (t14). In this figure, G-hoarding Y (t2), request X (t4) and C-hoarding X (t7)

will not be logged as metadata of the mobile host. They are put there just to show when

they occur.

The events happened are recorded in a log. Log length is the time duration from

the first event to the last one in the log. The algorithm to collect metadata at a mobile host

is given as following:

While (true)
If an event e comes at time t
/Log the event
add e to the log
switch (e)
case connect:
save connect status and connect start time
case disconnect:
save connect status and connect end time
increment duration by the real connection time









increment disconnect fequency by 1
case read:
increment read fequency of the accessed data item
case tentative update:
increment tentative update frequency of the updated data item
save the issue time of the tentative update
case committed-update:
increment commit update frequency of the updated data item
save the commit time of the tentative update
calculate commit delay of this update
calculate the mean commit delay
calculate commit rate

If log length is greater than the length of a sliding window
tstartl = the start time of the previous window
tstart2 = the start time of the current window
For an event e happened at time t' E [tstartl, tstart2)
//Eliminate effects of the event
switch (e )
case connect:
tdisconnect = the time of disconnection for e'
if tdsconnect E [tstartl, tstart2)
decrement duration by (tdisconnect t)
delete the disconnection event from the log
decrement disconnect fequency by 1
else
decrement duration by (tstart2 t')
case disconnect:
decrement duration by (t' tstart)
decrement disconnect fequency by 1
case read:
decrement read fequency of the data item by 1
case tentative update:
decrement tentative update frequency by 1
case committed update:
decrement commit update frequency by 1
decrement commit delay
calculate the mean commit delay
calculate commit rate
Delete e 'from the log

In the above algorithm, the mean commit delay for each data item is maintained

as the total commit delay divided by the commit update frequency in the current time

sliding window. The metadata that is used in currency redistribution includes connection









duration, disconnect frequency, read frequency, tentative update frequency, update

commit rate and the mean commit delay.

It is clear from the algorithm that the overhead to collect metadata for a mobile

host is trivial. The main overhead is the I/O cost to store the event and update metadata

when an event occurs. The storage of the metadata and events needs only a couple of disk

pages that is very small comparing to the capacity of the mobile hosts. Other overhead is

just some CPU cycles. There is no message cost since it happens totally locally.

Therefore, the overhead to collect metadata for mobile hosts is very small and the

potential benefits may well worth the effort.

So far we have talked about local metadata for mobile hosts. Logically, global

metadata is the union of all local metadata and it is decentralized. To form global

metadata, local metadata may be piggybacked with anti-entropy messages to get to be

known by all the hosts in the system. For ad-hoc databases, it is performed in a

decentralized manner to collect metadata and redistribute currency via pair-wise

communication. While in distributed databases, global metadata is more powerful to do

reallocation in the point of the view of the whole system.

For a fixed host in the distributed network, the focused subset of metadata mainly

includes access statistics, the rate and delay to commit updates. The algorithms to get

such information are similar to those for mobile hosts. Such local metadata is maintained

for each data item at each fixed host and the union of local metadata is the global

metadata. The union operation may be performed explicitly at request of a fixed host, or

local metadata may be piggybacked with anti-entropy messages to propagate to other

hosts.






43


Now with the metadata in hand, it is ready to refer it to redistribute currency. It is

addressed in the next chapter.














CHAPTER 5
DYNAMIC CURRENCY ALLOCATION AND REDISTRIBUTION

As stated in previous chapters, traditional distributed databases are static in that

data allocation is determined and will not be changed. But the dynamic characteristics of

mobile environment require that mobile databases are designed and reconfigured in a

dynamic manner. The varying characteristics are recorded as metadata. In the mobile

databases, the semantics of a data replica is indicated by the amount of currency.

Furthermore, the semantics may be changed to adapt to the environment characteristics

and database accesses. Metadata is referred to determine the data semantics in that the

amount of currency is redistributed and thus data replicas are reallocated.

In the previous chapter, metadata is classified and the collection algorithms are

given. This chapter is focused on how to do currency redistribution referring to metadata.

5.1 A Target of Currency Allocation

There are a large number of categories of metadata in mobile databases as

described in section 4.1. This thesis is focused on a subset of them: connection duration,

disconnection frequency, statistical data of accesses, update commit delay and commit

rate.

To allocate currency while taking advantages of metadata, a policy of assigning

weights to metadata and mapping it to currency is needed. All the database members

have to agree to the weight assignment policy to metadata. Intuitively, positive weights

should be given to the metadata of connection duration, read frequency and tentative

update frequency. It is obvious that a mobile host with longer connection duration, more









frequent read/write accesses and higher commit rate plays a more important role and

should get more currency. While the metadata of disconnection frequency and commit

delay should be assigned negative weights since they reveal the inability of a mobile host.

These numbers of weights may be customized according to the expected

performance and requirements of the system.

The weight of a replica is the summary of production of metadata weight and the

value of metadata, which is composed of two parts: one comes from metadata of the

mobile host i.e. connection duration and disconnection frequency, the other consists of

weights of metadata of the replica, i.e. read frequency, tentative update frequency,

commit update frequency, commit rate, and mean commit delay.

Weight of a replica Xi is defined as W(X1) = _m w(m), where M is the union
meM

of sets of metadata for the replica and metadata for the mobile host where the replica

resides, and w(m) is the weight of metadata m.

The mapping of currency to weight is in direct proportion: a replica with more

weight will be given more currency, i.e. for two replicas X1 and X2, their total currency is

C, and they have weights W1 and W2, respectively. Then they should get currencies Ci

and C2, respectively, calculated as following:

C1 C W1(WI+W2)

C2 C W2 (W+ W2)

Metadata is collected only after a mobile host has hoarded a replica. It is not

available when the data is first hoarded. In this case, expected metadata or user profiles

should be given as the initial metadata.









5.2 Dynamic Currency Redistribution Referring to Metadata

Metadata records access statistics of databases and connection statistics of mobile

hosts, i.e. which data are hot and which sites are hot. Currencies flow in the system

dynamically and adapt to the use of databases. They are always going toward the place

where they are needed most: hot sites and hot replica. But in order to be correct and

efficient, it should be careful to exchange currencies among replicas in mobile and fixed

hosts.

5.2.1 Correctness Requirements of Currency Redistribution

In the weighted voting scheme, the most important property is that the total

currency of an object is fixed for any election. In currency exchanges, this property

should be maintained carefully, otherwise if the amount of total currency is not fixed any

more, the correctness of the scheme will be hurt: there is no way to determine majority or

plurality hence no way to commit updates.

The correctness requirements of currency exchange consist of following two

items:

1) No more: Any amount of currencies of any replica should not be used more

than once in any election.

2) No less: Any amount of currencies of any replica is available to every election,

i.e. should be used at least once.

From the above two requirements, it is implied that any amount of currencies of

any replica will be used exactly once in every election. To satisfy the requirements, the

currency exchange policies should be designed carefully to select the elections that the

exchanged currencies take effective.









5.2.2 Currency Redistribution

In currency redistribution, there are two things to determine: one is how much

currency each involved host should get, the other is when or from which election the

redistributed currency should take effective? They will be addressed respectively in the

following three scenarios:

Between two weak connected mobile hosts. In this case, mobile hosts

communicate in pair-wise manner. The amounts of currencies are directly proportional to

the weights of replicas they have. Assuming both mobile host M1 and M2 have replicas of

data item X, and hoard currencies C1 and C2 respectively. The weights calculated from

metadata are W1 and W2, respectively. Then the target amounts of currencies of the two

mobile hosts should be the following:

Currency for the replica in M1 is Ci' = (C1 + C2) Wi / (Wi + W2), and

Currency for the replica in M 2is C = (C + C2) W2 / (Wi + W2).

So the transferred currency between these two mobile hosts is as following:

AC = I Ci' C2'1 = (C + C2) I W W2 /(Wi + W2).

These two mobile hosts M1 (with most recent election el on data X) and M2 (with

most recent election e2 on data X) would like to exchange (say, from M, to M2) currency

AC of replicas of X in their pair-wise communication. The currency synchronization

performed prior to the currency exchange will bring the replica with lower commit

version number up to the replica with the higher commit number.

The currency exchange is effective in election e, which is defined as following:

1) If ei < e2, then e = e2. Mi has not voted for election e (e is unknown in Mi), so

AC can be used in e of M2.









2) If el == e2:

If both M1 and M2 voted for the same candidate or neither of them voted,

then e = e2.

If M1 voted but M2 did not: if M2 will vote for the same candidate as M1,

then e = e2, otherwise, e = e2 + 1.

If M2 voted but Mi did not, then M2 will vote AC for the same candidate

as the one M2 voted C2 for, i.e. e = e2.

If both M1 and M2 voted but for the different candidates, then e = e2 + 1.

3) If ei > e2:

If M1 voted, then e = ei + 1. Since AC has been used by M1 in elections e2,

e2 + 1, .. el, it can only be used in M2's future voting from (ei + 1).

If Ml has not voted for el, then e = ei.

Among fixed hosts and/or strong connected mobile hosts. Assuming replicas

of data item X are hoarded by fixed hosts and/or strong connected mobile hosts numbered

from 1 to k, their current weights are W1, ... Wi, ... Wk and their currencies before

redistribution are C1, ... Ci, ... Ck. The amount of currency a replica should get after

distribution is directly proportional to its weight:

k k
Ci' = ( Cj) Wi / ( Wj)
J=1 J=1

The currency redistribution is performed via distributed transactions. Due to the

good network communication of fixed hosts and/or strong connected mobile hosts, it can

be seen that all of them have the same current election e'. For a host i who hoards AC =









(Ci' Ci) from other hosts, the currency exchange is effective in election e, which is

defined as following:

1) If AC has not been voted or voted for the same candidate as the host i voted,

then e = e'.

2) If AC has been voted but the host i didn't vote: if the host i will vote for the

same candidate, then e = e'; otherwise, e = e' + 1.

3) If AC has been voted and the host i voted but for different candidates, then e =

e' + 1.

It is possible that AC comes from more than one host, i.e. AC = AC1 + AC2 +... +

ACm. Then the host i hoards AC1, AC2, ... ACm one by one, using the above algorithm to

get effective elections for each of hoarded currencies.

Between a weak connected mobile host and a fixed host. In this case, the

currency exchange may involve one or more neighbors of the fixed host. Considering the

scenario that the currency in the fixed host is not enough to meet the requirement of the

mobile host, the fixed host may have to borrow some currency from its neighbors. Or the

mobile host may want to return more currency to the fixed network and the currency

should be distributed to more fixed hosts. These will cause currency shrink or currency

swell in the distributed databases. They are performed via distributed transactions and are

transparent to the mobile host.

1) A mobile host hoards currency from a fixed host:

It is similar to the case between two weak connected mobile hosts if the fixed host

has enough currency to give. Otherwise, the fixed host will borrow currencies from one









or more of its neighbors to cause such neighbors shrink in currencies, as illustrated in the

Figure 5-1.




AC "- ,---i




Figure 5-1 Currency shrink in fixed hosts to meet the hoarding request of a mobile host


The amount of currency a fixed host shrinks is directly proportional to its weight

of the replica:

k
ACi = AC Wi/( W)
J=1

If AC comes from only the fixed host, the effective election of the currency

exchange is defined similar to the case between two weak connected mobile hosts. If AC

comes from more than one fixed host, i.e. AC = AC1 + AC2 +... + ACm. then the mobile

host hoards AC1, AC2, ... ACm one by one, and get effective elections for each of

hoarded currencies.

2) A mobile host returns currency to a fixed host:

In this case, the mobile host gives some or all of its currency to the fixed host.

Then fixed host then distributed the currency to its neighbors to cause their currencies

swell. There are two steps to go: the first is AC go to the fixed host, the second is AC get

distributed.

The amount of currency for a fixed host i should increase is:

k
ACi= AC* Wi/( Wj)
J=1

















Figure 5-2 Currency swell in fixed hosts when a mobile host returns currency

In this case, since the fixed hosts in the fixed network have the same election, the

effective election of AC is the same for all the involved fixed hosts. It is defined similar

to the case among fixed hosts.

5.3 Ad-hoc Database Check-out/Check-in Currency

When the mobile hosts are all docked (strong connected), all the mobile and fixed

hosts have good communication. The mobile database now becomes a distributed

database. When some or all of mobile hosts weak connected, they form an ad-hoc

network and their database is an ad-hoc database. The ad-hoc database carries out some

or all of currencies and perform database operations in ad-hoc manner. For each

individual mobile or fixed host, the currencies are redistributed referring to metadata

using the scheme given in section 5.2. Primaries may dilute, concentrate or be transferred

in or between ad-hoc database and the distributed database.

The scenario of ad-hoc database checking out currency is given in Figure 5-3.


Figure 5-3 Scenario of ad-hoc database checking out currency









When the ad-hoc is all docked, the mobile database is actually a distributed

database. So traditional distributed database management can be used to run the system,

except that metadata collection is performed. When the ad-hoc is half docked or all

undocked, the mobile database now consists of ad-hoc database and distributed database.

So the database should switch to dynamic, weighted voting scheme to take the

advantages of dynamic redesign and reconfigure via dynamic currency redistribution.

The scenario of ad-hoc database checking in currency is shown in Figure 5-4.




~O





Figure 5-4 Scenario of ad-hoc database checking in currency

When all the mobile hosts return to the fixed network thus the ad-hoc network

becomes all docked, the mobile database is now becoming a distributed database again.

The dynamic, weighted voting scheme may be switched to the traditional way of

distributed database system.

5.4 Creation and Retirement of Currency and Data

Assuming that the fixed global work set, once created, will not change. For

mobile and fixed hosts, creation of currency and data happens when the hosts hoard a

replica. The replica will be allocated some currency while ensuing that the total currency

for a data item in the system is always is fixed.

Fixed hosts have large capacity, so they can always store data replicas. Even

when they have not used a data replica for a long time, the system just leave its currency









as zero to indicate the infrequent use of data, instead retire the data replica from the fixed

host.

The capacity of a mobile host is limited, so it cannot afford the cost to store a

replica that it will not need any more, especially when the replica needs a large storage

space. After giving all its currency to one of its peers, now the host has a replica with

zero currency. To retire the replica, the host has to retire its currency first, i.e. setting its

currency to undefined. Then the replica is deleted from the disk of the mobile host. There

is some housekeeping to do: remove the replica ID from HS (hoarded Set), delete its

metadata, votes and election information, etc.














CHAPTER 6
SIMULATION

To demonstrate the benefits of the protocols given in previous chapters, a

simplified simulation has been implemented. It simulates the behaviors of mobile hosts

under two cases: dynamic currency redistribution and static currency allocation. The

metrics of our focus are commit rate, commit percentage and commit delay. Before

qualifying the performance of the protocols, the simulation assumption and settings are

described first.

6.1 Simulation Assumption

The simulation has been implemented using Java in a local area network

environment, i.e. CISE network. A host is implemented as a process running on a UNIX

Solaris machine remotely and UDP data grams are used to communicate among

processes. Since UDP is not reliable, in general, we may expect that our data packets

could be lost, duplicated or delivered out of order. But in the CISE network, this will not

really be a concern.

The focus of the simulation is to show the benefits of dynamic currency

redistribution among mobile hosts, so the fixed network is concentrated as one fixed host

to avoid currency shrink and currency swell in distributed databases. Four mobile hosts

are modeled and each of them has an event creator which generates events to simulate the

activities of a real mobile host. The main assumptions are:

1). The database is a single object database, i.e. there is only one object shared
among these hosts.









2). Data hoarding is assumed to be performed prior the simulation, i.e. each host
has a non-zero currency of the object when the simulation is started.

3). The generated tentative updates are independent so that the abort or
commitment of a tentative update does not have any effect on the other tentative or
committed updates.

4). Applications read committed updates only. Tentative updates are unavailable
before they commits.

5). The mobile hosts are failure free, so we need not worry about currency loss.

The metadata in consideration includes connect duration, disconnect frequency,

read and tentative update frequencies, commit rate and commit delay.

6.2 Simulation Model

The simulation is designed to be started by an initiator, which takes a configure

file and start hosts according to the arguments as configured. Each host is running

remotely and working independently with regard to their own configures after being

started. The following figure illustrates the scenario of the initiator and the hosts.


Figure 6-1 Initiator and hosts in the simulation









The simulation of a mobile host consists of a processor and a listener. The

algorithm of a processor is following:

Initialize;
While the simulation is not yet finished
If the message queue is not empty and the host is connected
Process messages;
Get next event from event creator;
Process event;
Add event to time sliding window;
If the time sliding window is over size
Adjust the window;
End while

A listener is implemented as a thread to receive messages from other hosts and

put them to a message queue. The message queue is accessed synchronously by the

processor and the listener of a host.

There are two types of messages being sent and received: REQUEST messages

and REPLY messages. A REQUEST message is composed of committed update table,

election, currency and weight of replica. A REPLY message includes committed update

table, election and delta currency. The committed update table is used to propagate

committed updates among peers in data synchronization. The election is used in voting

scheme to collect currencies. The currency and weight of replica are used in currency

redistribution.

For a mobile host, if the current event is CONNECT, then the host will send a

REQUEST message to the selected peer. The peer will perform data synchronization,

currency synchronization and currency reallocation according to their weights and send

back a REPLY message to inform the results. Messages in the model of a host are shown

in the following figure:











Processor:
REQUEST
Process event CONNECT

Data Synchronization I
S Listener: Currency Synchronization RE
IREQUEST Currency Redistribution
REPLY Message
Qee Data Synchronization
QCurrency Synchronization
REPLYCurrency Redistribution



Figure 6-2 Messages in a mobile host

6.3 Simulation Settings

In mobile database applications, access of the database items may varies

according to the interests of the mobile applications. So the simulator should mimic the

activities of mobile applications and generate different events to cause hot spot

transferred among the hosts. To get different frequencies of events, intervals between two

consecutive events are configured for each host. Roughly the activity patterns of each

host are designed as two sections: the fixed host 0 is configured inactive in the first

section but active in the second section; mobile host 4 is configured active in the first

section and inactive in the second section; the other mobile hosts are configured inactive

in both the first and second sections.

One of the most important parameters is the tentative update ratio. According to

the simulation assumption, all the tentative updates are independent. A tentative update

should be issued to win an election to get committed. The election performs currency

synchronization among replicas and currencies are intended to be redistributed to flow to

the hottest place of the system. It is expected that the tentative update ratio have direct










impact to the commit rate and commit delay. Relative to the frequencies of read events,

the tentative update frequency ratios are designed from 0.1 to 0.6.

The width of the time sliding window is also important in that a too wide window

causes the metadata data changes slowly thus currency flow slowly so may not catch the

hot place in time, while a too narrow window is vulnerable to some false frequent events

and lead to unnecessary currency flow hence decrease the efficiency of the system.

The scenarios of static currency allocation simulated in this model are uniform

currency allocation and primary currency allocation. The former is a case of non-primary

scheme and the latter is equivalent to the primary-copy scheme. To compare the

performance of the dynamic design to the static design, the scenarios of dynamic

currency redistribution design are simulated under the same initial currency allocations as

the static cases.

The main simulation parameters and settings are summarized in Table 6-1 as

follows.

Table 6-1 Primary simulation parameters
Parameter Setting Description
windowWidth 6 seconds Width of time sliding window
simuTime 80 seconds The time of simulation running
simuSection [0, 40], [40, 80] Simulation time sections
The ratio of tentative updates
updateRatio 0.1, 0.2, 0.3, 0.33, 0.4, 0.5, 0.6 i
to read events
Hosts HostO Hostl Host2 Host3 Host4
Internals First
In s Ft 1.0 1.0 1.0 1.0 0.1 Intervals between two
between two section
between two s n consecutive events in different
consecutive Second
Sconsecute Second 0.1 1.0 1.0 1.0 1.0 time sections
events (seconds) section

Initial currency Uniform 20 20 20 20 20 These are the initially allocated
allocation currencies. For static cases,
(total = 100) Primary 60 10 10 10 10 they are not to be changed.









The settings show that in the first section, the host 4 is very active and the other

hosts are not, while in the second section, the hot point transfers to the host 0 and the host

4 becomes cold. The purpose of such setting is to show the most currency is always

intended to flow to the hottest host.

6.4 Simulation Results

The analysis of the simulation results is focused on the commit rate, commit

percentage and mean commit delay. The commit rate is defined as the average number of

committed updates per time sliding window. The commit percentage is the ratio of

committed updates to the total tentative updates generated in the system. The commit

delay of a committed update is defined as the difference from the tentative update issue

time to the time that a host knows its commitment. Mean commit delay is the mean delay

time of committed updates in the system averaged to all the hosts.

The simulation results demonstrate that the dynamic design is more beneficial that

the static design. Two scenarios are studied to qualify the performance: one is uniform

scenario, i.e. the currencies are initially allocated to each replica uniformly; and the other

is primary scenario, in which the primary currency is initially given to one replica. The

initially allocated currencies remain unchanged in static cases while dynamically change

with weights/metadata of replicas in dynamic cases.

6.4.1 Commit Rate and Commit Percentage

The commit rate and commit percentage of dynamic cases versus static cases of

uniform scenario are given in Figure 6-3 and Figure 6-4.












10
8
6 -- dynamic
E 4 --- static
E
0
S2 -
0
0.1 0.2 0.3 0.4 0.5 0.6
update ratio



Figure 6-3 Commit rate of uniform scenario


1
0.8-
0 0.6 --- dynamic
a- 0.4 --- static
E 0.2
0
8 0
0.1 0.2 0.3 0.4 0.5 0.6
update ratio



Figure 6-4 Commit percentage of uniform scenario

It can be clearly seen that the dynamic design is much more beneficial than the

static design except when the update ratio is rather low. Specifically, when the update

ratio is 0.1, little benefit of dynamic design is shown over the static design. But when the

update ratio is bigger, the benefit becomes significant: the commit rate of the dynamic

design increases while that of the static design remains almost unchanged; the commit

percentage of the dynamic is almost constant but that of the static design decrease

rapidly. The reason is that in the dynamic design, the currency is always flowing to the

hottest replicas thus there are more tentative updates to get plural currency and be

committed rapidly. While in the static case, the currency allocation is fixed and there is










no priority for the hottest replica, so the commit rate is almost a constant no matter the

number of tentative updates generated.

Figure 6-5 and Figure 6-6 illustrate the commit rate and commit percentage of

dynamic cases versus static cases of primary scenario:


10
S8-
6 -6-~dynamic
E 4 --static


0
8 2

0.1 0.2 0.3 0.4 0.5 0.6
update ratio



Figure 6-5 Commit rate of primary scenario


1
S0.8
S0.6 dynamic
0.4 -- static
E 0.2
8 0
0.1 0.2 0.3 0.4 0.5 0.6
update ratio


Figure 6-6 Commit percentage of primary scenario

We can learn from the above figures that in the primary scenario, the difference of

dynamic and static cases is not so significant as the uniform one. The reason is that the

primary currency happens to be allocated to one of the hottest replicas so the performance

of static design is not too bad since a fixed primary currency makes all the local tentative

updates committed. It can also be seen from Figure 6-5 and Figure 6-6 that the dynamic

case still beat the static case when the update ratio is higher than 0.3 even one of hot

replica is lucky to get primary currency in the static case.










It is reasonable that the benefits of the dynamic design will be more significant,

even better than the uniform scenario, if the primary currency is unfortunately given to a

cold replica.

6.4.2 Mean Commit Delay

Figure 6-7 and Figure 6-8 demonstrate the commit delay of dynamic cases versus

static cases in uniform and primary scenarios:


20

15 _
-- ---dynamic
10
E --static


0 -
0.1 0.2 0.3 0.4 0.5 0.6
update ratio



Figure 6-7 Commit delay of uniform scenario


8

6-
4 -4-dynamic
E -- static
o 2-
0
0.1 0.2 0.3 0.4 0.5 0.6
update ratio


Figure 6-8 Commit delay of primary scenario

The above figures compare the dynamic design and the static design for uniform

and primary scenarios in terms of how fast they commit updates. It can be observed that

in the uniform scenario, the commitment of dynamic design is much faster than that of

static design except when the update ratio is rather low. But in the primary scenario, the






63


benefit is not so significant because the fixed primary currency in static design does

speed the commitment in the primary replica.

The main overhead of the dynamic design is metadata management and currency

redistribution. As stated in chapter 4, the overhead to collect metadata is trivial. The main

overhead related to currency redistribution is message cost, but the information can be

piggybacked with the anti-entropy messages and that is only a few bytes thus save

bandwidth of mobile hosts. Therefore, the overhead of the dynamic design is little.














CHAPTER 7
CONCLUSIONS AND FUTURE WORK

This thesis is focused on flexible protocols for dynamic database design and

reconfiguration in mobile environments. Traditional distributed database design is static,

while mobile environments require a dynamic design to support mobility. In this thesis,

the concept of mobile database is given first, and then a dual data/currency hoarding and

synchronization protocol is introduced. Metadata is used to allocate currencies

dynamically so that the mobile database is reconfigured such that the replica location,

replication and data semantics can be changed dynamically via currency redistribution

referring to metadata. The benefits of dynamic design versus static design are shown via

the simulation results. Mobile databases consist of a large scope of research and

application issues. In this thesis, what we addressed is only a small subset of it. There is a

lot of future work to do:

1) This thesis is focused on just a small subset of metadata. In order to get better
performance adaptive to the system changes, the full set of metadata should be
considered. This requires a more completed metadata collection mechanism.

2) Associate rules to predict metadata to build rule-based adaptive currency
redistribution. The metadata in this thesis is collected only after the events happen, i.e. it
comes from history of the system. If there is a scheme to predict what a mobile host
needs in the future and hoard the data in advance, the performance will be brought up
significantly.

3) The concept of broadcast databases is introduced and included in the hoarding
and synchronization mechanism. Detailed algorithms and more use of broadcast should
be explored. It should be more powerful to use broadcast to propagate update
commitment, election winner awards and hint of primary location.

4) Data management plays a crucial role in mobile computing. Decades of
experience with query processing, transactions, replication, caching etc provide a solid






65


base of technology on which to build. But, mobile computing brings challenges in all
aspects of data management. Query processing in mobile databases has new
characteristics and should be performed in an optimal way. Mobile transaction models
will be built based on the traditional transaction models. For example, the operations in
mobile databases include hoarding and synchronization as well as read and write.

5). A complete simulation/implementation is needed to show the benefits of
dynamic design of mobile databases.















LIST OF REFERENCES


[1] S. Acharya, R. Alonso, M. Franklin, S. Zdonik, Broadcast Disks: Data Management
for Asymmetric Communication Environments, SIGMOD Conference, pp. 199-210,
1995

[2] D. Agrawal, A. El-Abbadi, and R. Steinke. Epidemic algorithms in replicated
databases, In Proc. 16th ACM SIGACT-SIGMOD Symposium on the Principles of
Database Systems (PODS), pp. 161-172, Tucson, Arizona, May 1997

[3] L. Capra, W. Emmerich and C. Mascolo, Exploiting Reflection and Metadata to Build
Mobile Computing Middleware, Advanced Topic Workshop Middleware for Mobile
Computing, Heidelberg, Germany, November 2001

[4] M. Cherniack, M. Franklin, S. Zdonik, Data Management for Pervasive Computing,
VLDB, Rome, Italy, Sep. 2001

[5] U. Cetintemel and P. J. Keleher, Light-Weight Currency Management Mechanisms in
Mobile and Weakly-Connected Environments. Journal of Distributed and Parallel
Databases, Vol 11, Nol, pp. 53-71, January 2002.

[6] U. Cetintemel, P. J. Keleher, M. Franklin, Support for Speculative Update
Propagation and Mobility in Deno, The 22nd International Conference on Distributed
Computing Systems, Mesa, Arizona, 2001

[7] U. Cetintemel and P. J. Keleher, Light-Weight Currency Management Mechanisms in
Deno, In the 10th IEEE Workshop on Research Issues in Data Engineering
(RIDE2000), February 2000.

[8] A. Demers, D. Greene, A. Hauser, W. Irish, J. Larson, S. Shenker, H. Sturgis, D.
Swinehart, and D. Terry. Epidemic Algorithms for Replicated Database Maintenance,
In Proceedings of ACM Symposium on the Principles of Distributed Computing,
pp. 1-12, August 1987.

[9] A. J. Demers, K. Petersen, M. J. Spreitzer, D. B. Terry, M. M. Theimer, and B. B.
Welch, The Bayou Architecture: Support for Data Sharing among Mobile Users,
In Proceedings of the Workshop on Mobile Computing Systems and Applications,
pp. 2-7, Santa Cruz, California, December 1994









[10] W. Emmerich, Software Engineering and Middleware: A Roadmap, In the Future of
Software Engineering 22nd International Conference on Software Engineering
(ICSE2000), May 2000

[11] A. Elmagarmid, Database Transaction Models for Advanced Applications, Morgan
Kaufmann Publishers, San Francisco, CA, 1999

[12] J. Gray, P. Helland, P. O'Neil, D. Shasha, The Dangers of Replication and a
Solution, SIGMOD'96, pp. 173-182, Montreal, Canada, 1996

[13] A. Helal, J. Hammer, A. Khushraj and J. Zhang, A Three-tier Architecture for
Ubiquitous Data Access, the First ACS/IEEE International Conference on Computer
Systems and Applications, pp. 177-180, Beirut, Lebanon, June 2001

[14] A. Helal, B. Haskell, J. Carter, R. Brice, D. Woelk, M. Rusinkiewicz, Any Time,
Anywhere Computing: Mobile Computing Concepts and Technology, Kluwer
Academic Publisher, New York, NY, 1999

[15] S. Jajodia and D. Mutchler, Dynamic voting algorithms for maintaining the
consistency of a replicated database, ACM Trans. on Database Systems, Vol. 15, No.
2, pp. 230-280, June 1990

[16] P. J. Keleher, Decentralized Replicated-Object Protocols, in the 18th ACMSIGACT-
SIGOPS Symposium on Principles of Distributed Computing, pp. 143-151, April
1999.

[17] G. H. Kuenning and G. J. Popek, Automated Hoarding for Mobile Computers,
Proceedings of the 16th ACM Symposium on Operating Systems Principles (SOSP-
16), pp. 264-275, St. Malo, France, October, 1997.

[18] J. J. Kistler, M. Satyanarayanan, Disconnected Operation in the Coda File System,
In Proc. Of the ACM Symposium on Operationg Systems Principles, pp. 213-225,
October 1991

[19] M. Lee, A. Helal, HiCoMo: High Commit Mobile Transactions, Journal of
Distributed and Parallel Databases, pp. 73-92, January 2002.

[20] M. Lanham, A. Kang, J. Hammer and A. Helal, Format-Independent Change
Detection and Propagation in Support of Mobile Computing, Proceedings of the XVII
Brazilian Symposium on Databases (SBBD), pp. 27-41, Gramado, Rio Grande do Sul,
Brazil, October, 2002

[21] Y. W. Lee, K. S. Leung, M. Satyanarayanan, Operation-based Update Propagation in
a Mobile File System, Proceedings of the USENIX Annual Technical Conference,
pp. 1-15, Jun. 1999, Monterey, CA









[22] M. T. Ozsu and P. Valduriez, Principles of Distributed Database Systems, Prentice
Hall Publisher, Englewood Cliffs, NJ, 1999

[23] K. Petersen, M. J. Spreitzer, D. B. Terry, M. M. Theimer, and A. J. Demers, Flexible
Update Propagation for Weakly Consistent Replication, Proceedings of the 16th ACM
Symposium on Operating Systems Principles, pp. 288-301, Saint Malo, France,
October 1997

[24] E. Pitoura and G. Samaras, Data Management for Mobile Computing, Kluwer
Academic Publishing, New York, NY, 1998

[25] M. Rennhachkamp, Mobile Database Replication, DBMS, pp. 81-84, October 1997

[26] M. Stonebraker, P. M. Aoki, W. Litwin, A. Pfeffer, A. Sah, J. Sidell, C. Staelin, and
A. Yu, Mariposa: A Wide-Area Distributed Database System, VLDB Journal, Vol. 5,
pp. 48-63, 1996.

[27] K. Stathatos, N. Roussopoulos, J. S. Baras, Adaptive Data Broadcast in Hybrid
Networks, VLDB, pp. 326-335, 1997

[28] C. A. Waldspurger, T. Hogg, B. A. Huberman, J. O. Kephart, and W. S. Stornetta,
Spawn: A Distributed Computational Economy, IEEE Transactions on Software
Engineering, Vol. 18, pp. 103-117, February 1992.

[29] O. Wolfson, S. Jajodia, and Y. Huang, An Adaptive Data Replication Algorithm,
ACM Trans. on Database Systems, Vol. 22, No. 2, pp. 255-314, June 1997

[30] O. Wolfson, S. Jajodia, An Algorithm for Dynamic Data Allocation in Distributed
Systems, Information Processing Letters, Vol. 53, No. 2, pp. 113-119, 1995

[31] O. Wolfson, S. Jajodia, Distributed Algorithms for Dynamic Replication of Data, in
proceedings of the 11th ACMPODS Symposium, pp. 149-163, San Diego, Calif., June
1992

[32] C. A. Waldspurger and W. E. Weihl, Lottery Scheduling: Flexible Proportional-
Share Resource Management, in Proceedings of the First Symposium on Operating
Systems Design and Implementation, pp. 1-11, Monterey, CA, November 1994.















BIOGRAPHICAL SKETCH

Yanli Xia was born in Sanyuan, Shaanxi Province, in China. She received a

Bachelor of Science degree in computer science and engineering from Nanjing

University of Aeronautics and Astronautics, Nanjing, China, in July 1997. Then she

entered the graduate program at Nanjing University of Aeronautics and Astronautics and

obtained a Master of Engineering degree in computer science in April 2000.

She enrolled at the University of Florida in August 2000 in the Department of

Computer and Information Science and Engineering. She worked as a teaching assistant,

and then research assistant for Dr. Abdelsalam (Sumi) Helal. Her future research interests

include mobile databases and distributed systems.