Optimalizace vyuˇzit´ı v´ypoˇcetn´ıho v´ykonu pˇri tˇeˇzen´ı kryptomˇen

Optimalizace vyuˇ zit´ı v´ ypoˇ cetn´ıho v´ ykonu pˇ ri tˇ eˇ zen´ı kryptomˇ en

Diplomov´ a pr´ ace

M13000174

Studijn´ı program: N2612 – Elektrotechnika a informatika Studijn´ı obor: 1802T007 – Informaˇcn´ı technologie Autor pr´ace: Bc. Pavel Buch´aˇcek

Vedouc´ı pr´ace: Ing. Petr Kretschmer

Usage optimalization of the computation performance in the crypto currency mining

process

Master thesis

M13000174

Study programme: N2612 – Electrical Engineering and Informatics Study branch: 1802T007 – Information technology

Author: Bc. Pavel Buch´aˇcek Supervisor: Ing. Petr Kretschmer

Podˇ ekov´ an´ı

R´ad bych podˇekoval vedouc´ımu pr´ace Ing. Petru Kretschme- rovi za cenn´e rady pˇri vytv´aˇren´ı diplomov´e pr´ace. D´ale bych r´ad podˇekoval doc. RNDr. Pavlu Satrapovi za zpracov´an´ı L^ATEX ˇsablony, kterou jsem vyuˇzil pˇri vytv´aˇren´ı t´eto zpr´avy.

Abstrakt

V pr´aci se zab´yv´am optimalizac´ı tˇeˇzebn´ıho procesu kryptomˇen. Rozeb´ır´am zde moˇzn´a rizika, kter´ymi jsou v´ypadky spojen´ı a n´ızk´a efektivita prob´ıhaj´ıc´ı tˇeˇzby. Je- jich negativn´ı dopad se snaˇz´ım minimalizovat zaˇrazen´ım proxy serveru um´ıstˇen´ym mezi tˇeˇzebn´ıho klienta a c´ılov´y pool server. C´ılem proxy serveru je monitorovat a analyzovat prob´ıhaj´ıc´ı tˇeˇzbu.

V pˇr´ıpadˇe v´ypadku spojen´ı nebo zjiˇstˇen´ı neefektivn´ı tˇeˇzby proxy server pˇrepoj´ı tˇeˇzebn´ıho klienta na jin´y pool server. Kromˇe tˇechto vlastnost´ı syst´em uˇzivateli umoˇzˇnuje definovat nˇekolik mˇen, kter´e bude jeho tˇeˇzebn´ı klient tˇeˇzit. U kaˇzd´e mˇeny m˚uˇze uˇzivatel nastavit urˇcit´y pˇr´ıdˇel v´ykonu.

Syst´em tak pˇrin´aˇs´ı vyˇsˇs´ı efektivitu tˇeˇzby a umoˇzˇnuje jednomu klientovi tˇeˇzit v´ıce mˇen. T´ım dojde k maximalizaci ˇsance na z´ısk´an´ı odmˇeny za ovˇeˇren´e bloky.

Kl´ıˇ cov´ a slova

kryptomˇeny, tˇeˇzen´ı kryptomˇen, Bitcoin, Getwork, Getblocktemplate, Stratum, poo- led mining

Abstract

This thesis focuses on the optimization of the cryptocurrency mining process. I dis- cuss all possible threats in this process, which can be a network connection errors or a low effectivity of the mining process. I try to minimalize the impact of these events by using a proxy server placed between a mining worker and a target pool server. The aim of the proxy server is to analyze all events in the mining process.

If the proxy server detects any network fail, or an ineffective mining process is detected, the proxy server will reconnect the mining worker to a different pool server immediately. Except of these features user can also define a several currencies which wants to mine. User can define an amount of performance for each of these currencies.

The system boosts the effectivity of the cryptocurrency mining process and allows the possibility to mine more currencies by one worker. These features will maximalize the chance to earn the block reward.

Keywords

crypto currency, cryptocurrency mining process, Bitcoin, Getwork, Getblocktem- plate, Stratum, pooled mining

Obsah

Seznam zkratek . . . 11

1 Uvod´ 12 2 Kryptomˇeny 13 2.1 Co je to kryptomˇena . . . 13

2.2 Uˇzivatel´e kryptomˇen . . . 14

2.3 Tˇeˇzaˇri kryptomˇen . . . 14

2.4 Tˇeˇzaˇrsk´a seskupen´ı . . . 14

2.5 Tˇeˇzebn´ı stroje . . . 15

2.6 Blockchain . . . 15

2.7 Bitcoin . . . 15

2.8 Alternativn´ı kryptomˇeny . . . 16

2.9 RPC protokoly . . . 16

2.9.1 Getwork . . . 16

2.9.2 Getblocktemplate . . . 17

2.9.3 Stratum . . . 17

3 N´avrh proxy serveru pro optimalizaci tˇeˇzby 18 3.1 Motivace . . . 18

3.2 Struktura syst´emu . . . 19

3.2.1 Abstrakce RPC protokol˚u . . . 19

3.2.2 Uloˇ´ ziˇstˇe dat . . . 20

3.2.3 Spr´ava spojen´ı . . . 21

3.2.4 Anal´yza nasb´ıran´ych dat . . . 22

3.2.5 Konfigurace syst´emu . . . 23

3.3 Moˇznosti syst´emu . . . 23

3.3.1 Algoritmy a mˇeny . . . 24

3.3.2 Pool servery . . . 24

3.3.3 Tˇeˇzebn´ı skupiny. . . 24

4 Realizace syst´emu pro optimalizaci tˇeˇzby 26 4.1 Knihovna pro pr´aci s RPC protokoly . . . 27

4.1.1 Princip ˇcinnosti knihovny . . . 27

4.1.2 Identifikace RPC protokolu . . . 28

4.1.3 Autentizace uˇzivatele . . . 30

4.1.4 Handlery RPC protokol˚u . . . 32

4.1.5 Pˇrepojov´an´ı klienta mezi pool servery . . . 32

4.2 Uloˇ´ ziˇstˇe nasb´ıran´ych dat . . . 34

4.2.1 Verzov´an´ı datab´aze . . . 35

4.2.2 Model aplikace . . . 35

4.2.3 Mapov´an´ı dat . . . 36

4.2.4 Testov´an´ı servisn´ı vrstvy . . . 39

4.3 Proxy server . . . 40

4.3.1 V´ypadky spojen´ı . . . 41

4.3.2 Pl´anovaˇc . . . 42

4.3.3 V´ypoˇcet efektivity spojen´ı . . . 42

4.3.4 Rozdˇelov´an´ı v´ykonu. . . 44

4.4 Webov´e rozhran´ı pro konfiguraci syst´emu . . . 45

4.4.1 REST API. . . 45

4.4.2 Webov´a aplikace . . . 47

4.5 Testov´an´ı syst´emu . . . 48

4.5.1 Testovac´ı prostˇred´ı . . . 48

4.5.2 Ovˇeˇren´ı funkˇcnosti syst´emu . . . 49

5 Z´avˇer 51

Literatura 52

A Pˇriloˇzen´e DVD 54

Seznam obr´ azk˚ u

3.1 Sch´ema syst´emu . . . 25

4.1 Rozdˇelen´ı syst´emu na jednotliv´e projekty . . . 26

4.2 Handlery um´ıstˇen´e ve frontˇe frontendov´eho kan´alu . . . 29

4.3 Hierarchie rozhran´ı adapt´er˚u pro abstrakci RPC protokol˚u . . . 33

4.4 Struktura modelov´ych tˇr´ıd pro ukl´ad´an´ı konfiguraˇcn´ıch dat . . . 37

4.5 Struktura modelov´ych tˇr´ıd pro ukl´ad´an´ı statistick´ych ukazatel˚u . . . 38

4.6 Struktura modelov´ych tˇr´ıd pro ukl´ad´an´ı stavov´ych dat aplikace . . . . 38

Seznam zkratek

AJAX Asynchronous JavaScript and XML, metoda pro asynchronn´ı zpra- cov´an´ı dat na pozad´ı webov´e str´anky.

API Application Programming Interface, rozhran´ı pro programov´an´ı aplikac´ı.

BTC Zkratka pro elektronickou mˇenu Bitcoin.

CQL Cassandra Query Language, dotazovac´ı jazyk pouˇz´ıvan´y pro mani- pulaci s daty v datab´azi Cassandra.

DOM Document Object Model, objektov´y model dokumentu reprezen- tuj´ıc´ı HTML str´anku.

GH/s Giga hashes per second, poˇcet spoˇcten´ych hash˚u za vteˇrinu. Jed- notka kter´a se pouˇz´ıv´a pro vyj´adˇren´ı v´ykonu tˇeˇzebn´ıho stroje.

HTTP Hypertext Transfer Protocol, inernetov´y protokol pro pˇrenos hyper- textov´ych dokument˚u.

JSON JavaScript Object Notation, zp˚usob z´apisu dat.

JSON-RPC RPC protokol, kter´y pouˇz´ıv´a data zak´odovan´a do form´atu JSON.

JSX Zp˚usob z´apisu k´odu, kter´y umoˇzˇnuje v javascriptov´em k´odu pouˇz´ıvat HTML znaˇcky.

REST API Representational State Transfer, metoda pro pˇr´ıstup k dat˚um za po- moci HTTP vol´an´ı.

RPC Remote procedure call, vzd´alen´e vol´an´ı procedur.

TTL Time to live, doba omezuj´ıc´ı platnost z´aznamu v datab´azi Cassan- dra. Po jej´ı uplynut´ı je z´aznam automaticky smaz´an.

1 Uvod ´

V t´eto pr´aci ˇcten´aˇre nejdˇr´ıve seznamuji se z´akladn´ımi pojmy a teori´ı t´ykaj´ıc´ı se kryptomˇen. Kromˇe princip˚u fungov´an´ı kryptomˇen se zmiˇnuji i o RPC protokolech vyuˇz´ıvan´ych pˇri jejich tˇeˇzbˇe.

Ve tˇret´ı kapitole se vˇenuji teoretick´emu n´avrhu syst´emu. Po definici vˇsech poˇzadavk˚u postupnˇe ˇreˇs´ım n´avrh jednotliv´ych komponent, kter´e budou nezbytn´e k jeho realizaci. Na z´avˇer t´eto kapitoly stanovuji moˇznosti syst´emu, kter´e bude sv´ym uˇzivatel˚um nab´ızet.

V kapitole s ˇc´ıslem ˇctyˇri popisuji realizaci navrˇzen´eho syst´emu. Jako prvn´ı se vˇenuji knihovnˇe pro abstrakci RPC protokol˚u, kter´a tvoˇr´ı z´aklad cel´eho syst´emu.

Pot´e, co syst´em nauˇc´ım rozumˇet vˇsem RPC protokol˚um, ˇreˇs´ım ukl´ad´an´ı monitoro- van´ych statistick´ych ukazatel˚u do datab´aze. Kromˇe tˇechto ´udaj˚u je potˇreba perzis- tentnˇe ukl´adat i konfiguraˇcn´ı a stavov´a data. Po vytvoˇren´ı zm´ınˇen´ych ˇc´ast´ı m´am k dispozici jiˇz vˇse potˇrebn´e pro anal´yzu efektivity tˇeˇzby a pˇrepojov´an´ı klient˚u.

V r´amci proxy serveru implementuji logiku pro pˇrepojov´an´ı klient˚u pˇri v´ypadc´ıch spojen´ı. D´ale zde realizuji periodicky spouˇstˇen´y skript staraj´ıc´ı se o anal´yzu efek- tivity tˇeˇzby a procentu´aln´ı rozdˇelov´an´ı v´ykonu mezi r˚uzn´e mˇeny. Na z´akladˇe jeho v´ystupu pot´e doch´az´ı k vytv´aˇren´ı poˇzadavku pro pˇrepojen´ı klienta na jin´y pool server.

Aby byl syst´em uˇzivatelsky pˇr´ıvˇetiv´y a umoˇzˇnoval snadn´e nastaven´ı vˇsech para- metr˚u tˇeˇzby, vytvoˇril jsem webov´e rozhran´ı, kter´emu se vˇenuji v dalˇs´ı podkapitole.

Z´avˇerem popisuji testov´an´ı syst´emu v pr˚ubˇehu v´yvoje a ovˇeˇren´ı jeho funkˇcnosti po dokonˇcen´ı realizace.

2 Kryptomˇ eny

Bitcoin a kryptomˇeny obecnˇe se za posledn´ıch nˇekolik let doˇckaly obrovsk´e popu- larity. Kromˇe r˚ustu uˇzivatelsk´e z´akladny a m´ıst, kde lze pomoc´ı kryptomˇen platit, roste tak´e v´ypoˇcetn´ı v´ykon s´ıtˇe. Tˇeˇzaˇri investuj´ı nemal´e pen´ıze do sv´eho tˇeˇzebn´ıho vybaven´ı. Pryˇc jsou doby, kdy se tˇeˇzilo pomoc´ı procesor˚u. Ani v´ypoˇcty pomoc´ı grafick´ych karet jiˇz nebyly dostaˇcuj´ıc´ı, a tak se zaˇcali pouˇz´ıvat programovateln´a hradlov´a pole – FPGA. Nejvˇetˇs´ıho v´ykonu spolu s nejpˇr´ıznivˇejˇs´ı spotˇrebou energie se dnes dosahuje pomoc´ı ASIC integrovan´ych obvod˚u. Jedn´a se o obvod, kter´y je navrˇzen pro v´ypoˇcet jednoho konkr´etn´ıho algoritmu. Jeho poˇrizovac´ı cena je vˇsak hodnˇe vysok´a.

Jak postupnˇe rostl v´ykon s´ıtˇe, mˇenily se i n´aroky na pouˇz´ıvan´e RPC protokoly.

P˚uvodnˇe navrˇzen´y Getwork byl ˇcasem nahrazen Getblocktemplate, u kter´eho nebylo nutn´e zas´ılat tolik poˇzadavk˚u v pr˚ubˇehu v´ypoˇctu. Stroj tak nebyl omezen kapacitou s´ıtˇe. Dnes nejpouˇz´ıvanˇejˇs´ı protokol Stratum vytvoˇril ˇcesk´y program´ator Marek Pa- latinus (vystupuj´ıc´ı pod pˇrezd´ıvkou Slush). Protokol je zaloˇzen na myˇslence, ˇze cel´y proces tˇeˇzby ˇr´ıd´ı pool server, kter´y m´a nejlepˇs´ı pˇrehled o tom, co je potˇreba poˇc´ıtat.

2.1 Co je to kryptomˇ ena

Kryptomˇeny jsou digit´aln´ı mˇeny, kter´e nemaj´ı ˇz´adnou fyzickou podobu (bankovky, mince). Jsou generov´any pomoc´ı poˇc´ıtaˇcov´e s´ıtˇe o velik´em v´ypoˇcetn´ım v´ykonu.

Hlavn´ımi vlastnostmi elektronick´ych mˇen je pln´a decentralizace. Mˇena tedy nen´ı z´avisl´a na vlivu st´atu, autora, nebo skupiny lid´ı. U tˇechto mˇen nehroz´ı inflace, padˇel´an´ı a zabavov´an´ı ´uˇct˚u. Na rozd´ıl od ostatn´ıch mˇen, nejsou kryptomˇeny zaloˇzeny na d˚uvˇeˇre jej´ımu vydavateli (bance, st´atu). Veˇsker´e finanˇcn´ı toky jsou sd´ılen´e pomoc´ı veˇrejn´e peer to peer s´ıtˇe. Neexistuje ˇz´adn´e centr´aln´ı m´ısto, kde by byly transakce uloˇzeny.

2.2 Uˇ zivatel´ e kryptomˇ en

Kaˇzd´y koncov´y uˇzivatel vlastn´ı jednu, nebo v´ıce penˇeˇzenek. Kaˇzd´e penˇeˇzence n´aleˇz´ı veˇrejn´y a priv´atn´ı kl´ıˇc. Uˇzivatel se k s´ıti pˇripoj´ı pomoc´ı programu, kter´y si udrˇzuje distribuovanou datab´azi se vˇsemi transakcemi v s´ıti (tzv. blockchain). Z toho lze zjistit, kter´e penˇeˇzence n´aleˇz´ı jak´e mince (nebo jejich ˇc´asti). Pokud chce uˇzivatel poslat pen´ıze nˇekomu jin´emu, vezme patˇriˇcn´y obnos penˇez a vytvoˇr´ı z nich transakci.

Transakce [1] m˚uˇze, ale nemus´ı obsahovat poplatek za proveden´ı. Transakci klient n´aslednˇe podep´ıˇse sv´ym soukrom´ym kl´ıˇcem. Takto vytvoˇrenou transakci odeˇsle do s´ıtˇe a transakce ˇcek´a na potvrzen´ı.

2.3 Tˇ eˇ zaˇ ri kryptomˇ en

Ukolem tˇ´ eˇzaˇr˚u je potvrzov´an´ı transakc´ı. Sb´ıraj´ı vˇsechny aktu´alnˇe nepotvrzen´e trans- akce a skl´adaj´ı je do blok˚u. K takto sestaven´emu bloku hledaj´ı kryptografickou nonci [2] (anglicky cryptographic nonce). Mus´ı naj´ıt takovou nonci, aby se hash v´ysledn´eho bloku veˇsel pod stanoven´y limit. Obt´ıˇznost se stanovuje dynamicky tak, aby se blok v s´ıti potvrdil pr˚umˇernˇe jednou za 10 minut. Obt´ıˇznost tedy roste spolu s v´ypoˇcetn´ım v´ykonem cel´e s´ıtˇe.

Motivac´ı tˇeˇzaˇr˚u je odmˇena za potvrzen´y blok. Ta je aktu´alnˇe stanovena na 25 BTC [3] a kaˇzd´e ˇctyˇri roky (kaˇzd´ych 210 000 blok˚u) se sniˇzuje na polovinu.

Tˇeˇzaˇri tak´e n´aleˇz´ı vˇsechny poplatky ze zahrnut´ych transakc´ı. Z tohoto principu vypl´yv´a, ˇze v souˇcasn´e dobˇe je vˇetˇsina transakc´ı bez poplatku. Jak se postupem ˇcasu bude sniˇzovat odmˇena za vytˇeˇzen´y blok, bude tak´e r˚ust cena za transakci.

Vzhledem k tomu, ˇze si tˇeˇzaˇr m˚uˇze vybrat, kter´e transakce do bloku zahrne, jsou obvykle transakce s poplatkem potvrzeny dˇr´ıve neˇz ty bez poplatku.

2.4 Tˇ eˇ zaˇ rsk´ a seskupen´ı

Pokud je tˇeˇzaˇr pˇripojen pˇr´ımo k distribuovan´e s´ıti (tzv. solo mining), je jeho pravdˇepodobnost na vytˇeˇzen´ı bloku velmi mal´a. Z tohoto d˚uvodu se tˇeˇzaˇri sdruˇzuj´ı do uskupen´ı (tzv. pooled mining [4]). Tˇeˇzaˇri se pˇripojuj´ı k pool serveru, kter´y je pˇripojen na Bitcoin s´ıt’. Pool server sestavuje transakce do blok˚u, kter´e n´aslednˇe pomoc´ı RPC protokol˚u zas´ıl´a tˇeˇzaˇr˚um k nalezen´ı nonce. Kaˇzd´y tˇeˇzaˇr m´a pˇridˇelen´y

rozsah, ve kter´em m´a nonci hledat. Tˇeˇzaˇr postupnˇe odes´ıl´a d´ılˇc´ı v´ysledky, kter´e maj´ı niˇzˇs´ı sloˇzitost, neˇz m´a aktu´aln´ı blok. Pot´e, co pool server od nˇekter´eho z tˇeˇzaˇr˚u obdrˇz´ı v´ysledek odpov´ıdaj´ıc´ı sloˇzitosti bloku, odeˇsle informaci do s´ıtˇe a z´ısk´a odmˇenu za vytˇeˇzen´y blok. Tato odmˇena je pot´e rozdˇelena mezi tˇeˇzaˇre podle toho, kolik zaslali meziv´ysledk˚u.

2.5 Tˇ eˇ zebn´ı stroje

Uˇzivatel, kter´y si zˇr´ıd´ı ´uˇcet na pool serveru, si definuje tˇeˇzebn´ı stroje (tzv. workery).

Jedn´a se o jednotliv´e tˇeˇzebn´ı stroje, kter´ymi se bude k poolu pˇripojovat.

2.6 Blockchain

Blockchain obsahuje kompletn´ı historii vˇsech transakc´ı v s´ıti [5], kter´a zaˇc´ın´a takzvan´ym genesis blokem [6]. Kaˇzd´y blok obsahuje kromˇe transakc´ı tak´e hash pˇredchoz´ıho bloku. Je tedy garantov´ano, ˇze jsou bloky ˇrazeny chronologicky za se- bou. Tento princip zabraˇnuje dvoj´ımu utr´acen´ı mˇeny (double-spending [7]). Pokud by byl nˇekter´y z blok˚u zmˇenˇen, musela by se pˇrepoˇc´ıtat jeho nonce a t´ım p´adem by se zmˇenil i jeho hash. Pot´e by se musely pˇregenerovat vˇsechny n´asleduj´ıc´ı bloky.

Pokud je tedy blok um´ıstˇen v blockchain dostateˇcnˇe hluboko (zhruba 6 potvrzen´ı), je tento proces z v´ykonnostn´ıho hlediska nemoˇzn´y.

2.7 Bitcoin

Bitcoin je prvn´ı a z´aroveˇn nejzn´amˇejˇs´ı, nejsilnˇejˇs´ı a nejpouˇz´ıvanˇejˇs´ı kryptomˇenou.

S´ıt’ vytvoˇril v roce 2009 ˇclovˇek pod pseudonymem Satoshi Nakamoto [8]. Hlavn´ı jednotkou mˇeny je Bitcoin, kter´y se znaˇc´ı zkratkou BTC. Nejmenˇs´ı pˇr´ıpustnou hod- notou mˇeny je tzv. satoshi, kter´y je definov´an jako 0.000 000 01 BTC. Poˇcet bitcoin˚u je pˇredem stanoven na 21 milion˚u BTC [9]. Tohoto ˇc´ısla by se podle pˇredpoklad˚u mˇelo dos´ahnout v roce 2140.

2.8 Alternativn´ı kryptomˇ eny

Na z´akladˇe ´uspˇechu Bitcoinu vznikly postupem ˇcasu i dalˇs´ı mˇeny, kter´e jsou zaloˇzeny na stejn´ych principech. Tomu nahr´av´a i to, ˇze vˇsechny zdrojov´e k´ody bitcoinu jsou volnˇe k dispozici. V podstatˇe kaˇzd´y si tak m˚uˇze vytvoˇrit vlastn´ı elektronickou mˇenu.

Alternativn´ı mˇeny se od sebe liˇs´ı obt´ıˇznost´ı, algoritmem pro tˇeˇzbu, celkov´ym poˇctem jednotek, kter´e lze vytˇeˇzit a dalˇs´ımi parametry. Patrnˇe nejv´yznamnˇejˇs´ı alternativn´ı kryptomˇenou je Litecoin.

2.9 RPC protokoly

Aby mohl pool server pˇridˇelovat pr´aci sv´ym uˇzivatel˚um (tˇeˇzaˇr˚um), mus´ı b´yt schopn´y s nimi komunikovat. Tato komunikace prob´ıh´a pomoc´ı RPC protokol˚u (remote pro- cedure call, vzd´alen´e vol´an´ı procedur). Pool server takto informuje uˇzivatele, kteˇr´ı zah´aj´ı v´ypoˇcet a n´aslednˇe poˇslou zpˇet vypoˇc´ıtan´y v´ysledek. Postupem ˇcasu vznikly celkem tˇri protokoly, kter´e se u kryptomˇen pouˇz´ıvaj´ı.

2.9.1 Getwork

Jedn´a se o historicky nejstarˇs´ı pouˇz´ıvan´y protokol [10]. Pˇrenos prob´ıh´a pomoc´ı HTTP komunikace. Protokol vyuˇz´ıv´a JSON-RPC specifikaci – veˇsker´a data se tedy pˇren´aˇsej´ı ve form´atu JSON.

Pot´e, co se tˇeˇzebn´ı klient pˇripoj´ı k pool serveru, zaˇsle ˇz´adost o pˇridˇelen´ı pr´ace.

Od serveru n´aslednˇe obdrˇz´ı odpovˇed’, kter´a obsahuje sestaven´y blok a obt´ıˇznost.

Kdyˇz klient nalezne poˇzadovanou nonci, odeˇsle pomoc´ı dalˇs´ı zpr´avy v´ysledek serveru.

Server mu odpov´ı, jestli tento v´ysledek pˇrij´ım´a (accepted), nebo nepˇrij´ım´a (rejected).

Pˇr´ıˇcinou odm´ıtnut´eho v´ysledku m˚uˇze b´yt napˇr´ıklad to, ˇze tento blok jiˇz vyˇreˇsil jin´y stroj (tzv. stale share).

Aby se pˇredch´azelo zbyteˇcnˇe velk´emu poˇctu odm´ıtnut´ych v´ysledk˚u, zavedla se moˇznost longpoll. Pot´e, co klient obdrˇz´ı prvn´ı zpr´avu se zadanou prac´ı, vytvoˇr´ı dalˇs´ı ˇz´adost na server (longpoll request). U tohoto spojen´ı nastav´ı klient velmi dlouhou dobu, po kterou bude ˇcekat na odpovˇed’. Ve chv´ıli, kdy pool server obdrˇz´ı od jin´eho stroje validn´ı v´ysledek, zaˇsle na vˇsechny otevˇren´e longpoll spojen´ı zpr´avu, kter´a obsahuje novou pr´aci. Po obdrˇzen´ı klient pˇreruˇs´ı aktu´aln´ı v´ypoˇcet a zaˇcne poˇc´ıtat

nov´y blok. Klient si tak´e otevˇre nov´e longpoll spojen´ı.

Hlavn´ı nev´yhodou tohoto protokolu je nutnost zas´ılat novou ˇz´adost pro kaˇzdou d´ılˇc´ı pr´aci. Tento fakt omezuje maxim´aln´ı v´ykon tˇeˇzebn´ıho stroje zhruba na 4 GH/s.

2.9.2 Getblocktemplate

Motivac´ı pro vznik tohoto protokolu [11] byla kromˇe v´ykonnostn´ıho hlediska tak´e moˇznost decentralizace. U Getwork protokolu ˇr´ıd´ı sestavov´an´ı transakc´ı do blok˚u pool server a tˇeˇzebn´ı stroj nem´a moˇznost to ovlivnit. Protokol je navrˇzen tak, aby bylo snadn´e jej do budoucna rozˇsiˇrovat. Veˇsker´a rozˇs´ıˇren´ı jsou zdokumentov´ana po- moc´ı BIP dokument˚u (Bitcoin Improvement Proposal) [12].

Protokol je stejnˇe jako Getwork, zaloˇzen na HTTP komunikaci a JSON-RPC specifikaci. Po pˇripojen´ı poˇsle klient ˇz´adost o ˇsablonu (template). Odpovˇed’ od pool serveru obsahuje obt´ıˇznost, hash pˇredchoz´ıho bloku, aktu´aln´ı nepotvrzen´e trans- akce a dalˇs´ı informace nutn´e ke sloˇzen´ı bloku. Klient tedy m˚uˇze prov´adˇet mnohem v´ıce v´ypoˇct˚u bez toho, aby si musel serveru ˇr´ıkat o dalˇs´ı pr´aci. Spoˇc´ıtan´e v´ysledky pr˚ubˇeˇznˇe pos´ıl´a serveru. Protokol takt´eˇz obsahuje moˇznost longpoll.

2.9.3 Stratum

Protokol Stratum je nejnovˇejˇs´ı a v souˇcasnosti tak´e nejpouˇz´ıvanˇejˇs´ı protokol [13].

U pˇredchoz´ıho protokolu veˇskerou komunikaci ˇr´ıd´ı tˇeˇzebn´ı klient. Nejlepˇs´ı pˇrehled o tom jak´a pr´ace je jiˇz hotov´a a co je aktu´alnˇe potˇreba poˇc´ıtat m´a vˇsak pool ser- ver. Klient otevˇre TCP soket, po kter´em komunikuje s pool serverem. Tento soket z˚ust´av´a otevˇren po celou dobu tˇeˇzby. Pool server tak m˚uˇze klientovi kdykoliv po- slat zpr´avu. Protokol je naz´yv´an line based. Jednotliv´e zpr´avy se od sebe totiˇz oddˇeluj´ı znakem konce ˇr´adky (\n). Protokol vyuˇz´ıv´a JSON-RPC 2.0 specifikace.

Pomoc´ı tohoto protokolu lze pˇres jedno TCP spojen´ı pˇripojit stroj o v´ykonnosti aˇz 18 EHash/s (Exa-hashes/s).

3 N´ avrh proxy serveru pro optimalizaci tˇ eˇ zby

3.1 Motivace

Pokud se ˇclovˇek rozhodne zab´yvat se tˇeˇzbou kryptomˇen, mus´ı si opatˇrit v´ypoˇcetn´ı stroje s patˇriˇcn´ym v´ykonem. To je spojeno s n´aklady na provoz, kter´e nejsou mal´e.

Odmˇenou za vynaloˇzen´e ´usil´ı by mˇela b´yt provize za ovˇeˇren´e bloky. V pr˚ubˇehu tˇeˇzby se ale m˚uˇze objevit nˇekolik jev˚u, kter´e maj´ı negativn´ıch dopad na v´yslednou efek- tivitu tˇeˇzby. Mohou to b´yt napˇr´ıklad v´ypadky internetov´eho spojen´ı mezi tˇeˇzebn´ım strojem a c´ılov´ym pool serverem. Vzhledem k velk´e konkurenci pˇri tˇeˇzbˇe kryptomˇen b´yvaj´ı tak´e pomˇernˇe ˇcast´e ´utoky na pool servery, kter´e maj´ı za c´ıl vyˇradit je z pro- vozu. V takov´em pˇr´ıpadˇe nen´ı pool server schopn´y s tˇeˇzebn´ım klientem komunikovat a ten t´ım p´adem nem´a co poˇc´ıtat. M˚uˇze se tak´e st´at, ˇze se tˇeˇzebn´ı klient snaˇz´ı tˇeˇzit mˇenu, kter´a m´a na nˇej pˇr´ıliˇs vysokou obt´ıˇznost. V takov´em pˇr´ıpadˇe nikdy nedos´ahne poˇzadovan´e odmˇeny za ovˇeˇren´y blok.

Na z´akladˇe tˇechto poznatk˚u vznikl n´apad na vytvoˇren´ı syst´emu, kter´y by se tyto negativn´ı jevy snaˇzil co nejv´ıce eliminovat. Klient by se nepˇripojoval k c´ılov´emu pool serveru pˇr´ımo, ale pomoc´ı meziˇcl´anku ve formˇe proxy serveru. Proxy server by pot´e na z´akladˇe uˇzivatelsk´e konfigurace a aktu´aln´ı situace zvolil c´ılov´y pool server.

Veˇskerou komunikaci mezi tˇeˇzebn´ım klientem a c´ılov´ym pool serverem by monitoro- val a ˇreˇsil vˇsechny v´yˇse popsan´e situace. Kromˇe toho by uˇzivateli umoˇznil definovat v´ıce mˇen, kter´e chce tˇeˇzit. Uˇzivatel by pot´e mˇel moˇznost v´ykon tˇeˇzebn´ıho stroje procentu´alnˇe rozdˇelovat mezi jednotliv´e mˇeny.

3.2 Struktura syst´ emu

Z´akladem pro cel´y syst´em bude abstrakce RPC protokol˚u (viz kapitola 2.9), po- moc´ı kter´ych komunikuje tˇeˇzebn´ı klient s pool serverem. Bude potˇreba rozliˇsovat jednotliv´e akce, kter´e jsou specifick´e pro konkr´etn´ı protokoly. Jednotliv´e ud´alosti bude potˇreba ukl´adat do perzistentn´ıho ´uloˇziˇstˇe a v periodick´ych intervalech je vyhodnocovat. Na z´akladˇe anal´yzy nasb´ıran´ych ukazatel˚u se vyhodnot´ı efektivita aktu´aln´ıho spojen´ı. V pˇr´ıpadˇe zjiˇstˇen´ı neefektivn´ıho spojen´ı syst´em pˇrepoj´ı klienta na jin´y pool server. Z tohoto d˚uvodu mus´ı syst´em evidovat vˇsechny aktivn´ı spo- jen´ı. Syst´em tak´e mus´ı hl´ıdat v´ypadky spojen´ı a okamˇzitˇe na nˇe reagovat. Kromˇe ukl´ad´an´ı statistick´ych ukazatel˚u tˇeˇzby je nutn´e ukl´adat tak´e konfiguraˇcn´ı ´udaje, na z´akladˇe kter´ych se zvol´ı c´ılov´y pool server.

3.2.1 Abstrakce RPC protokol˚ u

Z´akladn´ım pˇredpokladem pro realizaci syst´emu na optimalizaci tˇeˇzby kryptomˇen je porozumˇen´ı protokol˚um, pomoc´ı kter´ych tˇeˇzebn´ı klient komunikuje s pool serverem.

Tato komunikace se bude muset po celou dobu tˇeˇzby monitorovat. Z pˇren´aˇsen´ych zpr´av se budou urˇcovat jednotliv´e ud´alosti protokol˚u a ty se budou ukl´adat do datab´aze.

Aby byl cel´y syst´em pˇrehlednˇejˇs´ı a l´epe testovateln´y, bude tato ˇc´ast navrˇzena jako knihovna. Ta se bude starat pouze o abstrakci RPC protokol˚u a nebude tedy ob- sahovat ˇz´adnou aplikaˇcn´ı logiku. Pˇr´ınosem tohoto ˇreˇsen´ı bude to, ˇze knihovna bude snadno pouˇziteln´a i pro ´uˇcely jin´ych projekt˚u pracuj´ıc´ıch s tˇemito RPC protokoly.

Knihovna bude muset umˇet analyzovat pˇr´ıchoz´ı zpr´avu od klienta a urˇcit u n´ı jeden ze tˇr´ı pouˇz´ıvan´ych RPC protokol˚u (Getwork, Getblocktemplate, Stratum).

Z pˇrijat´e zpr´avy mus´ı pˇreˇc´ıst jm´eno a heslo klienta. Na z´akladˇe tˇechto informac´ı provede jeho autentizaci. Podle obsahu zpr´avy urˇc´ı ud´alost protokolu a zpr´avu d´ale pˇred´a na pool server. Podobn´ym zp˚usobem bude zpracov´avat i odpovˇedi pˇrij´ıman´e od pool serveru.

Z definovan´ych poˇzadavk˚u je patrn´e, ˇze veˇsker´a logika t´ykaj´ıc´ı se s´ıt’ov´eho pro- vozu bude zapouzdˇrena pˇr´ımo v knihovnˇe. Naopak aplikaˇcn´ı logika t´ykaj´ıc´ı se au- tentizace klient˚u a zpracov´an´ı ud´alost´ı protokol˚u bude implementov´ana mimo tuto knihovnu. Pro tyto ´uˇcely bude knihovna definovat nˇekolik rozhran´ı. Konkr´etn´ı im-

Knihovna se bude starat o navazov´an´ı spojen´ı mezi klientem a pool serverem.

Vˇsechna takto vznikl´a spojen´ı bude d´ale spravovat. Pomoc´ı rozhran´ı bude informo- vat o ud´alostech RPC protokol˚u i o v´ypadc´ıch spojen´ı. D´ale bude umˇet pˇripojen´eho klienta pˇrepojit na jin´y pool server. Poˇzadavky na pˇrepojen´ı klienta budou opˇet vznikat externˇe, knihovna je bude pouze zpracov´avat. Definov´ano bude tak´e roz- hran´ı pro ´uloˇziˇstˇe konfiguraˇcn´ıch dat. Na jeho z´akladˇe bude knihovna schopna urˇcit c´ılov´y server pro klienta.

Aby bylo moˇzn´e knihovnu samostatnˇe testovat, bude v n´ı pro kaˇzd´e z defino- van´ych rozhran´ıch existovat jedna v´ychoz´ı implementace.

3.2.2 Uloˇ ´ ziˇ stˇ e dat

Abych mohl vyhodnocovat efektivitu tˇeˇzby, mus´ım v jej´ım pr˚ubˇehu ukl´adat pomˇernˇe velk´e mnoˇzstv´ı statistick´ych ukazatel˚u pro kaˇzd´e spojen´ı. Kromˇe nasb´ıran´ych ukaza- tel˚u bude nutn´e ukl´adat tak´e stavov´a data aplikace. Ukl´ad´an´ı i pˇr´ıstup k dat˚um mus´ı b´yt rychl´y. Aby byl syst´em do budoucna snadno ˇsk´alovateln´y, mus´ım od zaˇc´atku poˇc´ıtat s moˇznost´ı distribuce syst´emu na v´ıce server˚u.

Na z´akladˇe tˇechto poˇzadavk˚u jsem se rozhodl pro pouˇzit´ı NoSQL datab´aze, konkr´etnˇe datab´aze Cassandra. Jej´ımi pˇrednostmi jsou hlavnˇe vysok´a rychlost [14]

a snadn´a ˇsk´alovatelnost. K manipulaci s daty je moˇzn´e pouˇz´ıvat dotazovac´ı jazyk CQL. Cassandra tak´e umoˇzˇnuje asynchronn´ı z´apis dat a jednotliv´ym z´aznam˚um je moˇzn´e nastavovat hodnotu TTL. Po jej´ım uplynut´ı dojde k automatick´emu od- stranˇen´ı takto oznaˇcen´ych z´aznam˚u.

Jako ´uloˇziˇstˇe pro konfiguraˇcn´ı a autentizaˇcn´ı ´udaje se nab´ız´ı pouˇzit´ı klasick´e relaˇcn´ı datab´aze. Znamenalo by to ale, ˇze bych v projektu musel pouˇz´ıvat dvˇe r˚uzn´e datab´aze. T´ım by se zkomplikovalo mapov´an´ı datab´azov´ych dat na model aplikace.

Oddˇelenˇe by se tak´e muselo ˇreˇsit verzov´an´ı datab´az´ı. V neposledn´ı ˇradˇe by tak´e vzrostla provozn´ı reˇzie a nutnost ˇreˇsit z´alohov´an´ı pro kaˇzdou z datab´az´ı oddˇelenˇe.

Relaˇcn´ı datab´aze nav´ıc nejde tak snadno ˇsk´alovat. D´ale bych se pot´ykal s probl´emy prov´az´an´ı z´aznam˚u mezi datab´azemi a konzistenc´ı dat.

Na z´akladˇe t´eto ´uvahy jsem se rozhodl pro pouˇzit´ı NoSQL datab´aze i pro ukl´ad´an´ı konfiguraˇcn´ıch dat. N´avrh datab´azov´e struktury bude oproti relaˇcn´ı da- tab´azi prob´ıhat odliˇsnˇe. V nˇekter´ych pˇr´ıpadech bude nutn´a denormalizace dat a s t´ım spojen´a duplicita z´aznam˚u. Benefitem tohoto ˇreˇsen´ı ale bude vyˇsˇs´ı rychlost, jed- noduˇsˇs´ı implementace a v´yborn´a ˇsk´alovatelnost.

Abych data logicky odliˇsil podle jejich charakteru, definuji tˇri datab´azov´e key- space. Keyspace pˇredstavuje v terminologii datab´aze Cassandra obdobu sch´ema v relaˇcn´ıch datab´az´ıch [15]. Konfiguraˇcn´ı a autentizaˇcn´ı ´udaje budou ukl´ad´any v key- space poolec_core, statistick´e ukazatele v poolec_real_time_statistics a sta- vov´a data v poolec_state_data.

3.2.3 Spr´ ava spojen´ı

D˚uleˇzitou funkcionalitou syst´emu je schopnost pˇrepojen´ı tˇeˇzebn´ıho klienta na jin´y pool server. Z toho d˚uvodu je nutn´e evidovat vˇsechna otevˇren´a spojen´ı. Syst´em bude definovat rozhran´ı pro vytv´aˇren´ı poˇzadavk˚u na pˇrepojen´ı klienta. Pokud vznikne takov´y poˇzadavek, dojde k uzavˇren´ı vˇsech spojen´ı dan´eho klienta. Pˇred odpojen´ım klienta se do ´uloˇziˇstˇe stavov´ych dat zaznamen´a adresa nov´eho pool serveru. Klient n´aslednˇe vytvoˇr´ı poˇzadavek na proxy server a ten ho pˇripoj´ı k nov´emu pool serveru.

U protokol˚u Getwork a Getblocktemplate m˚uˇze pˇri tomto procesu doj´ıt k jedn´e mezn´ı situaci, jej´ıˇz vznik je pops´an n´ıˇze.

• Klient je pˇripojen k pool serveru X.

• Vznikne poˇzadavek pro pˇrepojen´ı na pool server Y.

• Dojde ke zpracov´an´ı poˇzadavku na pˇrepojen´ı klienta. Spojen´ı mezi proxy ser- verem a klientem se uzavˇre a do stavov´ych dat se uloˇz´ı adresa pool serveru Y.

• Klient vˇsak st´ale poˇc´ıt´a blok ze serveru X. Po dokonˇcen´ı v´ypoˇctu poˇsle v´ysledek na server.

V tomto pˇr´ıpadˇe by doˇslo k tomu, ˇze by byl v´ysledek pro pool server X zasl´an na pool server Y. V´ysledek v´ypoˇctu by s nejvˇetˇs´ı pravdˇepodobnost´ı nebyl pool ser- verem Y akceptov´an a ˇcas na jeho v´ypoˇcet by byl k niˇcemu. Abych t´eto situaci mohl zabr´anit, bude nutn´e si do stavov´ych dat ukl´adat adresu pool serveru pro tˇeˇzen´e bloky. V´ysledek tak bude zasl´an na spr´avn´y server i po zpracov´an´ı poˇzadavku na pˇrepojen´ı. Naˇstˇest´ı nem˚uˇze doj´ıt k situaci, kdy by jeden klient tˇeˇzil v´ıce blok˚u souˇcasnˇe, takˇze bude staˇcit uchov´avat pro kaˇzd´eho klienta vˇzdy pouze posledn´ı blok.

Aby pˇrepojov´an´ı klient˚u prob´ıhalo efektivnˇe a ˇc´asteˇcnˇe se pˇredch´azelo v´yˇse po- pisovan´emu probl´emu, nedojde k ukonˇcen´ı spojen´ı ihned po vytvoˇren´ı poˇzadavku na

nˇekolika m´alo okamˇzik˚u poslal na pool server. Kdybych klienta odpojil okamˇzitˇe, byl by tento meziv´ysledek zahozen. Pˇrepojen´ı klienta tedy probˇehne pˇri splnˇen´ı prvn´ı z n´asleduj´ıc´ıch podm´ınek:

• Klient odeslal spoˇc´ıtan´y v´ysledek a pool server vr´atil odpovˇed’.

• Klient odeslal ˇz´adost o pˇridˇelen´ı nov´eho v´ypoˇctu (u protokol˚u Getwork a Get- blocktemplate).

• Server poslal informaci o nov´em v´ypoˇctu (odpovˇed’ na longpoll request, metody difficulty set a mining notify).

• Vyprˇsel ˇcasov´y limit ˇz´adosti o pˇrepojen´ı.

3.2.4 Anal´ yza nasb´ıran´ ych dat

Nasb´ıran´a data se budou v syst´emu periodicky vyhodnocovat. V definovan´em inter- valu se bude periodicky spouˇstˇet skript, kter´y si z datab´aze naˇcte vˇsechna data vznikl´a od jeho posledn´ıho spuˇstˇen´ı. Nad nimi se provede anal´yza a vyhodnot´ı se efektivita tˇeˇzby za tento ˇcasov´y ´usek. Efektivita se bude urˇcovat na z´akladˇe poˇc´ıtan´eho sk´ore. V´ypoˇcet sk´ore bude zaloˇzen na vybran´ych statistick´ych ukaza- tel´ıch tˇeˇzby. V syst´emu bude definov´ano mezn´ı sk´ore, po jehoˇz pˇrekroˇcen´ı bude tˇeˇzba povaˇzov´ana za neefektivn´ı.

Periodicky spouˇstˇen´y skript bude tak´e zajiˇst’ovat procentu´aln´ıho rozdˇelen´ı v´ykonu tˇeˇzebn´ıch stroj˚u mezi jednotliv´e mˇeny. Pro tuto potˇrebu budu muset ve stavov´ych datech aplikace evidovat ˇcas zaˇc´atku tˇeˇzby pro jednotliv´e klienty. Po- kud bude tˇeˇzba vyhodnocena jako efektivn´ı (nebude tedy vytvoˇren poˇzadavek na pˇrepojen´ı), dojde ke spoˇc´ıt´an´ı doby, po kterou klient z aktu´aln´ıho serveru tˇeˇz´ı.

Rozdˇelen´ı v´ykonu bude zaloˇzeno na definovan´em ˇcasov´em kvantu. Takto definovan´a ˇcasov´a jednotka bude povaˇzov´ana za 100% v´ykonu. Podle uˇzivatelsk´eho nastaven´ı se dopoˇcte pˇr´ısluˇsn´e ˇcasov´e kvantum, po jehoˇz dobu se m´a tˇeˇzit. Pˇrekroˇc´ı-li doba tˇeˇzby toto kvantum, dojde k pˇrepojen´ı klienta.

Pˇri zpracov´an´ı statistik potˇrebuji naˇc´ıst z´aznamy v ˇcasov´em rozsahu od jejich po- sledn´ıho zpracov´an´ı. U kaˇzd´eho z´aznamu bych si tedy mˇel ukl´adat ˇcas jeho poˇr´ızen´ı a zpracov´an´ı. Dotaz pro naˇcten´ı z´aznam˚u by pot´e obsahoval podm´ınku na ˇcasov´y rozsah. S t´ım by vˇsak byla spojen´a zbyteˇcn´a reˇzie. Vyuˇziji proto jedn´e z pˇrednost´ı datab´aze Cassandra a u statistick´ych dat budu nastavovat hodnotu TTL. Kaˇzd´y

statistick´y z´aznam bude m´ıt nastavenou ˇcasovou platnost, po jej´ımˇz uplynut´ı dojde k jeho automatick´emu smaz´an´ı. Doba TTL bude nastavena synchronnˇe s perio- dou spouˇstˇen´ı skriptu pro vyhodnocen´ı dat. Pˇri naˇc´ıt´an´ı z´aznam˚u tak budu v da- tab´azov´em dotazu kl´ast podm´ınku pouze na tˇeˇzebn´ıho klienta. Odpadne t´ım nut- nost ukl´adat si u z´aznam˚u ˇcasov´e ´udaje. Vzhledem k tomu, ˇze dotaz bude obsahovat pouze podm´ınku na ID klienta, bude jeho zpracov´an´ı mnohem rychlejˇs´ı.

Synchronizace automatick´eho maz´an´ı z´aznam˚u a spouˇstˇen´ı skriptu pro jejich vy- hodnocen´ı vˇsak nikdy nebude dokonal´a. M˚uˇze se tak st´at, ˇze se nˇekter´e z´aznamy zpracuj´ı dvakr´at, popˇr´ıpadˇe budou nˇekter´e pˇreskoˇceny. Vzhledem k vysok´emu poˇctu nasb´ıran´ych dat vˇsak m˚uˇzu tuto nedokonalost zanedbat. Kromˇe jednoznaˇcn´e v´ykonnostn´ı v´yhody se tak´e zabr´an´ı moˇzn´emu pˇrehlcen´ı datab´aze z´aznamy, kter´e budou v ˇcase pˇrib´yvat velmi rychle.

V dalˇs´ıch verz´ıch syst´emu bych chtˇel uˇzivateli nab´ıdnout historickou statistiku tˇeˇzby rozdˇelenou podle r˚uzn´ych ukazatel˚u. Uchov´av´an´ı vˇsech nasb´ıran´ych statis- tick´ych ukazatel˚u tˇeˇzby by ale bylo velmi n´aroˇcn´e na diskov´y prostor. Bude tedy nutn´e data vhodnˇe agregovat a ukl´adat je do zvl´aˇstn´ıho keyspace pro dlouhodob´e statistiky. Pro tuto potˇrebu vznikne dalˇs´ı periodicky spouˇstˇen´y skript. Pˇri jeho spuˇstˇen´ı probˇehne agregace dat nasb´ıran´ych od posledn´ıho bˇehu skriptu a jejich uloˇzen´ı do dlouhodob´ych statistik. Z tohoto datov´eho zdroje se statistiky budou vypisovat v uˇzivatelsk´em rozhran´ı.

3.2.5 Konfigurace syst´ emu

Jak jsem jiˇz zm´ınil v kapitole 3.2.2, budu v datab´azi ukl´adat i konfiguraˇcn´ı data.

Aby aplikace byla jednoduˇse nastaviteln´a, vytvoˇr´ım uˇzivatelsk´e rozhran´ı ve formˇe responzivn´ı webov´e aplikace. Abych mohl v budoucnu jednoduˇse vytvoˇrit mobiln´ı aplikaci nebo poskytovat data aplikac´ım tˇret´ıch stran, rozhodl jsem se pro vytvoˇren´ı REST API rozhran´ı. Webov´a aplikace bude ve formˇe javascriptov´eho klienta, kter´y bude se serverem komunikovat pomoc´ı AJAXov´ych poˇzadavk˚u.

3.3 Moˇ znosti syst´ emu

Pomoc´ı webov´eho rozhran´ı si uˇzivatel zaloˇz´ı ´uˇcet, pod kter´ym bude spravovat vˇsechny sv´e tˇeˇzebn´ı klienty a jejich konfiguraci. V budoucnu zde tak´e nalezne sta-

vygenerov´an unik´atn´ı k´od, pomoc´ı kter´eho bude schopn´y autentizovat sv´e tˇeˇzebn´ı klienty.

3.3.1 Algoritmy a mˇ eny

V aplikaci si uˇzivatel nastav´ı, jak´e mˇeny bude cht´ıt tˇeˇzit. Kaˇzd´a mˇena je zaloˇzena na konkr´etn´ım algoritmu. Jeden tˇeˇzebn´ı klient m˚uˇze tˇeˇzit pouze mˇeny, kter´e maj´ı spoleˇcn´y algoritmus. V datab´azi budou pˇreddefinov´any nejpouˇz´ıvanˇejˇs´ı algoritmy a mˇeny. Pokud bude uˇzivatel cht´ıt tˇeˇzit jinou mˇenu, m˚uˇze si ji v syst´emu vytvoˇrit s´am.

3.3.2 Pool servery

N´aslednˇe si uˇzivatel definuje vˇsechny pool servery, ze kter´ych chce tˇeˇzit. U kaˇzd´eho nastav´ı mˇenu a autentizaˇcn´ı ´udaje. Pro jednu mˇenu si uˇzivatel m˚uˇze nadefinovat v´ıce server˚u. V pˇr´ıpadˇe v´ypadku spojen´ı se pouˇzije z´aloˇzn´ı server.

3.3.3 Tˇ eˇ zebn´ı skupiny

Uˇ´celem tˇeˇzebn´ıch skupin je vytvoˇrit seznam mˇen, kter´e budou klienti vyuˇz´ıvaj´ıc´ı ta- kovou skupinu tˇeˇzit. Kaˇzd´a skupina m´a definovan´y algoritmus a libovoln´y poˇcet mˇen.

Uˇzivatel si pro kaˇzdou mˇenu zvol´ı, jak´y procentu´aln´ı pod´ıl tˇeˇzby j´ı bude vˇenov´an.

Kaˇzd´a mˇena m´a v r´amci skupiny pˇriˇrazenou prioritu. K mˇenˇe je moˇzn´e pˇriˇradit v´ıce pool server˚u. Do takto vytvoˇren´e tˇeˇzebn´ı skupiny je moˇzn´e zaˇradit i v´ıce tˇeˇzebn´ıch klient˚u. Po pˇripojen´ı klienta dojde k nalezen´ı tˇeˇzebn´ı skupiny, do kter´e je zaˇrazen.

Klient bude pˇripojen na prvn´ı definovan´y pool server mˇeny s nejvyˇsˇs´ı prioritou.

Pokud by doˇslo k v´ypadku spojen´ı u aktu´aln´ıho pool serveru, bude klient pˇrepojen na definovan´y alternativn´ı pool server. V z´avislosti na nastaven´em rozdˇelen´ı v´ykonu bude klient periodicky mˇenit tˇeˇzenou mˇenu. Pˇrep´ın´an´ı mezi mˇenami bude prob´ıhat v z´avislosti na nastaven´ych priorit´ach. Pokud se pˇri periodick´em vyhodnocov´an´ı statistick´ych ukazatel˚u shled´a tˇeˇzba aktu´aln´ı mˇeny jako neefektivn´ı, dojde k pˇrepnut´ı na dalˇs´ı mˇenu definovanou ve skupinˇe.

Obr´azek 3.1: Sch´ema syst´emu

4 Realizace syst´ emu pro optimalizaci tˇ eˇ zby

Syst´em jsem realizoval v jazyce Java verze 8. V s´ıt’ov´e ˇc´asti aplikace vyuˇz´ıv´am fra- meworku Netty. Na spr´avu z´avislost´ı jednotliv´ych modul˚u syst´emu pouˇz´ıv´am Ma- ven. Pro dependency injection, REST API a periodick´e spouˇstˇen´ı skript˚u vyuˇz´ıv´am frameworku Spring.

Abych logicky oddˇelil jednotliv´e ˇc´asti aplikace, je projekt rozdˇelen na nˇekolik mo- dul˚u. Jejich vz´ajemn´e propojen´ı je zn´azornˇen´e na obr´azku 4.1. Z´aklad tvoˇr´ı modul core, kde je implementov´an model aplikace a servisn´ı tˇr´ıdy pro mapov´an´ı na da- tab´azov´a data. Knihovna pro pr´aci s RPC protokoly je implementovan´a v modulu rpclib. Dalˇs´ı ˇc´ast´ı je modul proxy, kter´y vyuˇz´ıv´a oba pˇredchoz´ı moduly syst´emu a je zde implementov´ana veˇsker´a logika proxy serveru. Kromˇe tˇechto modul˚u existuje v syst´emu jeˇstˇe rest modul staraj´ıc´ı se o REST API a web modul s javascriptovou klientskou aplikac´ı.

Obr´azek 4.1: Rozdˇelen´ı syst´emu na jednotliv´e projekty

4.1 Knihovna pro pr´ aci s RPC protokoly

Jak jsem stanovil v kapitole3.2.1, bude tato ˇc´ast syst´emu realizovan´a jako knihovna.

Knihovna bude obsahovat rozhran´ı definuj´ıc´ı jednotliv´e akce RPC protokol˚u.

Konkr´etn´ı implementace tˇechto rozhran´ı budou knihovnˇe pˇred´any externˇe. Aby se knihovna dala samostatnˇe testovat, bude obsahovat v´ychoz´ı implementace tˇechto rozhran´ı.

4.1.1 Princip ˇ cinnosti knihovny

Knihovna funguje na principu proxy serveru. Pomoc´ı proxy modulu se k n´ı pˇripoj´ı tˇeˇzebn´ı klient. Knihovna pˇr´ıchoz´ı zpr´avu analyzuje a pˇrepoˇsle ji na pool server.

V knihovnˇe se pracuje se dvˇema kan´aly. Kan´al mezi tˇeˇzebn´ım klientem a proxy serverem naz´yv´am frontendov´ym kan´alem a kan´al mezi proxy serverem a pool serverem backendov´ym kan´alem. Zpracov´an´ı zpr´avy prob´ıh´a pomoc´ı takzvan´ych handler˚u. Kaˇzd´y z kan´al˚u definuje svoj´ı sadu handler˚u, kter´ymi zpr´ava postupnˇe proch´az´ı [16]. Podle typu zpr´avy, kterou m´a handler zpracov´avat, m˚uˇze b´yt defi- nov´an jako pˇr´ıchoz´ı nebo jako odchoz´ı. ˇZivotn´ı cyklus zpr´avy pˇrich´azej´ıc´ı od klienta je n´asleduj´ıc´ı:

• Zpr´ava postupnˇe projde vˇsemi pˇr´ıchoz´ımi handlery um´ıstˇen´ymi ve fronten- dov´em kan´alu.

• N´aslednˇe je pˇred´ana na backendov´y kan´al, kde projde handlery urˇcen´ymi pro zpracov´an´ı odchoz´ı zpr´avy.

• Po pr˚uchodu posledn´ım handlerem je posl´ana na proxy server.

• Odpovˇed’ n´aslednˇe projde vˇsemi pˇr´ıchoz´ımi handlery zaˇrazen´ymi v backen- dov´em kan´alu.

• Pot´e je pˇred´ana na frontendov´y kan´al a projde vˇsemi jeho odchoz´ımi handlery.

• Posledn´ı odchoz´ı handler frontendov´eho kan´alu se postar´a o posl´an´ı zpr´avy klientovi.

Vˇsechny zpr´avy pˇrijdou jako objekt datov´eho typu ByteBuf. Ve frontˇe

z/do poˇzadovan´eho form´atu (v z´avislosti na smˇeru zpr´avy). Nˇekter´e zpr´avy nav´ıc mohou b´yt fragmentovan´e na nˇekolik ˇc´ast´ı. Pot´e je nutn´e pouˇz´ıt agregaˇcn´ı handler, kter´y zachycuje jednotliv´e fragmenty zpr´avy a teprve kdyˇz je zpr´ava kompletn´ı, pˇred´a ji dalˇs´ımu handleru.

Kaˇzd´y z handler˚u m˚uˇze zpr´avu modifikovat a na z´akladˇe sv´e logiky rozhodnout, jestli zpr´avu pˇred´a ke zpracov´an´ı dalˇs´ımu handleru, zahod´ı ji, nebo ji rovnou zaˇsle zpˇet klientovi. Zaˇrazen´ı konkr´etn´ıch handler˚u je zn´azornˇeno na obr´azku 4.2.

Jako prvn´ı je ve frontˇe zaˇrazen handler staraj´ıc´ı se o rozpozn´an´ı typu RPC pro- tokolu. Na z´akladˇe jeho v´ystupu dojde k zaˇrazen´ı dalˇs´ıch handler˚u pro konkr´etn´ı typ protokolu. Ty se nejdˇr´ıve postaraj´ı o pˇreveden´ı zpr´avy z typu ByteBuf na ˇciteln´y form´at. D´ale pˇrijde na ˇradu handler pro autentizaci tˇeˇzebn´ıho klienta. Pokud tento proces probˇehne ´uspˇeˇsnˇe, je zpr´ava pˇred´ana handleru urˇcen´emu k identifi- kaci ud´alosti RPC protokolu. Nakonec zpr´ava putuje do handleru, kter´y ji pˇred´a na backendov´y kan´al, kde dojde k jej´ımu pˇreposl´an´ı na pool server.

Aby mohl proxy server zpracov´avat i odpovˇedi pool serveru, jsou tyto handlery zaˇrazeny i v backendov´em kan´alu. Jejich instance je tedy sd´ılen´a pro oba kan´aly.

Pro tyto ´uˇcely vyˇzaduje Netty framework takto pouˇz´ıvan´e handlery oznaˇcit pomoc´ı anotace @Sharable.

4.1.2 Identifikace RPC protokolu

Vˇsechny RPC protokoly komunikuj´ı pomoc´ı zpr´av zas´ılan´ych ve form´atu JSON. Liˇs´ı se vˇsak v komunikaˇcn´ım kan´alu, kter´y pro v´ymˇenu tˇechto zpr´av vyuˇz´ıvaj´ı. Podle vyuˇz´ıvan´eho protokolu je m˚uˇzeme rozdˇelit na dvˇe z´akladn´ı skupiny. Prvn´ı skupinu tvoˇr´ı protokoly Getwork a Getblocktemplate (viz kapitoly 2.9.1 a 2.9.2), kter´e ko- munikuj´ı pomoc´ı HTTP protokolu. Protokol Stratum (viz kapitola 2.9.3) vyuˇz´ıv´a ke komunikaci TCP socket, po kter´em pos´ıl´a jednotliv´e textov´e zpr´avy oddˇelen´e znakem konce ˇr´adky. Dalˇs´ı zpracov´an´ı zpr´avy tedy z´avis´ı na typu RPC protokolu.

U kaˇzd´e zpr´avy proto mus´ıme nejdˇr´ıve rozhodnout, o jak´y typ protokolu se jedn´a.

Z toho d˚uvodu je na zaˇc´atku fronty handler˚u um´ıstˇen FrontendAnalyticHandler. Ten se postar´a o rozpozn´an´ı typu protokolu a na z´akladˇe toho zaˇrad´ı do fronty dalˇs´ı handlery. Ty se postaraj´ı o dek´odov´an´ı zpr´avy z objektu ByteBuf do ˇciteln´eho form´atu. U RPC protokol˚u zaloˇzen´ych na HTTP protokolu se jedn´a o instanci tˇr´ıdy DefaultFullHttpRequest pro pˇr´ıchoz´ı poˇzadavky, respektive o instanci tˇr´ıdy DefaultFullHttpResponse pro odpovˇedi.

U protokolu Stratum se jedn´a o objekt datov´eho typu String.

Na z´akladˇe identifikace typu protokolu se do fronty zaˇrad´ı handlery specifick´e pro rozpoznan´y protokol. Je-li rozpozn´an protokol komunikuj´ıc´ı pomoc´ı HTTP, je jeˇstˇe potˇreba rozliˇsovat mezi protokoly Getwork a Getblocktemplate. Abych nemu- sel v aplikaci definovat speci´aln´ı sadu handler˚u pro kaˇzd´y RPC protokol, vyuˇz´ıvaj´ı HTTP protokoly spoleˇcnou frontu handler˚u. Jejich zpracov´an´ı je totiˇz, aˇz na roz- pozn´an´ı ud´alosti RPC protokolu, naprosto shodn´e.

Do fronty se tak zaˇrad´ı handlery GetworkHandler a GetblocktemplateHandler, kter´e dˇed´ı od spoleˇcn´eho pˇredka AbstractRpcHttpBasedHandler. V pˇredkovi je implementov´ana logika, kter´a se postar´a o urˇcen´ı RPC protokolu. Pokud rozpoznan´y protokol nesouhlas´ı s protokolem handleru, je zpr´ava pˇred´ana dalˇs´ımu handleru bez jak´ehokoliv zpracov´an´ı. Zpr´ava je t´ım p´adem vˇzdy zpracov´ana jen jedn´ım handlerem RPC protokolu.

4.1.3 Autentizace uˇ zivatele

Tˇeˇzebn´ı klient ve zpr´avˇe pos´ıl´a pˇrihlaˇsovac´ı ´udaje k pool serveru. Na z´akladˇe tˇechto

´

udaj˚u ale nejsem schopn´y rozpoznat uˇzivatel˚uv ´uˇcet v syst´emu. Potˇrebuji proto, aby klient v tˇele zpr´avy zas´ılal autentizaˇcn´ı ˇretˇezec vygenerovan´y ve webov´em rozhran´ı a n´azev workera evidovan´y u jeho ´uˇctu. Na z´akladˇe tˇechto ´udaj˚u jsem schopn´y klienta autentizovat a pˇriˇradit mu uˇzivatelsk´y ´uˇcet v aplikaci. Aby doˇslo ke korektn´ımu spojen´ı s pool serverem, tak je nutn´e tyto ´udaje ve zpr´avˇe zmˇenit na autentizaˇcn´ı

´

udaje pool serveru. Ty jsou naˇcteny z datab´aze, kde si je pro jednotliv´e pool servery definuje uˇzivatel.

Knihovna pracuje s rozhran´ım Authenticator, kter´e definuje metodu pro au- tentizaci klienta a naˇcten´ı pˇrihlaˇsovac´ıch ´udaj˚u k pool serveru. Implementace, kter´a naˇc´ıt´a data z datab´aze, je um´ıstˇena v proxy projektu. Knihovna obsahuje pouze implementaci s testovac´ımi daty.

Identifikace jm´ena a hesla u protokol˚u, kter´e komunikuj´ı pomoc´ı HTTP je cel- kem snadn´a. Autentizace klienta prob´ıh´a pomoc´ı basic access authentication.

Jm´eno a heslo je tud´ıˇz pˇren´aˇseno v hlaviˇcce HTTP zpr´avy. Pro zjiˇstˇen´ı jm´ena a hesla je potˇreba pˇreˇc´ıst hodnotu hlaviˇcky a prov´est base 64 dek´odov´an´ı. T´ım z´ısk´am ˇretˇezec, ve kter´em je jm´eno a heslo oddˇelen´e dvojteˇckou.

U protokolu Stratum je ale identifikace jm´ena workera mnohem obt´ıˇznˇejˇs´ı.

Nav´az´an´ı spojen´ı mezi klientem a pool serverem prob´ıh´a n´asledovnˇe:

• Klient zaˇsle zpr´avu volaj´ıc´ı metodu mining.subscribe.

• Pool server zaˇsle inicializaˇcn´ı ´udaje, aby klient mohl zaˇc´ıt poˇc´ıtat.

• Teprve pot´e zaˇsle klient zpr´avu s autentizaˇcn´ımi ´udaji.

• Pool server potvrd´ı, nebo zam´ıtne autentizaci.

Zde nar´aˇz´ım na probl´em. Proxy server by totiˇz potˇreboval prvn´ı zpr´avu pˇreposlat na pool server. Bohuˇzel v tomto okamˇziku jeˇstˇe nezn´a jm´eno workera a nezn´a t´ım p´adem ani URL adresu pool serveru. Proxy server v tomto pˇr´ıpadˇe postupuje n´asledovnˇe:

• Po obdrˇzen´ı inicializaˇcn´ı zpr´avy od klienta mu proxy server odeˇsle

”fiktivn´ı odpovˇed’“ a p˚uvodn´ı zpr´avu si uloˇz´ı.

• Od klienta obdrˇz´ı autentizaˇcn´ı zpr´avu, kterou si rovnˇeˇz uloˇz´ı.

• V t´eto chv´ıli zn´a jm´eno workera, nav´aˇze tedy spojen´ı s pool serverem.

• Po ´uspˇeˇsn´em spojen´ı s pool serverem mu pˇrepoˇsle prvn´ı zpr´avu od workera.

• Odpovˇed’ od pool serveru pˇrepoˇsle klientovi, aby zaˇcal poˇc´ıtat re´aln´y blok.

• N´aslednˇe proxy server pˇrepoˇsle na pool sever tak´e druhou (autentizaˇcn´ı) zpr´avu, aby doˇslo ke spr´avn´e asociaci mezi pool serverem a workerem.

• D´ale jiˇz komunikace prob´ıh´a standardnˇe, proxy server tedy pˇrekl´ad´a veˇsker´e poˇzadavky mezi klientem a pool serverem.

Kromˇe takto z´ıskan´eho jm´ena a hesla potˇrebuji u kaˇzd´eho tˇeˇzebn´ıho klienta zn´at i dalˇs´ı informace. Z tohoto d˚uvodu se pro kaˇzd´eho autentizovan´eho klienta vytvoˇr´ı instance objektu WorkerInternalName. Ten obsahuje ˇc´ıslo portu a adresu aktu´alnˇe vyuˇz´ıvan´eho pool serveru. Kromˇe tˇechto ´udaj˚u uchov´av´a tak´e instanci objektu WorkerInternalName. V nˇem je zapouzdˇreno jm´eno tˇeˇzebn´ıho klienta, jeho identifikaˇcn´ı ˇretˇezec, identifik´ator ´uˇctu, n´azev tˇeˇzebn´ı skupiny a aktu´alnˇe tˇeˇzen´a mˇena.

4.1.4 Handlery RPC protokol˚ u

U kaˇzd´e zpr´avy dojde k identifikaci RPC protokolu a podle toho se roz- hodne, kter´y handler ji bude zpracov´avat. Ke kaˇzd´emu protokolu n´aleˇz´ı pr´avˇe jeden handler. Jedn´a se o handlery GetworkHandler, GetblocktemplateHandler a StratumHandler. Z kaˇzd´e pˇr´ıchoz´ı zpr´avy se nejdˇr´ıve pˇreˇcte IP adresa a ˇc´ıslo portu. N´aslednˇe dojde k parsov´an´ı tˇela zpr´avy. JSON zpr´ava pˇren´aˇsen´a ve formˇe tex- tov´eho ˇretˇezce se pˇrevede do objektov´e reprezentace, se kterou d´ale pracuji. K t´eto transformaci vyuˇz´ıv´am knihovny FasterXML/jackson. Ta na z´akladˇe m´e reˇserˇse [17]

vykazovala z dostupn´ych knihoven nejlepˇs´ıho v´ykonu. Rychl´e zpracov´an´ı zpr´avy je totiˇz pro ´uˇcely m´eho syst´emu velmi d˚uleˇzit´e.

N´aslednˇe jsou analyzov´any jednotliv´e atributy JSON zpr´avy. Na jejich z´akladˇe se rozhodne o ud´alosti RPC protokolu a jej´ıch parametrech. Handler m´a k dispozici sadu adapt´er˚u. Po dokonˇcen´ı anal´yzy pˇrijat´e zpr´avy zavol´a na kaˇzd´em z adapt´er˚u pˇr´ısluˇsnou metodu, kter´e pˇred´a naˇcten´a data. Handler se star´a i o poˇc´ıt´an´ı doby odpovˇedi pro kaˇzd´y poˇzadavek. Tento ˇcasov´y ´udaj je tak´e pˇred´av´an do adapt´er˚u.

C´ılem adapt´er˚u je abstrahovat jednotliv´e ud´alosti RPC protokol˚u. Pro kaˇzd´y protokol existuje interface, kter´y tyto ud´alosti definuje. Hierarchie rozhran´ı je zob- razena na obr´azku4.3.

Pro jeden protokol je moˇzn´e definovat i v´ıce adapt´er˚u. Operace prov´adˇen´e v adapt´erech mus´ı b´yt velmi rychl´e. V pˇr´ıpadˇe jejich vyˇsˇs´ı ˇcasov´e n´aroˇcnosti by doch´azelo ke zpoˇzd’ov´an´ı komunikace mezi klientem a pool serverem. Z tohoto d˚uvodu pouˇz´ıv´a jejich implementace v proxy modulu asynchronn´ı z´apis do datab´aze.

Knihovna pro abstrakci RPC protokol˚u obsahuje pro kaˇzd´y z protokol˚u dvˇe v´ychoz´ı implementace adapt´er˚u. Ty opˇet slouˇz´ı pouze k ovˇeˇren´ı funkˇcnosti t´eto knihovny. Prvn´ı adapt´er slouˇz´ı k prost´emu v´ypisu zaznamenan´ych ud´alost´ı do kon- zole. Druh´y slouˇz´ı k zachyt´av´an´ı statistick´ych ukazatel˚u tˇeˇzby, kter´e si ukl´ad´a do pamˇeti.

4.1.5 Pˇ repojov´ an´ı klienta mezi pool servery

Abych mohl realizovat pˇrepojov´an´ı klient˚u mezi pool servery, mus´ım si v aplikaci ukl´adat vˇsechna vytvoˇren´a spojen´ı. Pro kaˇzd´eho klienta mus´ım tak´e ukl´adat ad- resu pool serveru, ke kter´emu je aktu´alnˇe pˇripojen. Kromˇe toho potˇrebuji uchov´avat vˇsechny poˇzadavky na pˇrepojen´ı klienta. Abych mohl ˇreˇsit probl´em popisovan´y v ka-

Obr´azek 4.3: Hierarchie rozhran´ı adapt´er˚u pro abstrakci RPC protokol˚u

pitole 3.2.3, mus´ım si u kaˇzd´eho klienta ukl´adat identifik´ator posledn´ıho tˇeˇzen´eho bloku.

Ukl´ad´an´ı tˇechto ´udaj˚u z´avis´ı na konkr´etn´ım pouˇzit´ı knihovny. Proto pro ´uloˇziˇstˇe definuji rozhran´ı Storage. V tom se nach´az´ı metody pro ˇcten´ı i z´apis ukl´adan´ych dat. Knihovna obsahuje z´akladn´ı implementaci, kter´a vˇse ukl´ad´a do operaˇcn´ı pamˇeti.

Vzhledem k tomu, ˇze u m´eho syst´emu poˇc´ıt´am s moˇznost´ı jeho distribuce mezi v´ıce server˚u, je potˇreba tomu pˇrizp˚usobit i ukl´ad´an´ı stavov´ych dat aplikace. M˚uˇze se totiˇz st´at, ˇze by se tˇeˇzebn´ı klient v pr˚ubˇehu tˇeˇzby pˇripojoval k r˚uzn´ym proxy server˚um. Nˇekter´e z tˇechto ´udaj˚u tak mus´ı b´yt dostupn´e na vˇsech serverech souˇcasnˇe.

Takto vyˇclenˇen´e ´udaje bude proto potˇreba ukl´adat do datab´aze. Data zapsan´a do datab´aze se automaticky replikuj´ı mezi vˇsechny servery, na kter´ych aplikace bˇeˇz´ı.

K tomuto ´uˇcelu se v proxy modulu nach´az´ı implementace rozhran´ı Storage, kter´a vybran´e ´udaje ukl´ad´a do datab´aze. Mezi data ukl´adan´a do datab´aze patˇr´ı informace o pool serveru, ke kter´emu je tˇeˇzebn´ı klient aktu´alnˇe pˇripojen, informace o dobˇe tˇeˇzby aktu´aln´ı mˇeny pro kaˇzd´eho klienta a identifik´ator posledn´ıho tˇeˇzen´eho bloku s vazbou na pool server. Ostatn´ı stavov´e informace bude staˇcit ukl´adat pouze do operaˇcn´ı pamˇeti. Jsou totiˇz potˇreba pouze na tom serveru, na kter´em poˇzadavek od klienta vznikl.

Kromˇe ´uloˇziˇstˇe definuji v knihovnˇe jeˇstˇe rozhran´ı ConnectionManager pro spr´avu spojen´ı. To obsahuje metody pro vytvoˇren´ı nov´eho poˇzadavku na pˇrepojen´ı klienta, okamˇzit´e pˇrepojen´ı klienta a pˇrepojen´ı na alternativn´ı pool server v pˇr´ıpadˇe v´ypadku spojen´ı. Jeho implementace se opˇet nach´az´ı v modulu proxy.

4.2 Uloˇ ´ ziˇ stˇ e nasb´ıran´ ych dat

Jak jsem jiˇz zd˚uvodnil v kapitole 3.2.2, pouˇz´ıv´am v aplikaci datab´azi Cassandra.

Pro komunikaci mezi aplikac´ı a datab´az´ı pouˇz´ıv´am DataStax Java Driver [18].

Pˇrem´yˇslel jsem o vyuˇzit´ı nˇekter´eho z existuj´ıc´ıch framework˚u pro mapov´an´ı aplikaˇcn´ıho modelu na datab´azov´a data. T´ım by vˇsak vznikla pomˇernˇe vysok´a reˇzie a v´ysledn´e datab´azov´e dotazy bych nemˇel plnˇe pod kontrolou. Rychlost z´apisu a ˇcten´ı dat je vˇsak pro efektivn´ı chod m´eho syst´emu kl´ıˇcov´a. Rozhodl jsem se proto, ˇze se pokus´ım mapovac´ı vrstvu pojmout co nejefektivnˇeji. Vytvoˇril jsem proto sadu servisn´ıch tˇr´ıd, kter´e se staraj´ı o mapov´an´ı dat. S daty pot´e manipuluji pomoc´ı dotazovac´ıho jazyka CQL. Datab´azov´e dotazy tak mohu maxim´alnˇe optimalizovat

a dos´ahnu mnohem lepˇs´ıho v´ykonu neˇz pˇri pouˇzit´ı frameworku.

4.2.1 Verzov´ an´ı datab´ aze

Po navrˇzen´ı aplikaˇcn´ıho modelu je nutn´e vytvoˇrit poˇzadovanou strukturu v datab´azi.

V pr˚ubˇehu v´yvoje aplikace se mus´ı zmˇeny proveden´e v modelu synchronizovat s da- tab´az´ı. Vzhledem k rozhodnut´ı, ˇze nebudu pro mapov´an´ı dat vyuˇz´ıvat ˇz´adn´y fra- mework, si budu muset i tyto operace ˇreˇsit s´am. Rozhodl jsem se pro osvˇedˇcenou metodu, kdy spolu se zmˇenami v modelu bude v pˇr´ısluˇsn´em commitu um´ıstˇena tak´e migrace, kter´a provede vˇsechny potˇrebn´e zmˇeny v datab´azi. Tyto migrace budou ps´any v jazyce CQL.

Takto vytv´aˇren´e migrace budou pojmenov´any podle ˇc´ısla verze. ˇC´ıslo verze m˚uˇze tak´e obsahovat n´azev prostˇred´ı. Mohu tak definovat migraci s testovac´ımi daty, kter´a se provede pouze, pokud aplikace pobˇeˇz´ı ve v´yvojov´em m´odu. Aktu´aln´ı ˇc´ıslo verze bude uloˇzeno v datab´azi.

Skript pro inicializaci datab´aze je definov´an ve tˇr´ıdˇe DefaultDbInitializer. Na zaˇc´atku si z adres´aˇre s migracemi naˇcte vˇsechny CQL soubory. Podle definovan´eho algoritmu seˇrad´ı ˇc´ısla verz´ı od nejstarˇs´ı po nejnovˇejˇs´ı. ˇC´ısla verz´ı mohou obsahovat i ˇc´ısla podverz´ı (napˇr.: 3, 3.1, 3.5.2, 3.5.2.10). Pot´e se pokus´ı naˇc´ıst ˇc´ıslo aktu´aln´ı verze z datab´aze. Pokud nen´ı nalezen ˇz´adn´y z´aznam (poˇzadovan´a datab´aze nebo tabulka neexistuje, popˇr´ıpadˇe neobsahuje ˇz´adn´e z´aznamy), tak tuto situaci povaˇzuje za prvn´ı spuˇstˇen´ı inicializace datab´aze a budou provedeny vˇsechny dostupn´e mi- grace. Kdyˇz je nalezeno ˇc´ıslo aktu´aln´ı verze, tak postupnˇe provede vˇsechny migrace novˇejˇs´ıch verz´ı. Nakonec se do datab´aze zap´ıˇse ˇc´ıslo verze posledn´ı aplikovan´e mi- grace.

V CQL skriptech je nutn´e pouˇz´ıvat r˚uzn´e hodnoty, kter´e jsou z´avisl´e na aktu´aln´ım prostˇred´ı, ve kter´em aplikace bˇeˇz´ı (napˇr´ıklad n´azev datab´aze). Aby tyto

´

udaje nebyly zad´any pˇr´ımo v migraˇcn´ıch skriptech, zavedl jsem moˇznost pouˇz´ıvat promˇenn´e. Skripty pouˇz´ıvaj´ı jednoduch´y ˇsablonovac´ı syst´em, ve kter´em je moˇzn´e vyuˇz´ıvat definovan´e promˇenn´e.

4.2.2 Model aplikace

Tˇr´ıdy definuj´ıc´ı persistentn´ı model aplikace se nach´az´ı v modulu core. Struktura

jednotliv´e poloˇzky a metody pro z´ısk´an´ı a nastaven´ı jejich hodnot. Vzhledem k tomu, ˇze pˇri testov´an´ı aplikace (v´ıce v kapitole 4.2.4) potˇrebuji mezi sebou porovn´avat r˚uzn´e instance modelov´ych tˇr´ıd, jsou v kaˇzd´e tˇr´ıdˇe definov´any metody hashCode a equals. Tyto metody se v jazyce Java staraj´ı o spr´avn´e porovn´av´an´ı objekt˚u mezi sebou. Jinak modelov´e tˇr´ıdy neobsahuj´ı ˇz´adnou logiku.

V modulu zajiˇst’uj´ıc´ı REST API, kter´y popisuji v kapitole 4.4.1, jsou tyto tˇr´ıdy automaticky serializov´any do JSON form´atu. V nˇekter´ych pˇr´ıpadech ale nen´ı ˇz´adouc´ı, aby se serializovaly vˇsechny poloˇzky entity. V takov´ych pˇr´ıpadech vyuˇz´ıv´am tˇr´ıdn´ı anotace JsonIgnoreProperties. V t´e se definuj´ı promˇenn´e, kter´e se maj´ı pˇri serializaci objektu pˇreskakovat.

Jak jsem definoval v kapitole 3.2.2, data jsou logicky rozdˇelena ve tˇrech da- tab´az´ıch (keyspaces). Toto rozdˇelen´ı se odr´aˇz´ı i v aplikaˇcn´ım modelu. Modelov´e tˇr´ıdy jsou tud´ıˇz rozdˇeleny ve tˇrech bal´ıˇcc´ıch. Strukturu vˇsech tˇr´ıd v jednotliv´ych bal´ıˇcc´ıch zn´azorˇnuji pomoc´ı class diagram˚u na obr´azc´ıch 4.4,4.5 a4.6.

4.2.3 Mapov´ an´ı dat

M´ym c´ılem bylo vytvoˇrit mapov´an´ı tak, aby se jiˇz v servisn´ı vrstvˇe co nejv´ıce mi- nimalizovala z´avislost na konkr´etn´ı datab´azov´e struktuˇre. Chtˇel jsem m´ıt mapov´an´ı zapouzdˇren´e na jednom m´ıstˇe a izolovan´e od zbytku aplikace. To v budoucnu usnadn´ı veˇsker´e ´upravy v modelu dat a eliminuje to vzniky chyb. Kromˇe aplikaˇcn´ıho modelu a servisn´ıch tˇr´ıd pro samotnou manipulaci s datab´azov´ymi daty, definuji v apli- kaci nav´ıc jeˇstˇe jednu vrstvu urˇcenou k mapov´an´ı datab´azov´e struktury na mo- del aplikace. Definuj´ı se tam n´azvy tabulek, n´azvy jednotliv´ych datov´ych atribut˚u a prim´arn´ı kl´ıˇce tabulek.

Kaˇzd´a mapovac´ı tˇr´ıda implementuje rozhran´ı Mapper a dˇed´ı od abstraktn´ı tˇr´ıdy AbstractMapper, kter´a je generick´a. Rozhran´ı definuje n´asleduj´ıc´ı metody:

• String getTableName() - Vrac´ı n´azev tabulky v datab´azi.

• Optional<T> mapObjectFromDbRow(Row row) - Vytvoˇr´ı datab´azov´y objekt z datab´azov´eho v´ysledku.

• Map<String, Object> getObjectColumnsWithValues() - Vrac´ı mapu s n´azvy datov´ych poloˇzek tabulky a jejich hodnotami.

Obr´azek 4.4: Struktura modelov´ych tˇr´ıd pro ukl´ad´an´ı konfiguraˇcn´ıch dat

Obr´azek 4.5: Struktura modelov´ych tˇr´ıd pro ukl´ad´an´ı statistick´ych ukazatel˚u

Obr´azek 4.6: Struktura modelov´ych tˇr´ıd pro ukl´ad´an´ı stavov´ych dat aplikace

• String[] getPrimaryKeyNames() - Vrac´ı n´azvy atribut˚u, kter´e tvoˇr´ı prim´arn´ı kl´ıˇc z´aznamu.

• Object[] getPrimaryKeyValues() - Vr´at´ı hodnoty atribut˚u prim´arn´ıho kl´ıˇce.

• Object getColumns() - Vr´at´ı objekt definuj´ıc´ı strukturu datab´azov´e tabulky.

T´eto mapovac´ı vrstvy vyuˇz´ıvaj´ı servisn´ı tˇr´ıdy. Za pomoci mapovac´ı vrstvy mohou manipulovat s daty, aniˇz by musely pˇr´ımo pouˇz´ıvat n´azvy datov´ych atribut˚u tabulky.

Kaˇzd´a servisn´ı tˇr´ıda implementuje metodu, kter´a vrac´ı instanci rozhran´ı mapper pro konkr´etn´ı modelovou tˇr´ıdu.

Servisn´ı tˇr´ıdy definuj´ı z´akladn´ı CRUD operace. U nich implementuji podporu pro vlastnosti datab´aze Cassandra. Tˇemi jsou moˇznost vloˇzen´ı z´aznamu pouze, po- kud jiˇz neexistuje, moˇznost nastaven´ı TTL nebo nastaven´ı stupnˇe konzistence dat.

Umoˇzˇnuj´ı tak´e asynchronn´ı z´apis do datab´aze. Pro datab´azov´e dotazy pouˇz´ıv´am prepared statements, pomoc´ı kter´ych se samotn´y dotaz poˇsle do datab´aze pouze poprv´e. Pˇri jeho dalˇs´ım vol´an´ı se do datab´aze pˇrenesou pouze parametry, kter´e se do dotazu vkl´adaj´ı.

4.2.4 Testov´ an´ı servisn´ı vrstvy

Mapovac´ı vrstva mi zajiˇst’uje vcelku pˇeknou abstrakci datab´azov´e struktury. Jej´ı hlavn´ı nev´yhodou je ale nutnost ruˇcn´ı synchronizace mapovac´ıch tˇr´ıd se struktu- rou datab´aze. Hlavnˇe pˇri ´uprav´ach aplikaˇcn´ıho modelu hroz´ı, ˇze se zapomene na datab´azovou migraci. Abych pˇredeˇsel vzniku takov´ychto chyb, testuji vˇsechny ma- povac´ı tˇr´ıdy pomoc´ı integraˇcn´ıch test˚u. Pro kaˇzdou servisn´ı tˇr´ıdu je naps´an vlastn´ı test, kter´y na testovac´ıch datech provede vˇsechny CRUD operace. T´ım se ovˇeˇr´ı bez- chybn´a funkˇcnost mapov´an´ı dat mezi datab´az´ı a aplikaˇcn´ım modelem. Pokud ser- visn´ı tˇr´ıda obsahuje i jin´e metody urˇcen´e pro konkr´etn´ı modelov´y objekt, p´ıˇsi testy i pro nˇe. Vzhledem k modul´arn´ımu n´avrhu syst´emu to povaˇzuji za velkou v´yhodu.

Pokud projdou vˇsechny testy spr´avnˇe, mohu pˇredpokl´adat, ˇze modul core poskytuje pro spr´avn´a vstupn´ı data spr´avn´y v´ystup.

4.3 Proxy server

Modul proxy v sobˇe vyuˇz´ıv´a dalˇs´ıch ˇc´ast´ı syst´emu a to modulu core pro komu- nikaci s datab´az´ı a modulu rpclib pro abstrakci RPC protokol˚u. Z jedn´e strany se k nˇemu pˇripojuje tˇeˇzebn´ı klient, na druh´e stranˇe komunikuje s c´ılov´ym pool serverem. V proxy modulu je implementov´ana veˇsker´a aplikaˇcn´ı logika, kter´a se star´a o ukl´ad´an´ı a vyhodnocov´an´ı statistick´ych ´udaj˚u tˇeˇzby a spr´avn´e pˇrepojov´an´ı tˇeˇzebn´ıho klienta mezi jednotliv´ymi pool servery. V r´amci proxy serveru se spouˇst´ı i pl´anovaˇc (scheduler). Ten se star´a o vyhodnocov´an´ı efektivity tˇeˇzby a o perio- dick´e pˇrepojov´an´ı klienta na z´akladˇe procentu´aln´ıho rozdˇelen´ı v´ykonu. Na stranˇe proxy serveru implementuji vˇsechny potˇrebn´e rozhran´ı poskytovan´e knihovnou pro abstrakci RPC protokol˚u.

Jsou zde implementov´any jednotliv´e adapt´ery, kter´e zpracov´avaj´ı ud´alosti RPC protokol˚u. V nich doch´az´ı k z´apisu vybran´ych statistick´ych ´udaj˚u do datab´aze.

Z v´ykonnostn´ıho hlediska mus´ı b´yt operace v adapt´erech velmi rychl´e. Vyuˇz´ıv´am zde proto moˇznosti datab´aze Cassandra zapisovat data do datab´aze asynchronnˇe.

V tomto pˇr´ıpadˇe aplikace poˇsle dotaz do datab´aze a d´ale neˇcek´a na jeho proveden´ı a n´avrat v´ysledku. M˚uˇze se tedy teoreticky st´at, ˇze se z´apis nezdaˇr´ı a aplikace o tom nebude informov´ana. Vzhledem k velk´emu poˇctu dat, kter´e se budou takto zazna- men´avat, m˚uˇzeme tuto skuteˇcnost ignorovat. Jak popisuji v kapitole3.2.4, nastavuji tˇemto z´aznam˚um hodnotu TTL. Po jej´ı expiraci dojde k automatick´emu smaz´an´ı na stranˇe datab´aze.

Hodnotu TTL definuji spoleˇcnˇe s dalˇs´ım nastaven´ım v konfiguraˇcn´ım souboru.

Ten v aplikaci za pomoci frameworku Spring naˇc´ıt´am a v k´odu pouˇz´ıv´am jednotliv´e hodnoty jako promˇenn´e. D´ıky tomu p˚ujde aplikace snadno ladit a mohu pouˇz´ıvat r˚uzn´e konfigurace v z´avislosti na bˇehov´em prostˇred´ı.

V proxy serveru d´ale implementuji rozhran´ı pro autentizaci. To zaslan´e pˇrihlaˇsovac´ı ´udaje porovn´av´a s ´udaji uˇzivatelsk´eho ´uˇctu v datab´azi. Pokud je auten- tizace ´uspˇeˇsn´a, dojde k uloˇzen´ı identifik´atoru uˇzivatelsk´eho ´uˇctu a ´udaj˚u o tˇeˇzebn´ı skupinˇe klienta do objektu WorkerInternalName. Tyto ´udaje jsou potˇreba pˇri dalˇs´ım zpracov´av´an´ı poˇzadavk˚u a uchov´av´an´ım v pamˇeti uˇsetˇr´ım zbyteˇcn´e datab´azov´e do- tazy.

Dalˇs´ı implementovanou ˇc´ast´ı je rozhran´ı Storage. To ukl´ad´a ˇc´ast dat do datab´aze a ˇc´ast do operaˇcn´ı pamˇet´ı (v´ıce o tomto rozdˇelen´ı v kapitole 4.1.5). ´Uloˇziˇstˇe dat poˇc´ıt´a s t´ım, ˇze k nˇemu bude souˇcasnˇe pˇristupovat nˇekolik proces˚u. Metody pro

z´apis a ˇcten´ı dat jsou proto synchronizovan´e.

Z knihovny rpclib v proxy modulu implementuji jeˇstˇe rozhran´ı ReconnecApi pro pˇrepojov´an´ı klient˚u. Jeho implementace se star´a o vytvoˇren´ı poˇzadavku na pˇrepojen´ı klienta za pomoci rozhran´ı ConnectionManager, jehoˇz logika se tak´e nach´az´ı v proxy serveru.

4.3.1 V´ ypadky spojen´ı

V pˇr´ıpadˇe v´ypadku spojen´ı s c´ılov´ym pool serverem se m´a proxy server postarat o okamˇzit´e pˇrepojen´ı na alternativn´ı pool server. Z tohoto d˚uvodu se v proxy ser- veru nach´az´ı implementace rozhran´ı ConnectionErrorListener, kter´e je definovan´e v knihovnˇe rpclib. Ke sv´e ˇcinnosti potˇrebuje m´ıt pˇr´ıstup k adapt´er˚um RPC pro- tokol˚u, spr´avci spojen´ı a servisn´ım tˇr´ıd´am naˇc´ıtaj´ıc´ım data z datab´aze. V pˇr´ıpadˇe selh´an´ı spojen´ı je v rpclib zavol´ana metoda connectionFailed. T´e jsou pˇred´any veˇsker´e informace o tˇeˇzebn´ım klientovi a pool serveru. Nejdˇr´ıve se rozhodne, jestli se jedn´a o pˇreruˇsen´ı spojen´ı mezi klientem a proxy serverem, nebo v´ypadek mezi proxy serverem a pool serverem. V obou pˇr´ıpadech se zavol´a pˇr´ısluˇsn´a metoda na adapt´erech. V nich dojde k zaznamen´an´ı informace do datab´aze podobnˇe jako pˇri ostatn´ıch ud´alostech RPC protokol˚u.

Pokud se jedn´a o v´ypadek spojen´ı k pool serveru, postar´a se d´ale ConnectionErrorListener o pˇrepojen´ı na alternativn´ı pool server. Z datab´aze se nejdˇr´ıve mus´ı naˇc´ıst informace o tˇeˇzebn´ı skupinˇe, ve kter´e je worker um´ıstˇen. Podle pool serveru zn´am´eho z informac´ı o v´ypadku spojen´ı se zjist´ı aktu´alnˇe tˇeˇzen´a mˇena.

Proxy server se snaˇz´ı o dodrˇzen´ı uˇzivatelem stanoven´eho rozdˇelen´ı v´ykonu mezi jed- notliv´e mˇeny. Proto se nejdˇr´ıve pokus´ı nal´ezt alternativn´ı server, kter´y si uˇzivatel definoval pro aktu´alnˇe tˇeˇzenou mˇenu.

Pokud nen´ı nalezen ˇz´adn´y alternativn´ı server, dojde k pˇrepnut´ı tˇeˇzby na jinou mˇenu. Mˇeny jsou definov´any v r´amci tˇeˇzebn´ı skupiny a jsou jim pˇriˇrazeny priority.

Dojde tedy k pˇrepojen´ı na mˇenu, kter´a je podle definovan´ych priorit dalˇs´ı na ˇradˇe.

Pokud je aktu´alnˇe tˇeˇzen´a mˇena posledn´ı v poˇrad´ı, dojde k pˇrepnut´ı zpˇet na prvn´ı mˇenu. Stˇr´ıd´an´ı mˇen tedy funguje na principu cyklick´eho z´asobn´ıku.

Pokud m´a uˇzivatel definovanou pouze jednu mˇenu bez alternativn´ıch pool ser- ver˚u, bude pokus o pˇripojen´ı na aktu´aln´ı pool server opakov´an. Toto ˇreˇsen´ı nen´ı dokonal´e a spol´eh´a na spr´avnou konfiguraci ze strany uˇzivatele. Do budoucna bych

novan´y ˇz´adn´y alternativn´ı pool server, na kter´y by se mohl klient pˇripojit, doˇslo by k pˇripojen´ı na jeden z glob´aln´ıch pool server˚u. Odmˇena z glob´aln´ıch pool server˚u by se pot´e dˇelila mezi uˇzivatele, kteˇr´ı na nich tˇeˇzili.

4.3.2 Pl´ anovaˇ c

Pl´anovaˇc m´a v syst´emu dva z´akladn´ı ´ukoly. Star´a se o procentu´aln´ı rozdˇelen´ı v´ykonu mezi jednotliv´e mˇeny a ˇreˇs´ı anal´yzu prob´ıhaj´ıc´ı tˇeˇzby a vyhodnocov´an´ı jej´ı efektivity.

Jeho v´ystupem m˚uˇze b´yt vytvoˇren´ı ˇz´adosti o pˇrepojen´ı klienta na jin´y pool server.

V aktu´aln´ı verzi aplikace je pl´anovaˇc implementov´an v r´amci proxy modulu. Zde m´a k dispozici vˇsechny potˇrebn´e ˇc´asti ke sv´e ˇcinnosti. Do budoucna uvaˇzuji o jeho pˇrestˇehov´an´ı do samostatn´eho modulu aplikace. Mohl by se pot´e spouˇstˇen na jin´em serveru, ˇc´ım bych dos´ahl moˇznosti lepˇs´ıho ˇsk´alov´an´ı v´ykonu syst´emu.

Spouˇstˇen´ı pl´anovaˇce prob´ıh´a periodicky v pevnˇe definovan´em inter- valu. K periodick´emu spouˇstˇen´ı vyuˇz´ıv´am frameworku Spring. Ve tˇr´ıdˇe SchedulerConfigurer, kter´a implementuje rozhran´ı SchedulingConfigurer, nastavuji spouˇstˇen´ı pl´anovaˇce v intervalu definovan´em v konfiguraˇcn´ım sou- boru. Pravidelnˇe je vol´ana metoda execute tˇr´ıdy SchedulerExecutor. Odtud se postupnˇe zavolaj´ı metody definovan´e v rozhran´ı Scheduler. To obsahuje dvˇe metody: reconnectIneffectiveConnection(SchedulerLog schedulerLog) a handlePerformanceSplitting(SchedulerLog schedulerLog). Ty implemen- tuji ve tˇr´ıdˇe DefaultScheduler. Obˇe maj´ı n´avratov´y typ boolean. Vrac´ı hodnotu true, pokud vytvoˇrily poˇzadavek na pˇrepojen´ı klienta. V opaˇcn´em pˇr´ıpadˇe je vr´acena hodnota false.

Pravidelnˇe prov´adˇen´y skript si z datab´aze nejprve naˇcte informace o vˇsech ak- tivn´ıch klientech. Pro kaˇzd´eho z nich pot´e postupnˇe zavol´a metody definovan´e v roz- hran´ı Scheduler. Nejdˇr´ıve je vol´ana metoda pro vyhodnocen´ı efektivity tˇeˇzby. Po- kud v r´amci t´eto metody nedojde ke vzniku ˇz´adosti o pˇrepojen´ı, zavol´a se metoda urˇcen´a k rozdˇelen´ı v´ykonu.

4.3.3 V´ ypoˇ cet efektivity spojen´ı

Prvnˇe jmenovan´a metoda se postar´a o anal´yzu nasb´ıran´ych statick´ych ukazatel˚u prob´ıhaj´ıc´ı tˇeˇzby. Na jejich z´akladˇe spoˇc´ıt´a sk´ore. Pokud takto spoˇc´ıtan´e sk´ore nepˇres´ahne mezn´ı pr´ah, je tˇeˇzba povaˇzov´ana za neefektivn´ı a dojde k vytvoˇren´ı