• No results found

FITKit Virtualization

N/A
N/A
Protected

Academic year: 2021

Share "FITKit Virtualization"

Copied!
40
0
0

Loading.... (view fulltext now)

Full text

(1)

VYSOK ´

E U ˇ

CEN´I TECHNICK ´

E V BRN ˇ

E

BRNO UNIVERSITY OF TECHNOLOGY

FAKULTA INFORMA ˇ

CN´ICH TECHNOLOGI´I

´

USTAV PO ˇ

C´ITA ˇ

COV ´

YCH SYST ´

EM ˚

U

FACULTY OF INFORMATION TECHNOLOGY DEPARTMENT OF COMPUTER SYSTEMS

VIRTUALIZACE FITKITU

BAKAL ´

A ˇ

RSK ´

A PR ´

ACE

BACHELOR’S THESIS

AUTOR PR ´

ACE

MAREK VAVRU ˇ

SA

AUTHOR

(2)

VYSOK ´

E U ˇ

CEN´I TECHNICK ´

E V BRN ˇ

E

BRNO UNIVERSITY OF TECHNOLOGY

FAKULTA INFORMA ˇ

CN´ICH TECHNOLOGI´I

´

USTAV PO ˇ

C´ITA ˇ

COV ´

YCH SYST ´

EM ˚

U

FACULTY OF INFORMATION TECHNOLOGY DEPARTMENT OF COMPUTER SYSTEMS

VIRTUALIZACE FITKITU

FITKIT VIRTUALIZATION

BAKAL ´

A ˇ

RSK ´

A PR ´

ACE

BACHELOR’S THESIS

AUTOR PR ´

ACE

MAREK VAVRU ˇ

SA

AUTHOR

VEDOUC´I PR ´

ACE

ING. ZDEN ˇ

EK VA ˇ

S´I ˇ

CEK

SUPERVISOR

(3)

Abstrakt

Pr´ace se zab´yv´a komplexn´ı virtualizac´ı v´yukov´e platformy FITkit.

Prvn´ı ˇc´ast bakal´aˇrsk´e pr´ace popisuje rozˇs´ıˇren´ı knihovny libkitclient o podporu virtu´aln´ıch zaˇr´ızen´ı a n´avrh protokolu pro sd´ılen´ı platformy FITkit v IP s´ıt´ıch. Protokol je rozˇs´ıˇren o podporu automatick´eho vyhled´av´an´ı zaˇr´ızen´ı v m´ıstn´ı s´ıti pomoc´ı protokolu UDP multi-cast. Druh´a ˇc´ast pr´ace se zab´yv´a n´avrhem architektury pro vzd´alen´y pˇreklad aplikac´ı pro platformu FITkit a jej´ı implementac´ı v programech fcmake a QDevKit. Posledn´ı ˇc´ast pr´ace shrnuje dosaˇzen´e v´ysledky a pˇredstavuje dalˇs´ı moˇznosti rozˇs´ıˇren´ı.

Abstract

Thesis presents a method of FITkit hardware platform virtualization. First part describes an extension of the libkitclient library to support virtual devices and discusses a protocol design for FITkit device sharing in the IP networks. The protocol is extended to offer an automatic device discovery in local network based on UDP multicast. The second part of the thesis presents an architecture for a remote compilation of FITkit platform binaries and the implementation in the fcmake and QDevKit. The last chapter summarizes implemented tools and presents possible future extensions.

Kl´ıˇ

cov´

a slova

FITkit, QDevKit, libkitclient, virtualizace, s´ıt’, TCP/IP, protokol, ASN.1, X.680, X.690, UDP, TCP, multicast

Keywords

FITkit, QDevKit, libkitclient, virtualization, network, TCP/IP, protocol, ASN.1, X.680, X.690, UDP, TCP, multicast

Citace

(4)

Virtualizace FITkitu

Prohl´

sen´ı

Prohlaˇsuji, ˇze jsem tuto bakal´aˇrskou pr´aci vypracoval samostatnˇe pod veden´ım pana Ing. Zdeˇnka Vaˇs´ıˇcka

. . . . Marek Vavruˇsa 17. kvˇetna 2011

Podˇ

ekov´

an´ı

Chtˇel podˇekovat sv´emu vedouc´ımu Ing. Zdeˇnku Vaˇs´ıˇckovi za obˇetav´e a odborn´e veden´ı v pr˚ubˇehu cel´eho bakal´aˇrsk´eho studia.

c

Marek Vavruˇsa, 2011.

Tato pr´ace vznikla jako ˇskoln´ı d´ılo na Vysok´em uˇcen´ı technick´em v Brnˇe, Fakultˇe in-formaˇcn´ıch technologi´ı. Pr´ace je chr´anˇena autorsk´ym z´akonem a jej´ı uˇzit´ı bez udˇelen´ı opr´avnˇen´ı autorem je nez´akonn´e, s v´yjimkou z´akonem definovan´ych pˇr´ıpad˚u.

(5)

Obsah

1 Uvod´ 2

2 N´astroje pro FITkit 3

2.1 Knihovna libkitclient . . . 3

2.2 FCMake . . . 4

2.3 QDevKit. . . 4

3 Podpora virtu´aln´ıch zaˇr´ızen´ı 5 3.1 Zmˇeny ve spr´avˇe zaˇr´ızen´ı . . . 5

3.2 Zmˇeny v komunikaci se zaˇr´ızen´ım . . . 6

4 Sd´ılen´ı zaˇr´ızen´ı v IP s´ıt´ıch 7 4.1 Modul pro sd´ılen´ı zaˇr´ızen´ı v IP s´ıt´ıch . . . 8

4.2 Implementace platformovˇe nez´avisl´e komunikace . . . 8

4.3 Protokol pro komunikaci se vzd´alen´ymi zaˇr´ızen´ımi . . . 9

4.4 Protokol pro vyhled´av´an´ı zaˇr´ızen´ı v m´ıstn´ı s´ıti . . . 12

4.5 Komunikaˇcn´ıho protokol v modulu IPBackend. . . 14

4.6 Sd´ılen´ı zaˇr´ızen´ı v programu QDevKit . . . 24

4.7 Podpora virtualizace v QDevKit . . . 26

5 Vzd´alen´y pˇreklad 27 5.1 Komunikace s pˇrekladov´ym serverem . . . 27

5.2 Tunelov´an´ı spojen´ı na pˇrekladov´y server . . . 31

(6)

Kapitola 1

´

Uvod

Hlavn´ı motivac´ı bakal´aˇrsk´e pr´ace zab´yvaj´ıc´ı se moˇznostmi virtualizace platformy FITkit je problematick´a a ˇcasto n´aroˇcn´a instalace softwarov´eho vybaven´ı potˇrebn´eho pro pˇreklad apli-kac´ı pro FITkit. Dalˇs´ı pˇr´ınos lze zpatˇrit v oblasti propagace. D´ıky virtualizci maj´ı pˇr´ıpadn´ı z´ajemci moˇznost si vyzkouˇset pr´aci s platformou vzd´alenˇe, aniˇz by ji museli fyzicky vlastnit ˇ

ci instalovat potˇrebn´y software. V r´amci projektu, kter´y se zab´yv´a realizac´ı virtu´aln´ı la-boratoˇre, m˚uˇzeme s navrˇzen´ym pˇr´ıstupem uˇsetˇrit znaˇcn´e mnoˇzstv´ı energie, nebot’ vˇsechna zaˇr´ızen´ı mohou b´yt pˇripojena k centr´aln´ı stanici, kter´a se bude starat o jejich zpˇr´ıstupnˇen´ı klientsk´ym stanic´ım. Mimo to sd´ılen´ı zaˇr´ızen´ı v IP s´ıt´ıch usnadn´ı student˚um kr´atkodob´e p˚ujˇcovan´ı FITkitu bez nutnosti ho fyzicky pˇrepojovat. Probl´em n´aroˇcn´e instalace softwa-rov´eho vybaven´ı ˇreˇs´ı virtualizace pˇrekladov´eho prostˇred´ı, kter´a dovoluje pˇreklad aplikac´ı bez nutnosti instalovat n´astroje lok´alnˇe.

N´apln´ı t´eto bakal´aˇrsk´e pr´ace je rozˇs´ıˇrit softwarov´e vybaven´ı platformy FITkit o moˇznost spravovat virtu´aln´ı zaˇr´ızen´ı a implementovat jak virtu´aln´ı zaˇr´ızen´ı komunikuj´ıc´ı s fyzick´ymi, tak architekturu pro vyhled´av´an´ı a sledov´an´ı stavu tˇechto zaˇr´ızen´ı.

Pr´ace je ˇclenˇena n´asledovnˇe. Prvn´ı kapitola se zab´yv´a ´uvodem do ˇreˇsen´e problematiky, jsou zde pops´any v´yvojov´e n´astroje pouˇz´ıvan´e pro usnadnˇen´ı pr´ace s platformou FITkit, pˇredevˇs´ım pak knihovnalibkitclient a aplikace QDevKit. Druh´a a tˇret´ı kapitola se vˇenuje specifikaci a n´avrhu komunikaˇcn´ıho protokolu, kter´y je pouˇzit pro sd´ılen´ı zaˇr´ızen´ı v s´ıti. Protokol implementuje standard X.680 ASN.1[5] s k´odov´an´ım X.690 BER[6] a vyuˇz´ıv´a pro-tokol TCP pro zajiˇstˇen´ı spolehliv´eho pˇrenosu dat.

Jako rozˇs´ıˇren´ı je zde navrˇzen a implementov´an jednoduch´y protokol pro automatick´e vy-hled´av´an´ı zaˇr´ızen´ı v m´ıstn´ıch IP s´ıt´ıch. Z´avˇerem t´eto ˇc´asti pr´ace je podpora obou protokol˚u a praktick´e vyuˇzit´ı v programu QDevKit. ˇCtvrt´a kapitola se zab´yv´a pˇrekladem aplikac´ı pro platformu FITkit na vzd´alen´em stroji bez nutnosti instalace dalˇs´ıho softwarov´eho vybaven´ı. V t´eto ˇc´asti je pops´ana realizace zabezpeˇcen´e metody poskytuj´ıc´ı pˇr´ıstup k pˇrekladov´emu serveru jak v r´amci s´ıtˇe VUT tak i mimo. V z´avˇeru jsou shrnuty dosaˇzen´e v´ysledky a navrˇzena moˇzn´a rozˇs´ıˇren´ı.

(7)

Kapitola 2

astroje pro FITkit

Pro platformu FITkit existuje softwarov´e vybaven´ı pro s´eriovou komunikaci, programov´an´ı mikroprocesoru a rekonfiguraci hradlov´eho pole. Z´akladn´ı knihovnu pro platformovˇe nez´avislou komunikaci se zaˇr´ızen´ım FITkit pˇredstavujelibkitclient. Knihovna je naps´ana v jazyce C++, ale souˇcasnˇe je pro ni vytvoˇreno rozhran´ı v jazyce Python. Tohoto rozhran´ı je vyuˇzito napˇr. v aplikaci FKFlash pro programov´an´ı platformy FITkit a termin´alov´e aplikaci FKTerm. Knihovna libkitclient pˇredstavuje z´aklad pro komunikaci v grafick´e termin´alov´e aplikaci QDevKit. Pro pˇreklad aplikac´ı se vˇsak pouˇz´ıv´a pˇrekladaˇc MSP-GCC a v´yvojov´e prostˇred´ı Xilinx ISE pro generov´an´ı konfiguraˇcn´ıho ˇretˇezce.

2.1

Knihovna libkitclient

Knihovna libkitclient se skl´ad´a z abstrakce rozhran´ı pro platformovˇe nez´avislou komuni-kaci se zaˇr´ızen´ım FITkit a spr´avce pˇripojen´ych zaˇr´ızen´ı. Zaˇr´ızen´ı FITkit je reprezentov´ano tˇr´ıdou FitKit a obsahuje pr´avˇe dva komunikaˇcn´ı kan´aly tˇr´ıdy FitKitChannel. Spr´avce zaˇr´ızen´ı pˇredstavuje dle sch´ematu2.1tˇr´ıda FitKitMgrimplementuj´ıc´ı ˇsablonuDeviceMgr. Ze sv´e podstaty spr´avce vytv´aˇr´ı a obsluhuje pr´avˇe jeden typ zaˇr´ızen´ı. V prostˇred´ı Microsoft Windows jsou tyto tˇr´ıdy implementov´any pomoc´ı knihovny D2XX, ofici´aln´ı podporovan´e knihovny pro pˇrimou komunikaci s pˇrevodn´ıky FTDI. Pro GNU/Linux je komunikace im-plementov´ana na z´akladˇe jednoduˇsˇs´ı knihovny libftdi.

FitKitMgr FitKit FitKitChannel DeviceMgr (API) FitKitChannel Device (API)

(8)

2.2

FCMake

Aplikace FCMake slouˇz´ı pˇredevˇs´ım pro generov´an´ı pˇrekladov´ych soubor˚uMakefile pro apli-kace na platformu FITkit, kter´e jsou pops´any definiˇcn´ımi soubory v jazyce XML. Definiˇcn´ı soubory obsahuj´ı jak metadata o aplikaci, tak seznam zdrojov´ych soubor˚u a z´avislost´ı konkr´etn´ı aplikace. Sd´ılen´a knihovna aplikace FCMake poskytuje rozhran´ı pro interpre-taci tˇechto soubor˚u, kter´e je vyuˇzito pro seznam aplikac´ı v grafick´e termin´alov´e aplikaci QDevKit. Aplikace je naps´ana v jazyce C++ s vyuˇzit´ım knihovny Qt[11].

2.3

QDevKit

Grafick´a termin´alov´a aplikace QDevKit (obr´azek 2.2) napsan´a v jazyce C++ umoˇzˇnuje mimo s´eriovou komunikaci se zaˇr´ızen´ım FITkit ve formˇe termin´alu tak´e programov´an´ı mikrokontroleru i rekonfiguraci hradlov´eho pole pomoc´ı komponenty FKFlash. Z´aroveˇn pˇrehlednˇe zobrazuje(1)dostupn´e aplikace pro platformu FITkit ve formˇe stromu a umoˇzˇnuje jejich aktualizaci z centr´aln´ıho repozit´aˇre projektu FITkit. Aplikace pro platformu FITkit je moˇzn´e pˇrekl´adat pˇr´ımo v r´amci aplikace, pokud jsou nainstalov´any n´astroje pro pˇreklad (MSP-GCC a Xilinx ISE). QDevKit tak´e umoˇzˇnuje spouˇstˇet simulaci pokud je nalezen si-mulaˇcn´ı software ModelSim. Zaˇr´ızen´ı FITkit jsou v aplikaci reprezentov´ana (2)seznamem ikon s podrobnˇejˇs´ımi ´udaji a otevˇren´e komunikaˇcn´ı kan´aly ve formˇe z´aloˇzek s termin´alem. Platformovˇe nez´avisl´e grafick´e rozhran´ı je implementov´ano pomoc´ı knihovny Qt[11].

(9)

Kapitola 3

Podpora virtu´

aln´ıch zaˇ

r´ızen´ı

Knihovna libkitclient byla p˚uvodnˇe navrˇzena pro pr´aci s jedn´ım typem zaˇr´ızen´ı (tˇr´ıda

FitKit) a protoˇze vytv´aˇren´ı instanc´ı nov´ych zaˇr´ızen´ı vˇcetnˇe implementaˇcnˇe z´avisl´ych ope-rac´ı bylo souˇc´ast´ı konkr´etn´ı tˇr´ıdy spr´avce zaˇr´ızen´ı (tˇr´ıdy FitKitMgr), nebylo jednoduˇse moˇzn´e obsluhovat virtu´aln´ı zaˇr´ızen´ı spolu s fyzick´ymi. Z´aroveˇn ale bylo nanejv´yˇs vhodn´e pokud moˇzno zachovat kompatibilitu na ´urovni zdrojov´eho k´odu se starˇs´ı verz´ı knihovny libkitclient.

Kompatibility na ´urovni zdrojov´ych k´od˚u je ˇc´asteˇcnˇe dosaˇzeno vytvoˇren´ım ˇcistˇe virtu´aln´ıho API pro pr´aci se zaˇr´ızen´ım a modul´arn´ı architektury spr´avy zaˇr´ızen´ı.

3.1

Zmˇ

eny ve spr´

avˇ

e zaˇ

r´ızen´ı

V p˚uvodn´ı verzi libkitclient slouˇzila tˇr´ıda DeviceMgr jako ˇsablona pro implementaci ob-sluhy jednoho typu zaˇr´ızen´ı, napˇr. FitKitMgr. Z toho d˚uvodu byla tˇr´ıda DeviceMgr novˇe implementov´ana jako plnˇe autonomn´ı bez nutnosti dalˇs´ıho rozˇsiˇrov´an´ı a pro implemen-taci konkr´etn´ıch potˇreb dan´eho typu zaˇr´ızen´ı byl zaveden syst´em modul˚u. Kaˇzd´y modul implementuje rozhran´ı tˇr´ıdyDeviceBackenda obsluhuje pr´avˇe jeden typ zaˇr´ızen´ı.

Povinn´e rozhran´ı modulu

Povinn´e rozhran´ı modulu tˇr´ıdyDeviceBackend zahrnuje metody pro:

Vytvoˇren´ı konkr´etn´ı instance zaˇr´ızen´ı, kter´a mus´ı implementovat rozhran´ı tˇr´ıdyDevice. Jedn´a se o metoduDevice* create(DeviceData*).

Inicializaci zaˇr´ızen´ı, napˇr. pro nastaven´ı stavu nebo inicializaci dalˇs´ıch prostˇredk˚u. Jedn´a se o metodubool initialize(Device *device).

Kontrolu komunikaˇcn´ıch kan´al˚u pˇripojen´eho zaˇr´ızen´ı. Jedn´a se o metodubool isReady(DeviceData*).

Aktualizaci seznamu vˇsech pˇripojen´ych zaˇr´ızen´ı, kter´e dan´y modul spravuje. Jedn´a se o metoduvoid update(DeviceData::List&).

(10)

Nepovinn´e rozhran´ı modulu

Z´aroveˇn m˚uˇze kaˇzd´y modul implementovat i nepovinn´e metody pro obsluhu ud´alost´ı:

Zaveden´ı modulu, zde je moˇzn´e pˇredevˇs´ım inicializovat potˇrebn´e prostˇredky pro hled´an´ı n´aleˇz´ıc´ıch zaˇr´ızen´ı. Jedn´a se o metodubool start().

Zastaven´ı modulu, zejm´ena pro uvolnˇen´ı zabran´ych prostˇredk˚u. Jedn´a se o metodubool stop().

Obsazen´ı voln´eho zaˇr´ızen´ı pro reakci na zmˇenu stavu zaˇr´ızen´ı. Jedn´a se o metoduvoid deviceAcquired(int).

Uvolnˇen´ı obsazen´eho zaˇr´ızen´ı.

Jedn´a se o metoduvoid deviceReleased(int).

Nalezen´ı nov´eho zaˇr´ızen´ı.

Jedn´a se o metoduvoid deviceFound(int).

Odpojen´ı existuj´ıc´ıho zaˇr´ızen´ı z d˚uvodu chyby v komunikaci nebo vyˇz´adan´eho odpojen´ı zaˇr´ızen´ı. Jedn´a se o metoduvoid deviceLost(int).

P˚uvodn´ı tˇr´ıduFitKitMgr nyn´ı implementuje modul FTDIBackend.

3.2

Zmˇ

eny v komunikaci se zaˇ

r´ızen´ım

Analogicky ke spr´avˇe zaˇr´ızen´ı doˇslo k nahrazen´ı tˇr´ıdy FitKitpro komunikaci se zaˇr´ızen´ım a tˇr´ıdy FitKitChannel pro komunikaci s jedn´ım kan´alem zaˇr´ızen´ı. Se vˇsemi zaˇr´ızen´ımi se nyn´ı pracuje pˇres ˇcistˇe virtu´aln´ı rozhran´ıDevicea s kan´aly pˇres rozhran´ıIOChannel. Metody pro pr´aci se zaˇr´ızen´ım i kan´aly z˚ustaly zachov´any.

Obdobnˇe jako v pˇr´ıpadˇe spr´avy zaˇr´ızen´ı, moduly implementuj´ı funkcionalitu jednot-liv´eho typu zaˇr´ızen´ı kter´y spravuj´ı. Funkcionalitu p˚uvodn´ı tˇr´ıdy FitKit zastupuje tˇr´ıda

FTDIDevice a tˇr´ıdu FitKitChannel nyn´ı implementuje FTDIChannel. Hlavn´ı rozd´ıl tedy pˇredstavuje oddˇelen´ı veˇrejn´eho API a implementace.

Tento pˇr´ıstup m´a nˇekolik v´yhod:

• Se zaˇr´ızen´ımi je moˇzn´e pracovat bez ohledu na implementaci pomoc´ı plnˇe virtu´aln´ıho rozhran´ı.

• Spr´ava vˇsech typ˚u zaˇr´ızen´ı je jednotn´a.

• Zaˇr´ızen´ı je moˇzno identifikovat dle typu a vyuˇz´ıvat jeho specifick´e funkce.

• Umoˇzˇnuje modul´arn´ım zp˚usobem rozˇsiˇrovat podporu o dalˇs´ı typy zaˇr´ızen´ı, i za bˇehu programu.

Pro potˇreby implementace nov´ych typ˚u zaˇr´ızen´ı byly pˇr´ıznaky zaˇr´ızen´ı rozˇs´ıˇreny o n´asleduj´ıc´ı:

• Device::Virtual- pokud je nastaven, jedn´a se o virtu´aln´ı zaˇr´ızen´ı. Slouˇz´ı pro potˇreby uˇzivatele odliˇsit fyzick´a zaˇr´ızen´ı od virtu´aln´ıch.

• Device::Shared - pokud je nastaven, tak zaˇr´ızen´ı neexistuje v´yhradnˇe pro danou instanci programu, ale je napˇr. sd´ıleno v s´ıti.

(11)

Kapitola 4

Sd´ılen´ı zaˇ

r´ızen´ı v IP s´ıt´ıch

Sd´ılen´ı zaˇr´ızen´ı je realizov´ano nov´ym modulem IPBackend, kter´y rozˇsiˇruje funkcionalitu o nov´y virtu´aln´ı typ zaˇr´ızen´ı tˇr´ıdy IPDevice. Hlavn´ım krit´eriem pro v´ybˇer knihovny pro s´ıt’ovou komunikaci byla jednoduchost, platformov´a nez´avislost a nez´avislost na dalˇs´ıch po-mocn´ych knihovn´ach. Z tˇechto d˚uvod˚u jsem jako z´aklad pouˇzil svou knihovnu liburpc, kterou jsem rozˇs´ıˇril o potˇreby projektu. Knihovna implementuje efektivn´ım zp˚usobem podmnoˇzinu standardu X.680 ASN.1[5] s k´odov´an´ım X.690 BER[6] a lze ji zakompilo-vat pˇr´ımo do moduluIPBackend. ModulIPBackend pracuje nez´avisle na obecn´em spr´avci zaˇr´ızen´ı, tak ukazuje sch´ema4.1.

DeviceMgr IPBackend IPDevice IPChannel IPService Fyzické zařízení

(12)

4.1

Modul pro sd´ılen´ı zaˇ

r´ızen´ı v IP s´ıt´ıch

Modul pro sd´ılen´ı zaˇr´ızen´ı v IP s´ıt´ıch pro knihovnulibkitclientse skl´ad´a z nˇekolika navz´ajem mezi sebou komunikuj´ıc´ıch ˇc´ast´ı.

IPDevice - implementace rozhran´ı tˇr´ıdyDevice, poskytuje metody pro pr´aci se vzd´alen´ym zaˇr´ızen´ım.

IPChannel - implementace rozhran´ı tˇr´ıdy IOChannel, poskytuje metody pro pr´aci se vzd´alen´ym kan´alem zaˇr´ızen´ı.

IPService - s´ıt’ov´a sluˇzba, kter´a zpˇr´ıstupˇnuje zaˇr´ızen´ı pˇripojen´a k dan´e stanici pro vzd´alen´e klienty.

IPDiscovery - s´ıt’ov´a sluˇzba umoˇzˇnuj´ıc´ı automatick´e vyhled´av´an´ı zaˇr´ızen´ı v m´ıstn´ı s´ıti pomoc´ı metody IP multicast.

IPBackend - samotn´y modul pro DeviceMgr, kter´y spravuje zaˇr´ızen´ı tˇr´ıdy IPDevice a sleduje jejich stav.

4.2

Implementace platformovˇ

e nez´

avisl´

e komunikace

Architektura protokolu sd´ılen´ı zaˇr´ızen´ı je pˇrirozenˇe decentralizovan´a a kaˇzd´a pˇripojen´a stanice tak m˚uˇze pracovat nez´avisle na ostatn´ıch. D´ıky tomu je protokol odoln´y v˚uˇci v´ypadku jednotliv´ych stanic a ´utok˚um typu DoS1 na centr´aln´ı uzly. Za nev´yhodu m˚uˇze b´yt povaˇzov´ana neexistence centr´aln´ı datab´aze eviduj´ıc´ı sd´ılen´a zaˇr´ızen´ı a jejich vyuˇzit´ı. Jako nosn´a vrstva byl zvolen protokol TCP k zajiˇstˇen´ı spolehliv´e komunikace mezi jednot-liv´ymi uzly. Komunikace se podob´a metodˇe RPC2, proto je nezbytn´e spolehlivou metodou doruˇcit ˇz´adost a z´aroveˇn obdrˇzet odpovˇed’ a to ve spr´avn´em poˇrad´ı, jelikoˇz odpovˇed’ m˚uˇze pˇres´ahnout d´elku jednoho UDP paketu, zejm´ena pˇri blokov´em ˇcten´ı dat. Toto je ˇreˇsiteln´e i protokolem orientovan´ym na zpr´avy, ale lze ˇr´ıci, ˇze implementac´ı spolehliv´e metody komu-nikace bychom znovu doˇsli ke spojovan´emu protokolu TCP.

Protoˇze implementace s´ıt’ov´e komunikace se liˇs´ı v z´avislosti na pouˇzit´e platformˇe, im-plementoval jsem objektovˇe orientovan´y modul pro s´ıt’ovou komunikaci podporuj´ıc´ı BSD sokety[13] na platformˇe GNU/Linux a BSD. Z´aroveˇn je podporov´ana knihovna Windows Sockets 2[10] (d´ale jen winsock2) v prostˇredn´ı Microsoft Windows. Hlavn´ı rozd´ıly jsou pˇredevˇs´ım:

• Nutnosti inicializovat syst´em s´ıt’ov´e komunikace vol´an´ım WSAStartup() pˇri pouˇzit´ı knihovnywsock2 a rozd´ıln´e n´azvy pro konverzi form´atu s´ıt’ov´ych adres.

• Nˇekter´a syst´emov´a vol´an´ı maj´ı t´eˇz pozmˇenˇenou s´emantiku, napˇr. pˇri pouˇzit´ı knihovny wsock2 je tˇreba sokety uzav´ırat pomoc´ı vol´an´ıclosesocket() kter´e je urˇceno pro sokety a nikoliv vol´an´ım close(), kter´e je v prostˇred´ı Microsoft Windows vyhrazeno pro popisovaˇce soubor˚u.

• S´emantika pˇredan´ych parametr˚u je u nˇekter´ych vol´an´ı rozd´ıln´a nebo mus´ı b´yt inicia-lizov´any na urˇcitou hodnotu. Napˇr. ˇcasov´a hodnota pro timeout pˇri vol´an´ıselect().

1

Denial of Service - metoda ´utoku zahlcen´ım sluˇzby, kter´a m´a za n´asledek odepˇren´ı legitimn´ıch poˇzadavk˚u.

2

(13)

Modul pro platformovˇe nez´avislou komunikaci je souˇc´ast´ı knihovny liburpc pˇriloˇzen´e ke knihovnˇelibkitclienta je reprezentov´ano tˇr´ıdouSocket. Tˇr´ıdaSocketimplementuje vˇsechny potˇrebn´e funkce pro pr´aci se spojovan´ymi protokoly vˇcetnˇe nˇekolika funkc´ı pro pr´aci s jed-noduˇsˇs´ım protokolem UDP. Nav´ıc je implementov´ana podpora pro registraci do skupin IP multicast.

4.3

Protokol pro komunikaci se vzd´

alen´

ymi zaˇ

r´ızen´ımi

Pouˇzit´y komunikaˇcn´ı protokol je zaloˇzen na podmnoˇzinˇe standardu X.680 ASN.1[5]. Jedn´a se tedy o strukturovan´y a pˇredevˇs´ım typovan´y protokol. D´ıky ˇsirok´emu pouˇzit´ı, zejm´ena v protokolech SNMP[2] a LDAP[9], je velmi dobˇre dokumentovan´y a v z´avislosti na pouˇzit´em k´odov´an´ı i prostorovˇe i ˇcasovˇe efektivn´ı. Z´aroveˇn je moˇzn´e transparentnˇe mˇenit k´odov´an´ı a napˇr. pro komunikaci s textovˇe zaloˇzen´ymi klienty pouˇz´ıt k´odov´an´ı X.693 XER[8] zaloˇzen´eho na jazyku XML[14]. Jako v´ychoz´ı k´odov´an´ı jsem pouˇzil X.690 BER[6] z n´asleduj´ıc´ıch d˚uvod˚u:

• Jedn´a se o bin´arn´ı k´odov´an´ı a podporuje ˇc´asteˇcnou kompresi, z toho d˚uvodu je pro-storovˇe efektivn´ı.

• Zapisuje se pˇr´ımo pˇri vytv´aˇren´ı PDU3, nen´ı nutn´e kaˇzdou zpr´avu kompilovat.

• Na rozd´ıl od X.691 PER[7] je v bin´arn´ı formˇe st´ale srozumiteln´y a ˇciteln´y.

K´odov´an´ı X.690 BER

Kaˇzd´a datov´a jednotka je k´odov´an´a tzv.

”tripletem“ (obr´azek4.2). Prvn´ı oktet reprezentuje datov´y typ, n´asleduj´ıc´ı oktety d´elku hodnoty v bytech a posledn´ı ˇc´ast samotn´a hodnota. V pˇr´ıpadˇe nˇekolika speci´aln´ıch typ˚u m˚uˇze b´yt d´elka nulov´a a jednotka bude m´ıt tedy pouze dva oktety - datov´y typ a nulov´y oktet reprezentuj´ıc´ı d´elku.

Typ (1 oktet) D´elka (1 - N oktet˚u) Hodnota (0 - N oktet˚u)

Obr´azek 4.2: Reprezentace datov´e jednotky protokolu ve formˇe

”tripletu“.

Datov´y typ je reprezentov´an pr´avˇe jedn´ım oktetem skl´adaj´ıc´ım se z tˇr´ıd, rozliˇsen´ı pri-mitivn´ıho a sloˇzen´eho datov´eho typu a samotn´eho ˇc´ısla identifikuj´ıc´ı datov´y typ.

Tˇr´ıda typu je reprezentov´ana 2 nejvyˇsˇs´ımi v´yznamov´ymi bity v oktetu a m˚uˇze nab´yt n´asleduj´ıc´ıch hodnot:

• Universal - obecn´e a standardem definovan´e datov´e typy, napˇr. cel´e ˇc´ıslo, ˇretˇezec. Tyto typy se nesm´ı b´yt podle standardu vyuˇzit´e pro jin´e s´emantick´e typy.

• Application- vlastn´ı typy pouˇzit´e v r´amci jedn´e aplikace, lze je pouˇz´ıt pro vytv´aˇren´ı vlastn´ıch datov´ych typ˚u.

• Context-specific - datov´y typ pouˇzit´y jen v urˇcit´em kontextu jako napˇr. SET OF

neboSEQUENCE.

• Private- soukrom´e datov´e typy, moˇzno pouˇz´ıt bez omezen´ı.

3

(14)

P/C bit rozliˇsuj´ıc´ı primitivn´ı nebo sloˇzen´y datov´y typ m˚uˇze nab´yt dvou hodnot - pokud je jeho hodnota 1, jedn´a se o sloˇzen´y datov´y typ.

ˇ

C´ıslo datov´eho typu urˇcuje jeho v´yznam v dan´e tˇr´ıdˇe, m˚uˇze nab´yvat max. 25hodnot. Pro tˇr´ıdu Universalvˇsechny hodnoty pˇredstavuj´ı pˇresnˇe definovan´y datov´y typ viz n´asleduj´ıc´ı tabulka.

Datov´y typ P/C bit C´ˇıslo (hexadecim´alnˇe)

BOOLEAN primitivn´ı 0x01

INTEGER primitivn´ı 0x02

OCTET STRING primitivn´ı 0x04

NULL primitivn´ı 0x05

ENUMERATED primitivn´ı 0x0A

SEQUENCE sloˇzen´y 0x10

SET OF sloˇzen´y 0x11

Obr´azek 4.3: Pˇrehledov´a tabulka pouˇzit´ych univerz´aln´ıch datov´ych typ˚u.

D´elka je ˇc´asteˇcnˇe komprimov´ana a je zaps´ana n´asleduj´ıc´ım zp˚usobem:

• Pokud je d´elka obsahu menˇs´ı neˇz 128 bajt˚u (0x80 hexadecim´alnˇe), je d´elka reprezen-tov´ana pˇr´ımo jedn´ım oktetem o t´eto hodnotˇe.

• V opaˇcn´em pˇr´ıpadˇe prvn´ı oktet reprezentuje hodnota 0x80 + N, kde N pˇredstavuje poˇcet bajt˚u vyuˇzit´ych pro z´apis d´elky a samotn´a d´elka je zaps´ana na n´asleduj´ıc´ıch N

bajtech. Napˇr. d´elka obsahu 1 bajt zapsan´a na 16 bitech (2 bajty) je reprezentov´ana jako posloupnost bajt˚u 0x82 0x00 0x01. Hodnoty d´elky je zaps´ana v poˇrad´ı bajt˚u Big-Endian4.

• Speci´aln´ı hodnota 0x80 u strukturovan´ych datov´ych typ˚u pˇredstavuje neurˇcenou d´elku datov´eho typu. V takov´em pˇr´ıpadˇe mus´ı za hodnotou n´asledovat speci´aln´ı da-tov´a jednotkaEOC. Tento zp˚usob z´apisu nen´ı v knihovnˇe liburpc podporov´an.

Knihovna liburpc implementuje z´apis d´elky nejkratˇs´ım moˇzn´ym zp˚usobem, tak jak to vyˇzaduj´ı standardy X.690 DER a X.690 CER.

0x04 0x05 ’t’ ’e’ ’x’ ’t’ ’\0’

Obr´azek 4.4: Pˇr´ıklad k´odov´an´ı X.690 DER datov´eho typu OCTET STRINGhodnoty"text".

4

(15)

Pouˇzit´e vlastn´ı datov´e typy

Pro komunikaci mezi jednotliv´ymi uzly bylo pouˇzito pˇredevˇs´ım typ˚u tˇr´ıdy Universal, vˇsechny pˇren´aˇsen´e zpr´avy jsou zapouzdˇreny vlastn´ım datov´ym typem tˇr´ıdyApplication. Tento strukturovan´y typ je podobn´y typuSEQUENCE, s t´ım rozd´ılem ˇze nese datov´e jednotky r˚uzn´ych typ˚u. Pro z´apis i ˇcten´ı slouˇz´ı tˇr´ıda Packet. Protoˇze je typ˚u zpr´av m´enˇe neˇz 25, je moˇzn´e operaˇcn´ı k´od zak´odovat pˇr´ımo do datov´eho typu zpr´avy. Vˇsechny tyto datov´e typy jsou strukturovan´e a n´aleˇz´ı tˇr´ıdˇe Application.

Datov´y typ Tˇr´ıda P/C bit C´ˇıslo (hexadecim´alnˇe)

UNSIGNED Private primitivn´ı 0x02

STRUCTURE Universal sloˇzen´y 0x00

CALL Application sloˇzen´y 0x00

Obr´azek 4.5: Pˇrehledov´a tabulka pouˇzit´ych univerz´aln´ıch datov´ych typ˚u.

Pˇr´ıklad pr´ace s komunikaˇcn´ım protokolem

Rozhran´ı na pr´aci s tˇr´ıdou Packetje velmi jednoduch´e, je zapotˇreb´ı: 1. Vytvoˇrit instanci paketu s operaˇcn´ım k´odem.

2. Pˇridat pˇren´aˇsen´a data.

3. Odeslat zpr´avu.

Na pˇr´ıkladu si uk´aˇzeme vytvoˇren´ı zpr´avy s operaˇcn´ım k´odemDevIsOpen s jednou datovou jednotkou typuINTEGER a hodnotou7:

// 1. Vytvoˇr´ı pr´azdnou zpr´avu

Packet pkt(DevIsOpen); // Application class, Structured, N = 1 // 2. Pˇrid´a data

pkt.addInt8(7); // Universal class, Primitive, N = 2 // 3. Odeˇsle zpr´avu

pkt.send(socket);

Zpr´ava odeslan´a t´ımto zp˚usobem bude m´ıt d´elku5oktet˚u a obsah 0x61 0x03 0x02 0x01 0x0a. Reprezentace oktet˚u je n´asledovn´a:

1. 0x61 - datov´y typ zpr´avy vˇcetnˇe operaˇcn´ıho k´odu. 2. 0x03 - d´elka obsahu v bajtech.

3. 0x02 - datov´y typINTEGER.

4. 0x01 - d´elka hodnoty je 1 bajt, jedn´a se tedy o osmibitov´e ˇc´ıslo. 5. 0x07 - osmibitov´a hodnota ˇc´ısla5.

5

(16)

4.4

Protokol pro vyhled´

av´

an´ı zaˇ

r´ızen´ı v m´ıstn´ı s´ıti

Pro snadn´e sd´ılen´ı zaˇr´ızen´ı v m´ıstn´ıch s´ıt´ıch byl navrˇzen jednoduch´y protokol pro automa-tick´e vyhled´av´an´ı pˇripojen´ych uzl˚u na b´azi metody IP multicast [12].

IP multicast

Metoda IP multicast doplˇnuje technologie unicast a broadcast. V´yhodou oproti technologii broadcast je pˇredevˇs´ım sn´ıˇzen´ı z´atˇeˇze v s´ıti a moˇznost vys´ılat data mimo pˇr´ımo pˇripojen´e uzly. Nev´yhodou oproti technologii broadcast je potom podpora ze strany router˚u na nˇeˇz klade technologie multicast vˇetˇs´ı n´aroky, pˇredevˇs´ım je tˇreba kromˇe smˇerov´an´ı pakety repli-kovat. D´ıky vyuˇzit´ı technologie multicast je tedy sd´ılen´ı moˇzno rozˇs´ıˇrit na ˇsirˇs´ı oblast, napˇr. mezi nˇekolika uˇcebnami a z´aroveˇn rozdˇelovat do skupin, coˇz u technologie broadcast moˇzn´e nen´ı.

Adresov´an´ı je podobn´e jako v metodˇe unicast, ale pouˇz´ıv´a se jin´e tˇr´ıdy adres. Zat´ımco pro unicast se pouˇz´ıvaj´ı adresy tˇr´ıdA,B aC, v technologii IP multicast se vyuˇz´ıv´a pouze tˇr´ıda adresD[1]. V t´eto tˇr´ıde se pouˇz´ıv´a pro adresov´an´ı rozsah224.0.0.0 - 239.255.255.0, kaˇzdou adresu tedy m˚uˇzeme snadno identifikovat podle prvn´ıho oktetu, kter´y v bin´arn´ı re-prezentaci zaˇc´ın´a hodnotou 1110[3].

Rozsah adres 224.0.0.0 - 224.0.0.255je rezervov´an pro adresov´an´ı.

Dosah datagramu je moˇzn´e ovlivnit nastaven´ım hodnoty TTL(Time To Live). Toto pole v datagramu IP ovlivˇnuje dosah paketu. Zapisuje se jedn´ım oktetem s rozsahem0 - 255.

TTL V´yznam

0 Pouze v r´amci jednoho uzlu. 1 Pouze v r´amci pods´ıtˇe. 32 V r´amci jedn´e s´ıtˇe (Intranet). 64 V r´amci kontinent´aln´ı s´ıtˇe Internet. 128 V r´amci mezikontinent´aln´ı s´ıtˇe Internet. 255 Bez omezen´ı.

Tabulka 4.1: V´yznam speci´aln´ıch hodnot TTL.

Multicastov´a skupina je reprezentov´ana pr´avˇe jednou adresou tˇr´ıdy D. Jelikoˇz jsou skupiny otevˇren´e, je moˇzn´e zas´ılat datagramy do skupiny bez nutnosti ˇclenstv´ı. Pro pˇr´ıjem datagram˚u je ˇclenstv´ı ve skupinˇe nezbytn´e.

(17)

Implementace metody IP multicast pro vyhled´av´an´ı zaˇr´ızen´ı

Pro implementaci protokolu vyhled´av´an´ı zaˇr´ızen´ı v m´ıstn´ı s´ıti byla vyuˇzita metoda IP mul-ticast. Mimo jiˇz uveden´ych d˚uvod˚u je v´yhodn´e i ˇclenˇen´ı do multicast skupin. Je tedy moˇzn´e oddˇelit jednotliv´e uzly sd´ılej´ıc´ı zaˇr´ızen´ı (napˇr. uˇcebny) do logick´ych skupin. V souˇcasn´e im-plementaci je pouˇzita skupina 225.26.27.28 a port 24242 Protoˇze technologie multicast pˇrirozenˇe neposkytuje moˇznost spolehliv´eho pˇrenosu, byl implementov´an jednoduch´y pro-tokol odoln´y v˚uˇci chyb´am.

Protokol pro vyhled´av´an´ı zaˇr´ızen´ı

Jelikoˇz nen´ı moˇzn´e vyuˇz´ıt pro pˇrenos dat spolehliv´y protokol TCP, je nutn´e zaruˇcit odolnost v˚uˇci chyb´am a zotaven´ı vlastn´ım zp˚usobem. Na z´akladˇe tˇechto poˇzadavk˚u jsem implemen-toval jednoduch´y protokol ide´aln´ı pro jak´ykoliv pˇrenos typu 1:M.

Protokol vyuˇz´ıv´a pro pˇrenos dat protokol UDP a skl´ad´a se pouze z dvou operaˇcn´ıch k´od˚u (viz tabulka4.2), pˇriˇcemˇz kaˇzd´y je reprezentov´an pouze jedn´ım oktetem. Z´aroveˇn je protokol textov´y a je moˇzn´e tak velice jednoduˇse implementovat aplikaci pouze sleduj´ıc´ı stav uzl˚u v s´ıti pouh´ym v´ypisem pˇr´ıchoz´ıch datagram˚u. Kaˇzd´a zpr´ava je ukonˇcena znakem0x00

a je moˇzn´e ji tedy do budoucna rozˇs´ıˇrit o dalˇs´ı metadata jako je napˇr. symbolick´e jm´eno, poˇcet zaˇr´ızen´ı, zp˚usob zabezpeˇcen´ı aj. IP adresu ohlaˇsovan´eho uzlu nen´ı tˇreba zapisovat do pˇren´aˇsen´ych dat, pˇrirozenˇe ji z´ısk´ame pˇr´ıjmem datagramu.

Typ zpr´avy Hexadecim´aln´ı k´od V´yznam

Announce 0x61 ’a’ Ohl´aˇsen´ı pˇripojen´eho uzlu.

Leave 0x6c ’l’ Odhl´aˇsen´ı uzlu ze skupiny. Tabulka 4.2: Typy zpr´av pro ohlaˇsov´an´ı uzl˚u v m´ıstn´ı s´ıti.

• Zpr´ava typuAnnounceupozorn´ı pˇr´ıjemce na aktivn´ı uzel v s´ıti a ten se m˚uˇze rozhod-nout pˇripojit k odesilateli spolehliv´ym protokolem a z´ıskat dalˇs´ı informace.

• Zpr´ava typu Leave upozorn´ı pˇr´ıjemce na odhl´aˇsen´ı odesilatele od multicastov´e sku-piny. To vˇsak nemus´ı nutnˇe znamenat ukonˇcen´ı prob´ıhaj´ıc´ı komunikace.

Protokol pro automatick´e vyhled´av´an´ı zaˇr´ızen´ı v s´ıti je tedy:

• Prostorovˇe efektivn´ı - jelikoˇz d´elka pˇren´aˇsen´ych dat v z´akladn´ı verzi je pouze 2 oktety, d´elka cel´eho UDP datagramu se tedy skl´ad´a z 8 oktet˚u hlaviˇcky a 2 oktet˚u uˇziteˇcn´ych dat.

• Velmi dobˇre ˇciteln´y bez nutnosti data d´ale zpracovat.

• Rozˇsiˇriteln´y o metadata bez ztr´aty kompatibility.

• Odoln´y v˚uˇci ztr´atˇe dat - ohl´aˇsen´ı prob´ıh´a periodicky, ztr´ata dat tedy znamen´a odd´alen´ı zpr´avy o jeden interval. V pˇr´ıpadˇe ztr´aty datagramu o odhl´aˇsen´ı uzlu ze skupiny do-jde automaticky k odpojen´ı klienta pˇri n´asleduj´ıc´ı aktualizaci seznamu pˇripojen´ych zaˇr´ızen´ı.

Protokol i implementaci s´ıtov´ehu uzlu pˇredstavuje tˇr´ıda IPDiscovery, pro implementaci platformovˇe nez´avisl´e s´ıt’ov´e vrstvy je pouˇzita vlastn´ı knihovna popsan´a v kapitole4.2.

(18)

4.5

Komunikaˇ

cn´ıho protokol v modulu IPBackend

Pro kompletn´ı virtualizaci zaˇr´ızen´ı v kontextu knihovny libkitclient je tˇreba implemen-tovat rozhran´ı tˇr´ıd DeviceBackend, Device a IOChannel. Pouˇzit´y komunikaˇcn´ı protokol tedy mus´ı podporovat pˇredevˇs´ım komunikaci mezi virtu´aln´ım a fyzick´ym zaˇr´ızen´ım, kde pro kaˇzd´e virtu´aln´ı zaˇr´ızen´ı existuje pr´avˇe jedno fyzick´e a souˇcasnˇe tak´e komunikaci mezi m´ıstn´ım a vzd´alen´ym spr´avcem zaˇr´ızen´ı a aktualizaci stavu pˇripojen´ych zaˇr´ızen´ı.

Uk´azka komunikace viz obr´azek 4.6.

Virtualizace spr´avce zaˇr´ızen´ı

Virtu´aln´ı spr´avce zaˇr´ızen´ı je implementov´an v tˇr´ıdˇeIPBackenda star´a se o sledov´an´ı stavu vzd´alen´ych zaˇr´ızen´ı. Jako nosn´y protokol pro virtualizaci je vyuˇzit protokol na b´azi X.680 ASN.1 popsan´y v kapitole 3 v reˇzimu ot´azka-odpovˇed’. D´ıky t´eto podobnosti protokolu s metodou RPC je moˇzn´e relativnˇe jednoduˇse pˇreloˇzit kaˇzd´e vol´an´ı metody modulu na pr´avˇe jeden operaˇcn´ı k´od. Operaˇcn´ı k´od paketu pˇredstavuje v z´apisu X.690 BER strukturovan´y datov´y typ tˇr´ıdyApplicationa ˇc´ıslem samotn´eho k´odu. Pro ˇc´ıslo typu je voln´ych 5 bit˚u v oktetu, lze tedy t´ımto zp˚usobem zak´odovat 25 operaˇcn´ıch k´od˚u. V pˇr´ıpadˇe vˇetˇs´ıho mnoˇzstv´ı k´od˚u lze pouˇz´ıt speci´aln´ı operaˇcn´ı k´od a poˇzadovan´y operaˇcn´ı k´od zak´odovat jako prvn´ı triplet v paketu s typemINTEGER n´asleduj´ıc´ım zp˚usobem:

Packet ::= CallType { opCode INTEGER }

IPBackend IPService Q: BackendAcquired A: BackendAcquired IPChannel Q: DevOpen A: DevOpen ... Q: DevClose A: DevClose IPBackend Q: BackendReleased A: BackendReleased

(19)

Pˇrehled virtualizovan´ych metod tˇr´ıdy IPBackend

Virtualizovan´e metody jsou reprezentov´any zpr´avami, pˇriˇcemˇz kaˇzd´y typ zpr´avy odpov´ıd´a pr´avˇe jedn´e virtualizovan´e funkci. Form´at zpr´av je zaps´an ve form´atu X.680 ASN.1[5].

BackendUpdate - vyhodnocen´ı seznamu sd´ılen´ych zaˇr´ızen´ı. Metoda se vol´a periodicky pˇri aktualizaci lok´aln´ıho seznamu zaˇr´ızen´ı a slouˇz´ı pˇredevˇs´ım k sledov´an´ı stavu vzd´alen´ych zaˇr´ızen´ı. Z´aroveˇn sleduje stav spojen´ı se vzd´alen´ymi uzly a v pˇr´ıpadˇe odpojen´eho uzlu uzavˇre vˇsechny virtu´aln´ı zaˇr´ızen´ı n´aleˇz´ıc´ı odpojen´emu uzlu a uvoln´ı zabran´e syst´emov´e prostˇredky. Souˇc´ast´ı t´eto operace je i ohl´aˇsen´ı uzlu v m´ıstn´ı s´ıti protokolem popsan´ym s sekci 4.4.

Dotaz

BackendUpdate ::= CallType + 0x10 { // 1 if sender expects a reply isQuery INTEGER(1)

}

Odpovˇed’

BackendUpdate ::= CallType + 0x10 { deviceList ::= SEQUENCE {

// Identifik´ator zaˇr´ızen´ı deviceID INTEGER(4), // Identifik´ator v´yrobce vendorID INTEGER(4),

// Identifik´ator prododuktu productID INTEGER(4),

// Stav a pˇr´ıznaky zaˇr´ızen´ı deviceFlags INTEGER(4) }

}

Tabulka 4.3: Form´at pro dotaz a odpovˇed’ operace BackendUpdate.

BackendIsDevReady - kontrola pˇripravenosti zaˇr´ızen´ı k zah´ajen´ı komunikace.

Dotaz

BackendIsDevReady ::= CallType + 0x11 { // Identifik´ator zaˇr´ızen´ı

deviceID INTEGER(4) }

Odpovˇed’

BackendIsDevReady ::= CallType + 0x11 { // Log. 1 pokud je pˇripraveno

boolState INTEGER(1) }

(20)

BackendAcquired - obsazen´ı dan´e instance zaˇr´ızen´ı pro v´yluˇcn´y pˇr´ıstup. Jedn´a se pouze o upozornˇen´ı, jako platn´a odpovˇed’ se vyhodnocuje paket se stejn´ym operaˇcn´ım k´odem. Obsah odpovˇedi se d´ale nevyhodnocuje.

Dotaz

BackendAcquired ::= CallType + 0x13 { // Identifik´ator zaˇr´ızen´ı

deviceID INTEGER(4) }

Odpovˇed’

BackendAcquired ::= CallType + 0x13 { }

Tabulka 4.5: Form´at pro dotaz a odpovˇed’ operace BackendAcquired.

BackendDevInitialize - inicializace zaˇr´ızen´ı po vytvoˇren´ı instance. V souˇcasn´e verzi nen´ı vyˇzadov´ana ani implementov´ana ˇz´adn´a speci´aln´ı inicializace virtu´aln´ıch zaˇr´ızen´ı.

BackendReleased - uvolnˇen´ı zaˇr´ızen´ı obsazen´eho operac´ıBackendAcquire. Jako platn´a odpovˇed’ se opˇet vyhodnocuje paket se stejn´ym operaˇcn´ım k´odem jako dotaz a obsah od-povˇedi se d´ale nevyhodnocuje.

Dotaz

BackendReleased ::= CallType + 0x14 { // Identifik´ator zaˇr´ızen´ı

deviceID INTEGER(4) }

Odpovˇed’

BackendReleased ::= CallType + 0x14 { }

Tabulka 4.6: Form´at pro dotaz a odpovˇed’ operace BackendReleased.

Virtualizace zaˇr´ızen´ı tˇr´ıdy Device

Virtu´aln´ı zaˇr´ızen´ı tˇr´ıdy IPDevice jsou vytv´aˇrena v r´amci tˇr´ıdy IPBackend popsan´e v pˇredchoz´ı podkapitole. Pˇredstavuj´ı tak zobrazen´ı pr´avˇe jednoho fyzick´eho zaˇr´ızen´ı. Spo-lehliv´y pˇrenos dat mezi fyzick´ym a virtu´aln´ım zaˇr´ızen´ı je zajiˇstˇen protokolem TCP. Proti fyzick´emu zaˇr´ızen´ı je zde nˇekolik dalˇs´ıch odliˇsnost´ı. Z d˚uvodu sd´ılen´eho TCP je spojen´ı je tˇreba vˇsechny operace synchronizovat a tud´ıˇz v kaˇzd´y ˇcasov´y okamˇzik m˚uˇze prob´ıhat ma-xim´alnˇe jedna operace. Pˇr´ıstup ke spojen´ı je synchronizov´an v r´amci cel´eho procesu. Tak´e stav zaˇr´ızen´ı se nezjiˇst’uje v kaˇzd´em okamˇziku, ale aktualizuje se periodicky v r´amci metody

IPBackend::update() z d˚uvodu nˇekolikan´asobnˇe vyˇsˇs´ı latence pˇri pˇrenosu dat pˇres TCP spojen´ı. Veˇsker´a komunikace ale prob´ıh´a formou dotaz - odpovˇed’, pro protistranu nen´ı tedy moˇzn´e upozornit tazatele na nov´a data.

V pojet´ı knihovnylibkitclient m´a kaˇzd´e zaˇr´ızen´ı implementuj´ıc´ı rozhran´ı tˇr´ıdyDeviceaˇz N kan´al˚u urˇcen´ych ke komunikaci. Samotn´a instance zaˇr´ızen´ı pouze sleduje stav zaˇr´ızen´ı a jednotliv´ych kan´al˚u. Tato data jsou aktualizov´ana periodicky pˇri kaˇzd´e aktualizaci spr´avce zaˇr´ızen´ı. M˚uˇzeme vyuˇz´ıt skuteˇcnosti, ˇze nen´ı podstatn´e zn´at pˇresn´y stav v kaˇzd´em okamˇziku a ˇc´ıst data z´ıskan´a pˇri posledn´ı aktualizaci zaˇr´ızen´ı. Tato vol´an´ı tedy nen´ı nutn´e virtualizo-vat.

(21)

Virtualizace komunikaˇcn´ıho kan´alu tˇr´ıdy IOChannel

Kaˇzd´e zaˇr´ızen´ı se skl´ad´a z N komunikaˇcn´ıch kan´al˚u, napˇr. v pˇr´ıpadˇe zaˇr´ızen´ı s USB pˇrevodn´ıkem FTDI FT2232 pouˇzit´em v platformˇe FITkit se jedn´a o dva komunikaˇcn´ı kan´aly oznaˇcen´e p´ısmeny A aB.

Rozliˇsov´an´ı tˇechto kan´al˚u je z´avisl´e na pouˇzit´em ovladaˇci sbˇernice USB. V pˇr´ıpadˇe operaˇcn´ıho syst´emu Microsoft Windows s ovladaˇciD2XX se jedn´a o dvˇe nez´avisl´a zaˇr´ızen´ı[4] zat´ımco v prostˇred´ı GNU/Linux za pouˇzit´ı knihovnylibusb dojde k rozpozn´an´ı zaˇr´ızen´ı se dvˇema komunikaˇcn´ımi kan´aly.

Z toho d˚uvodu je nutn´e virtualizovat zaˇr´ızen´ı aˇz na ´urovni knihovny libkitclient, kter´a model komunikace se zaˇr´ızen´ım sjednocuje bez ohledu na pouˇzitou platformu.

Pˇrehled virtualizovan´ych funkc´ı tˇr´ıdy IPChannel

Virtualizovan´y komunikaˇcn´ı kan´al plnˇe implementuje rozhran´ıIOChannel, pro z´ısk´an´ı kon-textu se vˇzdy jako prvn´ı dvˇe datov´e jednotky v paketu uv´adˇej´ı 32bit identifik´ator zaˇr´ızen´ı a 8bit identifik´ator kan´alu. Kaˇzd´y komunikaˇcn´ı kan´al tedy lze jednoznaˇcnˇe identifikovat na 42 bitech. Vzhledem k tomu ˇze identifik´ator zaˇr´ızen´ı je unik´atn´ı v r´amci jedn´e instance programu, doch´az´ı mapov´an´ı identifik´ator˚u vzd´alen´ych zaˇr´ızen´ı na m´ıstn´ı.

DevIsOpen - zjiˇst’uje, zda-li je komunikaˇcn´ı kan´al otevˇren´y. Tento typ zpr´avy imple-mentuje vol´an´ıisOpen(), v pˇr´ıpadˇe ´uspˇechu vrac´ılog. 1 v pˇr´ıpadˇe ne´uspˇechu log. 0.

Dotaz

DevIsOpen ::= CallType + 0x01 { // Identifik´ator zaˇr´ızen´ı deviceID INTEGER(4), // Identifik´ator kan´alu chanID INTEGER(1) } Odpovˇed’ DevIsOpen ::= CallType + 0x01 { // Odpovˇed’ response INTEGER(1) }

(22)

DevBytesIn - vrac´ı poˇcet nepˇreˇcten´ych bajt˚u ve vyrovn´avac´ı pamˇeti kan´alu. Zpr´ava implementuje vol´an´ıbytesIn() a vrac´ı 32 bitov´e cel´e ˇc´ıslo s poˇctem bajt˚u ve vyrovn´ac´ı pamˇeti v pˇr´ıpadˇe ´uspˇechu. Pokud nastane bˇehem operace chyba, vrac´ı z´aporn´e ˇc´ıslo.

Dotaz

DevBytesIn ::= CallType + 0x02 { // Identifik´ator zaˇr´ızen´ı deviceID INTEGER(4), // Identifik´ator kan´alu chanID INTEGER(1) } Odpovˇed’ DevBytesIn ::= CallType + 0x02 { // Odpovˇed’ bytesIn INTEGER(4) }

Tabulka 4.8: Form´at pro dotaz a odpovˇed’ operace DevBytesIn.

DevOpen - otevˇre komunikaˇcn´ı kan´al pro ˇcten´ı i z´apis. Zpr´ava implementuje vol´an´ı

open()a vrac´ı 32 bitov´e cel´e ˇc´ıslo slog. 1v pˇr´ıpadˇe ´uspˇechu nebo z´aporn´e ˇc´ıslo pˇredstavuj´ıc´ı chybov´y k´od tˇr´ıdyIOChannel. Tento mechanismus zajiˇst’uje kontrolu periodicky ukl´adan´eho stavu dan´eho zaˇr´ızen´ı. Pokud je kan´al jiˇz otevˇren na vzd´alen´em uzlu a nedoˇslo jeˇstˇe k ak-tualizaci jeho stavu, dojde k vr´acen´ı chybov´eho k´odu.

Dotaz

DevOpen ::= CallType + 0x03 { // Identifik´ator zaˇr´ızen´ı deviceID INTEGER(4), // Identifik´ator kan´alu chanID INTEGER(1) } Odpovˇed’ DevOpen ::= CallType + 0x03 { // Odpovˇed’ openReturn INTEGER(4) }

Tabulka 4.9: Form´at pro dotaz a odpovˇed’ operace DevOpen.

DevClose - uzavˇre komunikaˇcn´ı kan´al pro ˇcten´ı i z´apis. Typ zpr´avy je inverzn´ı k operaci

DevOpen a implementuje vol´an´ıclose(). V´ysledkem je 32 bitov´e cel´e ˇc´ıslo s log. 1 v pˇr´ıpadˇe ´uspˇechu nebo z´aporn´e ˇc´ıslo pˇredstavuj´ıc´ı chybov´y k´od tˇr´ıdy IOChannel.

Dotaz

DevClose ::= CallType + 0x04 { // Identifik´ator zaˇr´ızen´ı deviceID INTEGER(4), // Identifik´ator kan´alu chanID INTEGER(1) } Odpovˇed’ DevClose ::= CallType + 0x04 { // Odpovˇed’ closeReturn INTEGER(4) }

(23)

DevStart - zah´aj´ı ˇcten´ı kan´alu fyzick´eho zaˇr´ızen´ı do vyrovn´avac´ı pamˇeti. Zpr´ava im-plementuje vol´an´ıstart() a vrac´ı 32 bitov´e cel´e ˇc´ıslo s log. 1 v pˇr´ıpadˇe ´uspˇechu nebo z´aporn´e ˇc´ıslo pˇredstavuj´ıc´ı chybov´y k´od tˇr´ıdy IOChannel. Implementace tohoto vol´an´ı je z´avisla na pouˇzit´e platformˇe a ovladaˇci fyzicky pˇripojen´eho zaˇr´ızen´ı.

Dotaz

DevStart ::= CallType + 0x14 { // Identifik´ator zaˇr´ızen´ı deviceID INTEGER(4), // Identifik´ator kan´alu chanID INTEGER(1) } Odpovˇed’ DevStart ::= CallType + 0x14 { // Odpovˇed’ startReturn INTEGER(4) }

Tabulka 4.11: Form´at pro dotaz a odpovˇed’ operace DevStart.

DevTerminate - ukonˇc´ı ˇcten´ı kan´alu fyzick´eho zaˇr´ızen´ı do vyrovn´avac´ı pamˇeti. Zpr´ava implementuje vol´an´ıterminate()a vrac´ı 32 bitov´e cel´e ˇc´ıslo s log. 1v pˇr´ıpadˇe ´uspˇechu nebo z´aporn´e ˇc´ıslo pˇredstavuj´ıc´ı chybov´y k´od tˇr´ıdyIOChannel. Implementace tohoto vol´an´ı je z´avisla na pouˇzit´e platformˇe a ovladaˇci fyzicky pˇripojen´eho zaˇr´ızen´ı. Operace je inverzn´ı kDevStart.

Dotaz

DevTerminate ::= CallType + 0x15 { // Identifik´ator zaˇr´ızen´ı

deviceID INTEGER(4), // Identifik´ator kan´alu chanID INTEGER(1) } Odpovˇed’ DevTerminate ::= CallType + 0x15 { // Odpovˇed’ terminateReturn INTEGER(4) }

(24)

DevFlush - vypr´azdn´ı vyrovn´avac´ı pamˇet’ ovladaˇce fyzick´eho zaˇr´ızen´ı. Tento typ zpr´avy implementuje vol´an´ıflush()a v´ysledkem je 32 bitov´e cel´e ˇc´ıslo slog. 1v pˇr´ıpadˇe ´uspˇechu nebo z´aporn´e ˇc´ıslo pˇredstavuj´ıc´ı chybov´y k´od tˇr´ıdy IOChannel.

Dotaz

DevFlush ::= CallType + 0x05 { // Identifik´ator zaˇr´ızen´ı deviceID INTEGER(4), // Identifik´ator kan´alu chanID INTEGER(1),

// Pˇr´ıznaky pro vyrovn´avac´ı pamˇet’ flags INTEGER(4) } Odpovˇed’ DevFlush ::= CallType + 0x05 { // Odpovˇed’ flushReturn INTEGER(4) }

Tabulka 4.13: Form´at pro dotaz a odpovˇed’ operace DevFlush.

DevSetBaudRate - nastav´ı pˇrenosovou rychlost komunikaˇcn´ıho kan´alu. Tento typ zpr´avy implementuje vol´an´ısetBaudRate()a v´ysledkem je 32 bitov´e cel´e ˇc´ıslo s log. 1v pˇr´ıpadˇe ´

uspˇechu nebo z´aporn´e ˇc´ıslo pˇredstavuj´ıc´ı chybov´y k´od tˇr´ıdyIOChannel. Dotaz

DevSetBaudRate ::= CallType + 0x06 { // Identifik´ator zaˇr´ızen´ı

deviceID INTEGER(4), // Identifik´ator kan´alu chanID INTEGER(1),

// Poˇzadovan´a pˇrenosov´a rychlost rate INTEGER(4) } Odpovˇed’ DevSetBaudRate ::= CallType + 0x06 { // Odpovˇed’ baudRateReturn INTEGER(4) }

(25)

DevConfigure - operace nastav´ı parametry pro s´eriovou linku. Zpr´ava implementuje vol´an´ıconfigure(). Jej´ım v´ysledkem je 32 bitov´e cel´e ˇc´ıslo s log. 1 v pˇr´ıpadˇe ´uspˇechu nebo z´aporn´e ˇc´ıslo pˇredstavuj´ıc´ı chybov´y k´od tˇr´ıdy IOChannel.

Dotaz

DevConfigure ::= CallType + 0x07 { // Identifik´ator zaˇr´ızen´ı

deviceID INTEGER(4), // Identifik´ator kan´alu chanID INTEGER(1),

// Poˇcet bit˚u na jeden znak bits INTEGER(4),

// Poˇcet stop bit˚u za kaˇzd´ym znakem stopBits INTEGER(4), // Parita parity INTEGER(4) } Odpovˇed’ DevConfigure ::= CallType + 0x07 { // Odpovˇed’ configureReturn INTEGER(4) }

Tabulka 4.15: Form´at pro dotaz a odpovˇed’ operace DevConfigure.

DevSetMode - nastaven´ı m´odu komunikace se s´eriov´ym zaˇr´ızen´ım. Mimo s´eriovou komu-nikaci lze pˇr´ımo ˇc´ıst hodnoty jednotliv´ych pin˚u. Zpr´ava implementuje vol´an´ısetMode(). Jej´ım v´ysledkem je 32 bitov´e cel´e ˇc´ıslo s log. 1 v pˇr´ıpadˇe ´uspˇechu nebo z´aporn´e ˇc´ıslo pˇredstavuj´ıc´ı chybov´y k´od tˇr´ıdyIOChannel.

Dotaz

DevSetMode ::= CallType + 0x08 { // Identifik´ator zaˇr´ızen´ı deviceID INTEGER(4), // Identifik´ator kan´alu chanID INTEGER(1), // Maska

mask INTEGER(1),

// M´od operace se zaˇr´ızen´ım mode INTEGER(4) } Odpovˇed’ DevSetMode ::= CallType + 0x08 { // Odpovˇed’ setModeReturn INTEGER(4) }

(26)

DevSetDtr - nastaven´ı ˇr´ızen´ı toku dat zp˚usobem DTR/DSR6. Zpr´ava implementuje

vol´an´ısetDtr(). Jej´ım v´ysledkem je 32 bitov´e cel´e ˇc´ıslo s log. 1v pˇr´ıpadˇe ´uspˇechu nebo z´aporn´e ˇc´ıslo pˇredstavuj´ıc´ı chybov´y k´od tˇr´ıdyIOChannel. V pˇr´ıpadˇe platformy FITkit do-jde deaktivac´ı obou linek ˇr´ızen´ı toku dat a n´aslednou reaktivac´ı k resetu mikrokontroleru.

Dotaz

DevSetMode ::= CallType + 0x09 { // Identifik´ator zaˇr´ızen´ı deviceID INTEGER(4), // Identifik´ator kan´alu chanID INTEGER(1), // Volba state INTEGER(1) } Odpovˇed’ DevSetMode ::= CallType + 0x09 { // Odpovˇed’ setDtrReturn INTEGER(4) }

Tabulka 4.17: Form´at pro dotaz a odpovˇed’ operace DevSetDtr.

DevSetRts - nastaven´ıˇr´ızen´ı toku dat zp˚usobem RTS/CTS7. Zpr´ava implementuje vol´an´ı

setRts(). Jej´ım v´ysledkem je 32 bitov´e cel´e ˇc´ıslo slog. 1v pˇr´ıpadˇe ´uspˇechu nebo z´aporn´e ˇ

c´ıslo pˇredstavuj´ıc´ı chybov´y k´od tˇr´ıdy IOChannel. Dotaz

DevSetRts ::= CallType + 0x10 { // Identifik´ator zaˇr´ızen´ı deviceID INTEGER(4), // Identifik´ator kan´alu chanID INTEGER(1), // Volba state INTEGER(1) } Odpovˇed’ DevSetRts ::= CallType + 0x10 { // Odpovˇed’ setDtrReturn INTEGER(4) }

Tabulka 4.18: Form´at pro dotaz a odpovˇed’ operace DevSetRts.

6

Data Terminal Ready / Data Set Ready - metoda hardwarov´eho ˇr´ızen´ı toku dat u RS232

7

(27)

DevRead - ˇcten´ı dan´eho poˇctu znak˚u z komunikaˇcn´ıho kan´alu. Zpr´ava implementuje vol´an´ıread(). Operace vrac´ı 32 bitov´e cel´e ˇc´ıslo s poˇctem pˇreˇcten´ych znak˚u v pˇr´ıpadˇe ´

uspˇechu nebo z´aporn´e ˇc´ıslo pˇredstavuj´ıc´ı chybov´y k´od tˇr´ıdy IOChannel. Zadan´y ˇcasov´y limit pro operaci nezohledˇnuje s´ıt’ovou latenci, absolutn´ı pˇresnost tedy nen´ı zaruˇcena.

Dotaz

DevRead ::= CallType + 0x11 { // Identifik´ator zaˇr´ızen´ı deviceID INTEGER(4), // Identifik´ator kan´alu chanID INTEGER(1),

// Poˇzadovan´y poˇcet znak˚u k pˇreˇcten´ı count INTEGER(4),

// ˇCasov´y limit na operaci timeout INTEGER(4)

}

Odpovˇed’

DevRead ::= CallType + 0x11 { // Poˇcet pˇreˇcten´ych znak˚u readBytes INTEGER(4), // Pˇreˇcten´a data data OCTET STRING }

Tabulka 4.19: Form´at pro dotaz a odpovˇed’ operace DevRead.

DevReadSome - ˇcten´ı znak˚u vyrovn´avac´ı pamˇeti s ˇcasov´ym limitem. Zpr´ava implemen-tuje vol´an´ıreadsome(). Operace vrac´ı 32 bitov´e cel´e ˇc´ıslo s poˇctem pˇreˇcten´ych znak˚u v pˇr´ıpadˇe ´uspˇechu nebo z´aporn´e ˇc´ıslo pˇredstavuj´ıc´ı chybov´y k´od tˇr´ıdy IOChannel. Zadan´y ˇ

casov´y limit pro operaci nezohledˇnuje s´ıt’ovou latenci, absolutn´ı pˇresnost tedy nen´ı zaruˇcena. Form´at zpr´avy je obdobn´y s operac´ıDevRead.

DevWrite - z´apis dan´eho poˇctu znak˚u na komunikaˇcn´ı kan´al. Zpr´ava implementuje vol´an´ı

write(). Operace vrac´ı 32 bitov´e cel´e ˇc´ıslo, kter´e ud´av´a poˇcet zapsan´ych znak˚u v pˇr´ıpadˇe ´

uspˇechu nebo z´aporn´e ˇc´ıslo pˇredstavuj´ıc´ı chybov´y k´od tˇr´ıdyIOChannel. Dotaz

DevWrite ::= CallType + 0x13 { // Identifik´ator zaˇr´ızen´ı deviceID INTEGER(4), // Identifik´ator kan´alu chanID INTEGER(1),

// Poˇzadovan´y poˇcet znak˚u k pˇreˇcten´ı count INTEGER(4),

// Data pro z´apis data OCTET STRING }

Odpovˇed’

DevWrite ::= CallType + 0x13 { // Poˇcet zapsan´ych znak˚u writtenBytes INTEGER(4) }

(28)

Implementace sluˇzby sd´ılen´ı fyzick´ych zaˇr´ızen´ı

Sluˇzba sd´ılen´ı fyzick´ych zaˇr´ızen´ı implementuje obsluhu poˇzadavk˚u vzd´alen´ych virtu´aln´ıch zaˇr´ızen´ı a pˇrekl´ad´a pˇr´ıchoz´ı poˇzadavky na operace nad fyzicky pˇripojen´ymi zaˇr´ızen´ımi. Z´aroveˇn je tˇreba sledovat stav pˇripojen´ych uzl˚u a jejich vazby na fyzicky pˇripojen´a zaˇr´ızen´ı. Pokud totiˇz dojde k pˇreruˇsen´ı spojen´ı, je nutn´e uvolnit vˇsechna zaˇr´ızen´ı obsazen´a dan´ym uzlem a uvolnit syst´emov´e prostˇredky. Pro s´ıt’ovou komunikaci je vyuˇzita platformovˇe nez´avisl´a knihovna pˇredstaven´a v sekci 4.2. Tato knihovna byla rozˇs´ıˇrena pro potˇreby implementace TCP serveru schopn´eho obsluhovat v´ıce spojen´ı v r´amci jednoho vl´akna s virtu´aln´ım rozhran´ım pro obsluhu pˇr´ıchoz´ıch dat.

V´ysledkem tˇr´ıdaIPServiceschopn´a autonomn´ıho bˇehu ve vlastn´ım vl´aknˇe. Pro imple-mentaci platformovˇe nez´avisl´ych vl´aken byla pouˇzita knihovna QtCore verze 4, kter´a po-skytuje objektovˇe orientovanou implementaci vl´aken v jazyce C++. Sluˇzba zpracov´av´a jak poˇzadavky spr´avce virtu´aln´ıch zaˇr´ızen´ıIPBackend, tak pˇr´ımou komunikaci mezi virtu´aln´ım a fyzick´ym zaˇr´ızen´ım.

4.6

Sd´ılen´ı zaˇ

r´ızen´ı v programu QDevKit

Prvotn´ı motivac´ı k m´e pr´aci bylo zpˇr´ıstupnit zaˇr´ızen´ı v r´amci lok´aln´ı s´ıtˇe, k tomu ´uˇcely byla navrˇzena a implementov´ana podpora pro virtu´aln´ı zaˇr´ızen´ı v knihovnˇe libkitclient a sluˇzba automaticky vyhled´avaj´ıc´ı zaˇr´ızen´ı v m´ıstn´ı s´ıti. Posledn´ı logickou ˇc´ast´ı bylo zpˇr´ıstupnit nov´e funkce uˇzivatel˚um softwarov´eho vybaven´ı platformy FITkit ve formˇe grafick´eho roz-hran´ı. Toho bylo dosaˇzeno rozˇs´ıˇren´ım grafick´e termin´alov´e aplikace QDevKit (obr´azek 4.7) o n´asleduj´ıc´ı funkce:

• Rozliˇsov´an´ı virtu´aln´ıch a fyzicky pˇripojen´ych zaˇr´ızen´ı.

• Moˇznost sd´ılet zaˇr´ızen´ı v m´ıstn´ı s´ıti.

• Zap´ınat a vyp´ınat funkci automatick´eho vyhled´av´an´ı zaˇr´ızen´ı v s´ıti.

(29)

Virtu´aln´ı zaˇr´ızen´ı jsou v aplikaci QDevKit odliˇsena od fyzick´ych transparentn´ı iko-nou. Takov´a zaˇr´ızen´ı nelze d´ale sd´ılet, jinak je moˇzn´e s nimi pracovat stejn´ym zp˚usobem jako s fyzick´ymi. Jsou z´aroveˇn podporovan´e i z´asuvn´ym modulem FKFlash a lze je tedy bˇeˇzn´ym zp˚usobem programovat. Sd´ılen´a zaˇr´ızen´ı nav´ıc obsahuj´ıc´ı znaˇcku symbolizuj´ıc´ı sd´ılen´ı. Pˇrehled pˇripojen´ych zaˇr´ızen´ı je pro vˇetˇs´ı pˇrehlednost rozdˇelen (obr´azek 4.7) do tˇr´ı kategori´ı :

• Zaˇr´ızen´ı pˇripojen´a ke sbˇernici USB (1), jedn´a se o fyzicky pˇripojen´a zaˇr´ızen´ı, kter´e mohou b´yt bez omezen´ı sd´ılena pro vzd´alen´e pouˇzit´ı.

• Zaˇr´ızen´ı automaticky nalezen´a v m´ıstn´ı s´ıti (2), nalezen´e pomoc´ı protokolu pro au-tomatick´e vyhled´av´an´ı, tato zaˇr´ızen´ı nelze d´ale sd´ılet.

• Pˇr´ımo pˇripojen´a zaˇr´ızen´ı v s´ıti (3) - tato zaˇr´ızen´ı jsou nalezena na sbˇernici USB a mohou b´yt d´ale sd´ılena.

(30)

4.7

Podpora virtualizace v QDevKit

Platforma FITkit poskytuje ˇsirok´e spektrum perifern´ıch zaˇr´ızen´ı, kter´e je moˇzn´e vyuˇz´ıt. Jedn´a se pˇredevˇs´ım o displej, kl´avesnici a ˇradu port˚u dostupn´ych v aplikac´ıch vyuˇz´ıvaj´ıc´ıch mikrokontroler MSP430 nebo programovateln´e hradlov´e pole Xilinx Spartan 3. Z toho vypl´yv´a omezen´ı pr´ace na vzd´alen´em zaˇr´ızen´ı, kter´e nem´a uˇzivatel fyzicky v dosahu. Tento probl´em ˇc´asteˇcnˇe ˇreˇs´ı z´asuvn´y modul do aplikace QDevKit, kter´y jsem implementoval spolu s Ing. Zdeˇnkem Vaˇs´ıˇckem a umoˇzˇnuje v re´aln´em ˇcase zobrazovat stav displeje a pˇren´aˇset stisky virtu´aln´ı kl´avesnice. Toho bylo dosaˇzeno implementac´ı komunikaˇcn´ıho protokolu v FPGA.

D´ıky tomu, ˇze s´eriov´y pˇrevodn´ık FTDI 2232C poskytuje dva s´eriov´e kan´aly, bylo moˇzn´e voln´y kan´alAvyuˇz´ıt pro komunikaci mezi z´asuvn´ym modulem a zaˇr´ızen´ım. Z´asuvn´y modul si tak periodicky m˚uˇze zjiˇst’ovat stav displej a dalˇs´ıch perifer´ı a zobrazovat jej v re´aln´em ˇ

case pˇr´ımo v oknˇe aplikace.

Obsluha komunikaˇcn´ıho kan´alu bˇeˇz´ı ve zvl´aˇstn´ım vl´aknˇe, aby nedoch´azelo z ovlivnˇen´ı plynulosti aplikace a pro vykreslov´an´ı se vyuˇz´ıv´a standardn´ı smyˇcka ud´alost´ı knihovny Qt. To vypl´yv´a z omezen´ı knihovny Qt vykreslovat uˇzivatelsk´e rozhran´ı pouze v hlavn´ım vl´aknˇe aplikace.

Z´asuvn´y modul je naps´an v jazyce C++ a je dostupn´y bez dalˇs´ıch ´uprav jako rozˇs´ıˇren´ı aplikace QDevKit (obr´azek4.8).

(31)

Kapitola 5

Vzd´

alen´

y pˇ

reklad

Motivac´ı pro virtualizaci pˇrekladov´eho prostˇred´ı pro moˇznost pˇrekl´adat aplikace bez nut-nosti instalovat n´astroje pro pˇreklad. D´ıky tomu je moˇzn´e napˇr. pracovat s FITkitem z veˇrejn´eho poˇc´ıtaˇce bez nutnosti instalace n´astroj˚u pro pˇreklad a sloˇzit´eho licencov´an´ı. Kaˇzd´a aplikace pro platformu FITkit se zpravidla sest´av´a ze dvou ˇc´ast´ı, pˇriˇcemˇz obˇe vyˇzaduj´ı spe-cifick´e n´astroje na pˇreklad.

Aplikace pro mikrokontroler napsan´a v jazyce C nebo jazyce symbolick´ych instrukc´ı pro rodinu MSP430 firmy Texas Instruments je souˇc´ast´ı vˇetˇsiny aplikac´ı. Zajiˇst’uje pˇredevˇs´ım komunikaci s termin´alov´ym programem a ˇr´ızen´ı programu. Pro pˇreklad do strojov´eho k´odu je pouˇzit volnˇe dostupn´y pˇrekladaˇc MSP GCC zaloˇzen´y na open-source pˇrekladaˇc´ı GCC.

Konfiguraˇcn´ı ˇretˇezec pro FPGA Spartan 3 pˇredstavuje druhou ˇc´ast aplikace. Ten je pˇr´ıpadˇe platformy FITkit zpravidla popsan´y jazykem VHDL a pro pˇreklad se vyuˇz´ıv´a v´yvojov´eho prostˇred´ı Xilinx ISE, kter´e obsahuje mimo pˇrekladaˇc tak´e simul´ator a mnoho dalˇs´ıch podp˚urn´ych aplikac´ı.

Pˇrekladaˇc MSP GCC i v´yvojov´e prostˇred´ı Xilinx ISE jsou podporov´any na platform´ach Microsoft Windows i GNU/Linux. Z´aporem je vˇsak pomˇernˇe sloˇzit´a instalace a pˇredevˇs´ım n´aroˇcnost n´astroj˚u na prostor na pevn´em disku stanice, pˇredevˇs´ım v pˇr´ıpadˇe prostˇred´ı prostˇred´ı Xilinx ISE. Z tˇechto d˚uvod˚u jsem v r´amci pr´ace navrhnul a implementoval pod-poru pro vzd´alen´y pˇreklad aplikac´ı pro platformu FITkit bez nutnosti instalace n´astroj˚u pro pˇreklad.

5.1

Komunikace s pˇ

rekladov´

ym serverem

Pˇrekladov´y server byl navrˇzen tak, aby bylo moˇzn´e pˇrekl´adat jak vzd´alenˇe, tak lok´alnˇe po pˇripojen´ı na vzd´alen´y termin´al. Z d˚uvodu zabezpeˇcen´ı kompatibiln´ı s existuj´ıc´ım syst´emem uˇzivatelsk´ych ´uˇctu je pro autentizaci i bezpeˇcnou komunikaci zvolen protokol Secure Shell verze 2(d´ale SSHv2)[15], jehoˇz podmnoˇzinu implementuje platformovˇe nez´avisl´a knihovna libssh. D´ıky pouˇzit´ı protokolu SSHv2 je moˇzn´e vyuˇz´ıt st´avaj´ıc´ı syst´em uˇzivatelsk´ych ´uˇct˚u pro pˇrihlaˇsov´an´ı na servery FIT VUT. Knihovna nab´ız´ı v´ıce moˇznost´ı autentizace, z nichˇz jsem v pr´aci implementoval dvˇe nejpouˇz´ıvanˇejˇs´ı.

(32)

Autentizace heslem

Hlavn´ı pˇrednost autentizace heslem je fakt, ˇze nen´ı tˇreba ukl´adat kryptografick´e tajemstv´ı na pevn´y disk a je tedy tedy odoln´a v˚uˇci ztr´atˇe ˇci kr´adeˇzi dat. Je tedy vhodn´a zejm´ena na sd´ılen´e poˇc´ıtaˇce, pˇrenosn´a zaˇr´ızen´ı nebo volnˇe dostupn´e stanice. Urˇcitou nev´yhodou je nepohodl´ı vypl´yvaj´ıc´ı z nutnosti pˇri kaˇzd´em pˇrihl´aˇsen´ı vyplnit heslo a tak´e nebezpeˇc´ı odez´ır´an´ı nebo zaznamen´avan´ı stisk˚u kl´aves. V m´e pr´aci je to ˇc´asteˇcnˇe ˇreˇseno sd´ılen´ım jednoho pˇripojen´ı pro komunikaci se serverem pro pˇreklad za celou dobu bˇehu programu. Heslo je tedy nutn´e zadat pouze pˇri prvn´ım pˇripojen´ı a nikoliv pro kaˇzd´y pˇreklad zvl´aˇst’. V terminologii SSHv2 se jedn´a o typy autentizace password[15].

Autentizace veˇrejn´ym kl´ıˇcem

Autentizace veˇrejn´ym kl´ıˇcem je zaloˇzena na principu asymetrick´e kryptografie, kde existuje soukrom´y kl´ıˇcAurˇcen´y pro ˇsifrov´an´ı a veˇrejn´y kl´ıˇcB, urˇcen´y pro deˇsifrov´an´ı. Klient zpra-vidla zaˇsifruje tajemstv´ı sv´ym soukrom´ym kl´ıˇcem a zaˇsle jej serveru. Ten si jednoduˇse ovˇeˇr´ı tajemstv´ı tak, ˇze se jej pokus´ı rozˇsifrovat veˇrejn´ym kl´ıˇcem a tak ovˇeˇrit p´arovost soukrom´eho a veˇrejn´eho kl´ıˇce. Pro tuto metodu autentizace je bˇeˇznˇe pouˇzito ˇsifrov´an´ı DSA nebo RSA o d´elce kl´ıˇce v ˇr´adu 1024 - 8192B. Hlavn´ı v´yhodou zp˚usobu autentizace je pohodlnost a a odolnost v˚uˇci odez´ır´an´ı nebo zaznamen´av´an´ı stisk˚u kl´aves. Nev´yhodou je potom nutnost ukl´adat tajemstv´ı (kl´ıˇcA) na pevn´y disk stanice, kde se m˚uˇze st´at pˇredmˇetem kr´adeˇze dat. V terminologii SSHv2 se jedn´a o typ autentizacepubkey[15].

Vzhledem k tomu, ˇze kaˇzd´a autentizaˇcn´ı metoda m´a sv´e v´yhody i nev´yhody, rozhodl jsem se implementovat jak autentizaci heslem, tak veˇrejn´ym kl´ıˇcem. Obˇe volby jsou do-stupn´e v aplikaci QDevKit (obr´azek 5.1) a je moˇzn´e je mˇenit.

(33)

Virtualizace prostˇred´ı pro pˇreklad aplikac´ı

Pˇri spuˇstˇen´ı aplikace QDevKit s nastaven´ym pˇripojen´ım k pˇrekladov´emu serveru dojde k vytvoˇren´ı spojen´ı na z´akladˇe n´ami zvolen´e metody autentizace. Protokol pro komuni-kaci s pˇrekladov´ym serverem se sest´av´a s posloupnosti pˇr´ıkaz˚u v jazyce SH a pˇren´aˇsen´ı soubor˚u pomoc´ı protokolu SFTP, spojen´ı lze tedy povaˇzovat za neinteraktivn´ı termin´al. Bˇehem ˇzivotn´ıho cyklu jednoho spojen´ı tak vznik´a N kontext˚u pro vykon´av´an´ı pˇr´ıkaz˚u nebo pˇrenos soubor˚u. Protokol je implementov´an v knihovnˇe libfcmake, je tedy moˇzn´e jej vyuˇz´ıt i pro vzd´alen´y pˇreklad aplikac´ı v termin´alov´e aplikaci fcmake bez nutnosti insta-lace grafick´eho prostˇred´ı. Toho je dosaˇzeno bud’ parametrem aplikace nebo generov´an´ım speci´aln´ıho Makefile. Z´aroveˇn je vˇsak moˇzn´e vyuˇz´ıt rozhran´ı knihovny pro implementaci komunikace s pˇrekladov´ym serverem v dalˇs´ıch aplikac´ıch, zejm´ena v termin´alov´e aplikaci QDevKit.

Protokol pro pr´aci s pˇrekladov´ym serverem

Samotn´y pˇrekladov´y server je implementov´an ve formˇe souboru skript˚u v jazyce SH. Pro korektn´ı funkci je nutn´e m´ıt na serveru zprovoznˇen´e prostˇred´ı pro pˇreklad aplikac´ı pro platformu FITkit, tedy zejm´ena pˇrekladaˇc MSP-GCC a v´yvojov´e prostˇred´ı Xilinx ISE. Samotn´y pˇreklad aplikace se sest´av´a z v´ıce nez´avisl´ych krok˚u (obr´azek 5.2).

Inicializace adresáře pro překlad Překlad Odstranění adresáře pro překlad Klient aktualizace prostředí pro překlad přenos souborů

přenos výsledku překladu

(34)

Inicializace adres´aˇre pro pˇreklad aplikace je prvn´ım krokem, kdy je pro kaˇzd´eho uˇzivatele vygenerov´an adres´aˇr pro pˇreklad v adres´aˇri pro doˇcasn´e soubory. Souˇcasnˇe je aktu-alizov´an aktu´aln´ı strom aplikac´ı platformy FITkit a nastaveno prostˇred´ı pro pˇreklad aplikace. Tento krok obstar´av´a skript bserver-prepare a jeho v´ystupem je cesta k adres´aˇri pro pˇreklad. Ta se zkl´ad´a z cesty k adres´aˇri pro doˇcasn´e soubory, uˇzivatelsk´e jm´ena a n´ahodn´eho ˇc´ısla. To je nutn´e pˇredevˇs´ım proto, aby mohlo prob´ıhat v´ıce paraleln´ıch pˇreklad˚u pro jednoho uˇzivatele.

N´ahodn´a ˇc´ısla adres´aˇr˚u jsou generov´ana tak dlouho, dokud se nenajde prvn´ı neobsa-zen´e ˇc´ıslo. Pˇr´ıklad takov´e cesty je napˇr. /tmp/xvavru00/build.12345.

Aktualizace soubor˚u potˇrebn´ych pro pˇreklad aplikac´ı je druh´y krokem. V pˇr´ıpadˇe pr´ace pˇr´ımo na pˇrekladov´em serveru je nutn´e do pˇripraven´eho adres´aˇre nahr´at vˇsechny potˇrebn´e soubory. Pokud pˇreklad prob´ıh´a vzd´alenˇe za pomoc´ı aplikace fcmake nebo QDevKit, tak se o vyhled´an´ı a pˇrenos vˇsech potˇrebn´ych soubor˚u star´a aplikace. D´ıky pˇrechodu pˇrekladov´eho syst´emu aplikac´ı platformy FITkit na form´at XML, je moˇzn´e v r´amci knihovny libkitclient sestavit strom z´avislost´ı a pˇren´aˇset tak pouze potˇrebn´e soubory pomoc´ı protokolu SFTP.

Pˇreklad aplikace prob´ıh´a pomoc´ı skriptubserver-make, kter´y m´a za ´ukol nastavit prostˇred´ı a zavolat nainstalovan´e n´astroje pro pˇreklad. V tomto okamˇziku prob´ıh´a pˇreklad stejn´ym zp˚usobem, jako v pˇr´ıpadˇe pˇrekladu na lok´aln´ım poˇc´ıtaˇci. Vzd´alen´y pˇreklad v r´amci aplikac´ı fcmake a QDevKit zachyt´av´a v´ystup termin´alu v re´aln´em ˇcase a interpretuje jej uˇzivateli. Po skonˇcen´ı skriptu je propagov´an n´avratov´y k´od aplikace stejn´ym zp˚usobem jako v pˇr´ıpadˇe pˇrekladu na lok´aln´ım poˇc´ıtaˇci.

Zpracov´an´ı pˇreloˇzen´e aplikace pˇredstavuje posledn´ı krok pˇrekladu. V pˇr´ıpadˇe ´uspˇechu je nutn´e pˇren´est zpˇet v´ysledek pˇrekladu pomoc´ı protokolu SFTP a pot´e smazat ad-res´aˇr pro pˇreklad aplikace. Pokud uˇzivatel pˇrekl´ad´a aplikaci pˇr´ımo na vzd´alen´em ser-veru bez vyuˇzit´ı aplikac´ı fcmake a QDevKit, je doporuˇceno po ukonˇcen´ı pr´ace smazat pouˇzit´e adres´aˇre pro pˇreklad.

Vzd´alen´y pˇreklad v aplikaci fcmake

Pˇrev´aˇzn´a ˇc´ast komunikace s pˇrekladov´ym serverem je implementov´ana v r´amci sd´ılen´e knihovnylibfcmake. Kl´ıˇc pro autentizaci je realizov´an tˇr´ıdou Keya jejich spr´avu obstar´av´a tˇr´ıda KeyChain. Metoda autentizace heslem nevyˇzaduje ˇz´adnou dalˇs´ı implementaci. Sa-motn´e ˇr´ızen´ı spojen´ı se serverem je implementov´ano tˇr´ıdou Remote a zajiˇst’uje pˇredevˇs´ım autentizaci metodou zad´an´ı hesla nebo veˇrejn´ym kl´ıˇcem. P´ar kl´ıˇc˚u je generov´an na stranˇe serveru vzhledem k tomu, ˇze je vyˇzadov´an bˇeh knihovny libfcmake na v´ıce platform´ach a knihovna libssh tuto funkcionalitu neposkytuje. Z´aroveˇn je poskytov´ano rozhran´ı pro obousmˇern´y pˇrenos soubor˚u pomoc´ı protokolu SFTP a moˇznost vykon´avat vzd´alenˇe pˇr´ıkazy ve formˇe neinteraktivn´ıho termin´alu. Toho je vyuˇzito pro funkce pro pˇr´ıpravu pˇrekladov´eho adres´aˇre a samotn´e funkce pro pˇreklad.

Samotn´a aplikace fcmake umoˇzˇnuje jak vytvoˇrit Makefile pro vzd´alen´y pˇreklad pomoc´ı parametru --remote. Alternativnˇe lze pouˇz´ıt parametr --remote-build a vykonat tak samotn´y vzd´alen´y pˇreklad pˇr´ımo v aplikaci fcmake bez nutnosti generovatMakefile. Form´at pˇr´ıkazu je n´asleduj´ıc´ı:fcmake -r xlogin00@server.

Adresa pˇrekladov´eho serveru mus´ı b´yt dosaˇziteln´a (nevytv´aˇr´ı se tunel jako v pˇr´ıpadˇe spojen´ı z aplikace QDevKit).

(35)

5.2

Tunelov´

an´ı spojen´ı na pˇ

rekladov´

y server

Pro ´uˇcely pˇrekladov´eho serveru n´am byla poskytnuta stanice vyhrazen´a pro vzd´alen´y pˇreklad aplikac´ı pro platformu FITkit. Stanice je d´ıky osazen´ı procesory Intel Xeon E5640 a 48GB operaˇcn´ı pamˇeti dostateˇcnˇe dimenzov´ana pro obsluhu paralelnˇe bˇeˇz´ıc´ıch ˇz´adost´ı o pˇreklad aplikac´ı, pˇredevˇs´ım na n´aroˇcnou synt´ezu konfiguraˇcn´ıho ˇretˇezce pro programovateln´e hradlov´e pole. Dostupnost stanice je vˇsak omezen´a pouze v r´amci s´ıt’ VUT. Z toho d˚uvodu bylo nutn´e nav´ıc implementovat syst´em tunelov´an´ı spojen´ı pˇres veˇrejnˇe dostupn´y server v s´ıti VUT a zajistit tak funkˇcnost vzd´alen´eho pˇrekladu i pro uˇzivatele mimo tuto s´ıt’. Protoˇze protokol Secure Shell implementuje i moˇznost tunelov´an´ı port˚u[15], rozhodl jsem se vyuˇz´ıt st´avaj´ıc´ı knihovnylibssh k implementaci platformovˇe nez´avisl´e sluˇzby pro s´ıt’ov´e tunelov´an´ı.

S´ıt’ov´e tunelov´an´ı v protokolu Secure Shell

S´ıt’ov´e tunelov´an´ı je metoda zapouzdˇren´ı p˚uvodn´ıho s´ıt’ov´eho protokolu jin´ym. Je moˇzn´e jej implementovat jak na linkov´e ´urovni modelu ISO/OSI, kde je typick´ym pˇredstavitelem protokol Layer 2 Tunneling Protocol(L2TP), tak pro potˇreby m´e pr´ace zaj´ımavˇejˇs´ı aplikaˇcn´ı vrstvˇe. S´ıt’ov´e tunelov´an´ı popsan´e protokolem Secure Shell je pro potˇreby m´e pr´ace zaj´ımav´e hned z nˇekolika hledisek.

Klient

Zprostředkovatel

port: 22 port: 80 Server

Obr´azek 5.3: Pˇr´ıklad tunelov´an´ı spojen´ı protokolu HTTP pˇres prostˇredn´ıka.

V´yhoda spoleˇcn´a pro jak´ykoliv protokol s´ıt’ov´eho tunelov´an´ı je obch´azet omezen´ı ak-tivn´ıch s´ıt’ov´ych prvk˚u. D´ıky t´eto vlastnosti je moˇzn´e napˇr. tunelovat jinak blokovan´y pro-tokol HTTP pˇres vzd´alen´y server (obr´azek 5.3). Konkr´etn´ım vyuˇzit´ım pro mou pr´aci je tunelov´an´ı spojen´ı protokolu Secure Shell na pˇrekladov´y server pˇres veˇrejnˇe dostupn´y ser-ver v s´ıti VUT (obr´azek5.4).

(36)

Druhou vlastnost´ı s´ıt’ov´eho tunelov´an´ı v protokolu Secure Shell je pˇrirozenˇe ˇsifrovan´y pˇrenos. Veˇsker´a komunikace je tedy pˇren´aˇsena po bezpeˇcn´em kan´alu, toho je vyuˇzito pro moˇznost tunelovat dalˇs´ı spojen´ı. Zabezpeˇcen´ı pˇrenosov´eho kan´alu je vyuˇzito pro moˇznost tunelov´an´ı spojen´ı k serveru poskytuj´ıc´ımu licence pro simulaˇcn´ı prostˇred´ı ModelSim.

Klient

merlin.fit.vutbr.cz

port: 22 port: 22

fitkit-build.fit.vutbr.cz

Obr´azek 5.4: Tunelov´an´ı spojen´ı na pˇrekladov´y server pˇres merlin.fit.vutbr.cz

Popsanou metodu s´ıt’ov´eho tunelov´an´ı je moˇzn´e popsat i jako formu pˇresmˇerov´an´ı port˚u. Pˇredstavuje tedy virtu´aln´ı spojen´ı mezi dvˇema s´ıt’ov´ymi prvky, mezi nimiˇz funguje jeden jako prostˇredn´ık umoˇzˇnuj´ıc´ı jejich propojen´ı. C´ılov´y s´ıt’ov´y prvek mus´ı b´yt pro prostˇredn´ıka pˇr´ımo dosaˇziteln´y, v pˇr´ıpadˇe takov´e situace je moˇzn´e s´ıt’ov´e tunely ˇretˇezit. Komunikace mezi nimi prob´ıh´a zabezpeˇcenˇe, v r´amci jednoho kan´alu spojen´ı protokolu SSHv2.

Implementace vzd´alen´eho pˇrekladu v aplikaci QDevKit

Aplikaci QDevKit jsem rozˇs´ıˇril o sluˇzbu implementuj´ıc´ı s´ıt’ov´e tunelov´an´ı za pomoc´ı knihovny libssh. Protoˇze se jedn´a o aplikaˇcn´ı vrstvu, je nutn´e neust´ale obsluhovat s´ıt’ov´y provoz na vytvoˇren´ych spojen´ıch a sledovat nov´e poˇzadavky o pˇripojen´ı. Z´aroveˇn je nutn´e zajistit aby obsluha prob´ıhaj´ıc´ıch spojen´ı neblokovala hlavn´ı smyˇcku ud´alost´ı knihovny Qt a ne-doch´azelo tak ke zpomalov´an´ı aplikace. Toho bylo dosaˇzeno v´ıcevl´aknovou implementac´ı obsluhy prob´ıhaj´ıc´ıch spojen´ı. Pro kaˇzd´y vytvoˇren´y s´ıt’ov´y tunel je vytvoˇrena instance tˇr´ıdy

TunnelService, kter´a vyuˇz´ıv´a vlastnosti tˇr´ıdyQTcpServer asynchronn´ım zp˚usobem zpra-cov´avat pˇr´ıchoz´ı spojen´ı. Pro kaˇzd´e vytvoˇren´e spojen´ı je pak spuˇstˇena obsluha ve zvl´aˇstn´ım vl´aknˇe.

Sluˇzba pro s´ıt’ov´e tunelov´an´ı rozliˇsuje tunel k pˇrekladov´emu serveru a ostatn´ı voliteln´e tunely. Ty jsou vyuˇzity pˇredevˇs´ım k tunelov´an´ı spojen´ı k licenˇcn´ımu serveru. Protoˇze se seznam port˚u m˚uˇze kdykoliv zmˇenit, je moˇzn´e je konfigurovat formou seznamu tunelovan´ych port˚u. Ty je moˇzn´e zmˇenit v nastaven´ı aplikace QDevKit na kartˇe S´ıt’. Z´aroveˇn je moˇzn´e je aktualizovat automaticky formou z´asuvn´ych modul˚u v jazyce Python i C++.

References

Related documents

Pervious pavement systems consist of a permeable pavement surface layer and one or more underlying aggregate layers designed to temporarily store stormwater.. Most pervious

BEYOND BUSINESS: CORPORATE SOCIAL RESPONSIBILITY (CSR) AMONG SMALL BUSINESSES IN JELUTONG MARKET,

Accordingly, the research problem tackled in this thesis is that learners from previously disadvantaged black schools in Cape Town lack knowledge of hospitality

We are interested in estimating the causal effect of changes in mortality, mea- sured by infant mortality or crude death rates, on GDP per capita growth, pop- ulation growth

or information about their expertise, which is repeated mainly with Negation feedback. Social: we mean context information related to a user’s role at work, and

The long- term goal of this project is to introduce the notion of learning space and explore the role of the design of learning space context-aware ontologies with the ultimate aim

Ether- net is frequently the protocol of choice whether data is transported in a local network (LAN), over optical fibre rings in a metropolitan network (MAN) or over long