RDP A result delivery protocol for mobile computing

RDP:AResultDeliveryProtocolforMobileComputing

MarkusEndler,ndKunioOkuda

DepartmentofComputerScience

UniversityofS˜aoPaulo,Brazil

endler,dilma,kunio@

Abstract

Nowadaysseveralinformationretrievalservicesarebe-

suchservicesareim-

plementedbygroupsofdistributedserversandsometimes

employtime-consumingdatalocationandretrievalproto-

er,manynetworkappli-

ans

thatclient-servercommunicationinservicesformobile

computingmustalsobereliabledespitetheintrinsicnon-

predictabilityrelatedtomobilecomputing.

Inthispaperwepresentaclient-serverprotocolwhich

implementsreliabledeliveryofmessagestomobilehosts.

Reliabilityheremeansthatforeveryrequestfromamo-

bileclienttoanetworkservice,eventuallyitwillreceive

theresult,despiteitsperiodsofinactivityandanynumber

otocolissuitablefornetworkservices

basedonrequest-replystyleofcommunication()

andwithlongrequestprocessingtimes,hereis

highprobabilitythataclientatamobilehostmigratesto

anothercellwhilewaitingforthereply.

Themainadvantageofourprotocolisthatthelocation

oftheproxyusedtoforwardmessagestoamobilehostis

notstatic(asinMobileIP),bywhichitfacilitatesdynamic

globalloadbalancingwithinthesetofMobileSupportSta-

tions.

uction

Withtheongoingimprovementandspreadofcellular

telephonytechnology,moreandmorecomputernetwork

,

itwillbepossibletoaccessmanysortsofinformationbases

fromlightweight,inexpensiveandhand-heldterminalsor

PDAs,,manyof

theseinformationbaseswillbefedwithdatasentbythese

mobiledevices,whichmayrangefromfrequentupdates

interactionsandprocessingwithintheTISnetwork.

Inordertoimplementefficientlytheoperationsoffered

bythesystemtomobileusers(suchasquery,update,sub-

scribe

1

,andmulticast

2

)wearedesigningandimplementing

asuiteofprotocols[7]thathandledifferentaspectsofthe

operations,suchasusermobility,datalocation,datarepli-

cation,TISinteraction,thatthemodeland

theprotocolsaregenericenoughtobeeasilyadaptableto

avarietyofapplications,rangingfromsupportsystemsfor

strategicalactionstoelectronicmailsystemsforportable

computers.

Inthispaperwefocusourattentiononaconnectionless

communicationprotocolformobileclientsnamedResult

DeliveryProtocol(RDP).Inourproject,thisprotocolis

usedforthequeryandsubscriptionoperationsmentioned

before.

Theremainderofthispaperisorganizedasfollows:In

section2wedefinethesystemmodelandtheunderlying

ion3wedescribetheResultDeliv-

eryProtocol,focusingonhowlocationupdatesofmigrat-

ingclientsandretransmissionsarehandledbytheprotocol.

Wethencompareourprotcolwithrelatedworkinsection

y,insection5wegiveinformalargumentsabout

itscorrectnessandtheincurredoverheadanddrawsome

conclusions.

ModelandAssumptions

Themodelofthesystemconsistsoftwotypesofma-

chines,thestatichostsandthemobilehosts().Static

hostsareconnectedtoeachotherthroughastaticandreli-

ablenetwork.

Amongthestatichosts,somealsoserveasMobileSup-

portStations()forthemobilehostsandareassumed

finesageographicregion(cell)

inwhichitisabletocommunicatewiththesetofmobile

ormationabout

theswithinacellismaintainedateachinadata

structurelocal

1

Theuserspecifiesanentityandathresholdonanyofitsattributeval-

ues,andthesystemwillnotifytheuseraboutrelatedchangesintheentity.

2

Theuserprovidesitsidentification,theidentificationofagroupof

users(previouslyconfigured)andamessagetobesenttothegroup.

sendsajoinmessagetotheinchargeforthecell

itiscurrentlyin,whichthenbecomesthecurrently

responsibleforthe(respMss).Aleavesthesystem

bysendingaleavemessagetoitsrespMss.

Mobilehostsareabletomovefromonecelltoan-

eraentersanewcellitsendsa

greet(oldMss)messagetotheresponsibleforthe

targetcell,whereoldMssistheidentityofthere-

is

informationtheofthenewcellisabletoinitiatea

Hand-offprotocolwiththeprevious(seeSection3.2).

Thisgreetmessageisalsosentbythe

whenit

becomesactiveagainwithinthesamecellwhereithasbeen

particularcase,however,the

will

mentioned

notinitiate

inmessage

aHand-off

greet

protocol,

isitself.

sincetheprevious

Actually,inthismodelweabstractfromthedetailsof

howalearnsthatitisenteringorleavingacell,assum-

ingthatthiscanbeachievedindifferentwaysaccordingto

thewirelesstechnologyinuse.

Figure1showsasystemwiththree

sandfives

(inthecorrespondingcellsormigrating)andwheremobile

hostisissuingarequesttoserverfromonecell,but

maypickuptheserver’sreplywhilevisitinganothercell.

Mh3

greet

Mss2

Mss3

Mh2

Mh4

mcast(1,4,5)

Mh1

Mss1

Mh5

Themainassumptionsofthemodelarethefollowing:

icationamongthe

sisreliableandmes-

sagedeliveryisincausalorder;

reliableanddonotfail;

ime,eachactiveisassociatedwithexactly

one(respMss).

ctiveitmustsendanAcktoallmessages

receivedfromitsrespMss,andwhileitisinactiveit

igrates

betweencellsitmaybeconsideredinactivebyboththe

()orthenewMss()duringtheperiodof

timeoftheHand-off.

etodetectifamessagefromitsrespMss

isanewoneorifitisaretransmission.

eavesthesystemifithasacknowledged

allmessagesreceivedbyitsrespMss.

DeliveryProtocol

Intheremainderofthispaperwepresentandanalyzea

protocolwhichguaranteesreliabledeliveryofreplymes-

protocol,whichwecalledResultDeliveryProtocol,issuit-

ablefornetworkservicesbasedonarequest-replystyle

ofinteraction()andwithlongrequestprocessing

hservices,itislikelythattheclient(onthe

mobilehost)migratestoanothercellwhilewaitingforthe

tocolcanbeusedwithawide

rangeofexistingnetworkservicessincefromtheperspec-

tiveoftheserver,serviceaccessisidenticaltotheonebya

staticclient.

Althoughthepresentationoftheprotocolisfocussedon

arequest-replystyleofinteraction,likeoperationqueryof

thetrafficinformationservice(Section1),itcanbeused

aswellforasynchronousnotificationsofeventstomobile

,theRDPmayaswellbeusedforimplement-

ingtheoperationsubscribe(Section1),bywhichamobile

clientisinformedofanymajorchangeinthetrafficsitua-

tion.

TheRDPprotocolisbasedontheindirectmodelfor

client-serverinteractionsproposedbyBadrinathetal.[2].

Inthismodelthemobilesupportstationsactasrepresen-

tativesforallthemobilehostswithintheircell,holdpart

ofthe’sstate,anddothetranslationbetweenthewired

andthewirelesscommunication.

eoftheProtocol

TheResultDeliveryProtocol(RDP)isbasedontheno-

tionofaproxyforrequests(orsimplyproxy).Aproxy

iscreatedonbehalfofa

thatwishestointeractwith

eatedatthe

responsibleforthe’scurrentcell(respMss)whenever

n

purposeoftheproxyistoprovideafixedlocationforthere-

ceptionofserverreplies,tokeeptrackofpendingrequests,

storetherequest’sresults,andtoforwardtheresultstothe

responsibleforthecellinwhichtheiscurrently

xyobjectexistsonlyuntilallresultfor-

,

atalatermoment,thesamemaycausethecreationof

anewproxyatthesameoradifferent,dependingon

r,atanytimeeach

isassociatedwithatmostoneproxy.

Inordertodecidetowhichtoforwardtheresultofa

request,eachproxyholdsavariablecalledcurrentLoc,

whichisupdatedwiththeaddressofthecurrentrespMssof

thecorresponding

also

holdsarequestListcontainingidentifiersofallpend-

ingrequestsissuedbythe.

ForbeingabletoupdatecurrentLocateverymigra-

tion,eachhasoneproxyreference(orsimplypRef)

associatedtoit,ame

suggests,apRefcontainsareference(sof

theandaproxyID)tothecurrentproxyassociated

r,whenadoesnothaveaproxy

(hasnopendingrequests)pRefholdsanullad-

lsocontainsaflagcalledReadytoKillpRef

(RKpR),whichsignalswhethertheproxyhasforwardedthe

resultofitslastpendingrequest(seesection3.3formore

details).

Eachtimea

receivesanewrequestfromoneof

s

annulladdress,anewproxyiscreatedlocallyonbehalfof

andupdatespRefwithitsownaddressandthe

proxy’ise,Mssforwardstherequestto

theproxywhoseaddressismentionedinpRef.

Whena

migratesfromtopRefis

handedoverthroughtheHand-offprotocol(seeSection3.2)

toaspartof’ompletionofthe

Hand-offfora,’snewlocationisupdatedatthe

donebyhavingsendaspecialmes-

sage(updatecurrentLoc)ssage

isalsosentwhenarespMssreceivesagreetmessagefrom

theannouncingitsswitchfromtheinactivetotheac-

roxy,thearrivaloftheupdatecur-

rentLocmessagecausesthevariablecurrentLocto

beupdatedandanynon-acknowledgedresultsfrompend-

ingrequeststobere-senttothenewlocation.

Whentheresultofanyofspendingrequests(say,re-

questR)arrivesataproxy(locatedat)itisforwarded

respMss)andthendeliveredtothroughwirelesscom-

munication.

Innormalconditions,

isactiveandstays

initscellforasufficientlongperiodoftime,thearrivalof

R’sresultisacknowledgedbythethroughaAckmes-

sage,has

arrived,theproxymarksthatrequestRhasbeencompleted,

removesitfromtherequestList,andpossiblysendsan

acknowledgmenttotheserver,dependingontheparticular

application-levelclient-serverprotocolbeingused.

IfrespMssisunabletoreach,becauseitismigrat-

ingorisininactivestate,orsimplybecausewirelesscom-

municationfailed,therespMssdoesnotattemptanynew

d,itistheproxythatwill

re-senttheresultassoonasitreceivesthenextupdateof

’saddress.

Ateach,higherpriorityisgiventoforwardingAck

messages(fromsto)thantoengaginginanynew

oidsthatresultsalreadyac-

r,

assoonasrespMssreceivesarequest(fromanother)

totransfer’sstate,aspartoftheHand-offprotocol,it

willignoreallfutureAckmessagesfromthis

.

Fromtheviewpointoftheproxy,untilitdoesnotreceive

anAckmessageinformingthatR’sresulthasbeenindeed

receivedbythe,itkeepsre-sendingtheresulttoevery

fromwhichitsgetsaupdatecurrentLocmes-

thatthisguaranteesthateveryresultfroma

requestwilleventuallyreachitsdestination(the),pro-

videdthatthedoesnotleavethesystemwithapending

cetopayforthisreliabilityisthateventu-

allyaresultwillbesentmorethanoncetoa.

-offProtocol

TheHand-offprotocolisexecutedbetweena

and

wheneveraswitchescells,andaimsattransfer-

ringallof’sasfollows:

Aenteringanewcellregistersitselfwiththecor-

)bysending

itagreetmessagecontainingtheidentificationofitspre-

avingannounceditselfto,a

mustnotreplytoanymessagefromanyother

than.

Whenreceivingthegreetmessage,sends

aderegmessage,askingittode-registerand

sendback’sproxyreference(pRef).Whenre-

ceivesderegMh,itrepliesto

withaderegAck

messagecontaining’spRef,andthenremoves

fromitslocal

Mhs

listandupdates’snewlocationwithitsproxy,bysend-

ingtheupdatecurrLocmessagetotheproxy,whose

addressiscontainedinpRef.

Thegreetmessageisalsosentbyawhenitbe-

comesactiveagainwithinthesamecellwhereithasbeen

case,however,message

greetcarriestheidentificationofscurrentrespMss,

andhencenoHand-offisinitiated.

xyLife-cycle

Althougheveryalwayshasatmostoneproxythat

forwardsresultstoit,thelocationoftheproxiesinthestatic

networkmaychangeovertime,bywhichtheprotocolfacili-

tatesdynamicgloballoadbalancingwithinthesetofs.

Asmentionedearlier,aproxyiscreatedwhenevera

issuesanewrequestandnoproxyisyetavailable,

addressin’reation,aproxy

iscapableofhandlingseveralconcurrentrequestsfromits

.

Whenaproxy(hostedat

)forwardstheresultof

thelastpendingrequest(say,)toarespMss,flagdel-

pRefissettoandispiggy-backedonthisresultmes-

sagesenttoa’sthatifthismessage

isreceivedbythe,thentheproxycanbedeleted.

WhentherespMssreceivesaresultmessagewithdel-

pRef

,itsetsflagRKpRtrueat’spRef,mean-

ingthatrespMsswillconfirmtheremovaloftheproxy(and

eraseproxy’saddressinpRef’s)assoonasitreceivesan

Ackfromthatisnotprecededbyanynewrequest.

Ifthisisthecase,respMsssendsmessageAckwithflag

del-proxy

piggy-backedonitto,bywhich

-

ever,ifinthemeantime,anewrequestfromarrivesat

respMss,flagRKpRisre-settoandAckmessageis

sentwithdel-proxy,meaningthattheoldproxy

2showsthe

proxyandpRefobjects,andtheflagsusedtocontrolthe

existenceoftheproxy.

Thus,theremovaloftheproxyisconfirmedbyrespMss

onlyifthefollowingconditionholds:RKpRand

forallof’srequeststhecorrespondingAckhasbeen

thatsincewillalwaysuserespMssas

thegatewayfornewrequests,itwillneverhappenthata

newrequestissenttoawhichisnothostinga’s

proxy.

es

Inthissectionwepresenttwoexamplestoillustratehow

RDPworks.

Figure3showsascenariowhereamobilehostMhissues

asinglerequesttoaserverat,thenmigratesto

ngthatthisis’sfirst

request,new

proxyiscreatedatwithitsvariablecurrentLoc

(abbreviatedbycurrL)settoandalsotheaddress

inpRefissetto

.

Noweachtimethemigrates(andaftertheHand-

offprotocoliscompleted)thenewsendsanupdate

currLmessagetotheproxyinordertoupdateitsvariable

currL.

Mh

res(del−pRef)

Ack

respMss

pRef

RKpR

res(del−pRef)

Ack(del−proxy)

Mss

p

proxy

currL

server

request

currL:=o

result

currL:=n

proxy

Mss

p

Mh

currL:=p

pRef:=(Mssp)

dereg

deregAck

+

pRef

update

currL

forward

result

+

del-pRef

update

currL

forward

result

+

del-pRef

greet

?

Ack

+

del-proxy

Mss

o

Hand-off

pRef

greet

Mss

n

Hand-off

Ack

Whentheresponseoftherequest(result)arrivesat

forwardsittotheMssmetionedincurrL,theproxy,

evenifinthemeantimehasmigrated,assuggestedby

thequestionmarkinthefi-backedonthere-

,becauseproxy’ssultmessagegoesdel-pRef

eMhhasmean-

whilemigratedtoanothercell,theproxydoesnotreceive

,hencewillrepeattheforwardingeveryanAckfrom

timeitsvariablecurrLisupdated,untilitfinallyreceives

anAckfromtheMh.

When

receivestheresultwithdel-pRef

,itsetstheflagRKpRat’spRef,forwards

.AssoonasresulttoMhandwaitsforanAckfrom

thismessagearrives,andsincestillRKpR,

erasestheaddressat’spRefandalsosends

messageAckpiggy-backedwithflagdel-proxy

y,whenthismessagearrivesatthe

proxyisdeleted.

Figure4depictsascenariowhereaMhissuesseveral

requeststhroughitsproxy,showingwhentheproxyisactu-

scenario,themobilehostMhfirstissues

requestAat(creatinganewproxy),andthenmi-

,initiallytheproxy’srequestList

containsonlyrequestAandwhenresultAarrivesfrom

forwardsresultAwithdel-pReftheserver,

ismessagearrives,setsflag

RKpR=trueat’spRef,andforwardsresultAtoMh.

However,sinceMhissuesanewrequestBbeforesend-

inganAckforresultA(AckA)flagRKpRissettofalse.

,itSincenowMssreceivesAckAwhenRKpR

leavespRef’saddressunchanged.

AfterreceivingrequestBfollowedbyAckA,the

proxy’srequestListendsupholdingonlyrequestB,

andresultBisforwardedto.

AssumethatmeanwhileanewrequestCarrivesatthe

proxy,causingitsrequestListtoholdbothrequestB

kBisreceivedbytheproxy,

andresultCisreceivedandforwarded,requestBcan

beremovedfromrequestList,leavingonlythesingle

pendingrequestC.

Inthisparticularcase,theproxydoesnotforwardagain

resultB(whichhasalreadybeensent),butsendsaspe-

cialmessagecontainingonlydel-pRefto,

whereitcausesflagRKpRat’spReftobesetto.

Finally,whenAckCarrivesfrom,pRef’saddressis

issettonull,andmessageAckCwithdel-proxy

server

resultA

requestA

requestB

resultB

requestC

resultC

proxy

Mss

p

requestA

update

currL

resultA

+

del-pRef

resultBresultC

del-pRef

Mh

requestB

Hand-off

AckA

requestC

AckB

AckC

+

del-proxy

Mss

resultA

requestBAckArequestC

resultB

AckB

resultC

AckC

senttoproxy,ansthatat

thenexttimeissuesanewrequest,anewproxywillbe

createdatitscurrentrespMss.

However,supposethatthelastdel-pRefmessagehad

,KpR

wouldbeleftunchangedandAckCwouldbesentto

withdel-proxy,avoidingtheremovalofthe

proxy.

dWork

Inourwork,weadopttheindirectmodelforclient-server

interactionsoriginallyproposedbyBadrinathetal.[2]and

nowadoptedalsoinmanyotherworks[14,3,8].Inthis

modelmobilityismadeexplicittoallprotocollayers(upto

theapplicationlayer)andthesserveasstaticinterme-

diatesforanycommunicationbetweenthemobileclients

edto

otherapproachesthatmakemobilityexplicitonlytothe

protocollayersuptothenetworklayer(IPand

itsoptimizations[10]),theindirectmodelhasasitsmain

advantagethepossibilitytobuildmobility-awarehigher-

levelprotocolswhichuselocalityinformationtodynami-

callyadaptthemselvestovarianttransmissionand/ornet-

workaccessconditions,suchascommunicationbandwidth

ofwirelessmedia,closestserver,er,thismodel

hastheadvantageofallowingthestoperformtrans-

lationsbetweenthewiredandwirelessmedium,andalso

tostoreapplication-specificdatarelatedtothestateofthe

s.‘local’

Basedontheindirectmodel,Bakre[3]proposesanin-

directTCPprotocol(I-TCP)andprotocolsathigherlayers,

pproach

,whichthefixedhostonly‘sees’animageofitspeer

isactuallystoredatitsrespMssandistransferredtoother

r,since

duringaHand-OffthewirelesscomponentofI-TCPsim-

plyresetscongestion-relatedparameters,I-TCPcannotrely

ontransport-layeracknowledgmentsanddefersthisrespon-

er,thefixedhost

isnowhold-(theserver)mustbeinformedthatanew

ing’ghourprotocolisnotaimedfor

connection-orientedservices,andhencedoesnotrequire

maintainingthestatusofaconnection,itproposesasolu-

tiontominimizethedisruptioncausedbytheHand-off.

AlthoughRDPisnotagenericnetworkprotocol(sinceit

issuitedonlyforconnectionlessrequest-replycommunica-

tion,ratherthanforgenericdatagramdelivery),itisuseful

tocompareitwithMobileIPduetosomecommonchar-

protocolsmessages(ordatagrams)are

-

bileIPtheyarecalledhomeandforeignagentandinRDP

protocols,the

location(inMobileIPterminology,care-ofad-current

dress)isstoredattheproxyandupdatedwheneverthe

registersatanew.

Themaindifferencesbetweentheprotocolsareasfol-

lows:InMobileIPthehomeagentisfixedratherthandy-

namic,

theproxyremainsatasamelocationonlywhilethereare

somependingrequests,andassoonasallresultsofpend-

ingrequestshavebeendeliveredsuccessfullytothecorre-

sponding

,,inRDPthe

proxymustkeeptrackofthependingrequests,meaningthat

hostingtheallnewrequestsmustbeforwardedtothe

proxy,rconse-

quenceoftheproxy’sdynamicaddressisthattheproxyref-

sateveryerence(pRef)hastobehandedoverbetween

nMobileIPtheaddressofhomeagentis

,itcanbeincludedby

However,MobileIPdoesnotguaranteereliabledatade-

mple,IPdatagramsmaybelost

whileanewcare-ofaddresschangeisonitswaytothe

homeagent,orduringtheperiodsofinactivityofthemo-

,MobileIPdelegatesthetaskofdetect-

ingandre-transmittinglostdatagramstouppernetworklay-

ers,r,ithasbeenshownthatconven-

tionaltransport-levelprotocolswithoutmobility-awareness

presentbadperformancewhenusedinawirelessenviron-

ment[4].InRDP,ontheotherhand,Hand-Offistightly

integratedwiththemessagedelivery,ensuringthatnomes-

sages(tresults)arelostdespitemigrationor

inactivity.

Manyotherworkshaveinvestigatedtheissueofdis-

ectDataman,fromRutgers,

ImielinskiandBadrinath[9]proposedseveralqueryandup-

datestrategiesfordistributedinformationservicesthatstore

frequentlymodifieddata,suchasthegeographiclocationof

individualmobilehosts.

ProjectRover[11],fromM.I.T.,isawell-knowndis-

tributedobjectdevelopmentenvironmentfordisconnected

idesmobilecomputingsupportbasedon

twoconcepts:QueuedRemoteProcedureCalls(QRPC)

andRelocableDynamicObjects(RDOs).InQRPC(asyn-

chronousRPC)theactualsendingoftheRPCrequestis

de-coupledfromtheQRPCinvocationandisperformedas

soonasthehasestablishedagoodcommunicationlink

anobjectencapsulatingboth

codeanddatathatcanexecuteeitherattheclientorthe

sense,QRPCandRDPperformcomple-

hefirstguaranteesreliablesending

ofrequests,RDPguaranteesreliableresultdelivery.

Pitouraetal.[12]describeageneralarchitectureofan

informationsystemformobileenvironment,andin[13]

proposesupportfortransactionsmanagementforwireless

ghrecentlymuchattentionhasbeen

giventotheproblemsofdatabasetransactionmanagement

[6]withdisconnectionrequirements,thisissueisnotad-

dressedbyourwork.

InProjectWireless-View[15](is-Chicago)sev-

eraldataallocationschemesarestudiedandspecificcost

modelsforaccesstocontinuouslychangingdatabasesfrom

clientsatmobilehostswereproposed.

Bayou[5](Xerox)isaweaklyconsistentstoragesystem

designedforamobilecomputingenvironmentthatsupports

thedevelopmentofavarietyofcollaborativeapplications,

suchassharedcalendars,mail,databases,etc.

Unlikeoursystemmodel,Bayoutreatsmobileunitsas

peersinapeer-to-peermodel,whereamobilehostmaybe

u,collectionsof

dataitemsarefullyreplicatedatagroupofBayouservers,

andclientscanreadorwriteanycopyresidingonanyserver

ncontri-

butionsofthissystemareitsmechanismsfordependency

checksandmergeprocedures,necessaryformaintaining

highavailabilityofBayousystemwithweakreplicacon-

sistency.

olAnalysisandConclusion

Theprotocolpresentedinthispaperguaranteesdelivery

(oftheresult)withatleast-onesemantics,sincetheproxy

keepsre-transmittingtheresultuntilanAckmessagear-

rives,signalingthatthe

hasindeedreceivedthere-

r,athatbecomesinactiverightafter

receptionoftheresultmessage(butdoesnotsendan

Ackmessage)willreceivethismessageagainwhenitbe-

comesactiveagain,eitherinthepreviousorinanewcell.

Ifthe

alreadysentanAcktoitsrespMssandif

wiredcommunicationguaranteesdeliveryofmessagesin

causalorder,thentheprotocolensuresdeliveryofmessages

becauseeach

issupposedtohandleAckforwardswithhighestpriority,

andthereforethefollowingsequenceofcausaldependen-

ciesamongevents(wheredenotesthesending

ofmessagefromserver)alwaysholds:

send(Ack)@Mss

send(Ack+del-proxy)@Mss

send(updatecurrL)@,theproxywillre-

ceivetheAckmessage(forwardedby)beforethe

messageupdatecurrL,from,andwillthusre-

movetheproxyinsteadofre-transmittingresult.

Inanycase,deliveryofredundantmessagesisnotama-

jorproblem,sinceitcanbeassumedthatthe

isableto

identifyduplicatedmessages.

Ifthewirelesscommunicationisreliable,re-

transmissionsoftheresultwiththeResultDelivery

Protocol(RDP)occuronlyifthemeantimeperioda

spendsinacellislessthan,where

andaretheaveragetransmissiontimes

forthewiredandwirelesscommunication,respectively.

Thisisunlikelytobethecaseforcurrentmobilesupport

systemswherethediameterofthecellsisofreasonable

size,lometers.

Themajoradvantageisthat,exceptfortheproxyref-

erence,neitherresultforwardingpointersnorotherresidue

(oftheresultmessage)needtobekeptatthe

,discardtheresultmessage

singleattempttoforwardittothelocal

3

aftera

.

Theoverheadofthisprotocolislimitedtothefollow-

ingextramessages:(1)oneupdatecurrLwheneverthe

mobilehostmigratesorbecomesactiveagain;and(2)one

extraAckmessagesentfromrespMsstotheproxywhen-

s,

everyrequestfromthemobilehosttoanapplicationserver

hastopassthroughtheproxy,sothattheproxycanholdit

aspending.

OurworkextendstheindirectmodelofBadrinathet

al.[2]inthesensethattheproxyrepresentsyetanother

communicationmediatorbetweenthemobileclientandthe

nadvantageofusingaproxyisthatfromthe

server’spointofview,theserviceisbeingrequestedfroma

fixedclient(xy),whichtransparentlyhandlesall

edwithsim-

ilarapproaches[3,1]ourprotocolaimsatminimizingthe

transferofa’sstatebetweentheoldandnewdur-

ingHand-off,becausemostofthedatarelatedtotherequest

(ult)iskeptattheproxy.

TheResultDeliveryProtocolisbeingimplementedas

thisprototype,wearesimulatinghostmobilitythroughran-

domcommunicationbetweendistributedprocesses(repre-

senting

s,andservers)withinaLinuxnetwork.

Usingthisprototype,wewilltestthisprotocolconcerning

itsefficiencywithrespecttoseveralpatternsofmobility,

urestep,weintendtore-

implementitinanetworkwithrealwirelesscommunication

support.

ThemainadvantageoftheRDPprotocolisthatalthough

ateachmomentonlyasingle

isresponsibleforre-

transmittingtherequestresultsforagiven,theproto-

colfacilitatesdynamicgloballoadbalancingwithintheset

er,theprotocolguaranteesthateventually

everyresultwillbedeliveredtotherequestingdespite

anynumberofmigrationsandperiodsofinactivity.

Acknowledgments

WegratefullyacknowledgeRicardodaRochaandour

colleaguesfromprojectSIDAMfortheirvaluablecom-

tSIDAMisbeingsupported

byFAPESP(Grantno.98/06138-2).

References

[1]ringmulti-

13th

InternationalConferenceonDistributedComputing

Systems,pages292–299,Pittsburgh,US,May1993.

[2]ath,,nski,and

ngMobileClients:ACaseforIn-

.4thWorkstationOperating

Systems,October1993.

[3]andImplementationofIndirectPro-

sis,

RutgersUniversity,October1996.

[4]tingvisitorlocation

n-

teenthIEEESymposiumonReliableDistributedSys-

tems(SRDS’98),pages109–117,Washington-Brus-

sels-Tokyo,.

[5],en,zer,,

r,ouArchitecture:

WorkshoponMobileComputingSystemsandAppli-

cations,SantaCruz,CA,U.S.,94.

[6]ofMobil-

-

biDE/Mobicom99Workshop,Seattle,WA,pages14–

,August1999.

[7]colforatomicmulticastamong

MWorkshop/Mobicom’99,Sea-

tle(USA),pages56–,August1999.

[8],gham,ting

.

ofMobiCom99,Settle,WA,pages36–,Au-

gust1999.

[9]nginhighly

18th

VLDBConference,1992.

[10]olsfor

r-

sonalComunications,3(1),February1996.

[11],,

ansactions

onComputers,February1997.

[12]nginformation

.3rdInter-

nationalConferenceonInformationandKnowledge

Management,pages371–378,1994.

[13]ngtransaction

rk-

shoponMobileComputingSystemsandApplications,

pages164–168,1994.

[14]eforWirelessOver-

PIEConferenceon

MultimediaandNetworking,(MMCM’96),SanJose,

CA,January1996.

[15]tioninDistributed

ansactions

onParallelandDistributedSystems,9(4),April1998.