Tiedon varmentaminen mobiilissa ja langattomassa ympäristössä

Transkriptio

1 Tiedon varmentaminen mobiilissa ja langattomassa ympäristössä Tietokannat nyt -seminaari Tuomo Saarinen i

2 1. Johdanto Mobiilin tietojenkäsittelyn ongelmat PC:n ja sen ongelmat mobiilin ja langattoman verkon kanssa Ratkaisuehdotuksia langattoman tiedonsiirron varmentamiseen PC Mobiiliin ja langattomaan ympäristöön TCOT aikakatkaisuun perustuva sitoutumisprotokolla Sisäkkäiset transaktiot Yksipuolinen sitoutumisprotokolla Yhteenveto Lähteet ii

3 1. Johdanto Tietokantoja säilytetään yhä ylenevissä määrin pienissä kannettavissa laitteissa kuten kännyköissä, kämmentietokoneissa, auton tietokoneissa ja jopa älykorteissa. Verrattuna perinteisiin kiinteisiin tietokantoihin, on näillä laitteilla mm. rajoitettu varastotila ja luotettavuus, rajoitettu voimanlähde, ennalta-arvaattomat verkonvaihdot ja rajoitettu kantavuus. Nämä ominaisuudet vaikuttavat oleellisesti tiedonvälityksen luotettavuuteen. Vaikka useimmissa mobiilipalveluissa voidaan hyväksyä yhteyskatkot ja häiriöt tiedonsiirrossa, niin on olemassa tapauksia, joissa on oltava varma, että tieto on varmennettu ja kaikilla osapuolilla tieto on päivitetty samaan tilaan. Tällaisia tilanteita ovat esim. pankkipalvelut, joissa on tärkeää että sekä asiakkaan että pankin tietokannoissa tilillä on saman verran rahaa ja että tilisiirrot varmistetaan molemmissa päissä. Toinen esimerkki on potilasrekisterin päivittäminen, joka vaatii tiukkaa atomisuutta, jotta voidaan olla varmoja rekisterin paikkansapitävyydestä. Näissä tapauksissa täytyy noudattaa ns. ACID-vaatimuksia, eli atomisuutta (atomicity), yhdenmukaisuutta (consistency), eristäytyneisyyttä (isolation) ja pysyvyyttä (durability). Atomisuus tarkoittaa sitä, että järjestelmä takaa että transaktio joko suoriuttaa kaikki tehtävänsä tai ei mitään, ettei esiinny ristiriitaista tietoa. Yhdenmukaisuus varmistaa että tietokanta on laillisessa tilassa ennen ja jälkeen transaktion, estäen kaikki laittomat toimenpiteet. Eristäytyneisyys takaa sen, että mikään transaktion ulkopuolinen operaatio ei näe transaktion tietoja sen suorituksen ollessa kesken. Pysyvyys takaa sen, että transaktion suoritettua operaationsa onnistuneesti, se tulee pysymään siinä tilassa häiriöidenkin sattuessa. Tietokantasovelluksissa jo vakiintunut transaktioiden varmentamismenetelmä on ns. kaksivaiheinen commit protokolla (2PC). Tämä protokollan toimintaideana on, että transaktiota suoritettaessa kaikki osapuolet joko hyväksyvät transaktion tai hylkäävät sen. Näin voidaan varmistua tiedon oikeellisuudesta kaikkien osapuolten kesken. Perinteisen 2PC:n siirtäminen mobiiliin ja langattomaan ympäristöön ei kuitenkaan suju ilman ongelmia, koska 2PC suunniteltiin käytettäväksi kiinteiden yhteyksien ja suurten ja tehokkaiden tietokantapalvelimien kanssa. Osa tässä kirjoituksessa esitetyistä 1

4 ratkaisuista perustuu 2PC:n hyödyntämiseen ja osa esittää uusia vaihtoehtoja transaktioiden varmentamiseksi. 2. Mobiilin tietojenkäsittelyn ongelmat Mobiililaitteiden suurimpana hyötynä on niiden liikkuvuus. Samalla se aiheuttaa kuitenkin ongelmia niiden toimintaan verkkoympäristöissä, joista suurin osa on yhä suunniteltu kiinteille yhteyksille. Mobiililaitteissa on muutamia rajoituksia verrattuna kiinteään. Siitä saattaa loppua akkuvirta tai levytila, sille tapahtuu herkemmin onnettomuuksia ja fyysistä vahinkoa, siinä on rajoitettu määrä kanavia kommunikointia varten ja se saattaa kadota verkosta tai vaihtaa verkkoa äkillisesti. Kuva 1 esittää mobiilin järjestelmän perusrakennetta. Järjestelmä jakautuu kahteen osaan: kiinteään ja langattomaan. Mobiiliyksikkö (MU, mobile unit tai MH, mobile host) on tietokone, joka pystyy liikkuessaan säilyttämään verkkoyhteytensä langattomien. Mobiiliyksikkö on yhteydessä kiinteään verkkoon tietyntyyppisten kiinteiden isäntien (FH, fixed host) avulla. Tämän tyyppisiä kiinteitä isäntiä kutsutaan tukiasemiksi (BS, base station tai MSS, mobile support station). Tukiasemassa on langaton rajapinta kommunikointiin mobiiliyksiköiden kanssa. Jokainen tukiasema kattaa maantieteellisen alueen, jota kutsutaan soluksi. Mobiiliyksikkö voi olla suorassa yhteydessä siihen tukiasemaan, jonka alueella se sijaitsee. Jos mobiiliyksikkö siirtyy yhdestä solusta toiseen, se ryhtyy kommunikoimaan uuden solun tukiaseman kanssa. Tätä prosessia kutsutaan tukiaseman vaihdoksi (handoff). 2

5 Kuva 1: Mobiilin järjestelmän perusrakenne 2.1 2PC:n ja sen ongelmat mobiilin ja langattoman verkon kanssa Kaksivaiheinen sitoutumisprotokolla eli 2PC (Kuva 2) on eniten käytetty protokolla hajautetuissa transaktioissa. Se on kuitenkin suunniteltu kiinteisiin verkkoihin, eikä sovellu mobiiliympäristöön sellaisenaan lukitsevuutensa ja useiden viestikierrostensa takia. 2PC:n voi jakaa kahteen vaiheeseen: äänestysvaiheeseen ja päätösvaiheeseen. Äänestysvaiheessa transaktion alullepanija, jota yleensä kutsutaan koordinaattoriksi, lähettää kaikille transkation osallistujille viestin, jossa niitä pyydetään valmistautumaan transaktion sitouttamiseen (commit). Jos jostain syystä yksikin osallistuja äänestää kieltävästi, niin koordinaattori palauttaa paikallisen tietokantansa (rollback) ja lähettää osallistujille keskeytys- eli abort-viestin. Jos kaikki osallistujat äänestivät kyllä, niin transaktion tekemät muutokset voidaan tehdä pysyviksi. Osallistujan kyllä-ääni merkitsee sitä, että paikalliset operaatiot on suoritettu onnistuneesti ja päivitykset voitaisiin tehdä pysyviksi, vaikka joku häiriö sattuisikin. Osallistuja, joka äänestää ei, 3

6 voi yksipuolisesti keskeyttää paikalliset operaatiot, kun taas kyllä äänen antanut joutuu odottamaan koordinaattorin päätöstä. Kuva 2: 2PC:n toiminta Protokollan suorituksen aikana koordinaattori ja osallistujat pitävät yllä yksityisiä lokeja, joissa on tiedot dataan tehdyistä muutoksista. Koordinaattorin loki pitää sisällään myös tiedot kaikista osallistujista. Nämä lokitiedostot pakkokirjoitetaan levylle. 2PC protokolla vaatii kaksi viestikierrosta ja 4n viestiä, missä n on osallistujien määrä. Langattomassa ympäristössä, jossa esiintyy paljon viiveitä ja kaistannopeus on alhainen ja vaihteleva, tämä kustannus on melko suuri. Jos isäntäyksikkönä on esim. kännykkä tai kämmentietokone, niin sen prosessointiteho ja muut resurssit saattavat olla pienemmät, kuin mitä koordinaattorilta vaaditaan kyseisessä transaktiossa. Isäntien liikuteltavuus mahdollistaa ennalta-arvaamattomat tukiasemavaihdot. Koska langattomien yhteyksien vähentämiseksi koordinaattori suoritettaan tukiasemassa, saattaa tästä tulla huomattavia viiveitä jos isäntä vaihtaa solusta toiseen tiheään tahtiin. 4

7 Mobiiliyksikkö saattaa poistua verkosta useasta eri syystä. Jos käyttäjä esim. katkaisee yhteyden kokouksen ajaksi tai säästääkseen akkua. Muita syitä ovat esim. virran loppuminen, laite ei ole minkään verkon alueella (esim. metrossa), laite vahingoittuu tai se varastetaan. 3. Ratkaisuehdotuksia mobiilin ja langattoman tiedonsiirron varmentamiseen Mobiilin ja langattoman tiedonsiirron varmentamista on tutkittu jo jonkin aikaa. Tämä paperi esittelee muutaman ehdotuksen. Nouali et. al. esittelee 2PC:n muokatun version, joka soveltuu sellaisenaan, koska se käyttää hyväkseen 2PC:tä. Kumar et. al. esittää aikakatkaisuun perustuvan mallin, joka poistaa 2PC:lle ominaisen lukitsemisen ongelman asettamalla aikarajan, jonka kuluessa transaktion tai sen osien oletetaan valmistuvan. Chrysanthis esittää sisäkkäisten transaktoiden mallin, jossa osallistujat voivat jakaa suoritustensa osittaistuloksia muille nopeuttaen kokonaissuoritusta. Bobineau et. al. esittävät yksipuolisen sitoutumisprotokollan, joka poistaa 2PC:n äänestysvaiheen ja näin nopeuttaa ja yksinkertaistaa viestiliikennettä osallistujien ja koordinaattorin välillä PC Mobiiliin ja langattomaan ympäristöön M-2PC -protokolla käyttää perustana 2PC protokollaa, liittäen siihen toimintoja, jotka helpottavat toimintaa mobiilissa ja langattomassa ympäristössä. Sen tavoitteena on sitouttaa globaalisti mobiili transaktio, joka suoritetaan usean isännän välillä. Mobiiliyksikköä, jossa transaktio luotiin kutsutaan asiakkaaksi (Home-MH, client), ja tukiasemaa, johon se oli silloin yhteydessä kotitukiasemaksi (Home-BS). Jos mobiiliyksikkö siirtyy uuteen soluun, se kiinnittyy sen solun tukiasemaan, jota kutsutaan nykyiseksi tukiasemaksi (Current-BS). Sitoutumisvaiheessa asiakas lähettää sitoutumispyynnön, jolloin senhetkisestä tukiasemasta tulee sitoutumistukiasema (Commit-BS). Nämä uudet nimet kuvaavat eri rooleja, joita protokollan täytyy käyttää pystyäkseen sopeutumaan joustavasti verkkoon. 5

8 Kuten 2PC:ssä, M-2PC:ssä on transaktion aloittaja (transaction initiator), joka on siis se mobiiliyksikkö, joka käynnisti transaktion. Lisäksi ovat osallistujat, jotka suorittavat transaktion operaatioita ja koordinaattori, joka huolehtii transaktion yhtenäisestä päättymisestä. Koordinaattorin pitää sijaita kiinteässä verkossa ollakseen suorassa yhteydessä osallistujiin. Lisäksi koordinaattoriin pitää saada yhteys asiakkaasta, joten paras paikka sille on senhetkinen tukiasema, josta tulee tällöin sitoutumistukiasema. Koordinaattori pysyy koko ajan samassa tukiasemassa, vaikka asiakas siirtyisi toiseen soluun sitoutumisen aikana. Mahdollisten yhteyskatkoksien takia koordinaattori hoitaa sitoutumiskäskyt. Eli asiakas lähettää koordinaattorille sitoutumispyynnön ja lokitiedostonsa. Koordinaattori lähettää sitten kaikille osallistujille äänestysviestin ja päättää transaktion sitouttamisesta tai peruutuksesta, jonka jälkeen se lähettää asiakkaalle tiedon lopputuloksesta. Koska asiakas saattaa siirtyä solusta toiseen transaktion suorituksen aikana, niin koordinaattorin täytyy tietää jatkuvasti, missä asiakas on. Tämä toteutetaan niin, että vaihtaessaan verkkoa asiakas lähettää koordinaattorille tiedon sijainnistaan. Jotta asiakas tietäisi koordinaattorin sijainnin myös mahdollisen virheen sattuessa, asiakas pakkokirjoittaa koordinaattorin tiedot paikallisesti ennen sitoutumispyynnön lähetystä. Mikäli joku muukin osallistuja sijaitsee mobiililaitteessa, toimii tämä osallistuja samalla tavalla kuin asiakas. Tämän osallistujan tukiasemasta tulee sen edustaja (partisipantagent), joka suorittaa osallistujan toiminnot ja lähettää hänelle tiedon tuloksista. 3.2 TCOT aikakatkaisuun perustuva sitoutumisprotokolla 2PC:n pahimpia haittapuolia on se, että se on lukitseva protokolla. Tällöin prosessin varaamia resursseja ei voi muut prosessit käyttää. Yksi tapa ratkaista mobiiliympäristön sitoutumisongelmat on aikakatkaisuun perustuva TCOT (Transaction Commit on Timeout). Tässä ratkaisussa prosesseja ei varattaisi loputtomiin, vaan ne vapautettaisiin tietyn ajan kuluttua. 6

9 TCOT:n perusrakenne on melko samanlainen kuin 2PC:n. Siinäkin on koordinaattori, joka hoitaa transaktion hallinnan ja yhtenäistämisen ja osallistujat, jotka suorittavat kukin omat tehtävänsä. TCOT sitoutuu, mikäli transaktion koordinaattori ei vastaanota virheilmoitusta tietyn ajan kuluessa. Tarkkaa arvoa aikakatkaisulle on vaikea määrittää, koska transaktion toimintaan vaikuttaa yleensä useita muuttujia. On kuitenkin mahdollista määrittää aikakatkaisulle arvo, joka toimii hyvin kaikissa tapauksissa. TCOT protokolla käyttää kahta eri aikakatkaisutyyppiä: Suorituksen aikakatkaisua (Execution timeout) ja päivityksen aikakatkaisua (Update shipping timeout). Suorituksen aikakatkaisu määrittää jokaiselle osallistujalle yksilökohtaisen ylärajan, jolloin kyseisen osallistujan pitäisi saada suorituksensa päätökseen. Päivityksen aikakatkaisu määrittää ylärajan, jolloin mobiiliyksikön lähettämä tieto päivityksistä on saapunut tietokantapalvelimelle. 3.3 Sisäkkäiset transaktiot Transaktio, joka käsittelee jaettua dataa tietokannassa, on yleensä rakenteeltaan atominen. Mobiililaitteiden kanssa näin ei voida aina tehdä. Koska atomisten transaktioiden oletetaan suorittavan eristyksissä, jolloin ne eivät voi jakaa laskentaansa usealle eri yksikölle, tai jakaa tilaansa ja osittaistuloksiansa. Avoimet sisäkkäiset transaktiot (open-nested transactions) mahdollistavat osittaistuloksien näyttämisen transaktion ulkopuolisille. Tämä johtuu siitä, että sisäkkäiset transaktiot voivat sitoutua tai peruuttaa transaktion yksipuolisesti. Nykyiset avoimet sisäkkäiset transaktiot eivät täytä mobiiliympäristöjen vaatimuksia osatietojen jakamisesta suoritusvaiheessa ja ylläpitää osasuorituksen tila tukiasemassa tavalla, joka minimoi kommunikointiviiveet. Chrysanthis esittää mobiilitransaktiomallin, joka suoriutuisi mobiiliympäristössä paremmin lisäämällä siihen kaksi uutta transaktiotyyppiä: ilmoitustransaktion (reporting transaction), joka voi jakaa osittaistuloksiansa muiden transaktioiden kanssa missä tahansa suorituksensa vaiheessa, ja näennäisrinnakkaiset transaktiot (co-transaktion) jotka vaihtavat suorituksessa olevaa transaktiota osittaistuloksia jaettaessa. Säilyttäen tilansa. Mobiilitransaktio on joukko melko itsenäisiä transaktioita (komponentteja), jotka voivat toimia limittäin muiden mobiilitransaktioiden kanssa. Komponenttitransaktio (Component transaction) voidaan 7

10 edelleen jakaa pienempiin komponenttitransaktioihin, jolloin mobiilitransaktiot voivat tukea haluttua sisäkkäisyystasoa. Mobiilitransaktio koostuu ilmoitustransaktioiden ja näennäisrinnakkaisten transaktioiden lisäksi kompensoivista transaktioista ja kompensoimattomista transaktioista. Kompensoivat transaktiot ovat atomisia transaktioita, joilla on transaktioiden välisiä riippuvuuksia. Näiden transaktioiden osakokonaisuudet, eli komponentit voivat sitoutua ennen koko transaktion sitoutumista. Mutta jos transaktio sen jälkeen peruu, niin komponentin kompensoijakomponentin (compensatable component) täytyy sitoutua. Kompensoijakomponentti semanttisesti peruu komponentin vaikutukset, mutta ei välttämättä palauta tietokantaa tilaan ennen komponentin suoritusta. Kompensoimattomat transaktiot ovat komponenttitransaktioita, jotka voivat sitoutua, mutta ne eivät voi sitouttaa tekemiänsä muutoksia, ennen kuin koko transaktio on sitoutunut. 3.4 Yksipuolinen sitoutumisprotokolla Bobineau et. al. esittävät että 2PC ei sovellu mobiiliympäristöön ja ehdottavat uutta atomista sitoutumisprotokollaa nimeltään yksipuolinen sitoutumisprotokolla (unilateral commit for mobile, UCM). UCM mahdollistaa transaktion suorituksen verkkoyhteyden ollessa pois päältä ja verkosta poistumisen sitoutumisen aikana ja vähentää langattoman yhteyden kuluja yksinkertaistamalla viestejä. UCM:n perusidea on luopua 2PC:n äänestysvaiheesta. Koordinaattori toimisi eräänlaisena diktaatorina, joka tyrkyttäisi päätöksensä kaikille osallistujille. Mikäli jokin virhe estää osallistujaa suorittamasta käskyjään, koordinaattori suorittaa eteenkierron transaktion epäonnistuneelle osalle. UCM käyttää Yksivaiheista sitoutumisprotokollaa (1PC). 1PC ei ole uusi idea, mutta sitä ei ole käytetty hajautetuissa transaktioissa, koska se tekee oletuksia osallistujien käyttäytymisestä. Koska 1PC:ssä on luovuttu äänestysvaiheesta, niin koordinaattori ei voi tietää pystyvätkö osallistujat takaamaan transaktioidensa ACID-ominaisuudet. 1PC:n pääideana onkin eliminoida koko tarve tälle tiedolle olettamalla, että jokainen osallistuja on täyttänyt nämä vaatimukset ennen sitoutumisvaihetta. Tämä vaatii muutamia oletuksia siitä, miten osallistujat suorittavat transaktiot. Ensinnäkin 1PC 8

11 olettaa, että kaikki transaktion operaatiot on suoritettu onnistuneesti ennen kuin protokolla käynnistetään. Eli siis transaktion paikallisten suoritushaarojen atomisuus on jo taattu ennen sitoutumisvaihetta. Toiseksi 1PC olettaa, että yhtenäisyysrajoitteet tarkistetaan välittömästi jokaisen päivitysoperaation jälkeen ja ennen kuin operaatio kuitataan. Näin transaktion yhtenäisyys on taattu kaikissa paikallisissa haaroissa. Kolmanneksi 1PC protokolla olettaa, että kaikki osallistujat sarjallistavat transaktionsa käyttäen pessimististä rinnakkaisuudenhallintaprotokollaa välttääkseen peräkkäiset peruutukset. Neljänneksi 1PC-protokolla olettaa että kaikkien osallistujien tekemien transaktioiden vaikutukset on kirjoitettu lokiin, joka on pakkokirjoitettu levylle. UCM:ssä transaktio koostuu viidestä komponentista (Kuva 3): applikaatiosta joka pyytää suorittamaan sarjan operaatioita, lokiagentista (LogAgent) joka kirjoittaa jokaisen operaation lokiin ennen suoritusta, osallistujista jotka suorittavat operaatiot, koordinaattorista joka ohjaa sitoutumisprotokollaa ja osallistuja-agenteista (PAgent) joita on yksi jokaista osallistujaa kohden ja jotka edustavat osallistujia ja joilla on aktiivinen rooli palautuksessa. Kuva 3: Tyypillinen UCM-konfiguraatio Kuva 4 esittää UCM:n toiminnan. Yksinkertaistamisen takia siinä näytetään vain yhden osallistujan, Pk:n toiminta. Tik tarkoittaa transaktion Ti paikallista suoritusta osallistujalla Pk. 9

12 Kuva 4: UCM:n skenaario, joka päättyy sitoutumiseen. Vaihe 1 kuvaa operaatioita, jotka suoritetaan Tik:n puolesta. Lokiagentti kirjoittaa lokiinsa jokaisen suoritettavan operaation. Operaatiot lähetetään sitten osallistujille (Pk) paikallista suoritusta varten. Vaihe 2 kuvaa transaktion suoritusta applikaation näkökulmasta. Kun applikaatio on saanut kaikilta osallistujilta kuittaukset, se lähettää sitoutumispyynnön. Tässä vaiheessa suoritusta osallistujat ovat paikallisesti taanneet omalta osaltaan ACID-vaatimusten atomisuuden, yhdenmukaisuuden ja eristyneisyyden. Ne eivät voi taata pysyvyyttä, koska ne eivät ole tietoisia transaktion päättämisestä. Koordinaattori takaa pysyvyyden saamalla lokiagentin tuottaman lokin ja pakkokirjoittamalla sen levylle. Vaiheessa 3, kun transaktion kaikkien osien ACIDvaatimukset on täytetty, koordinaattori tekee sitoutumispäätöksen ja pakkokirjoittaa päätöksen levylle, lähettää kaikille sitoutumiskäskyn ja odottaa niiden kuittausta. Jos transaktio peruutetaan, koordinaattori hylkää kaikki transaktion lokitiedot ja lähettää peruutusviestin. Tässä oletetaan käytettävän peruutusprotokollaa, joka ei lähetä kuittauksia peruutuksista, eikä peruutuspäätöstä kirjata koordinaattorin lokiin. 10

13 Jos osallistuja kaatuu vaiheessa 1, niin transaktion atomisuusvaatimus on häiriintynyt ja koordinaattori lähettää peruutusviestin. Mikäli osallistuja kaatuu vaiheessa 2 tai 3, toimitaan eri tavalla. Oletetaan, että kaikki muut osallistujat ovat suorittaneet toimintansa onnistuneesti Pk:ta lukuun ottamatta ja koordinaattori on saanut kaikilta muilta kuittauksen sitoutumispyyntöön. Pk:n oletetaan takaavan paikalliset ACIDvaatimuksensa, joten Tik joko palautetaan ehjään tilaan, mikäli Pk kaatui ennen sitoutumista, tai Tik sitoutetaan paikallisesti, mikäli Pk kaatui juuri ennen kuin se lähetti koordinaattorille sitoutumiskuittauksen. Osallistuja-agentin tehtävä palautusvaiheessa on määrittää pitääkö Tik suorittaa uudestaan vai ei. Se tekee tämän päätöksen tarkistamalla Pk:n lokista, löytyykö sieltä commit-merkintää. Jos merkintä löytyy, Tik on suoritettu onnistuneesti Pk:ssa ennen Pk:n kaatumista. Jos merkintää ei löydy, niin Tik täytyy palauttaa ehjään tilaan ja suorittaa uudestaan. 4. Yhteenveto Tässä kirjoituksessa esitetyt ratkaisuvaihtoehdot tiedon varmentamiseksi mobiilissa ja langattomassa ympäristössä toimivat hieman eri tavalla, mutta kaikissa on joitain samoja piirteitä. Kaikki lähtevät siitä oletuksesta, että transaktion koordinaattorin ei pitäisi sijaita mobiililaitteessa, mikäli suinkin mahdollista. Jotkut ratkaisut on rakennettu olemassa olevien toimintojen päälle, jolloin niiden käyttöönotto on mahdollisimman helppoa ja päivityskustannukset pysyvät pienempinä. Toisissa ratkaisuissa on taasen kehitetty kokonaan uusia toimintatapoja, jolloin ne saattavat olla vaivalloisempia ottaa käyttöön, mutta saattavat toimia tehokkaammin, koska ne on suunniteltu kokonaan mobiililaitteita ajatellen. 11

14 5. Lähteet [BPA00] Bobineau, C. Pucheral, P. and Abdallah, M. (2000): A unilateral commit protocol for mobile and disconnected computing. Proc. of the 12 th int. conf. on parallel and distributed computing Systems (PDCS), Las Vegas, USA. [Chr03] Chrysanthis, P. K. (1993): Transaction Processing in Mobile Computing Environment. Proc. Of the IEEE Workshop on advances in parallel and distributed systems, Princeton, New Jersy, USA, [KPD02] Kumar, V., Prabhu, N., Dunham, M., H., Seydim, A., Y., TCOT-A Timeout-Based Mobile Transaction Commitment Protocol IEEE Transactions on Computers archive [NDD05] Nadia Nouali, Anne Doucet, Habiba Drias: A Two-Phase Commit Protocol for Mobile Wireless Environment. ADC 2005: