26/03/2015

SDIS2014/2015:Project1DistributedBackupService

1.Introduction
Inthisprojectyouwilldevelopadistributedbackupserviceforalocalareanetwork(LAN).Theideais
tousetheunuseddiskspaceofthecomputersinaLANforbackingupfilesinothercomputersinthe
sameLAN.Theserviceisprovidedbyservers,onepercomputer,inanenvironmentthatisassumed
cooperative(ratherthanhostile).Eachserverretainscontroloveritsowndisksand,ifneeded,may
reclaimthespaceitmadeavailableforbackingupothercomputers'files.

1.1Assumptions
Theassumptionsmaderegardingtheenvironmentandthesystemareessentialwhendesigninga
distributedapplication.Inthissection,wetrytoexplicitalltheassumptionsthatyoucanmake,when
devisingyoursolution.Weputtheminasinglesectionsothatyoucaneasilyfindthem.Some
assumptionsstemfromtheenvironmentinwhichtheserviceisexpectedtooperateonandareeasyto
understand.Otherassumptionsarenotveryrealistic,buttheyaremadetosimplifyyoursolution.
Weassumethatthesystemiscomposedbyasetofcomputersinterconnectedbyalocalareanetwork.
Theserviceisprovidedbyasetofservers,onepercomputerthatparticipatesinthebackupservice.A
servermanageslocaldiskstoragewhereitmaystorefiles,orpartsthereof,andisidentifiedbytheIP
addressoftherespectivecomputer,whichisassumedtoneverchange.
Weassumethatthenetworkmaylooseorduplicatemessages,butthatnetworkfailuresaretransient.I.e.,
ifthesenderkeepsretransmittingamessage,itwilleventuallyreachitsdestination.
Likewisecomputersmayfailbycrashing,buttheymayalsorecover.Failureofacomputermayleadto
thelossoffiles,notonlytheonesoriginallystoredinthatcomputerbutalsothoseithasbackedupfor
otherpeers.
Weassumealocalareanetworkadministeredbyasingleentityinafriendlyenvironment.All
participantsbehaveaccordingtotheprotocolspecifiedanddonotattempttotakeadvantageofthe
serviceortoattackit.Furthermore,weassumethattheparticipantsdonotmodify,eitherintentionallyor
accidentally,thebackedupdata.

2.Service
Thebackupserviceisprovidedbyasetofservers,eachofwhichrunsonacomputer.Becausenoserver
isspecial,wecalltheseservers"peers".(Thiskindofimplementationisoftencalledserverlessservice.)
Asstatedearlier,eachpeercanbeidentifiedbytheIPaddressofthecomputerwhereitruns.

2.1ServiceDescription
Thepurposeoftheserviceistobackupfilesbyreplicatingtheircontentinthedisksofmultiple
computers.Weassumethateachfilehasa"home"computer,whichhastheoriginalcopyofthefile.
Althoughthefilewillbestoredonsomefilesystem,whichmaybedistributed,thebackupservicewill
generateanidentifierforeachfileitbacksup.ThisidentifierisobtainedbyapplyingSHA256,a
cryptographichashfunction,tosome*bitstring*.Eachimplementationcanchoosethe*bitstring*used
togenerateafileidentifier,aslongasthatchoicegeneratesfileidentifiersthatareuniquewithveryhigh
http://web.fe.up.pt/~pfs/aulas/sd2015/projs/proj1.html

1/8

26/03/2015

SDIS2014/2015:Project1DistributedBackupService

probability,i.e.thatbitstringshouldbeunique.Furthermore,becausethebackupserviceisnotawareof
versionsofafile,thebitstringusedtogenerateafileidentifiershouldincludedataandormetadatathat
ensuresthatamodifiedfilehasadifferentfileId.Asasuggestionyoucancombinethefilemetadata(file
name,datemodified,owner...)and/orfiledatatogeneratethatbitstring.
Thebackupservicesplitseachfileinchunksandthenbacksupeachchunkindependently,ratherthan
creatingmultiplefilesthatareacopyofthefiletobackup.Eachchunkisidentifiedbythepair(fileId,
chunkNo).Thesizeofeachchunkis64KByte(whereKstandsfor1000).Thesizeofthelastchunkis
alwaysshorterthanthatsize.Ifthefilesizeisamultipleofthechunksize,thelastchunkhassize0.A
peerneednotstoreallchunksofafile,orevenanychunkofafile.Therecoveryofeachchunkisalso
performedindependentlyoftherecoveryofotherchunksofafile.
Inordertotoleratetheunavailabilityofpeers,theservicebacksupeachchunkwithagivendegreeof
replication,i.e.onagivennumberofpeers.Thedesiredreplicationdegreeofachunkdependsonthefile
towhichitbelongs,andallchunksofagivenfilehavethesamedesiredreplicationdegree.However,at
anytimeinstant,theactualreplicationdegreeofachunkmaybedifferentfromtheonethatisdesired.
Inadditiontothebasicfunctionalityforbackingupandrecoveringafile,thebackupservicemust
providethefunctionalityforreclaimingdiskspaceonpeers.First,asarequirementoftheservice,each
peerretainstotalcontrolontheuseofitslocaldisk.Ifacomputeradministratordecidestoreducethe
amountoflocaldiskspaceusedbythebackupservice,itmayhavetofreediskspaceusedforbackingup
chunks.Thiswilldecreasethereplicationdegreeofthechunk,whichmaydropbelowthedesiredvalue.
Inthatcase,theservicewilltrytocreatenewcopiesofthechunksoastokeepthedesiredreplication
degree.Second,afilemaybedeleted.Inthiscase,thebackupserviceshoulddeleteallthechunksofthat
file.Actually,deletionofthechunksofafile,mayhappennotonlywhenthefileisdeletedonitsfile
system,butalsowhenitismodified,because,forthebackupsystem,itwillbeadifferentfile.Foodfor
thought:Isthisaproblemifwewishtokeepthebackupsofmultipleversionsofafile?
Asdescribed,thebackupserviceknowsonlyaboutchunksofthebackedupfiles,whichareidentifiedby
thefileId.Itknowsnothingaboutthefilesystemswheretheyarekept.Ofcoursetobeofpracticaluse,
themappingbetweenthefileIdkeptbythebackupsystemandthenameofthatfile(andpossiblyitsfile
system)needstosurviveafailureoftheoriginalfilesystem.Thisproblemcanbesolvedindifferent
ways,butyouarenotrequiredtodoitforthisproject.Forthisproject,andtokeepitfeasibleforallof
you,wewillassumethatthismappingisneverlost.

2.2ServiceInterface
Theserviceinterfaceisnotspecified.Youcandesignitasyouwish.Itmaybeassimpleasa
configurationfilewiththemaximumamountofdiskspacetheservicecanuseandalistingofthelocal
filestobackupandtheirreplicationdegrees.Regardless,itmustprovidethefunctionalityrequiredtotest
theprotocol.YoucanfindfurtherdetailsinAnnexA,butyoushouldreadthemonlyaftertheremainder
ofthisdocument.

3.Protocol
Inthissectionwedescribetheprotocolthatisexecutedbythepeers.
Theprotocolusedbythebackupservicecanbedecomposedinseveralsmallersubprotocols,whichare
usedforspecifictasks,andthatcanberunconcurrently:
http://web.fe.up.pt/~pfs/aulas/sd2015/projs/proj1.html

2/8

26/03/2015

SDIS2014/2015:Project1DistributedBackupService

1. chunkbackup
2. chunkrestore
3. filedeletion
4. spacereclaiming
Manyofthesesubprotocolsareinitiatedbyapeer.Todistinguishitfromtheotherpeers,inthe
descriptionofthesesubprotocols,wecallthatpeertheinitiatorpeer.Theotherpeersarecalledpeers
only.Theroleofinitiatorpeercanbeplayedbyanypeer,dependingontheparticularinstanceofthe
subprotocol.
Allsubprotocolsuseamulticastchannel,thecontrolchannel(MC),thatisusedforcontrolmessages.All
peersmustsubscribetheMCchannel.Somesubprotocolsusealsooneoftwomulticastdatachannels
(MDBandMDR),whichareusedtobackup/restorefilechunkdata.
NoteTheIPmulticastaddressesofthesechannelsshouldbeconfigurableviathe6firstcommandline
argumentsoftheserverprogram,inthefollowingorderMC,MDB,MDR,withtheIPmulticastaddress
beforetheportnumber.

3.1MessageFormatandFieldEncoding
Inthissubsectionwedefineagenericformatforallmessages.Below,inthesubprotocoldescription,we
specifiytheformatofeachmessagebyspecifyingthefieldsthatmustbepresent.Whentheyareusedin
amessage,theymustbeencodedasdescribedherein.
Thegenericmessageiscomposedbytwoparts:aheaderandthebody.Theheadercontainsessentially
controlinformation,whereasthebodyisusedforthedataandisusedinonlysomemessages.
Header
TheheaderconsistsofasequenceofASCIIlines,sequencesofASCIIcodesterminatedwiththe
sequence'0xD''0xA',whichwedenote<CRLF>becausethesearetheASCIIcodesoftheCRandLF
charsrespectively.Eachheaderlineisasequenceoffields,sequencesofASCIIcodesseparatedby
spaces,theASCIIchar''.Notethat:
1. theremaybemorethanonespacebetweenfields
2. theremaybezeroormorespacesafterthelastfieldinaline
3. theheaderalwaysterminateswithanemptyheaderline.I.e.the<CRLF>ofthelastheaderlineis
followedimmediatelybyanother<CRLF>,withoutanycharacterinbetween.
Intheversiondescribedherein,theheaderhasonlythefollowingnonemptysingleline:
<MessageType><Version><FileId><ChunkNo><ReplicationDeg><CRLF>

Someofthesefieldsmaynotbeusedbysomemessages,butallfieldsthatappearinamessagemust
appearintherelativeorderspecifiedabove.
Nextwedescribethemeaningofeachfieldanditsformat.
<MessageType>
http://web.fe.up.pt/~pfs/aulas/sd2015/projs/proj1.html

3/8

26/03/2015

SDIS2014/2015:Project1DistributedBackupService

Thisisthetypeofthemessage.Eachsubprotocolspecifiesitsownmessagetypes.Thisfield
determinestheformatofthemessageandwhatactionsitsreceiversshouldperform.Thisis
encodedasavariablelengthsequenceofASCIIcharacters.
<Version>
Thisistheversionoftheprotocol.ItisathreeASCIIcharsequencewiththeformat<n>'.'<m>,
where<n>and<m>aretheASCIIcodesofdigits.Forexample,version1.0,theonespecifiedinthis
document,shouldbeencodedasthecharsequence'1''.''0'.
<FileId>
Thisisthefileidentifierforthebackupservice.Asstatedabove,itissupposedtobeobtainedby
usingtheSHA256cryptographichashfunction.Asitsnameindicatesitslengthis256bit,i.e.32
bytes,andshouldbeencodedasa64ASCIIcharactersequence.Theencodingisasfollows:each
byteofthehashvalueisencodedbythetwoASCIIcharacterscorrespondingtothehexadecimal
representationofthatbyte.E.g.,abytewithvalue0xB2shouldberepresentedbythetwochar
sequence'B''2'(or'b''2',itdoesnotmatter).Theentirehashisrepresentedinbigendianorder,
i.e.fromtheMSB(byte31)totheLSB(byte0).
<ChunkNo>
ThisfieldtogetherwiththeFileIdspecifiesachunkinthefile.Thechunknumbersareintegersand
shouldbeassignedsequentiallystartingat0.ItisencodedasasequenceofASCIIcharacters
correspondingtothedecimalrepresentationofthatnumber,withthemostsignificantdigitfirst.
Thelengthofthisfieldisvariable,butshouldnotbelargerthan6chars.Therefore,eachfilecan
haveatmostonemillionchunks.Giventhateachchunkis64KByte,thislimitsthesizeofthefiles
tobackupto64GByte.
<ReplicationDeg>
Thisfieldcontainsthedesiredreplicationdegreeofthechunk.Thisisadigit,thusallowinga
replicationdegreeofupto9.Ittakesonebyte,whichistheASCIIcodeofthatdigit.
Body
Whenpresent,thebodycontainsthedataofafilechunk.Thelengthofthebodyisvariable.Asstated
above,ifitissmallerthanthemaximumchunksize,64KByte,itisthelastchunkinafile.Theprotocol
doesnotinterpretthecontentsoftheBody.Fortheprotocolitsvalueisjustabytesequence.

3.2Chunkbackupsubprotocol
Tobackupachunk,theinitiatorpeersendstotheMDBmulticastdatachannelamessagewhosebodyis
thecontentsofthatchunk.Thismessageincludesalsothechunkidandthedesiredreplicationdegree:
PUTCHUNK<Version><FileId><ChunkNo><ReplicationDeg><CRLF><CRLF><Body>

ApeerthatstoresthechunkuponreceivingthePUTCHUNKmessage,shouldreplybysendingonthe
multicastcontrolchannel(MC)aconfirmationmessagewiththefollowingformat:
STORED<Version><FileId><ChunkNo><CRLF><CRLF>

afterarandomdelayuniformlydistributedbetween0and400ms.Foodforthought:Whyusearandom
delay?
http://web.fe.up.pt/~pfs/aulas/sd2015/projs/proj1.html

4/8

26/03/2015

SDIS2014/2015:Project1DistributedBackupService

Thismessageisusedtoensurethatthechunkisbackedupwiththedesiredreplicationdegreeasfollows.
Theinitiatorpeercollectstheconfirmationmessagesduringatimeintervalofhalfasecond.Ifthe
numberofconfirmationmessagesitreceiveduptotheendofthatintervalislowerthanthedesired
replicationdegree,itretransmitsthebackupmessageontheMDchannel,anddoublesthetimeinterval
forreceivingconfirmationmessages.Thisprocedureisrepeateduptoamaximumnumberoffivetimes.
Hint:BecauseUDPisnotreliable,apeerthathasstoredachunkmustreplywithaSTOREDmessageto
everyPUTCHUNKmessageitreceives.Therefore,theinitiatorpeerneedstokeeptrackofwhichpeers
haveresponded.
Apeershouldalsocountthenumberofconfirmationmessagesforeachofthechunksithasstoredand
keepthatcountinnonvolatilememory.Thisinformationisusedifthepeerrunsoutofdiskspace:in
thatevent,thepeerwilltrytofreesomespacebyevictingchunkswhoseactualreplicationdegreeis
higherthanthedesiredreplicationdegree.
Enhancement:Thisschemecandepletethebackupspaceratherrapidly,andcausetoomuchactivityon
thenodesoncethatspaceisfull.Canyouthinkofanalternativeschemethatensuresthedesired
replicationdegree,avoidstheseproblems,and,nevertheless,caninteroperatewithpeersthatexecutethe
chunkbackupprotocoldescribedabove?

3.3Chunkrestoreprotocol
Thisprotocolusesthesamemulticastcontrolchannel(MC)asthebackupprotocol,butusesadifferent
multicastchannelfordata,themulticastdatarecoverychannel(MDR).
Torecoverachunk,theinitiatorpeershallsendamessagewiththefollowingformattotheMC:
GETCHUNK<Version><FileId><ChunkNo><CRLF><CRLF>

Uponreceivingthismessage,apeerthathasacopyofthespecifiedchunkshallsenditinthebodyofa
CHUNKmessageviatheMDRchannel:
CHUNK<Version><FileId><ChunkNo><CRLF><CRLF><Body>

ToavoidfloodingthehostwithCHUNKmessages,eachpeershallwaitforarandomtimeuniformly
distributedbetween0and400ms,beforesendingtheCHUNKmessage.IfitreceivesaCHUNK
messagebeforethattimeexpires,itwillnotsendtheCHUNKmessage.
Enhancement:Ifchunksarelarge,thisprotocolmaynotbedesirable:onlyonepeerneedstoreceivethe
chunk,butweareusingamulticastchannelforthat.Canyouthinkofachangetotheprotocolthatwould
eliminatethisproblem,andyetinteroperatewithnoninitiatorpeersthatimplementtheprotocol
describedinthissection?

3.4Filedeletionsubprotocol
Whenafileisdeletedfromitshomefilesystem,itschunksshouldalsobedeletedfromthebackup
service.Inordertosupportthis,theprotocolprovidesthefollowingmessage,thatshouldbesentonthe
http://web.fe.up.pt/~pfs/aulas/sd2015/projs/proj1.html

5/8

26/03/2015

SDIS2014/2015:Project1DistributedBackupService

MC:
DELETE<Version><FileId><CRLF><CRLF>

Uponreceivingthismessage,apeershouldremovefromitsbackingstoreallchunksbelongingtothe
specifiedfile.
Thismessagedoesnotelicitanyresponsemessage.Animplementation,maysendthismessageasmany
timesitwishestoensurethatallspaceusedbychunksofthedeletedfilearedeletedinspiteofthelossof
somemessages.
Enhancement:Ifapeerthatbacksupsomechunksofthefileisnotrunningatthetimetheinitiatorpeer
sendsaDELETEmessageforthatfile,thespaceusedbythesechunkswillneverbereclaimed.Canyou
thinkofachangetotheprotocol,possiblyincludingadditionalmessages,thatwouldallowtoreclaim
storagespaceeveninthatevent?

3.5Spacereclaimingsubprotocol
Thealgorithmformanagingthediskspacereservedforthebackupserviceisnotspecified.Each
implementationcanuseitsown.However,whenapeerdeletesacopyofachunkithasbackedup,it
shallsendtotheMCchannelthefollowingmessage:
REMOVED<Version><FileId><ChunkNo><CRLF><CRLF>

Uponreceivingthismessage,apeerthathasalocalcopyofthechunkshallupdateitslocalcountofthis
chunk.Ifthiscountdropsbelowthedesiredreplicationdegreeofthatchunk,itshallinitiatethechunk
backupsubprotocolafterarandomdelayuniformlydistributedbetween0and400ms.Apeerreceiving
thePUTCHUNKmessage,shouldbackoffandrestrainfromstartingyetanotherbackupsubprotocolforthe
samefilechunk.
Foodforthought:ThelossofREMOVEDmessagesmayleadtoanoverestimationofthenumberofcopies
ofafilechunk,andconsequentlyitsactualreplicationdegreemaybelowerthanthedesiredreplication
degree.Onewaytotrytopreventthiswouldbetoaddaresponsemessage.Canyouthinkofother
alternatives?Whataretheprosandcons?
Enhancement:Ifthepeerthatinitiatesthechunkbackupsubprotocolfailsbeforefinishingit,the
replicationdegreeofthefilechunkmaybelowerthanthatdesired.Canyouthinkofachangetothe
protocol,compatiblewiththechunkbackupsubprotocol,thatcouldtoleratethisfaultinanefficientway?
Trytocomeupwithasolutionthatworksinbothcasesofexecutionofthechunkbackupsubprotocol,
i.e.bothwhenachunkisbeingbackedupthefirsttimeandwhenacopyofthechunkisdeleted.

3.6ProtocolEnhancements
Ifyouchoosetoenhanceanyofthesubprotocolsdescribedabove,ortocreatenewsubprotocolstoadd
somefeatures,youmustbecarefultoensureinteroperabilitywiththesubprotocolsdefinedinthis
document.
http://web.fe.up.pt/~pfs/aulas/sd2015/projs/proj1.html

6/8

26/03/2015

SDIS2014/2015:Project1DistributedBackupService

Ifpossible,youshouldavoidchangingoraddinganymessage.Ifyoufindthatthatisunavoidable,you
shouldadheretothefollowingrules:
1. Theheaderofeachmessageshallbeasequenceoflines,suchthatitdoesnotbreakthegeneral
formatrulesusedintheheaderdefinition:
1. Thelastheaderlineisalwaysanemptyline,i.e.the<CRLF>ASCIIcharactersequence
2. Eachheaderlineterminateswiththe<CRLF>ASCIIcharactersequence
3. FieldsinaheaderlineareseparatedbythespaceASCIIchar
2. Ifyouhavetochangemessagesdefinedherein,donotchangetherespectiveheaderline,instead
addnewheaderlines.

4.FinalRemarks
4.1Whatandhowtosubmit?(Changedon20150324:submissionisviaSVNon
Redmine)
YoushouldsubmitallthesourcecodefilesviatheSVNrepositoryoftheRedmineprojectthatyoumust
createforSDIS.Yourprojectidshallbenamedsdis1415t<n>g<p><q>,where<n>isthenumberofyour
section(turma)and<p><q>aretwodigitswiththenumberofyourgroup,e.g.sdis1415t3g06.Inaddition
tothesourcecodefiles,youshouldsubmitaplainASCIIfilenamedREADMEwithinstructionsfor
compilingandrunningyourapplication.
Furthermore,ifyouhaveimplementedanyenhancementtotheprotocolspecifiedinthisdocument,you
shouldsubmitalsoareport,aPDFfilenamedprotocol.pdfalsoviatheSVNrepositoryofyour
Redmineproject.Foreachenhancementyouhaveimplemented,theprotocolshouldincludeits
specificationandexplainitsrational.Thisshouldnotbelongerthanapageperenhancement.

4.2Gradingcriteria(Changedon20150324:useofJavaNIOwithsinglethreaded
allowsalsomaximumscore)
Wewilltestyourimplementationalsowiththatofothergroups,andpossiblyourown,toensurethatthe
protocolsareimplementedinaninteroperableway.Therefore,wesuggestthatasyoudevelopyour
projectyoutestitwiththatofothergroups.
Aproficientconcurrentimplementationofthesubprotocolswithoutenhancementsdescribedinthis
documentisworthaprojectgradeof80%.Toachieveconcurrency,youcanuseeithermultiplethreads
orJavaNIO.
Byimplementingeachofthe4suggestedenhancements,youwillgetanadditional5%.Pleasenotethat
yourenhancedsubprotocolsmuststillinteroperatewithnonenhancedsubprotocols,thereforeyoumust
beverycarefulindesigningtheseenhancements.
Youwillhavetheopportunitytoevolvethisserviceinthesecondproject.(Theideaisto"move"the
servicefromaLANtotheInternet.)Actually,ifyouwishtogetaveryhighgradeinthiscourse(say18
orabove)itislikelyeasierifyouchoosethispaththanifyouchoosetheimplementationofaweb
service.Thisisbecausethispathislikelytobemoredifficultandtheprojectdifficultydeterminesthe
maximumgradeyoucanget.
Havingsaidthat,ifyoufindotheropportunitiestoimprovetheservice(forexample,howtodealwith
http://web.fe.up.pt/~pfs/aulas/sd2015/projs/proj1.html

7/8

26/03/2015

SDIS2014/2015:Project1DistributedBackupService

"congestion"onthenetwork)youmaygetextracredit.However,youshoulddiscussthemfirstwithus.
CreatinganewtopiconMoodlewouldbeanicewaytostartthatdiscussion.

AnnexA:ServiceInterface
Thisdocumentfocusesontheprotocolsnotontheserviceinterface.Thisisintentional.Youcanchoose
theinterfacethatismoreconvenientforyou,butitmustprovidesomemeanstoinitiateanyofthe
(sub)protocolsfortestingthem.I.e.,theremustbesomewaytotellyourserviceto:
1. backupafilewithagivenreplicationdegree
2. restoreafilethatwaspreviouslyreplicated
3. deleteafilethatwaspreviouslyreplicated
4. tofreesomediskspacethatisbeingusedtostorecopiesofchunksbackedupbyremotepeers
Althoughyouaregiventhefreedomtodefinetheinterface,itcannotrequiretheusertoinputthe
<fileId>ofthecorrespondingfile.(Itisalongstringofhexadecimalsymbols,andthereforenoteasyfor
humanstohandle.)Aslongasyousatisfythisrequirement,anyinterfaceisOK,andthereisnogainin
providingaspeciallyfancyGUIorevenaGUI:essentiallythegradingwilldependontheprotocols
theimplementationofthosewehavespecified,andthespecificationandimplementationofthoseyou
mayspecifyinthescopeoftheenhancements.

AnnexB:Interoperability
Yourimplementationmustinteroperatewiththatofotherstudents:wewilltestthis.Thatisyourservice
mustbeabletoexecutethefourtasksmentionedinthepreviouspointusingonlythemessagesinSection
3.Youshouldconsiderboththebehaviorasaninitiatorpeerandotherwise.(Ofcourse,iftherearenot
enoughremotepeersimplementingyourenhancement,thecorrespondingenhancedprotocolmayfail.)
Toavoidinterferencebetweentheexecutionofnoninteroperableimplementations,aservicemustdrop
messagesthatitdoesnotunderstand.Thisisageneralruleofeveryprotocol.
Ifyouimplementanyenhancements,itisprobablyeasiertoensureinteroperabilityifyouprovidetwo
operatingmodes:onewiththeenhancementsandtheotherwithout.Thelattershalluseonlythe
messagesdefinedinthisdocument.
Youshouldcarryoutinteroperabilitytestsassoonaspossible.Thechunkbackupsubprotocolisagood
startingpoint.Ifyourimplementationisabletoexecutethissubprotocolwithimplementationsfrom
othercolleagues,thenitshouldnotbehardtogettheimplementationoftheothersubprotocolsto
interoperate.
Thiscanbedoneratherearlyinyourdevelopmentandwithoutmucheffort.Youcanprovidea.class
filethatprintsthemessagestothestandardoutput.Thisway,othergroupscanusethatfile,togenerate
messagestotesttheirowncode,inparticularthecodethatparsesthemessages.

http://web.fe.up.pt/~pfs/aulas/sd2015/projs/proj1.html

8/8