Vorgurakendused 2 prax 1 2018 kevad
Sisukord
Ülesanne
Sul on võimalik valida kahe erineva ülesande vahel:
- Lihtsa P2P võrgu realiseerimine ja sellele distributed ledgeri mõne aluskomponendi (mitte veel terve ledgeri) realiseerimine.
- Lihtsa P2P võrgu realiseerimine ja sellel anonümiseeriva võrgu (mikro-TOR) realiseerimine.
Kummalgi juhul on sul alustuseks vaja implementeerida lihtne P2P protokoll üle HTTP, nii et:
- protokoll oleks realiseeritud HTTP protokolli peale (vaja implementeerida ka HTTP server ja klient)
- mitu sinu rakenduse klooni suudavad suhelda nii samas masinas, töötades eri portide peal, kui mitmes erinevas masinas eri IP-de peal.
- eesmärk on kõigi rakendused omavahel suhtlema ja ühise võrguna tegutsema panna
Programmeerimiskeel on vabalt valitav. Masin(ad), kus su süsteem töötab, on vabalt valitavad: võid kasutada oma laptoppi, arvutiklassi arvutit, dijkstrat või mõnda muud serverit.
NB! Siin praksis ei või kasutada nö suurt veebiserverit a la Apache, Nginx vms. Lihtsad http teegid on samas OK. Ei soovitaks kasutada ka veebiraamistikke a la Spring vms: need ei ole esimese praksi jaoks mõttekad ning nende jaoks on eraldi 2. praksi variant.
Praktikumi lõpus pead tegema juhendajale oma grupiga väikese demo - et kuidas töötab - ja seletama natuke oma koodi ehitust.
Jooksvalt praktikumide käigus täienev nimekiri soovitustest kuidas rakendust samm-sammult ehitada asub siin: https://github.com/martinve/pyp2p Näidisrakendus on kirjutatud Pythonis aga tegevuste nimekiri on universaale sõltumata platvormist.
Kuidas alustada
Sul on kõigepealt vaja teha väike P2P rakendus, ehk proge, mis suudaks oma kloonidega suhelda. Konkreetsemalt:
- sinu proge on käsurea rakendus ilma kasutajaliideseta
- ta kuulab, kas temaga tahetakse võtta ühendust ja võtab ise teistega ühendust
- tahame saavutada, et meil käib korraga N koopiat, eri masinates, ja nad süngivad omavahel datat (ledgeri puhul) või saadavad päringuid teistele laiali (tori puhul).
- "teiste kuulamine tähendab", et ta on server
- eeldame, et ühendus toimub üle http
Kõigepealt tee nii, et sinu proge reageeriks http päringutele ja vastaks neile mingi testvastuse, et sa saaks ise aru, et ta on värgi kätte saanud.
Järgmine asi on panna ta ise teistega ühendust võtma: siis ta avab urli nagu brauser.
Küsimus, et kuidas päringuid kodeerida.
võtame GET näite urliga
http://1.2.3.4:4500/request?param1=val1¶m2=val2
siin http://1.2.3.4:4500/ ütleb, mis masinaga (1.2.3.4) ühendust võtta mis pordilt (4500) ja see
request?param1=val1¶m2=val2
on string, mis rakendus kätte saab ja ise parsima peab, ja mida võib kodeerida ehk ka näiteks nii
/val1/val2/
POST puhul see osa
request?param1=val1¶m2=val2
on mittevajalik ja parem oleks teha ainult
http://1.2.3.4:4500/
ja saata sisu jsoni tekstina a la
{"param1":val1, "param2":val2}
kuigi saab ka saata postiga lihtsalt
param1=val1¶m2=val2
mis on veidi vähem mainstream.
Mis teeb käsurea rakendus? Panen ta käima, ta jääbki käima ja trükib vajadusel debuginfot. Tal peab olema pordikuulamise tükk sees ja talle peab kuskil ütlema, et mis porti kuulata. Tal võiks olla default port a la 5134 ja saad käivitades öelda pordi a la ühes aknas
prog.py 6345
teises aknas aga
prog.py 7890
NB! Iga kloon samas masinas peaks olema eri pordil.
Näidisrakendus
Näidisrakenduse implementatsioon Pythonis on leitav Githubist: https://github.com/martinve/pyp2p
HTTP server/klient
HTTP baasil töötav protokoll näeb välja umbes järgmine:
GET http://1.2.3.4/request?param1=val1¶m2=val2 POST http://1.2.3.5/response?param1=val1¶m3=val3
jne. Seega tuleb meil teha:
- HTTP server, mis suudaks vastu võtta GET ja POST päringut ning parseerida pathi ja parameetrid (query stringi). Meid huvitab ka IP, kust päring tuli, see tuleb edaspidi kasutamiseks meelde jätta. POST päringu puhul peab lugema päringu "keha" (body).
- Selle peale peaks serveris käivituma mingi funktsioon. Selle võime jätta hetkel tühjaks
- Lõpuks saadame vastuse samuti HTTP päringuga. Seega vaja selleks HTTP klienti.
Server tuleb realiseerida ise, kasutades võrgust leitavaid näiteid mikro-http-serveri jaoks (tüüpiliselt paar lehekülge koodi). Selliseid näitekoode võib täiesti otse kasutada.
C jaoks on sobiv mikroserver näiteks tiny, java jaoks sobib alustuseks sisseehitatud HTTP server. Socketi tasemel alternatiividest on see server väga hea väike näide, aga selgitava tekstita, ning selgitavate tekstidega servereid leiad mh siit ja siit.Loe java socketitest põhjalikumalt siit. Pythoni serverinäite saad siit; lühem ja uuem. Http kohta võib lugeda näiteks siit.
Rakenduse variant 1: distributed ledgeri komponent
Sul on vaja kirjutada lihtne bitcoini-tüüpi rakendus, mis suudab leida oma kloone ehk sõlmi võrgus, küsida neilt olemasolevaid ledgeri blokke ja saata neile endale teadaolevaid blokke ja uusi transaktsioone (transaktsioonid on ülekanded ehk mistahes info, millest blokk kokku pannakse).
"Ledgeri blokk" võib selles praksis olla lihtsalt suvaline string või json struktuur: neid ei pea kontrollima, sünkima ega kaevandama. Piisab lihtsalt nende kogumisest ja soovijatele laialisaatmisest.
Sa võid ise valida, kas
- realiseerid lihtsustatud protokolli, millega saad ise distributed ledgeri ehitada, ei saa aga suhelda päris-bitcoini sõlmedega.
- või realiseerid alamhulga tegelikust bitcoini protokollist: see on tehniliselt päris keeruline (protokoll on bititasemel ja seal on palju detaile), samas saad siis ise leida päris-bitcoini võrgusõlmi ja katsetada, mis juhtub, kui neile näiteks ise ülekandeid vms saadad. Kui seda kaalud, siis loe enne bitcoini materjale kursuse põhilehel ja tutvu hardcore dokumentatsiooniga algul siit https://bitcoin.org/en/developer-guide#p2p-network ja siis siit https://en.bitcoin.it/wiki/Protocol_documentation
Nüüd detailsemalt meie oma lihtsustatud protokollist. Edaspidises eeldame, et http päringud on GET päringud, kui mõne puhul pole spetsiaalselt öeldud, et tegu on POST päringuga. Pane tähele, et sul on vaja realiseerida nii kloonide/blokkide küsimine kui nende küsimisele vastamine!
Kloonide ehk sõlmede leidmine võrgus
Klooni leidmine tähendab, et saad teada ip aadressi ja pordi, kus võiks olla töötav kloon. Sinu rakendusel peaks kõigepealt olema väike konfifail, kuhu saad kirjutada järjest mõned ip aadressid ja pordid: soovitav on see esitada teha jsoni listina. Käivitades hakkab sinu rakendus neid läbi käima ja küsima neilt, milliseid teisi kloone nad teavad. Nii kogud kokku pikema listi kloonidest. Samuti pead suutma vastata endale teadaolevate kloonide päringule.
Soovitav on realiseerida päring http protokolliga, näiteks nii:
http://xx.xx.xx.xx:yyyy/addr
millele vastatakse kloonide json listiga, samas formaadis, kui sinu konfifailis.
Reaalse töö käigus ei ole sul vaja leida kõiki töötavaid kloone, piisab mingist "mõistlikust" hulgast.
Hea mõte on taustaks läbi lugeda need lühikesed jutud kursuse põhilehelt (arusaadavalt ei pea sa neid meetodeid realiseerima):
- https://bitcoin.stackexchange.com/questions/3536/how-do-bitcoin-clients-find-each-other
- https://en.bitcoin.it/wiki/Satoshi_Client_Node_Discovery
Ledgeri blokkide küsimine
Sul on vaja regulaarselt küsida ja kettal hoida nö ametliku ledgeri kõiki blokke. Ledger on lihtsalt blokkide list. Igal blokil on oma tekstiline id (bitcoini puhul bloki hash) ja sisu. Bloki hash tuleb arvutada bloki tekstilise esituse pealt sha-256 hashifunktsiooniga, ning konvertida hex-kujule. Hashe saadame siis alati hex-kujul.
Nagu öeldud, ei pea me esimeses praksis blokkide sisuga ja nende kontrollimisega tegelema, selleks on teine praks.
Kuna sul võib juba olla mingi hulk ledgeri blokke salvestatud, siis on kasulik saada küsida ka blokke alates mingist teadaolevast blokist (ehk tema hashist).
Blokkide järjestuse võid teha esialgu lihtsalt nii, et hoiad blokke saabumise järjekorras. Lõplikus ledgeri variandis peaks blokid olema hashchaini järjestuses (blokk N+1 hash moodustatakse bloki sisust+eelmise bloki hashist, vaata seda pilti, kus on näha bloki sees olev hashide merkle puu ja blokkide järjestus lihtsa hashiahelana), aga seda hashchaini ja kontrolli ei ole esialgu vaja teha.
Blokkide küsimine peaks välja nägema nii, et saad
- küsida korraga blokkide nimistut ehk hashide listi (kas tervet või ainult uuemaid)
- küsida konkreetseid blokke vastavalt nende hashidele.
Kõigi blokkide nimistu küsimine võiks välja näha nii:
http://xx.xx.xx.xx:yyyy/getblocks
ja alates-blokist-Z nii:
http://xx.xx.xx.xx:yyyy/getblocks/Z
kus Z on bloki id ehk hash.
Vastuseks võiksid saada bloki hashide listi.
Ühe konkreetse bloki küsimine võiks välja näha nii:
http://xx.xx.xx.xx:yyyy/getdata/H
kus H on bloki hash, millele vastavat blokki tahad.
Uute transaktsioonide ja uute ledgeri blokkide laialisaatmine
Siin toimub tehingute ja blokkide laviinitaoline laialisaatmine kõigile kloonidele: iga kloon salvestab talle saadetud info ja saadab selle siis teistele edasi.
Sul olema võimalik omal initsiatiivil laiali saata transaktsioone ehk ülekandeid (a la Jaan kannab 2018-02-15 Antsule 0.0001 bitcoini).
See päring võiks olla POST päring, kus url on
http://xx.xx.xx.xx:yyyy/inv
ning postitatud väärtus (st tekst peale http päiste järel olevat tühja rida) on on transaktsiooni hash ja tema json-esitus. Transaktsiooni sisu võiks esialgu olla suvaline (json) string. Sellise postitatud päringu vastuseks võiks anda kas arvu 1 kui transaktsioon aktsepteeriti või veateate (näiteks {"errcode": ..., "errmsg": ...} kui teda ei aktsepteeritud.
Kättesaadud transaktsioon tuleks salvestada ja omakorda teistele kloonidele laiali saata. Pane tähele, et kui sa oled mingi hashiga transaktsiooni saad, siis peaksid vaatama, kas ta sul juba on, ja kui on, siis mitte edasi saatma.
Samuti peab sul olema võimalik saata teistele kloonidele omal initsiatiivil uusi blokke, mis nemad peaks oma ahela lõppu lisama, kontrolle pole esialgu vaja (teises praksis hakkame tegelema blokkide kontrolli ja "ametliku" ahela sünkimisega. Blokk koosneb üldjuhul hulgast kontrollitud transaktsioonidest.
See päring võiks olla POST päring, kus url on
http://xx.xx.xx.xx:yyyy/block
ning postitatud väärtus (st tekst peale http päiste järel olevat tühja rida) on bloki hash ja tema tekstiline sisu (vali ise, kuidas neid kodeerid). Sellise postitatud päringu vastuseks võiks anda kas arvu 1 kui blokk aktsepteeriti või veateate (näiteks {"errcode": ..., "errmsg": ...} kui teda ei aktsepteeritud.
Jällegi, kättesaadud blokk tuleks salvestada ja omakorda teistele kloonidele laiali saata. Pane tähele, et kui sa oled mingi hashiga bloki saad, siis peaksid vaatama, kas ta sul juba on, ja kui on, siis mitte edasi saatma.
Rakenduse variant 2: anonümiseeriv võrk
Eesmärgiks on ehitada anonümiseeriv võrk nagu Tor. Täpsemalt on eeskujuks praeguseks mitteaktiivne anonüümne failijagamise võrk MUTE Network. Sealt võetud ideid kasutades teeme võrgu, kus saab anonüümselt veebist faile (html vms) alla laadida.
Meie võrgus teab iga võrgusõlm (node) näiteks kolme naabrit. Kui sõlm A tahab alla laadida URL-i http://google.ee, saadab ta päringu kõigile oma naabritele. Need omakorda saadavad päringu oma naabritele jne. Päringul on kaasas salajane identifikaator - ainult A teab, et see identifikaator seostub temaga. Lõpuks jõutakse võrgusõlmeni B, kes otsustab, et laadib ise URL-i sisu alla. B ei tea kes URL-i sisu soovis, aga saadab vastuse suunas, kust ta päringu sai. Samal viisil liigub vastus mööda võrku tagasi, kuni jõuab A-ni, kes tunneb ära oma salajase identifikaatori.
Võrku liituda ja sealt lahkuda võib suvalisel ajal. Seetõttu tuleb liitudes ja edasi perioodiliselt värsket naabrite nimekirja küsida, selleks paigutatakse samasse võrgu eraldi kataloogiserver.
Protokoll
Port. Vaikimisi on eeldatud, et võrgusõlmed kasutavad sõnumite vastuvõtmiseks porti 1215. Kasuta seda, kui suhtled teiste üliõpilaste programmidega ja kataloogiserveriga virtuaallaboris. Iseseisvaks või kohalikuks testimiseks võib kasutada ka muid porte.
Päringu saamise kinnitus. Peale iga HTTP päringu saamist vastab võrgusõlm tekstiga "OK"
juhul kui ei olnud viga ning tekstiga "Error: xxxxxxxxxxx"
kui oli viga (xxxxxxxxxxx tähistab vabas vormis vea kirjeldust ning selle võib ka ära jätta). Vastuse saatmine on kohustuslik, isegi kui võrgusõlm päringuga tulnud sõnumit ignoreerib. Korrektse sõnumi puhul peab vastuse HTTP staatus olema 200, muul juhul on lubatud ka HTTP veakoodide esinemine.
Naabrite nimekiri. Iga minuti tagant tuleb naabrite nimekirja kataloogiserverist uuendada (vt allpool).
URL-i (faili) alla laadimise päring
nimi (path) | /download |
parameetrid | ?id=xxxxxxxx&url=yyyyyyy |
tüüp | HTTP GET |
body |
xxxxxxxx on selle sõnumi jaoks genereeritud juhuslik number. Kui sama võrgusõlm näeb hiljem sama id-ga file
sõnumit, siis see sisaldab soovitud vastust. yyyyyyy on täispikk URL, mis peab olema turvaliselt kodeeritud, Pythoni lahendus.
Näide: http://1.2.3.4:1215/download?id=7652354352&url=http%3A//google.ee/%3Fs%3Dbla%26lang%3Den
Käsitlemise reeglid:
- Kui sõlm algatab ise selle päringu, peab ta meelde jätma
id
, et hiljem vastust ära tunda - Päringu algatav võrgusõlm saadab sõnumi kõigile hetkel teadaolevatele naabritele
- Esimest korda selle sõnumi vastu võtmisel otsustab võrgusõlm, kas faili alla laadida (tõenäosus x%, konfitav)
- Kui faili alla ei laadita, saadab võrgusõlm sõnumi edasi kõigile oma naabritele, v.a juhul kui naabri IP langeb kokku sõnumi edastanud sõlme IP-ga
- Kui fail alla laaditakse, siis algatatakse
file
tüüpi sõnum (vt. allpool) - Mõlemal juhul tuleb meelde jätta sõnumi
id
ja edastanud võrgusõlme IP
- Teist korda sama (või enda algatatud)
id
-ga sõnumi vastu võtmise korral seda ignoreeritakse - Päringu algatanud sõlm peab arvestama võimalusega, et võrgu ebastabiilse iseloomu tõttu ei ole vastuse saabumine garanteeritud
Faili sisu tagastamine
nimi (path) | /file |
parameetrid | ?id=xxxxxxxx |
tüüp | HTTP POST |
body | {"status":yyy, "mime-type":"zzzzzzzz", "content":"..."} |
xxxxxxxx on sama, mis download
sõnumis, mille saamise tõttu fail alla laaditi. HTTP päringu kehas on JSON formaadis objekt, mis sisaldab base64 kodeeringus faili ja selle metadatat. yyy on faili allalaadimisel saadud HTTP staatus. zzzzzzzz on faili sisu MIME tüüp (peale dekodeerimist). "content" väljal on RFC-3548 ühilduvas base64 kodeeringus (Pythoni tugi) faili sisu.
URI näide: http://5.6.7.8:1215/file?id=7652354352
Keha näide 1:
{"status":200, "mime-type":"text/html", "content": "PCFET0NUWVBFIGh0bWwgUFVCTElDICItLy9XM0MvL0RURCBYSFRNTC..."}
Keha näide 2 (viga):
{"status":404}
Käsitlemise reeglid:
- Päringu algatav võrgusõlm saadab sõnumi naabrile, kellelt sama
id
-gadownload
sõnumi vastu võttis - Kui eelmine samm ebaõnnestus, saadetakse sõnum kõigile naabritele
- Esimest korda selle sõnumi vastu võtmisel otsustab võrgusõlm, kas fail oli tema enda soovitud (
id
parameeter)- Kui ei olnud, saadab võrgusõlm sõnumi edasi naabrile, kellelt saabus sama
id
-gadownload
päring - Kui eelmine samm ebaõnnestus (või sellist naabrit ei teata), saadetakse sõnum edasi kõigile naabritele, v.a. juhul kui naabri IP langeb kokku käsitletava
file
sõnumi saatja IP-ga - Kui fail oli sõlme enda soovitud, parseeritakse päringu kehast staatus ja olemasolul faili sisu.
- Kui ei olnud, saadab võrgusõlm sõnumi edasi naabrile, kellelt saabus sama
- Teist korda sama (või enda algatatud)
id
-ga sõnumi vastu võtmise korral seda ignoreeritakse
Millal faili alla laadida?
Oletame, et võrgus on 10 arvutit. Kui allalaadimispäring laiali saadetakse, peaks üks neist hakkama faili alla laadima, ülejäänud 9-l pole seda vaja teha. Kuidas aga otsustada, kelle töö on fail alla laadida? Korrektne viis seda teha oleks DHT abil, mis aga mitmekordistaks protokolli keerukust. Kui me aga loobume korrektsusest lihtsuse huvides, saab asja teha ka täiesti suhtlusvabalt.
Igal võrgusõlmel on oma "laiskuse mõõt", näiteks antud juhul number 0.9. Kui võrgusõlm näeb päringut, mille peale tuleks algatada faili alla laadimine, leiab ta juhusliku numbri vahemikus 0 kuni 1. Kui see on suurem kui tema laiskus, siis tuleb hakata faili alla laadima. Kui aga laiskus on suurem, siis saadetakse sõnum edasi teistele. Antud näite puhul on kõige tõenäolisem, et üks võrgusõlm hakkab faili alla laadima, ehkki võib ka juhtuda, et neid on mitu või mitte ühtegi.
Kataloogiserver
Kataloogiserveriga suhtlemine toimub lihtsa klient-serveri mudeli abil, seal pole P2P protokolli tarvis. Naabrite küsimine:
http://192.168.3.11:1215/getpeers
Vastus:
[ "1.2.3.4:1215", "5.6.7.8:1215", "1.2.3.6:1215" ]
Vastus on JSON formaadis. Naabreid võib olla ka rohkem või vähem kui 3 (näiteks juhul, kui keegi teine pole võrguga liitunud).
Soovitused
Konfiguratsioon. Formaat pole oluline, aga mõtekas on järgmised parameetrid konfigureeritavaks teha. Pordi võib teha ka käsureaparameetriks:
; lokaalse testimise korral vähenda, suures võrgus suurenda laziness = 0.5 ; kataloogiteenus, siia võid panna ka staatilise tekstifaili URL-i directory = http://192.168.3.249:1215/getpeers ; lokaalseks mitme instantsiga testimiseks port = 1215
Naabrite tabel. Täidetakse kataloogiserverit kasutades.
nr | ip | port | elus |
---|---|---|---|
1 | 1.2.3.4 | 1215 | Y |
2 | 5.6.7.8 | 1215 | Y |
3 | 1.2.3.6 | 1215 | N |
4 |
Väli elus
võimaldab meelde jätta, kui naaber võrgust ära kaob. Seda saab asendada ka ajatempliga, aga jah/ei lipu käsitlemine on lihtsam.
Minu päringute tabel. Kuna igal päringul on uus id
, tuleb mitme päringu tegemisel ajalugu meelde jätta.
nr | id | url | ajatempel |
---|---|---|---|
1 | 7652354352 | http://google.ee/?s=bla&lang=en | Sat Sep 17 02:16:57 2016 |
2 |
Väli url
on kasulik näiteks veateadete edastamiseks. ajatempel
abil saab tuvastada, kui kaua päring on vastust oodanud ning vajadusel päringut korrata - sel juhul tuleb kindlasti uus identifikaator genereerida - või anda veateade.
Marsruutimistabel. Kui ülejäänud tabelid on "maitse küsimus", siis protokollis ette nähtud sõnumite käsitlusreeglite järgmiseks on järgnev marsruutimistabeli formaat oluliseks lihtsustavaks abivahendiks.
nr | id | download ip | file ip |
---|---|---|---|
1 | 7652354352 | 1.2.3.4 | |
2 | 7657856788 | 5.6.7.8 | |
3 | 9845345233 | 1.2.3.6 | 5.6.7.8 |
4 |
download ip
on naabri IP, kes saatis meile vastava identifikaatoriga download
sõnumi. Juhul kui näeme sama identifikaatoriga file
sõnumit, tuleks meil just download ip
aadressile see edastada. Mõeldav on ka juhtum, kus meil tuleb sisse file
sõnum, millele vastavat download
sõnumit me ei ole näinud. See tuleb aga ikkagi marsruutimistabelisse registreerida, et korduvat sõnumite laialisaatmist vältida (rida 2). file
sõnumi saatja IP läheb väljale file ip
. Juhul kui mõlemad sõnumid on nähtud, siis on mõlemad IP-d täidetud (rida 3) ning igasugusel edasisel kokkupuutel antud identifikaatoriga pole enam tarvis reageerida.
Seda tabelit saab täiendada ka ajatempliga, et vanemaid kirjeid kustutama hakata. Väikeste testimismahtude juures pole see veel vajalik.
Juhtimine Et testida, on minimaalselt vaja rakendusele ka alla laaditavaid URL-e ette sööta. Selleks on mõeldavad järgmised viisid:
- lähtekoodi sisse kirjutatud, lihtne teha aga raske hallata
- loetakse tekstifailist rakenduse käivitamisel
- antakse rakendusele käsurea argumendiks
- reaalajas üle HTTP (võimaldab näiteks AJAX-iga veebiliides lisada)
- reaalajas käsurealiidese (CLI) abil
- ...
Testimiseks on soovitatav esialgu lihtsam variant võtta ning hiljem kui rakendus juba suuremalt osalt töötab, leida viis, mis võimaldab paindlikumalt ja massilisemalt testida.
Praktikumi kirjeldus täieneb jooksvalt semestri käigus