Technick´
a univerzita v Koˇ
siciach
Fakulta elektrotechniky a informatiky
RTP stream d´
at typu ˇ
casov´
ych priebehov
2012
Martin Mikula
Technick´
a univerzita v Koˇ
siciach
Fakulta elektrotechniky a informatiky
Katedra kybernetiky umelej inteligencie
RTP stream d´
at typu ˇ
casov´
ych priebehov
Bakal´
arska pr´
aca
ˇ
Studijn´
y program:
Hospod´arska infromatika
ˇ
Studijn´
y odbor:
9.2.10 Hospod´arska informatika
ˇ
Skoliace
pracovisko: Katedra kybernetiky umelej inteligencie (KKUI)
ˇ
’:
Skolitel
Koˇ
sice 2012
Ing. Rudolf Jakˇsa, PhD.
Martin Mikula
Analytick´
y list
Autor:
Martin Mikula
N´azov pr´ace:
RTP stream d´at typu ˇcasov´
ych priebehov
Jazyk pr´ace:
slovensk´
y
Typ pr´ace:
Bakal´arska pr´aca
Poˇcet str´an:
63
Akademick´
y titul:
Bakal´ar
Univerzita:
Technick´a univerzita v Koˇsiciach
Fakulta:
Fakulta elektrotechniky a informatiky (FEI)
Katedra:
Katedra kybernetiky umelej inteligencie (KKUI)
ˇ
Studijn´
y odbor:
9.2.10 Hospod´arska informatika
ˇ
Studijn´
y program:
Hospod´arska infromatika
Mesto:
Koˇsice
Ved´
uci pr´ace:
Ing. Rudolf Jakˇsa, PhD.
D´atum odovzdania:
25. 5. 2012
D´atum obhajoby:
19. 6. 2012
Kl’u
´ˇcov´e slov´a:
RTP, ˇcasov´e priebehy, stream, bakal´arska pr´aca
Kateg´oria konspekt:
V´
ypoˇctov´a technika; Poˇc´ıtaˇcov´e siete; Umel´a inteligencia
Citovanie pr´ace:
Martin Mikula: RTP stream d´at typu ˇcasov´
ych priebehov.
Bakal´arska pr´aca. Koˇsice: Technick´a univerzita v Koˇsiciach,
Fakulta elektrotechniky a informatiky. 2012. 63 s.
N´azov pr´ace v AJ:
RTP streaming for time series data
Kl’u
´ˇcov´e slov´a v AJ:
RTP, time series data, stream, bachelor
Abstrakt v SJ
T´ato bakal´arska pr´aca sa zaober´a t´emou streamovania d´at typu ˇcasov´
ych priebehov v re´alnom ˇcase pomocou RTP protokolu. V teoretickej ˇcasti sa ˇcitatel’ dozvie
ˇ sia ˇcast’ prezentuje d´ata
z´akladn´e inform´acie o RTP protokole a jeho fungovan´ı. Dalˇ
typu ˇcasov´
ych priebehov a moˇznosti ich prenosu. V z´avere sa pr´aca venuje firm´am,
ktor´e v s´
uˇcasnosti pon´
ukaj´
u stream d´at. Praktick´a ˇcast’ pr´ace sa zaober´a n´avrhom
a implement´aciou rieˇsenia na prenos d´at pomocou RTP protokolu. Posledn´a ˇcast’
predstavuje fungovanie cel´eho syst´emu a moˇznosti jeho praktick´eho pouˇzitia.
Abstrakt v AJ
This Bachelor Thesis deals with real-time data streaming using RTP protocol. In
theoretical part we focus on the basic information about RTP protocol and its
usage. The next chapter deals with real time data and the transfer possibilities.
In the end of theoretical part we focus on companies providing data streaming.
Practical part deals with data transfer proposal by using RTP protocol and with
the implementation of solution. The last chapter is focused on the whole system and
its possible practical usage.
ˇ
Cestn´
e vyhl´
asenie
Vyhlasujem, ˇze som diplomov´
u pr´acu vypracoval samostatne s pouˇzit´ım uvedenej
odbornej literat´
ury.
Koˇsice 25. 5. 2012
...........................
Vlastnoruˇcn´y podpis
Pod’akovanie
T´
ymto by som chcel pod’akovat’ ved´
ucemu a konzultantovi svojej bakal´arskej pr´ace
Ing. Rudolfovi Jakˇsovi, PhD., za cenn´e odborn´e rady, pripomienky a trpezlivost’ pri
tvorbe mojej bakal´arskej pr´ace. Mojim rodiˇcom a sestre d’akujem za trpezlivost’ a
podporu poˇcas mˆojho ˇst´
udia.
Obsah
´
Uvod
1
Formul´
acia u
´ lohy
2
1 RTP - Real-time transport protokol
3
1.1
Hist´oria RTP protokolu . . . . . . . . . . . . . . . . . . . . . . . . . .
3
1.2
S´
uˇcasti RTP protokolu . . . . . . . . . . . . . . . . . . . . . . . . . .
4
1.3
Odosielanie d´at . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.4
Tvorba RTP paketu . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.5
Fragment´acia r´amcov . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.6
Pr´ıjem d´at . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
´
2 Uvod
do prenosu d´
at typu ˇ
casov´
ych priebehov
16
2.1
Modely d´atov´
ych tokov . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.2
Firmy pon´
ukaj´
uce streamovacie sluˇzby . . . . . . . . . . . . . . . . . 17
3 N´
avrh syst´
emu pre RTP stream d´
at typu ˇ
casov´
ych priebehov
3.1
20
Celkov´a blokov´a sch´ema syst´emu pre RTP stream d´at typu ˇcasov´
ych
priebehov . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.2
N´arvh programu pre odosielanie d´at . . . . . . . . . . . . . . . . . . . 21
3.3
N´avrh programu pre prij´ımanie d´at . . . . . . . . . . . . . . . . . . . 24
3.4
Kniˇznice a hlaviˇckov´e s´
ubory potrebn´e na sfunkˇcnenie rieˇsenia . . . . 27
4 Overenie funkˇ
cnosti implementovan´
eho syst´
emu
28
4.1
N´aroˇcnost’ pouˇzitia oRTP . . . . . . . . . . . . . . . . . . . . . . . . 28
4.2
Prenos d´at . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.3
Overenie r´
ychlosti a kvality prenosu . . . . . . . . . . . . . . . . . . . 34
4.4
Porovnanie poˇctu prenesen´
ych paketov s TCP a UDP . . . . . . . . . 39
5 Z´
aver
41
FEI
KKUI
Zoznam pouˇ
zitej literat´
ury
43
Zoznam pr´ıloh
44
Pr´ıloha B
45
Pr´ıloha C
51
9
FEI
KKUI
´
Uvod
Ciel’om mojej bakal´arskej pr´ace je vyuˇzit’ moˇznosti RTP protokolu na prenos d´at
typu ˇcasov´
ych priebehov. S´
u to d´ata, ktor´e s´
u usporiadan´e podl’a ich ˇcasov´eho
v´
yskytu. Jedn´a sa o prenos, v ktorom zohr´ava dˆoleˇzit´
uu
´lohu aktu´alnot’ d´at. Pren´aˇsa
sa vel’k´e mnoˇzstvo jednoduch´
ych ˇc´ısel, ktor´e s´
u n´ahodne generovan´e v gener´atore
ˇc´ısel. Kaˇzd´e ˇc´ıslo bude pren´aˇsan´e osobitne. Na prenos bud´
u pouˇz´ıt´e programy, ktor´e
pˆovodne sl´
uˇzili na prenos zvuku. Tie bud´
u upraven´e tak, aby boli schopn´e naˇc´ıtat’
d´ata z textov´eho s´
uboru a n´asledne ich prenes´
u medzi dvoma poˇc´ıtaˇcmi. Prenos
by mal byt’ r´
ychly, ked’ˇze sa jedn´a o mal´e d´atove jednotky. Po prenose bud´
u d´ata
op¨atovne pripraven´e na d’alˇsie pouˇzitie, a to tak, ˇze bud´
u op¨atovne zap´ısan´e do
textov´eho s´
uboru.
Prv´a ˇcast bakal´arskej pr´ace je venovan´a hlavne pribl´ıˇzeniu RTP protokolu. RTP protokol bol prv´
ykr´at publikovan´
y v roku 1996. Zo zaˇciatku bol pouˇz´ıvan´
y iba na prenos
ˇ
zvuku. Casom
sa k nemu pridalo aj video. V s´
uˇcatnosti sa pouˇz´ıva na prenos audiovizu´alnych d´at po sieti. Pom´aha pri sledovan´ı vide´ı na youtube a umoˇzn
ˇuje n´am vidiet’ a poˇcut’ osobu na druhom konci pri videotelefonovan´ı. Tieto moˇznosti poskytuje
RTP protokol vd’aka tomu, ˇze umoˇzn
ˇuje rozloˇzenie a n´asledn´
u rekonˇstrukciu d´at v
spr´avnom porad´ı. Na to vyuˇz´ıva vlastnosti ako s´
u ˇcasov´e peˇciatky a sekvenˇcn´e ˇc´ısla.
ˇ
Dalej
sa tu nach´adza aj ˇcast’ venovan´a u
´vodu do problematiky d´at typu ˇcasov´
ych
pribehov a ich prepojenia na RTP protokol.
Druh´a ˇcast’ pr´ace popisuje n´avrh programov, ktor´e s´
u potrebn´e na prenos medzi
dvoma poˇc´ıtaˇcmi. S´
u tam pop´ısan´e programy spolu s argumentami potrebn´
ymi na
spustenie jednotliv´
ych programov. Pri programoch na prenos s´
uborov s´
u vyp´ısan´e
k nim prisl´
uchaj´
uce hlaviˇckov´e s´
ubory a kniˇznice potrebn´e na spustenie.
V tretej ˇcasti sa nach´adza overenie pouˇzit´eho rieˇsenia, jeho n´asledn´a anal´
yza, a
zistenie moˇznost´ı jeho praktick´eho vyuˇzitia.
1
FEI
KKUI
Formul´
acia u
´ lohy
Zadanie bakal´arskej pr´ace obsahuje nasleduj´
uce u
´lohy:
1. Vypracovat’ u
´vod do problematiky RTP streamov.
2. Vypracovat’ u
´vod do problematiky prenosu d´at typu ˇcasov´
ych priebehov.
3. Navrhn´
ut’ syst´em pre RTP stream d´at typu ˇcasov´
ych priebehov.
4. Implementovat’ navrhnut´
y syst´em pre RTP stream d´at typu ˇcasov´
ych priebehov.
5. Overit’ funkˇcnot’ implementovan´eho syst´emu a analyzovanie moˇznost´ı jeho
praktick´eho pouˇzitia.
6. Vypracovat’ dokument´aciu podl’a pokynov ved´
uceho pr´ace.
Podl’a rozdelenia jednotliv´
ych u
´loh je pr´aca rozdelen´a do piatich kapitol.
V prvej kapitole s´
u bliˇzˇsie pop´ısan´e inform´acie o RTP protokole. Zaober´a sa hist´oriou
a zloˇzen´ım RTP protokolu. V d’alˇs´ıch ˇcastiach s´
u pop´ısan´e inform´acie o tom ako RTP
protokol posiela a prij´ıma pakety, ako ich vytv´ara z framov, a tieˇz ako n´asledne z
paketov vytv´ara framy.
Druh´a kapitola sa venuje u
´vodu do problematiky ˇcasov´
ych priebehov. V jednoduchosti je tu vysvetlen´e co s´
u ˇcasov´e priebehy, ako ich del´ıme. V d’alˇsej ˇcasti s´
u
pop´ısan´e jednotliv´e zloˇzky ˇcasov´
ych priebehov.
Tretia kapitola sa zaober´a n´avrhom a implement´aciou syst´emu pre RTP stream d´at
typu ˇcasov´
ych priebehov. Je v nej pop´ısan´a a vysvetlen´a blokov´a sch´ema cel´eho
ˇ
syst´emu. Dalej
obsahuje detailn´
y opis jednotliv´
ych programov, ktor´e s´
u potrebn´e na
prenos d´at a ich sp´
uˇst’ac´ıch argumnetov.
ˇ
Stvrt´
a kapitola sa zaober´a overen´ım moˇznost´ı syst´emu a jeho praktick´
ym vyuˇzit´ım.
Posledn´a piata kapitola sa zaober´a zhodnoten´ım v´
ysledkov.
2
FEI
1
KKUI
RTP - Real-time transport protokol
RTP (Real-time transport protokol) je protokol, ktor´
y sl´
uˇzi na prenos d´at v re´alnom
ˇcase. Tento odsek je odvoden´
y z internetovej str´anky slovenskej wikip´edie - Real-time
Transport Protokol (Sk.wikip´edia, 2012). Prim´arne sa pouˇz´ıva na prenos audia a videa po sieti. Zaist’uje doruˇcovanie segmentov v spr´avnom porad´ı pomocou ˇcasov´
ych
peˇciatok (timestamp) a sekvenˇcn´
ych ˇc´ısel. Protokol tieˇz poskytuje sluˇzby na identifik´aciu obsahu (payload) a monitorovanie doruˇcenia. Protokol s´am o sebe nedisponuje mechanizmom na zaistenie vˇcasn´eho doruˇcenia d´at alebo poskytovania nejak´eho
QoS (Quality of Service). Na to spolupracuje s RTCP (RTP Control Protokol) protokolom, ktor´
y monitoruje t´
uto sluˇzbu a pom´aha pri synchroniz´acii pri viacn´asobn´
ych
streamoch. Sekvenˇcn´e ˇc´ıslo obsiahnut´e v RTP umoˇzn
ˇuje prij´ımatel’ovi rekonˇstruovat’
postupnost’ segmentov od odosielatel’a, mˆoˇze byt’ tieˇz pouˇzit´e na urˇcenie spr´avnej
poz´ıcie segmentu, napr. pri dek´odovan´ı videa bez nutnosti dek´odovat’ predch´adzaj´
uce
segmenty. Typicky beˇz´ı RTP na UDP protokole, mˆoˇze byt’ ale pouˇzit´
y aj v in´
ych
siet’ov´
ych a transportn´
ych protokoloch.
1.1
Hist´
oria RTP protokolu
RTP protokol bol vytvoren´
y skupinou pre Audio/Video Transport, ktor´a patr´ı do
organiz´acie IETF (Internet Engineering Task Force) a prv´
ykr´at bol publikovan´
yv
roku 1996 ako RFC 1889. Neskˆor sa stal s´
uˇcast’ou skupiny protokolov H.323 organiz´acie International Telecommunications Union (ITU), ktor´e s´
u odpor´
uˇcan´e na
prenos audia a videa po sieti (Perkins, 2003). Mnou pouˇzit´
y protokol je vezia RFC
3550 z roku 2003.
Kompletn´
y zoznam jednotliv´
ych verzi´ı sa nach´adza na adrese spoloˇcnosti networksorcery (rfcs, 2012).
3
FEI
KKUI
Obr. 1 – 1 Na obr´
azku je zn´
azornen´a komunik´acia cez RTP protokol. (Durresi a Jain, 2012)
1.2
S´
uˇ
casti RTP protokolu
Fyzick´
a vrstva
Tento odsek je odvoden´
y z internetovej str´anky anglickej wikip´edie - Real-time Transport Protokol (En.Wikip´edia, 2012). Streamovnie v multimedi´alnych aplik´aci´ach
vyˇzaduje aktu´alny prenos inform´aci´ı a preto sa mˆoˇze tolerovat’ urˇcit´a strata paketov, kvˆoli ktorej bude t´ato aktu´alnost’ zachovan´a. Napr´ıklad strata paketov v audio
aplik´acii mˆoˇze viest’ k strate zlomku sekundy zvukov´
ych d´at, ktor´a mˆoˇze byt’ nahraden´a vhodn´
ymi algoritmami. Hoci je RTP ˇstandardizovan´
y pre TCP (Transmission
Control Protocol) tento protokol nepouˇz´ıva. Dˆovodom je, ˇze TCP uprednostˇ
nuje
spol’ahlivost’ na u
´kor aktu´alnosti. Namiesto toho v¨aˇcˇsina implement´aci´ı RTP je upraˇ sie prenosov´e protokoly
ven´a pre pouˇzitie na UDP (User Datagram Protocol). Dalˇ
pre multimedi´alne prenosy s´
u SCTP a DCCP, aj ked’ tie sa od roku 2010 vel’mi
nevyuˇz´ıvaj´
u.
4
FEI
KKUI
Zloˇ
zenie RTP paketu
Tento odsek je odvoden´
y z knihy autora Colina Prekinsa, 2003 (Perkins, 2003). RTP
protokol je zloˇzen´
y z 2 pod-protokolov:
• Data transfer protokol - pracuje s vysialen´ım d´at, ako je audio a video, v
re´alnom ˇcase medzi koncov´
ymi syst´emami. Inform´acie v tomto protokole obsahuj´
u sekvenˇcn´e ˇc´ısla sl´
uˇziace na kontrolu paketov, ˇcasov´e peˇciatky (timestamps) na synchroniz´aciu, a payload, ktor´
y urˇcuje typ pren´aˇsan´
ych d´at a identifik´aciu zdroja.
• Kontroln´
y protokol (RTCP) - zabezpeˇcuje quality of service (QoS) ako sp¨atn´
u
v¨azbu a synchroniz´aciu medzi streamami. RTCP beˇz´ı paralelne s RTP a poskytuje pravideln´e pod´avanie spr´av s t´
ymito inform´aci´ami. Hoci d´atov´e pakety
s´
u typicky posielan´e kaˇzd´
ych p´ar milisek´
und, kontroln´
y protokol pracuje na
u
´rovni sek´
und. Inform´acie, ktor´e zasielaja RTCP s´
u nevyhnutn´e pre synchroniz´aciu medzi pr´
udmi m´edi´ı, napr´ıklad na synchroniz´aciu zvuku a videa.
RTP Data Transfer Packet
T´ato ˇcast’ je odvoden´a z knihy autora Colina Prekinsa, 2003 (Perkins, 2003) a
internetovej str´anky spoloˇcnosti networksorcery (networksorcery, 2012). Z´akladn´a
hlaviˇcka RTP d´atov´eho paketu je dlh´a 12 oktetov.V pr´ıpade potreby je moˇzn´e ju
rozˇs´ırit’ eˇste o 4 aˇz 60 d’alˇs´ıch oktetov. Povinn´e ˇcasti hlaviˇcky s´
u:
• payload(PT) - 7 bitov,
• sekvenˇcn´e ˇc´ıslo(sequence number) - 16 bitov,
• ˇcasov´a peˇciatka(timestanp) - 32 bitov,
• synchronizaˇcn´
y identifik´ator zdroja(SSRC) - 32 bitov.
Okrem toho sa tu nach´adzaj´
u aj d’alˇsie zloˇzky:
5
FEI
KKUI
• poˇcet vysielaj´
ucich zdrojov(CC) - 4 bity,
• marker udalost´ı(M) - 1 bit,
• podpora pre zabalenie hlaviˇcky(P) - 1 bit,
• rozˇs´ırenie hlaviˇcky(X) - 1 bit,
• ˇc´ıslo verzie(V) - 2 bity.
Obr. 1 – 2 Na obr´
azku sa nach´
adza hlaviˇcka RTP paketu. S´
u tu vyobrazen´e jednotliv´e ˇcasti
hlaviˇcky aj s miestom, ktor´e zaberaj´
u. Obr´azok je prebrat´
y z knihy (Perkins, 2003).
Payload type alebo PT, identifikuje typ m´edia pren´aˇsan´eho paketom. Prij´ımaj´
uca
aplik´acia presk´
uma payload type a urˇc´ı ako dan´
y typ m´edia spracovat’. Presn´a interpret´acia payload je definovan´a v RTP profile(Name a Type) , ktor´
y viaˇze payload
ˇc´ıslo do payload form´atu. Payload v rozsahu 96 aˇz 127 je vyhraden´
y pre dynamick´e
6
FEI
KKUI
pridel’ovanie pre audio / video profil, ktor´
y sa pr´ave pouˇz´ıva. Najzn´amejˇsie typy
payload typov je moˇzn´e na´ajst’ v tabul’ke 1 – 1.
PT
Name
Type
Clock rate(Hz)Audio channels
0
PCMU
Audio
8000
1
RFC 1890
3
GSM
Audio
8000
1
RFC 1890
8
PCMA
Audio
8000
1
RFC 1890
12
QCELP
Audio
8000
1
RFC 2685
14
MPA
Audio
90000
RFC 2250, RFC 3551
25
CellB
Video
90000
RFC 2029
26
JPEG
Video
90000
RFC 2435
28
nv
Video
90000
RFC 3551
31
H261
Video
RFC 2032
32
MPV
Video
RFC 2250
33
MP2T Audio/Video
34
H263
RFC 2250
Video
96 - 127 dynamic
RFC 3551
dynamics GSM-HR
Audio
8000
1
dynamicsGSM-EFR
Audio
8000
1
dynamics
Audio
variable
1
dynamicsH263-1998
Video
90000
dynamics BMPEG
Video
90000
VDVI
References
Tabul’ka 1 – 1 V tabul’ke s´
u zobrazen´e najzn´amejˇsie payload typy.
Sekvenˇ
cn´
eˇ
c´ıslo sl´
uˇzi na identifik´aciu paketov a poskytuje inform´acie prij´ımatel’ovi
ak sa pakety stratia, alebo nie s´
u dodan´e naˇcas. Nepouˇz´ıva sa na urˇcenie poradia,
v ktorom priˇsli pakety. Sekvenˇcn´e ˇc´ıslo je typu unsigned 16-bit integer a zvyˇsuje
sa o jednotku po odoslan´ı kaˇzd´eho paketu. Ak sa dosiahne maxim´alna hodnota,
sekvenˇcn´e ˇc´ıslo sa op¨atovne nastav´ı na nulu. Toto sa deje pomerne ˇcasto. Napr.
7
FEI
KKUI
pri aplik´aciach typu voice-over-IP(VoIP) sa to deje pribliˇzne kaˇzd´
ych 20 min´
ut. To
znamen´a, ˇze aplik´acia by sa nemala spoliehat’ na sekvenˇcn´e ˇc´ısla ako na jedin´
y identifik´ator paketov.
ˇ
Casov´
e peˇ
ciatky sa pouˇz´ıvaj´
u na urˇcenie poradia, v ktorom boli doruˇcen´e u
´daje
ˇ
z m´edia. Casov´
a peˇciatka je 32-bit unsigned integer a zvyˇsuje sa v z´avislosti na
r´
ychlosti m´edia. Tak ako pri sekvenˇcn´
ych ˇc´ıslach aj tu sa pri prekroˇcen´ı maxim´alnej
hodnoty op¨at’ nastav´ı nula. Pri typickom video kodeku, kde sa pouˇz´ıva taktovacia
frekvencia 90kHz, sa dosiahne maxim´alna hodnota pribliˇzne za 13 hod´ın. Pri audiu
s taktovaciou frekvenciou 8 kHz je tento interval cca 6 dn´ı.
Poˇciatoˇcn´a hodnota ˇcasovej peˇciatky je n´ahodne vybran´e ˇc´ıslo, ktor´e nemus´ı zaˇc´ınat’
od nuly. Tak ako pri sekvenˇcy
´ch ˇc´ıslach maj´
u tieto opatrenia zabezpeˇcit’, aby bolo
t’aˇzˇsie deˇsifrovat’ RTP tok. Prij´ımatel’ by mal byt’ schopn´
y prehrat’ stream bez ohl’adu
na pˆovodn´
u ˇcasov´
u peˇciatku a tieˇz by mal zvl´adnut’ vynulovanie, pretoˇze t´
ym, ˇze
ˇcasov´a peˇciatka nezaˇc´ına od nuly mˆoˇze vynulovanie nastat’ kedykol’vek.
ˇ
Casov´
a peˇciatka je odvoden´a od ˇcasu m´edia, ktor´
y sa mus´ı zvyˇsovat’ v line´arne a
monot´onnym spˆosobom, produkovat’ ˇcasov´
y pl´an pre kaˇzd´
u rel´aciu RTP zv´aˇst’. To
plat´ı bez ohl’adu na to, ak´
ym spˆosobom sa mˆoˇze vytv´arat’ medi´alny tok.
Synchronizaˇ
cn´
y identifik´
ator zdroja (SSRC) sl´
uˇzi na identifik´aciu jednotliv´
ych
u
´ˇcastn´ıkov v r´amci RTP prenosu. SSRC je 32 - bit integer, ktor´e je n´ahodne vybran´e u
´ˇcastn´ıkmi prenosu. Po tom, ako bol priraden´
y SSRC indentifik´ator, u
´ˇcastn´ık
ho pouˇz´ıva pri odosielan´ı paketov. Vzhl’adom k tomu, SSRC hodnoty sa prirad’uj´
u
lok´alne, mˆoˇze sa stat’, ˇze dvaja u
´ˇcastn´ıci bud´
u mat’ rovnak´
u hodnotu SSRC. Preto
mˆoˇzu nastat’ kol´ızie, ked’ jedna aplik´acia prij´ıma pakety od dvoch rˆoznych u
´ˇcastn´ıkov.
V pr´ıpade, ˇze u
´ˇcastn´ık zist´ı kol´ıziu pri hodnot´ach SSRC, mus´ı zaslat’ RTPC BYE pre
zruˇsenie pˆovodnej hodnoty SSRC a vyberie si nov´
u hodnotu SSRC. Tento detekˇcn´
y
mechanizmus zaist’uj´
uci unik´atnost’ SSRC je pre kaˇzd´eho u
´ˇcastn´ıka unik´atny.
8
FEI
KKUI
Ak u
´ˇcastn´ık vytv´ara viac streamov v r´amci jedn´eho RTP prenosu mus´ı mat’ kaˇzd´
y
vysielaj´
uci prvok in´
u hodnotu SSRC tak, aby prij´ımaˇce mohli rozl´ıˇsit’ jednotliv´e
streamy.
Poˇ
cet vysielaj´
ucich zdrojov V pr´ıpade, ˇze je vysielan´
ych viac RTP streamov,
viac d´atov´
ych zdrojov sa mˆoˇze podiel’at’ na tvorbe RTP d´atov´eho paketu. Tento list
identifikuje u
´ˇcastn´ıkov(CSRC), ktor´ı sa podiel’aj´
u na tvorbe RTP paketu a nie s´
u
zodpovedn´ı za ˇcasovanie a synchroniz´aciu. Kaˇzd´
y list identifikuj´
uci u
´ˇcastn´ıkov je 32
- bit integer zodpovedaj´
uci SSRC dan´eho u
´ˇcastn´ıka, ktor´
y prispel tvorbe paketu.
D´lˇzka CSRC je uveden´a v poli CC v hlaviˇcke RTP.
Marker RTP paketu je jeden bit v hlaviˇcke RTP paketu pouˇz´ıvan´
y na oznaˇcenie
zauj´ımav´
ych udalost´ı poˇcas streamovania. Pri prenose audia je marker nastaven´
y na
jedna pri prvom pakete po chv´ıli ticha. V ostatn´
ych pr´ıpadoch je nastaven´
y na
nulu. Pri prenose videa je marker nastaven´
y na jednotku, aby pouk´azal na paket
obsahuj´
uci posledn´
y r´amec. V ostatn´
ych pr´ıpadoch je nastaven´
y na nulu.
Podpora pre zabalenie hlaviˇ
cky Indikuje to, ˇze paket bol orezan´
y zo svojej
pˆovodnej podoby.
Real-time Transport Control protokol
T´ato ˇcast’ je odvoden´a z knihy autora Colina Prekinsa, 2003 (Perkins, 2003). Kontroln´e pakety s´
u posielan´e pravidelne. Interval medzi paketmi je zn´amy ako u
´ˇctovn´
y
interval. Vˇsetka ˇcinnost’ RTCP sa deje v n´asobkoch tohto intervalu. Doba medzi
paketmi je doba, pomocou ktorej sa prepoˇc´ıt´avaj´
u ˇstatistiky kvality. Interval sa l´ıˇsi
v z´avislosti od form´atu m´edi´ı. Typicky je to 5 sek´
und pre mal´e prenosy, ale mˆoˇze sa
zv´
yˇsit’ aˇz na niekol’ko min´
ut.
9
FEI
KKUI
Obr. 1 – 3 Na obr´
azku je zn´
azornen´a komunik´acia cez RTP spolu s RTCP protokol. (Durresi a
Jain, 2012)
Kaˇzd´
y RTP prenos je identifikovan´
y siet’ovou adresou a p´arom portov: jeden pre
d´ata pren´aˇsan´e pomocou RTP a druh´
y pre d´ata pren´aˇsan´e cez RTCP. Port RTCP
by mal byt’ o jedna v¨aˇcˇs´ı ako port pre RTP. Napr´ıklad, ak odosielatel’ poˇsle d´ata na
UDP porte 5004, bude kontroln´
y kan´al posielat’ d´ata na rovnak´
u adresu na UDP
porte 5005. Na obr´azku 1 – 4 je moˇzn´e vidiet’ hlaviˇcku RTCP paketu.
Obr. 1 – 4 Na obr´
azku sa nach´
adza hlaviˇcka RTCP paketu. S´
u tu vyobrazen´e jednotliv´e ˇcasti
hlaviˇcky aj s miestom, ktor´e zaberaj´
u. Obr´azok je prebrat´
y z knihy (Perkins, 2003).
10
FEI
KKUI
Zloˇzenie RTCP paketu:
• verzia(V) - 2 bity,
• podpora pre zabalenie hlaviˇcky(P) - 1 bit,
• poˇcet poloˇziek(IC) - 5 bitov,
• typ paketu(PT) - 8 bitov,
• dlˇzka(Length) - 16 bitov.
Verzia paketu Je vˇzdy nastaven´a na ˇc´ıslo 2. Nov´a verzia nie je v bl´ızkej dobe v
pl´ane.
Podpora pre zabalenie hlaviˇ
cky Indikuje to, ˇze paket bol orezan´
y zo svojej
povodnej podoby.
Poˇ
cet poloˇ
ziek Niektor´e typy paketov obsahuj´
u zoznam poloˇziek. Na urˇcenie
poˇcetu poloˇziek pol’a sa pouˇz´ıva t´ato zloˇzka, kde sa uv´adza poˇcet poloˇziek v pakete.
Do tejto ˇcasti je moˇzn´e vloˇzit’ aˇz 31 poloˇziek, ktor´e mˆoˇzu byt’ zahrnut´e v kaˇzdom
RTCP pakete. Ak je potrebn´e preniest’ viac ako 31 poloˇziek, mus´ı byt’ vygenerovan´
ych viac RTPC paketov. Ak je t´ato poloˇzka nastaven´a na nulu znamen´a to, ˇze
zoznam poloˇziek je pr´azdny (nemus´ı to nutne znamenat’, ˇze paket je pr´azdny). Pri
paketoch , ktor´e nepotrebuj´
u pole poˇcet poloˇziek je moˇzn´e toto pole pouˇzit’ na in´e
u
´ˇcely.
Typ paketu identifikuje ak´
y typ inform´aci´ı je pren´aˇsan´
y v pakete. Moment´alne
je definovan´
ych p¨at’ ˇstandardn´
ych typov paketov.
D´lˇ
zka paketu D´lˇzka pol’a oznaˇcuje d´lˇzku paketov. Meria sa v 32-bitov´
ych slov´ach,
pretoˇze vˇsetky RTCP pakety s´
u n´asobkami 32 bitov na d´lˇzku. Nula je tieˇz platn´a
11
FEI
KKUI
d´lˇzka, ˇco naznaˇcuje, ˇze paket sa sklad´a z iba ˇstyroch oktetov hlaviˇcky.
1.3
Odosielanie d´
at
T´ato ˇcast’ je odvoden´a z knihy autora Colina Prekinsa, 2003 (Perkins, 2003). Odosielatel’ je zodpovedn´
y za zachytenie audiovizu´alnych d´at, ˇci uˇz naˇzivo alebo zo s´
uboru,
ich pr´ıpravu na prenos a generovanie RTP paketov. Tieˇz sa mˆoˇze podiel’at’ na oprave
ch´
yb a riaden´ı pret’aˇzenia pomocou u
´pravy vysielan´
ych medi´alnych pr´
udov v reakcii
na sp¨atn´
u v¨azbu prij´ımatel’a.
Obr. 1 – 5 Na obr´
azku je zn´
azornen´e odoslanie RTP paketu. Od zachytenia m´edia, jeho k´odovania,
kompresia, vytrvorenia r´
amcov, zabalenia r´amcov aˇz po ich odoslanie na internet. Obr´azok je
prebrat´
y z knihy (Perkins, 2003).
Odosielatel’ prij´ıma nekomprimovan´e d´ata, medi´alne zvukov´e vzorky alebo video
sn´ımok do vyrovn´avacej pam¨ate, z ktorej s´
u vytvoren´e r´amce. Tie mˆoˇzu byt’ neskˆor
k´odovan´e niekol’k´
ymi spˆosobmi v z´avislosti na pouˇzitom algoritme. Ak s´
u r´amce
pr´ıliˇz vel’k´e, mˆoˇzu byt’ rozdelen´e do niekol’k´
ych RTP paketov a ak s´
u dostatoˇcne mal´e,
mˆoˇze byt’ niekol’ko sn´ımok vloˇzen´
ych do jedn´eho RTP paketu. Komprimovan´
ym
r´amcom sa prirad´ı ˇcasov´a peˇciatka a sekvenˇcn´e ˇc´ıslo a tie sa potom nahraj´
u do RTP
paketov pripraven´
ych k prenosu. Odosielatel’ bude generovat’ pravideln´e spr´avy o
stave v podobe RTCP paketov. Tieˇz dost´ava sp¨atn´
u v¨azbu od ostatn´
ych u
´ˇcastn´ıkov,
a tieto inform´acie pouˇz´ıva na prispˆosobenie jeho prenosu.
12
FEI
1.4
KKUI
Tvorba RTP paketu
T´ato ˇcast’ je odvoden´a z knihy autora Colina Prekinsa, 2003 (Perkins, 2003). Generovan´e r´amce prech´adzaj´
u paketiz´aciou. Kaˇzd´emu r´amcu je priraden´a ˇcasov´a peˇciatka.
Ak payload form´at podporuje fragment´aciu, potom s´
u vel’k´e r´amce rozdelen´e na
menˇsie ˇcasti tak, aby sa voˇsli do maxim´alnej prenosovej jednotky siete (to je obvykle potrebn´e pri prenose videa). Nakoniec sa vytvor´ı jeden alebo viac RTP paketov
pre kaˇzd´
y r´amec. Kaˇzd´
y tak´
yto paket obsahuje medi´alne d´ata a hlaviˇcku. Form´at
paketu a payload hlaviˇcka urˇcuj´
u ˇspecifik´aciu pouˇzit´eho kodeku. Okrem d´atov´
ych
RTP paketov, ktor´e priamo reprezentuj´
u r´amce, mˆoˇze odosielatel’ generovat’ aj pakety na opravu ch´
yb a tak mˆoˇze zmenit’ poradie sn´ımok pred zaˇciatkom prenosu.
Odosielatel’ nesmie vymazat’ d´ata, ktor´e mˆoˇzu byt’ potrebn´e na korekciu ch´
yb, alebo
v procese k´odovania. To poˇziadavka znamen´a, ˇze odosielatel’ mus´ı uchovat’ d´ata vo
vyrovn´avacej pam¨ati po urˇcit´
u dobu, poˇcas ktorej bud´
u odosielan´e zodpovedaj´
ucej
pakety. To z´avis´ı na type pouˇzit´eho kodeku a sch´emy pouˇzitej na opravu ch´
yb.
1.5
Fragment´
acia r´
amcov
R´amce, ktor´e prekraˇcuj´
u maxim´alne prenosov´e siete jednotky (MTU- maximum
transmission unit), musia byt’ rozdelen´e do niekol’k´
ych RTP paketov. Kaˇzd´
y fragment
m´a ˇcasov´
u peˇciatku z pˆovodn´eho r´amcu a tieˇz mˆoˇze mat’ priloˇzen´
u payload hlaviˇcku,
ktor´a bliˇzˇsie popisuje dan´
y fragment. (Perkins, 2003)
Tento odsek je odvoden´
y z knihy autora Colina Prekinsa, 2003 (Perkins, 2003).Fragment´acia je proces, ktor´
y je kritick´
y vzhl’ahom na kvalitu pren´aˇsan´eho m´edia, v
pr´ıpade straty paketov. Je potrebn´a schopnost’ dek´odovat’ kaˇzd´
y fragment samostatne, inak strata jedn´eho fragmentu mˆoˇze mat’ za n´asledok vyredenie celej sn´ınky.
Payload form´at, ktor´
y je tieˇz vyˇzadovan´
y pri fragment´acii zvyˇcajne definuje pravidl´a, podl’a ktor´
ych mˆoˇzu byt’ u
´daje rozdelen´e na vhodn´
ych miestach a spolu s
payload hlaviˇckou pom´ahaj´
u prij´ımatel’ovi pouˇzit’ u
´daje v pr´ıpade, ak sa niektor´e
13
FEI
KKUI
ˇ
Obr. 1 – 6 Na obr´
azku je zn´
azornen´e delenie nadrozmern´
ych r´amcov na menˇsie ˇcasti. Dalej
s´
u im
prirad’ovan´e identifikaˇcn´e ˇcasti hlaviˇcky, aby bolo moˇzn´e r´amce op¨at’ zloˇzit’. Obr´azok je prebrat´
yz
knihy (Perkins, 2003).
fragmenty stratia.
1.6
Pr´ıjem d´
at
T´ato ˇcast’ je odvoden´a z knihy autora Colina Prekinsa, 2003 (Perkins, 2003). Prij´ımatel’
je zodpovedn´
y za zber RTP paketov zo siete, opravuje a koriguje ak´
ukol’vek stratu
paketov, obnovenie ˇcasovania, dekompresii m´edia a prezentuje v´
ysledok koncov´emu
uˇz´ıvatel’ovi. Okrem toho sa oˇcak´ava, ˇze prij´ımatel’ bude odosielat’ spr´avy o kvalite
pr´ıjmu tak, aby bol odosielatel’ schopn´
y prispˆosobit’ prenos tak, aby zodpovedal
vlastnostiam siete. Prij´ımaˇc taktieˇz udrˇziava datab´azu u
´ˇcastn´ıkov prenosu, aby bolo
moˇzn´e uˇz´ıvatel’ovi podat’ inform´acie o ostatn´
ych u
´ˇcastn´ıkov.
Prv´
ym krokom prij´ımacieho procesu je zber paketov zo siete, overenie ich spr´avnosti,
a vloˇzenie do prij´ımacieho radu. S´
u to jednoduch´e oper´acie, nez´avisle na form´ate
m´edi´a. Pakety s´
u odstr´anen´e z ich vstupn´eho radu a presunut´e na k´odovac´ı kan´al
kvˆoli kontrole str´at. Po kaˇzdej takejto kontrole s´
u pakety vloˇzen´e do v´
ystupnej vy-
14
FEI
KKUI
Obr. 1 – 7 Na obr´
azku je zobrazen´
y pr´ıjem RTP paketu. Jeho prijatie, urˇcenie typu, dek´odovanie,
oprava ch´
yb, aˇz po vytvorenie fin´
alneho m´edia. Obr´azok je prebrat´
y z knihy (Perkins, 2003).
rovn´avacej pam¨ate, kde zost´avaj´
u aˇz do vytvorenia pˆovodn´
ych r´amcov. Potom s´
u
op¨at’ vloˇzen´e do vyrovn´avacej pam¨ate, kde je potrebn´e odstr´anit’ ak´ekol’vek rozdiely v naˇcasovan´ı, spˆosoben´e v´
ykyvmi v sieti. V´
ypoˇcet d´lˇzky odkladu je jedn´
ym z
najdˆoleˇzitejˇs´ıch aspektov v n´avrhu pri zaveden´ı RTP. T´
ymto procesom sa dosiahne,
ˇze zoskupen´e pakety tvoria kompletn´e r´amce a poˇskoden´e, alebo ch´
ybaj´
uce r´amce s´
u
opraven´e. N´asledne s´
u r´amce dek´odovan´e. Nakoniec s´
u medi´alne u
´daje poskytnut´e
koncov´emu uˇz´ıvatel’ovi. V z´avislosti od form´atu m´edia a v´
ystupn´eho zariadenia, je
moˇzn´e hrat’ kaˇzd´
y stream individu´alne.
15
FEI
KKUI
´
Uvod
do prenosu d´
at typu ˇ
casov´
ych priebehov
2
T´ato ˇcast’ je odvoden´a z ˇcl´anku autora S. Muthukrishnan, 2012 (Data Streams,
ˇ
2012). Casov´
y priebeh je rad hodnˆot urˇcit´eho ˇstatistick´eho znaku usporiadan´
y podl’a
ˇcasov´eho sledu ich v´
yskytu. Hodnoty sledovan´eho znaku sa obvykle zaznamen´avaj´
u
v rovnako dlh´
ych ˇcasov´
ych intervaloch. Tieto hodnoty s´
u zaznamen´avan´e a pomocou
streamovania d´at pren´aˇsan´e.
D´atov´
y stream alebo d´atov´
y tok je definovan´
y ako sekvencia digit´alne k´odovan´
ych
sign´alov, ktor´e s´
u odosielan´e a prij´ıman´e poˇcas prenosu. D´atov´
y tok reprezentuje
vstupn´e d´ata, ktor´e zat’aˇzuj´
u komunik´aciu a v´
ypoˇctov´
y v´
ykon nasleduj´
ucimi spˆosobmi:
• odosielan´ım - odoslanie vel’keho mnoˇzstva vstupn´
ych d´at,
• spracovan´ım - spracovanie n´aroˇcn´
ych funkci´ı a vel’k´eho mnoˇzstva vstupn´
ych
d´at,
• uloˇzen´ım - doˇcasn´e uloˇzenie d´at alebo dlhodob´e uloˇzenie d´at
Tieto poˇziadavky ovplyvnili infraˇstrukt´
uru prenosov a rozdelili ju na dva typy:
• Vytv´aranie automatick´
ych, vel’mi podrobn´
ych d´atov´
ych kan´alov poskytuj´
ucich
postupn´
u aktualiz´aciu. T´ato met´oda bola vytvoren´a v posladn´
ych desat’roˇciach.
Jedn´a sa o siete, ktor´e poskytuj´
u obrovsk´e d´atove prenosy.
• Potreba zloˇzit´
ych anal´
yz v re´alnom ˇcase. V tejto met´ode sa upravuj´
u podkladov´e materi´aly, kde je potrebn´a iba aktualiz´acia vybranej hodnoty. Zloˇzit´e
anal´
yzy sa uˇz realizuj´
u offline.
2.1
Modely d´
atov´
ych tokov
T´ato ˇcast’ je odvoden´a z ˇcl´anku autora S. Muthukrishnan, 2012 (Data Streams,
2012). Zloˇzky d´atov´eho toku a1 , a2 , . . . prich´adzal´
u sekvenˇcne za sebou a popisuj´
u
16
FEI
KKUI
z´akladn´
y sign´al A, jednorozmern´
u funkciu A: [1. . . N] → R2 .
• Time series Model - Kaˇzd´e ai sa rovn´a A[i] a to sa men´ı s rast´
ucim i. Tento
model ˇcasov´
ych priebehov je vhodn´
y na sledovanie prev´adzky na danej IP
adrese napr´ıklad kaˇzd´
ych 5 min´
ut. NASDAQ takto pozoruje objem obchodov
kaˇzd´
u min´
utu.
• Cash Register Model - Pri tomto modeli ai zvyˇsuje A[j]. ai = (j,Ii ), Ii ≥ 0
to znamen´a Ai [j] = Ai − 1[j]+Ii , kde Ai je stav sign´alu po i-tej zloˇzke. Tento
model sa pouˇz´ıva na sledovanie IP adresy, ktor´a pristupuje na server a posiela
pakety.
• Turnstile Model - Pri tomto modeli ai upravuje A[j]. ai = (j,Ui ) to znamen´a
Ai [j] = Ai − 1[j]+Ui , kde Ai je sign´al po i-tej zloˇzke a Ui mˆoˇze byt’ pozit´ıvne
alebo negat´ıvne. Tento model bol inˇspirovan´
y turniketmi v New York-skom
metre, kde turnikety sleduj´
u pr´ıchody a odchody l’ud´ı. Je vhodn´
y na sledovanie
plne dynamick´
ych situaci´ı.
2.2
Firmy pon´
ukaj´
uce streamovacie sluˇ
zby
QuoteMedia
Firma QuoteMedia pon´
uka software, ktor´
y poskytuje efekt´ıvne doruˇcovanie inform´aci´ı.
Umoˇzn
ˇuje sp´ajanie, manaˇzovanie a prenos d´at od viacer´
ych subjektov, ako s´
u napr´ıklad
najv¨aˇcˇsie buzry v Kanade, USA a Eur´ope. To pon´
uka firm´am z´ıskavat’ komplexn´e a
aktu´alne inform´acie o trhu. Trhov´e u
´daje s´
u doruˇcovan´e prostredn´ıctvom viacer´
ych
samostatn´
ych kan´alov. Kaˇzd´
y z t´
ychto kan´alov mˆoˇze byt’ samostatne konfigurovatel’n´
y, ˇco umoˇzn
ˇuje maximalizovat’ efektivitu a zn´ıˇzit’ n´aklady na ˇs´ırku pouˇz´ıvan´eho
p´asma. D´ata s´
u pren´aˇsan´e prostredn´ıctvom vyhraden´
ych liniek cez internet. Klient si
mˆoˇze vybrat’ medzi TCP protokolom(Transmission Control Protocol) a UDP protokolom(User Datagram Protocol) na prenos d´at. D´ata s´
u pren´aˇsan´e vo form´ate string.
17
FEI
KKUI
To zjednoduˇsuje implement´aciu, testovanie a u
´drˇzbu. QuoteMedia tieˇz podporuje
MDDL(Market Data Definition Language), XML a bin´arny form´at d´at. Software
umoˇzn
ˇuje pr´ıjem d´at v re´alnom ˇcase ale aj pr´ıjem oneskoren´
ych d´ata. (QuoteMedia,
2012)
Quotestreamtm Professional je urˇcen´
y pre profesion´alne finanˇcn´e sluˇzby. Pon´
uka
r´
ychle, spol’ahliv´e a komplexn´e u
´daje o trhu. Rieˇsenie pon´
uka n´ızke oneskorenie d´at,
moˇznost’ prispˆosobenia zobrazenia vel’kosti obrazovky, pokroˇcil´e vykresl’ovanie grafov, komplexn´e anal´
yzy, sp´avy a u
´daje. Quotestream PRO pon´
uka ˇsirok´e pokrytie
trhu, spol’ahlivost’, flexibilitu a bolo vytvoren´e s vyuˇzit´ım najnovˇs´ıch technol´ogi´ı.
Quotestreamtm
je najakt´alnejˇs´ı software pon´
ukaj´
uci rieˇsenie v oblasti streamu
spravovania portf´olia v re´alnom ˇcase. Je urˇcen´
y pre neprofesion´alov, ale aj napriek tomu poskytuje bohat´
y obsah, r´
ychly prenos d´at a prispˆosobenie koneˇcn´emu
uˇz´ıvatel’ovi. Je to ide´alne rieˇsenie pre banky, makl´erske firmy a online port´aly, ktor´e
chc´
u poskytn´
ut’ svojim z´akazn´ıkom stream u
´dajov o trhu v re´alnom ˇcase.
Quotestreamtm Wireless je unik´atna J2ME aplik´acia, ktor´a poskytuje komplexn´
u spr´avu portf´olia a ˇsirok´
y rozsah finanˇcn´
ych inform´aci´ı, sluˇzieb. Quotestream
Wireless je plne integrovan´
y so vˇsetk´
ymi Quotestream desktopov´
ymi aplik´aciami.
Quotestream Wireless pon´
uka ˇsirok´
u ˇsk´alu finanˇcn´
ych inform´aci´ı, ako je NASDAQ,
trhov´
ych indexov, historick´
ych m´ap, podrobn´e cit´acie, firemn´e spr´avy, v´
yskum a
d’alˇsie.
Weswit, Lightstreamer
Weswit Srl je softv´erov´a spoloˇcnost’ zameran´a na v´
yvoj Lightstreamer, ˇspiˇckov´eho
rieˇsenia pre sprostredkovanie d´at v re´alnom ˇcase prostredn´ıctvom webu. Lightstreamer pren´aˇsa d´ata v re´alnom ˇcase z a do vˇsetk´
ych desktopov´
ych aj mobiln´
ych we18
FEI
KKUI
bov´
ych prehliadaˇcov a aplik´aci´ı. Podporuje technol´ogie ako HTML, HTML5, Ajax,
Flex, Silverlight, iOS, Android, BlackBerry, Windows Phone, Java a .NET, s obojsmern´
ym tokom d´at cez HTTP a WebSockets. Po dvan´ast’roˇcn´
ych sk´
usenostiach v
oblasti prenosu d´at v re´alnom ˇcase, Weswit vytvorila technol´ogiu pon´
ukan´
u mnoh´
ym
finanˇcn´
ym inˇstit´
uci´am, letectvu, vojsku, podporu pre hry, ˇsportov´e a z´abavn´e podniky. (Weswit, Lightstreamer, 2012)
Lightstream server je real-time engine, ktor´
y poskytuje d´ata v re´alnom ˇcase
pomocou HTTP a WebSocketov pre vˇsetky typy klientov(HTML str´anky, dom´ace
mobiln´e aplik´acie, desktopov´e aplik´acie, . . . ). Jadro Lightstreamer serveru m´a u
´lohu
distrib´
uciu d´at klientom a to spol’ahliv´
ym a u
´ˇcinn´
ym spˆosobom, ktor´
y pon´
uka jedineˇcn´e funkcie, ako je ˇs´ırka p´asma, frekvenˇcn´e riadenie a adapt´ıvny streaming.
Lightstreamer implementuje rad sofistikovan´
ych mechanizmov, ktor´e mu pom´ahaj´
u
prejst’ cez ak´
ykol’vek firewall a proxy bez rizika zablokovania. Lightstreamer z´ıskava
d´ata a metad´ata z back-end syst´emov, ktor´e s´
u zvyˇcajne chr´anen´e druh´
ym firewallom. Webov´
y prehliadaˇc dostane statick´
u ˇcast’ webov´
ych str´anok z webov´eho servera,
a z´aroneˇ
n dost´ava aktualiz´acie v re´alnom ˇcase Lightstreamer servera.
19
FEI
3
KKUI
N´
avrh syst´
emu pre RTP stream d´
at typu ˇ
casov´
ych
priebehov
Pre potrebu prenosu d´at typu ˇcasov´
ych priebehov boli navrhnut´e a implementovan´e
tri programy. Prv´
y program je urˇcen´
y na n´ahodn´e generovanie ˇc´ısel. Tento program
je na zaˇciatku cel´eho prenosu d´at. Druh´
y program naˇc´ıta ˇc´ısla zo s´
uboru, do ktor´eho
ich zap´ısal program na ich generovaie a n´asledne ich odoˇsle na urˇcen´
u IP adresu.
Na tejto adrese d´ata prij´ıme tret´ı program. Ten sa postar´a o ich prijatie a z´apis do
s´
uboru. Toto zapisovanie do s´
uborov je urˇcen´e predovˇset´
ym preto, aby bolo moˇzn´e
overit’, ˇci boli odoslan´e a prijat´e vˇsetky vygenerovan´e ˇc´ısla, ˇci bol ich prenos u
´speˇsn´
y
a ˇci boli prenesen´e v spr´avnom porad´ı.
3.1
Celkov´
a blokov´
a sch´
ema syst´
emu pre RTP stream d´
at
typu ˇ
casov´
ych priebehov
Syst´em pracuje na 2 poˇc´ıtaˇcoch. Na prvom poˇc´ıtaˇci beˇzia dva programy. Prv´
y je
urˇcen´
y na generovanie jednotliv´
ych ˇc´ısel. Tie s´
u generovan´e n´ahodne. Tomuto programu je moˇzn´e nastavit peri´odu, podl’a ktorej bude ˇc´ısla generovat’. Program taktieˇz
vytvor´ı s´
ubor v textovom form´ate, do ktor´eho bude tieto n´ahodne generovan´e ˇc´ısla
zapisovat’. Ako vidno na obr´azku blokovej sch´emy 3 – 1, na tento program nadv¨azuje
druh´
y program, ktor´
y je urˇcen´
y na prenos ˇc´ısel medzi prv´
ym a druh´
ym poˇc´ıtaˇcom.
Program send naˇc´ıta aktu´alne ˇc´ıslo, posledn´e ˇc´ıslo zap´ısan´e v s´
ubore, a n´asledne
ho odoˇsle na urˇcen´
u IP adresu. Na druhom poˇc´ıtaˇci pracuje program recv. Tento
program sl´
uˇzi na prij´ımanie d´at z prv´eho poˇc´ıtaˇca. Recv ˇcak´a na zadanom porte
na pr´ıjem d´at. Po prijat´ı pren´aˇsan´
ych d´at ich zap´ıˇse do textov´eho s´
uboru, ktor´
y
bol vytvoren´
y pri jeho ˇstarte. Po ukonˇcen´ı prenosu ˇc´ısel sa zobrazia ˇstatisky o danom prenose. Zobraz´ı sa napr. poˇcet prijat´
ych paketov, poˇcet prijat´
ych bytov, poˇcet
prenesen´
ych bytov a in´e u
´daje, ktor´e informuj´
uou
´speˇsnosti/ne´
uspeˇsnoti prenosu.
20
FEI
KKUI
Obr. 3 – 1 Blokov´
a sch´ema cel´eho syt´emu. Zahrˇ
nuje dva poˇc´ıtaˇce. Na prvom pracuje program na
generovanie ˇc´ısel a program na ich odosielanie. Na druhom poˇc´ıtaˇc´ı ˇcak´a program na prij´ımanie
ˇc´ısel.
3.2
N´
arvh programu pre odosielanie d´
at
Na odosielanie d´at bol navrhut´
y program send. Program send sa sp´
uˇst’a s nasledovn´
ymi argunetami:
./send [subor.txt] [ip adresa] [port]
21
FEI
KKUI
Na spustenie je potrebn´e zadat’ tri argumenty. Prv´
ym je textov´
y s´
ubor, v ktorom s´
u
uloˇzen´e ˇc´ısla urˇcen´e na prenos. Tento by mal byt’ vytvoren´
y pred zah´ajen´ım prenosu.
ˇ s´ım argumentom je IP adresa poˇc´ıtaˇca, na ktor´
Dalˇ
y sa bud´
uu
´daje pren´aˇsat’. Prenos
je moˇzn´e uskutoˇcnit’ aj v r´amci jedn´eho poˇc´ıtaˇca zadan´ım adresy localhostu, teda
127.0.0.1. Tret´ım argumentom je port, na ktorom bude komunik´acia prebiehat’.
Na obr´azku 3 – 2 je v´
yvojov´
y diagram programu send.
Program na zaˇciatku over´ı, ˇci s´
u vˇsetky parametre zadan´e spr´avne. V pr´ıpade, ˇze
to tak nie je, bude vyp´ısan´a chybov´a hl´aˇska, ktor´a upozorn´ı uˇz´ıvatel’a na zle zadan´e
parametre. Po u
´speˇsnom ˇstarte programu sa najskˆor inicializuj´
u ˇcasti protokolu potrebn´e na prenos d´at. Pripravia sa algoritmy, ktor´e s´
u urˇcen´e na radenie paketov,
ˇ
vypisovanie upozornen´ı a ch´
yb. Dalej
sa pripravia algoritmy, ktor´e blokuj´
u a ˇcakaj´
u
na prenesen´e d´ata. Nadviaˇze sa spojenie s poˇc´ıtaˇcom, ktor´eho IP adresa bola zadan´a
pri ˇstarte. Priprav´ı sa aj port, na ktorom bude prebiehat’ komunik´acia a prenos d´at. V
d’alˇsom kroku program priprav´ı textov´
y s´
ubor na ˇc´ıtanie aktu´alneho ˇc´ısla. V naˇsom
pr´ıpade bude aktu´alne ˇc´ıslo to, ktor´e je v textovom s´
ubore zap´ısan´e ako posledn´e.
K naˇc´ıtaniu ˇc´ısla doch´adza pred kaˇzd´
ym odoslan´ım. T´
ymto spˆosobom sa zabezpeˇc´ı
odoslanie vˇzdy aktu´alneho ˇc´ısla. Po jeho naˇc´ıtan´ı program send odoˇsle toto ˇc´ıslo
na urˇcen´
u IP adresu. Send vytv´ara pakety vel’kosti 172 bytov. 12 bytov je uˇcen´
ych
pre hlaviˇcku RTP paketu. Viac o hlaviˇcke paketu je pop´ısan´e v ˇcasti 1.2. Zvyˇsn´
ych
160 bytov je urˇcen´
ych pre pren´aˇsan´e ˇc´ıslo. Pren´aˇsan´e ˇc´ıslo je naˇc´ıtavan´e ako ret’azec
znakov. To ohraniˇcuje pren´aˇsan´e ˇc´ıslo na d´lˇzku 160 znakov. Program send bol navrhnut´
y tak, aby ˇc´ısla pren´aˇsal st´ale. Preto nie je moˇzn´e ho priamo vypn´
ut’. Program
posiela d´ata aj vtedy, ked’ nie je nadviazan´e spojenie. Toto rieˇsenie bolo navrhnut´e
pre pr´ıpady, ak by doˇslo poˇcas prenosu k nejak´emu preruˇseniu ˇci uˇz na prenosovom
m´ediu alebo chybou na prij´ımacom zariaden´ı. Ak dˆojde k preruˇseniu prenosu bude
na to uˇz´ıvatel’ upozornen´
y v´
ypisom zobrazen´
ym na obr´azku 3 – 3. Po znovupripojen´ı
programu na pr´ıjem d´at tento program op¨atovne obdrˇz´ı najaktu´alnejˇsie d´ata.
22
FEI
KKUI
Obr. 3 – 2 V´
yvojov´
y diagram pre program send, program na odosielanie d´at.
23
FEI
KKUI
Obr. 3 – 3 Na obr´
azku je moˇzn´e vidiet’ zadanie pr´ıkazu na spustenie programu aj s jeho arguˇ
mentami. Dalej
vidno chybov´e hl´
asenie v pr´ıpade preruˇsenia spojenia.
3.3
N´
avrh programu pre prij´ımanie d´
at
Na pr´ıjem d´at bol navrhut´
y program recv. Program recv sa sp´
uˇst’a nasledovn´
ymi
argunetami:
./recv [subor.txt] [port]
Pre spustenie programu na pr´ıjem d´at je potrebn´e zadat’ dva argumenty. Prv´
y je
textov´
y s´
ubor. Do nasledovn´eho s´
uboru bud´
u zapisovan´e ˇc´ısla po ich prenose a
prijat´ı programom recv. V pr´ıpade, ˇze s´
ubor nebol vytvoren´
y skˆor, vytvor´ı sa pri
spusten´ı programu. Druh´
ym argumentom je ˇc´ıslo portu, na ktorom bude prebiehat’
komunik´acia.
Na obr´azku 3 – 4 je v´
yvojov´
y diagram programu recv.
24
FEI
KKUI
Obr. 3 – 4 V´
yvojov´
y diagram pre program recv, program na prij´ımanie d´at.
25
FEI
KKUI
Program ako prv´e otestuje, ˇci boli vˇsetky zadan´e parametre spr´avne. Ak neboli
zadan´e spr´avne, bude vyp´ısan´a chybov´a hl´aˇska, ktor´a upozorn´ı uˇz´ıvatel’a na zle
zadan´e parametre. Program na zaˇciatku vytvor´ı textov´
y s´
ubor, do ktor´eho sa bud´
u
ˇ
ˇc´ısla po prijat´ı zapisovat’. Dalej
sa inicializuj´
u ˇcasti protokolu potrebn´e k prenosu d´at.
Pripravia sa algoritmy, ktor´e s´
u urˇcen´e na radenie paketov, vypisovanie upozornen´ı
ˇ
a ch´
yb. Dalej
sa pripravia algoritmy, ktor´e blokuj´
u a ˇcakaj´
u na prenesen´e d´ata. Na
rozdiel od programu na posielanie d´at sa v tomto programe inicializuj´
u aj algoritmy
pod´avaj´
uce sp¨atn´
u v¨azbu. Program ˇcak´a na zah´ajenie komunik´acie na porte urˇcenom
na zaˇciatku. Program potom ˇcak´a na prijatie paketov. Po prijat´ı paketu a zisten´ı
pren´aˇsan´eho ˇc´ısla preform´atuje typ premennej z typu ret’azec na typ integer a zap´ıˇse
tieto ˇc´ısla do s´
uboru. Prenos je potrebn´e ukonˇcit’ manu´alne stlaˇcen´ım CTRL + [C].
Po ukonˇcen´ı prenosu sa tieˇz zobraz´ı ˇstatistika o pren´aˇsan´
ych d´atach. V´
ypis sa l´ıˇsi
od toho, ktor´
y je moˇzn´e vidiet’ pri programe na odosielanie d´at. Na obr´azku 3 –
5 je moˇzn´e vidiet’ v´
ypis, ktor´
y sa zobraz´ı po ukonˇcen´ı prenosu. V´
ypis informuje o
poˇcte prijat´
ych paketov a bytov. Zobrazuj´
u sa nielen inform´acie o sp´avne doruˇcen´
ych
d´atach ale aj o t´
ych, ktor´e boli doruˇcen´e neskoro, respekt´ıve boli zahoden´e.
Obr. 3 – 5 Na obr´
azku je moˇzn´e vidiet’ zadanie pr´ıkazu na spustenie programu aj s jeho argumentami. Pod n´ım sa nach´
adzaj´
u ˇstatistick´e inform´acie o prenose.
26
FEI
3.4
KKUI
Kniˇ
znice a hlaviˇ
ckov´
e s´
ubory potrebn´
e na sfunkˇ
cnenie
rieˇ
senia
Pre bezprobl´emov´
u kompil´aciu je portebn´e najskˆor stiahnut’ a nainstalovat’ kniˇznicu
oRTP (oRTP, 2012). Programy na odosielanie a prij´ımanie d´at vyuˇz´ıvanj´
u nasledovn´e hlaviˇckov´e subory: ortp/ortp.h, signal.h, stdlib.h, sys/types.h, sys/time.h,
stdio.h, time.h, unistd.h. Potrebn´e hlaviˇckov´e s´
ubory je moˇzn´e vidiet’ aj na obr´azku
3 – 6.
Obr. 3 – 6 Na obr´
azku s´
u vyobrazen´e hlaviˇckov´e s´
ubory potrebn´e na spustenie. Pod nimi je
kniˇznica potrebn´
a na kompil´
aciu.
27
FEI
KKUI
4
Overenie funkˇ
cnosti implementovan´
eho syst´
emu
V praktickej ˇcasti som sa venoval n´aroˇcnosti pouˇzitia RTP protokolu na prenos d´at
typu ˇcasov´
ych radov. Pop´ısal som spˆosob, ak´
ym sa d´ata pren´aˇsaj´
u a kol’ko d´at je
prenesen´
ych za urˇcit´
u ˇcasov´
u jednotku. Boli vykonan´e 2 typy meran´ı. V prvom boli
porovn´avan´e r´
ychlosti a kvalita prenosu na jednotliv´
ych typoch prenosov´
ych medi´ı.
V druhom boli porovn´avan´e poˇcty prenesen´
ych paketov s d’alˇs´ımi dvoma protokolmi
transportnej vrstvy.
4.1
N´
aroˇ
cnost’ pouˇ
zitia oRTP
Program na odosielanie d´
at
Implementovan´e rieˇsenie vych´adza z programu na videotelefonovanie linphone1 . Podprogram pouˇz´ıt´
y na prenos zvuku bol upraven´
y na prenos jednoduch´
ych ˇc´ısel. Bolo
upraven´e naˇc´ıtanie vstupn´
ych u
´dajov tak, aby sa odosielalo najaktu´alnejˇsie ˇc´ıslo,
ˇc´ıslo zap´ısan´e v s´
ubore ako posledn´e. Algoritmus na posielanie d´at je nasledovn´
y:
while ( 1 ) {
while ( ! f e o f ( i n f i l e ) )
f s c a n f ( i n f i l e , ”%s ” , buf ) ;
s t r n c p y ( b u f f e r , buf , s i z e o f ( b u f f e r ) ) ;
i=s i z e o f ( b u f f e r ) ;
rtp session send with ts ( session , buffer , i , user ts ) ;
u s e r t s +=160;
rewind ( i n f i l e ) ;
}
1
http://www.linphone.org
28
FEI
KKUI
Prv´a ˇcast’ zabezpeˇcuje naˇc´ıtanie aktu´alneho ˇc´ısla a jeho konverziu do form´atu potrebn´eho na odoslanie. Podmienka na konci zabezpeˇcuje, ˇze algoritmus sa ukonˇc´ı
vo chvili, ked’ dˆojde k ukonˇceniu spojenia. Samotn´e odosielanie d´at je v programe
zabezpeˇcn´e pomocou pr´ıkazu:
rtp session send with ts ( session , buffer , i , user ts )
Pr´ıkaz sa odvol´ava na algoritmy obsiahnut´e s kniˇznici oRTP. Tam sa na z´aklade
vstupn´
ych parametrov pren´aˇsan´
ych pr´ıkazom, ktor´
y sl´
uˇzi na odoslanie d´at vytvoria
pakety a n´asledne sa odoˇsl´
u.
Popis jednotliv´
ych parametrov:
• session - n´azov vytvoren´eho prenosu,
• buffer - buffer obsahuje d´ata, ktor´e s´
u pren´aˇsan´e v paketoch,
• i - vel’kost’ pre´aˇsan´
ych d´at v bytoch,
ych peˇciatok.
• user ts - hodnota potrebn´a pri tvorbe ˇcasov´
Program na prij´ımanie d´
at
Program na pr´ıjem d´at op¨at’ vych´adza z progamu linphone. V tomto programe bol
upraven´
y v´
ystup. Prenesen´e d´ata program zapisuje do textov´eho s´
uboru. Algoritmus
na prij´ımanie d´at je n´asledovn´
y:
while ( cond )
{
have more =1;
while ( have more ){
e r r=r t p s e s s i o n r e c v w i t h t s ( s e s s i o n , b u f f e r , 1 6 0 , t s ,& have more ) ;
i f ( e r r >0) s t r e a m r e c e i v e d =1;
i f ( ( s t r e a m r e c e i v e d ) && ( e r r >0)) {
29
FEI
KKUI
int c = a t o i ( b u f f e r ) ;
f p r i n t f ( o u t f i l e , ”%i \n” , c ) ;
}
}
t s +=160;
}
V algoritme na pr´ıjem d´at zabezpeˇcuje prij´ımanie pr´ıkaz:
r t p s e s s i o n r e c v w i t h t s ( s e s s i o n , b u f f e r , 1 6 0 , t s ,& have more )
Ak pr´ıjem d´at prebehol u
´speˇsne, bez ch´
yb, bud´
u n´asledne d´ata zap´ısan´e do s´
uboru.
Pr´ıkaz sa odvol´ava na algoritmy obsiahnut´e s kniˇznici oRTP. Tam sa na z´aklade
vstupn´
ych parametrov pren´aˇsan´
ych pr´ıkazom, ktor´
y je urˇcen´
y na pr´ıjem d´at pakety
op¨atovne dek´oduj´
u tak, aby bol ich obsah ˇcitatel’n´
y.
Popis jednotliv´
ych parametrov:
• session - n´azov vytvoren´eho prenosu,
• buffer - buffer obsahuje d´ata, ktor´e s´
u pripraven´e na z´apis,
• 160 - vel’kost’ pre´aˇsan´
ych d´at v bytoch(160 je vel’kost’ vyhradenej pam¨ate),
• ts - hodnota vyˇzadovan´a pri ˇcasov´
ych peˇciatk´ach,
• have more - indik´acia, ˇze do ˇcasovej peˇciatky je pridan´
ych viac d´at.
Kniˇ
znice a hlaviˇ
ckov´
e s´
ubory
Pre u
´speˇsn´
u kompil´aciu programov na odosielanie a prij´ımanie je potrebn´e mat’
nainˇstalovan´
u sadu kniˇzn´ıc oRTP protokolu. T´
u je moˇzn´e stiahn´
ut’ z nasleduj´
ucej
str´anky (oRTP, 2012). Pr´ıkaz na kompilovanie je naslednovn´
y:
30
FEI
KKUI
g c c −o send r t p s e n d . c −l o r t p
respekt´ıve
g c c −o r e c v r t p r e c v . c −l o r t p
Na obr´azku 3 – 6 s´
u pop´ısan´e vˇsetky hlaviˇckov´e s´
ubory, ktor´e vyuˇz´ıvaj´
u programy
na prenos d´at.
send ortp/ortp.h, signal.h, stdlib.h, sys/types.h, sys/time.h, stdio.h, time.h
recv ortp/ortp.h, signal.h, stdlib.h, sys/types.h, stdio.h, unistd.h
4.2
Prenos d´
at
Syst´em na prenos d´at sa sp´
uˇst’a programom na generovanie ˇc´ısel. Ten je potrebn´e
spustit’ ako prv´
y, aby bolo odkial’ ˇc´ıtat’ ˇc´ısla.
. / c i s l o nazov suboru delay
Program na generovanie ˇc´ısel ako prv´e vytvor´ı textov´
y s´
ubor, z ktor´eho sa bud´
u
generovan´e ˇc´ısla naˇc´ıtavat’. Odosielat’ sa bude vˇzdy poslen´e zap´ısan´e ˇc´ıslo. Posledn´e
ˇc´ıslo je naˇc´ıtan´e pomocou nasledov´eho algoritmu:
while ( ! f e o f ( i n f i l e ) )
f s c a n f ( i n f i l e , ”%s ” , buf ) ;
Tento spˆosob je jedn´
ym z moˇzn´
ych rieˇsen´ı hl’adania aktu´alneho ˇc´ısla. Dan´e rieˇsenie
m´a vˇsak chybu. T´a sa bude prejavovat’ pri vel’kom mnoˇzstve pren´aˇsan´
ych ˇc´ısel. V
tak´
ych pr´ıpadoch bude potrebn´e prejst’ vel’k´
ym mnoˇzstvo ˇc´ısel, k´
ym sa algoritmus
dostane k posledn´emu, najaktu´alnejˇsiemu, ˇc´ıslu. Tento fakt mˆoˇze neskˆor viest’ k vynechaniu nejak´eho ˇc´ısla z prenosu. Moment kedy k tomu dˆojde z´aleˇz´ı aj od r´
ychlosti
31
FEI
KKUI
gemerovania ˇc´ısel. V mojom pr´ıpade sa to d´a simulovat’ pomocou ˇcasu, ktor´
y bude
medzi generovan´ım jednotliv´
ych ˇc´ısel.
Po spusten´ı programu na generovanie ˇc´ısel je moˇzn´e spustit’ program na odosielanie
d´at. Ten bude posielat’ d´ata aj ked’ nie je pripojen´
y program na pr´ıjem d´at. Program
urˇcen´
y na odosielanie d´at sa sp´
uˇst’a pomocou pr´ıkazu:
. / send n a z o v s u b o r u I P a d r e s a p o r t
Program po ˇstarte over´ı, ˇci s´
u zadan´e vˇsetky parametre potrebn´e na spustenie. V
pripade, ˇze ich poˇcet nesed´ı vyp´ıˇse chybov´e hl´asenie, ktor´e upozorn´ı puoˇz´ıvatel’a
na spr´avne parametre. Po u
´speˇsnom ˇstarte programu sa inicializuj´
u algoritmy zabezpeˇcuj´
uce spojenie a kontrolu nad prenosom d´at. V d’alˇsom kroku sa pomocou
ˇ ıslo je naˇc´ıtavan´e ako
algoritmu na ˇc´ıtanie ˇc´ısel naˇc´ıta posledn´e zap´ısan´e ˇc´ıslo. C´
ret’azec znakov(char[160]). Vel’kost’ ˇc´ısla je obmedzen´a na 160 znakov. Protokol vˇsak
podporuje d´ata typu unsigned char[160]. Preto bolo nutn´a konverzia medzi jednotliv´
ymi form´atmi. T´a je vykonan´a pomocou kopirovania obsahu. N´asledne pomocou
nasleduj´
uceho pr´ıkazu:
rtp session send with ts ( session , buffer , i , user ts )
Po odoslan´ı d´at program nastav´ı kurzor na zaˇciatok dokumentu, aby mohol op¨at’
prejst’ cel´
y textov´
y s´
ubor a tak naˇc´ıtat’ posledn´e, aktu´alne, ˇc´ıslo. Program bude
posielat’ d´ata st´ale, k´
ym sa neukonˇc´ı okno, v ktorom program pracuje. Tento spˆosob
m´a zaruˇc´ıt’ prenos d´at aj v pr´ıpade, ˇze poˇcas prenosu doˇslo k preruˇseniu spojenia
alebo inej poruche na prenosovom m´ediu alebo zariaden´ı na pr´ıjem d´at.
Program na prij´ımanie d´at sa sp´
uˇst’a pr´ıkazom:
. / recv nazov suboru port
Po naˇstartovan´ı programu sa over´ı poˇcet zadan´
ych parametrov potrebn´
ych na spustenie. V pripade, ˇze ich poˇcet nesed´ı vyp´ıˇse chybov´e hl´asenie, ktor´e upozorn´ı puoˇz´ıvatel’a
32
FEI
KKUI
na spr´avne parametre. Po u
´speˇsnom ˇstarte programu sa inicializuj´
u algoritmy zaˇ
bezpeˇcuj´
uce spojenie a kontrolu nad prenosom d´at. Dalej
sa nastav´ı hodnota have more
na hodnotu 1. Potom sa pomocou nasluj´
uceho pr´ıkazu pr´ıjm´
u d´ata:
r t p s e s s i o n r e c v w i t h t s ( s e s s i o n , b u f f e r , 1 6 0 , t s ,& have more )
Po prijat´ı sa over´ı, ˇci prijat´
y paket obsahoval nejak´e d´ata. Ak ´ano program zaregistruje, ˇze boli prijat´e nejak´e d´ata. Tie n´asledne prekonvertuje na ˇc´ıseln´
y form´at a
zap´ıˇse do s´
uboru. Program st´ale ˇcak´a na pr´ıjem d´at, aj v pr´ıpade, ˇze ˇziadne d´ata
nie s´
u odosielan´e. Preto je potrebn´e ho manu´alne ukonˇcit’. Po ukonˇcen´ı prij´ımania
d´at sa ukonˇcia aj algoritmy zabezpeˇcuj´
uce spojenie.
Cel´
y syst´em prenesie jedno vygenerovan´e ˇc´ıslo viackr´at, k´
ym dˆojde k jeho zmene.
To spˆosobuje rozdielne vyzeraj´
uci textov´
y s´
ubor, z ktor´eho boli ˇc´ısla naˇc´ıtavan´e a
textov´
y s´
ubor, do ktor´eho sa prenesen´e ˇc´ısla zapisovali. Za beˇzn´
ych podmienok bolo
jedno ˇc´ıslo prenesen´e 50 kr´at. V´
ynimku tvor´ı prv´e prenesen´e ˇc´ıslo, ked’ˇze vˇsetky programy urˇcen´e na generovanie a prenos ˇc´ısel nie je moˇzn´e spustit’ naraz. To, kol’kokr´at
bude jedno ˇc´ıslo pren´aˇsan´e je moˇzn´e ˇciastoˇcne ovplyvnit’ hodnotou oneskorenia pri
sp´
uˇst’an´ı programu na generovanie ˇc´ısel. V tabul’ke 4 – 1 je moˇz´e vidiet’ ako hodnota
oneskorenia ovlyvnila kol’ko kr´at bolo jedno ˇc´ıslo prenesen´e.
Oneskoreniepoˇcet prenesen´ı
1000
50
10000
50
100000
50
1000000
50
1500000
75
2000000
100
Tabul’ka 4 – 1 Vplyv oneskorenia na poˇcet prenesen´ı jedn´eho ˇc´ısla.
Poˇcet prenesen´ı nebolo moˇzn´e zn´ıˇzit’, lebo programovac´ı jazyk C generuje n´ahodn´e
ˇc´ısla na z´aklade ˇcasu. Pri minim´alnom ˇcase potrebnom na zmenu ˇc´ısla bolo poslen´e
33
FEI
KKUI
vygenerovan´e ˇc´ıslo prenesen´e minim´alne 50 kr´at. Z talul’ky 4 – 1 sa d´a urˇcit’, ˇze
k prenosu jedn´eho ˇc´ısla doch´adza pribliˇzne kaˇzd´
ych 20 minisek´
und. V´
yraznejˇsie
v´
ykyvy som nezaznamenal ani pri pouˇzit´ı rˆoznych prenosov´
ych technol´ogi´ı. Testoval
som prenos v r´amci jedn´eho poˇc´ıtaˇca pomocou localhostu a prenos medzi dvoma
poˇc´ıtaˇcmi prostredn´ıctvom ethernetov´eho k´abla a wifi.
4.3
Overenie r´
ychlosti a kvality prenosu
RTP protokoly boli vybran´e na prenos d´at typu ˇcasov´
ych priebehov aj kvˆoli svojej
prenosovej r´
ychlosti. T´ato ˇcast’ je venovan´a testovaniu r´
ychlosti implementovan´eho
rieˇsenia. Bude sa sledovat’ poˇcet prenesen´
ych d´at za sekundu. Namiesto programu
na generovanie ˇc´ısel bol pouˇzit´
y s´
ubor s jedn´
ym ˇc´ıslom. Eliminoval sa t´
ym probl´em,
krot´
y by mohol nastat’ pri vel’kom mnoˇzstve ˇc´ısel zap´ısan´
ych v textovom s´
ubore.
Probl´em vych´adza z toho, ˇze program na odosielanie d´at mus´ı prejst’ cel´
y textov´
y
s´
ubor aby sa dostal k posledn´emu ˇc´ıslu, ˇco by mohlo viest’ o oneskoreniu.
Program na odosielanie d´at bol tieˇz ˇciastoˇcne upraven´
y. Bol odstr´anen´
y algoritmus na hl’adanie a naˇc´ıtanie posledn´eho ˇc´ısla. V tomto pr´ıpade uˇz nie je nutn´e
prehl’ad´avat’ cel´
y textov´
y dokument. T´
ymto by sa mala ur´
ychlit’ aj jeho ˇcinnost’.
Do programu na pr´ıjem d´at boli pridan´e funkcie na zistenie aktu´alneho ˇcasu. Tie boli
pouˇzit´e pri zisten´ı ˇcasu na zaˇciatku a na konci prenosu. Do ˇcasti urˇcenej na pr´ıjem
d´at bola eˇste pridan´a jedna premenn´a, ktor´a zabezpeˇcovala poˇc´ıtanie prijat´
ych paketov. Tak bolo moˇzn´e po ukonˇcen´ı prenosu zistit’, akou prenosovou r´
ychlost’ou boli
pren´aˇsan´e jednotliv´e d´ata.
Porovn´avali sa r´
ychlosti a stabilita prenosu najskˆor na localhoste, po n
ˇom nasledoval ethernetov´
y k´abel a nakoniec wi-fi pripojenie. Celkovo bolo uskutoˇcnen´
ych
45 meran´ı. Pre kaˇzd´
y typ prenosu 15 meran´ı. Na kaˇzdom prenosovom m´ediu sa
uskutoˇcnilo 5 meran´ı s d´lˇzkou prenosu 10 sek´
und, 5 meran´ı s d´lˇzkou prenosu 30
sek´
und a 5 meran´ı s d´lˇzkou prenosu 60 sek´
und. Zisten´e v´
ysledky s´
u zaznamenan´e v
34
FEI
KKUI
tabul’k´ach 4 – 2, 4 – 3 a 4 – 4.
35
FEI
KKUI
D´lˇzka prenosu(s)ˇc. meraniaprenesen´e B/sprijat´e paketyoneskoren´e pakety
10
30
60
1.
8617,2
501
0
2.
9030
525
0
3.
8548,4
497
0
4.
8858
515
0
5.
8840,8
514
0
1.
8708,93
1519
57
2.
8605,73
1501
0
3.
8657,33
1510
0
4.
8714,67
1520
0
5.
8749,07
1526
0
1.
8597,13
2999
0
2.
8585,67
2995
0
3.
8614,33
3005
0
4.
8620,07
3007
0
5.
8597,13
2999
0
Tabul’ka 4 – 2 V´
ysledky merania r´
ychlosti a stability prenosu pre localhost.
Prenos d´at v r´amci jedn´eho poˇc´ıtaˇca bol pomerne r´
ychly bezprobl´emov´
y. R´
ychlost’
prenosu neklesala pod 8500 B/s. Strata paketov aˇz na jedno meranie bola nulov´a,
ˇco bolo spˆosoben´e aj t´
ym, ˇze na prenosov´e m´edium nepˆosobili vonkajˇsie vplyvy.
Poˇcas 10 sekundov´
ych prenosov bolo priemerne prenesen´
ych 510,4 paketov, poˇcas
30 sekundov´
ych meran´ı bolo v priemere prenesen´
ych 1515,2 paketov a poˇcas 60
sekundov´
ych meran´ı bolo v priemere prenesen´
ych 3001 paketov.
36
FEI
KKUI
D´lˇzka prenosu(s)ˇc. meraniaprenesen´e B/sprijat´e paketyoneskoren´e pakety
10
30
60
1.
8703,3
506
0
2.
8703,3
506
1
3.
8634,4
502
0
4.
8686
505
0
5.
8668,8
504
0
1.
8611,47
1502
34
2.
8611,47
1502
0
3.
8485,33
1480
0
4.
8611,47
1502
24
5.
8542,67
1490
72
1.
8665,93
3023
0
2.
8637,27
3013
1
3.
8608,6
3003
0
4.
8600
3000
1
5.
8608,6
3003
73
Tabul’ka 4 – 3 V´
ysledky merania r´
ychlosti a stability prenosu pre etherneto´
y k´abel.
Prenos prostredn´ıctvom ethernetov´eho k´abla bol takmer tak´
y r´
ychly ako prenos
v r´amci jedn´eho poˇc´ıtaˇca. Pri jednom meran´ı klesla r´
ychlost’ pod 8500 B/s. Poˇcas
prenosu vˇsak doˇslo k oneskoreniu v¨aˇcˇsieho mnoˇzstva paketov. Poˇcas 10 sekundov´
ych
prenosov bolo priemerne prenesen´
ych 504,6 paketov, poˇcas 30 sekundov´
ych meran´ı
bolo v priemere prenesen´
ych 1495,2 paketov a poˇcas 60 sekundov´
ych meran´ı bolo v
priemere prenesen´
ych 3008,4 paketov.
37
FEI
KKUI
D´lˇzka prenosu(s)ˇc. meraniaprenesen´e B/sprijat´e paketyoneskoren´e pakety
10
30
60
1.
8651,6
503
3
2.
8376,4
487
49
3.
8651,6
503
0
4.
8668,8
504
0
5.
8548,4
497
0
1.
8605,73
1501
10
2.
8663,07
1511
0
3.
8622,93
1504
22
4.
8600
1500
2
5.
8611,47
1502
0
1.
8568,47
2989
8
2.
8548,4
2982
41
3.
8554,13
2984
40
4.
8545,53
2981
42
5.
8562,73
2987
0
Tabul’ka 4 – 4 V´
ysledky merania r´
ychlosti a stability prenosu pre wifi pripojenie.
Prenos cez wifi pripojenie pri d´lˇzkach prenosu 10s a 30s bol porovnatel’ne r´
ychly ako
prenos v r´amci poˇc´ıtaˇca alebo po ethernetovom k´abli. Pri dlhˇsom prenose sa zaˇcala
prejavovat’ niˇzˇsia r´
ychlost’, ale len minim´alne. Stabilita prenosu a mnoˇzstvo oneskoren´
ych paketov dosiahli najhorˇsie v´
ysledky zo vˇsetk´
ych meran´ı. Poˇcas 10 sekundov´
ych prenosov bolo priemerne prenesen´
ych 498,8 paketov, poˇcas 30 sekundov´
ych
meran´ı bolo v priemere prenesen´
ych 1503,6 paketov a poˇcas 60 sekundov´
ych meran´ı
bolo v priemere prenesen´
ych 2984,6 paketov.
38
FEI
KKUI
Hodnotenie meran´ı
Ciel’om t´
ychto meran´ı bolo zistit’ rozdiely v r´
ychlosti a kvalite prenosu na troch
rˆoznych prenosov´
ych m´ediach. Porovn´avan´e m´edia boli localhost, ethernetov´
y k´abel,
a wifi pripojenie. Pri prenosoch trvaj´
ucich 10 a 30 sek´
und neboli viditel’n´e ˇziadne
v´
yrazn´e rozdiely v r´
ychlosti prenosu a poˇcte prenesen´
ych paketov. Rozdiely sa prejavili aˇz pri prenosoch, ktor´e trvali 60 sek´
und, kde prenos cez wifi uˇz nest´ıhal nepren´aˇsat’ tak´
y objem d´at ako localhost alebo ethernetov´
y k´abel. Odch´
ylky boli s´ıce
mal´e, ale jednalo sa len o kr´atke intervaly poˇcas, ktor´
ych boli pakety pren´aˇsan´e.
Pri v¨aˇcˇs´ıch ˇcasov´
ych intervaloch by mohli byt’ odch´
ylky v poˇcte prenesen´
ych paketov v´
yraznejˇsie. Pri meraniach bolo moˇzn´e kontrolovat’ aj poˇcet paketov doruˇcen´
ych
neskoro. Tu bol tieˇz najmenej chybov´
y localhost. Pri prenose pomocou localhostu
bolo zisten´e iba jedno meranie, v ktorom doˇslo k oneskoreniu poˇctu paketov. Viac
chybov´e boli uˇz prenosy pomocou ethernetov´eho k´abla a wifi pripojenia. Prenos
prostredn´ıctvom wifi bol najchybovejˇs´ı. Doch´adzalo pri n
ˇom k pomerne vel’k´emu
oneskorovaniu paketov.
4.4
Porovnanie poˇ
ctu prenesen´
ych paketov s TCP a UDP
RTP protokol je nastaven´
y tak, aby kaˇzd´
u sekundu preniesol 50 paketov. Preto
bolo vykonan´e meranie na porovnanie s ostatn´
ymi protokolmi transportnej vrstvy.
Porovn´avan´e boli RTP protokol, TCP protokol (Transmission Control Protocol) a
UDP protokol (User Datagram Protocol). Poˇcas experimentu bolo vykonan´
ych 15
meran´ı. Pre kaˇzd´
y typ protokolu bolo uroben´
ych 5 meran´ı. D´lˇzka prenosu bola
nastaven´a na 60 sek´
und. Zisten´e v´
ysledky s´
u zaznamenan´e v tabul’ke 4 – 5
39
FEI
KKUI
ˇc. meraniaprenes. pakety cez RTPprenes. pakety cez TCPprenes. pakety cez UDP
1.
2999
399851
550762
2.
2995
395792
528315
3.
3005
399866
513871
4.
3007
399839
511055
5.
2999
389399
510413
Tabul’ka 4 – 5 V´
ysledky merania prenosu paketov za 60 sek´
und pomocou RTP, TCP a UDP
protokolov.
V´
ysledky meran´ı
Ciel’om t´
ychto meran´ı bolo zistit’, ak´e s´
u rozdiely v poˇcte prenesen´
ych paketov pomocou jednotliv´
ych protokolov transportnej vrstvy. Porovn´avan´e boli tri protokoly.
RTP protokol, TCP protokol (Transmission Control Protocol) a UDP protokol (User
Datagram Protocol). Kaˇzd´e meranie trvalo 60 sek´
und. V´
ysledky potvrdili, ˇze najviac
paketov bolo prenesen´
ych cez UDP protokol. UDP protokol posielal d´ata bez ohl’adu
na to, ˇci bolo spojenie nadviazan´e alebo nie. TCP protokol bol pomalˇs´ı pribliˇzne o
110 tis´ıc paketov za 60 sek´
und. Tu sa vˇsak vyˇzadovalo u
´speˇsn´e nadviazanie spojenia
pred t´
ym, ako doˇslo k prenosu. Pri RTP protokole bol potvrden´
y prenos pribliˇzne
50 paketov za sekundu, ˇco d´avalo po 60 sekund´ach pribliˇzne 3000 paketov.
40
FEI
5
KKUI
Z´
aver
Moja bakal´arska pr´aca je venovan´a t´eme streamovania d´at typu ˇcasov´
ych priebehov
v re´alnom ˇcase pomocou RTP protokolu. Na rieˇsenie zadan´eho probl´emu bolo potrebn´e naˇstudovat’ si problematiku fungovania RTP protokolu a tieˇz problematiku
ˇ
prenosu d´at typu ˇcasov´
ych priebehov. Dalej
bolo potrebn´e navrhn´
ut’ a implementovat’ syst´em potrebn´
y na prenos d´at typu ˇcasov´
ych priebehov.
Hlavn´
y pr´ınos mojej bakal´arskej pr´ace je v moˇznosti implementovania RTP protokolov, pˆovodne urˇcen´
ych na prenos audio-vizu´alnych d´at, na prenos d´at typu
ˇcasov´
ych priebehov. Uveden´e rieˇsenie poskytuje r´
ychly prenos jednoduch´
ych ˇc´ısel
po sieti. T´
ymto spˆosobom sa zabezpeˇcuje neust´aly pr´ıjem aktu´alnych hodnˆot. To je
potrebn´e napr´ıklad pri prenose d´at z burzy, kde s´
u aktu´alne d´ata nevyhnutn´e pre
potreby rozhodovania. Rieˇsenie je tieˇz moˇzn´e pouˇzit’ na prenos meteorologick´
ych d´at,
ako s´
u napr´ıklad aktu´alne nameran´e teploty. Po ukonˇcen´ı prenosu rieˇsenie umoˇzn
ˇuje
vyhodnotenie ˇstatist´ık o prenose, ako je poˇcet prenesen´
ych paketov alebo inform´acie
o tom, kol’ko paketov dorazilo oneskorene.
V prv´
ych kapitol´ach som sa venoval u
´vodu do problematiky RTP protokolu, jeho
hist´orii a fungovaniu. Tu bol pop´ısan´
y form´at paketu, jeho vytvorenie, prenos a
op¨atovn´e spracovanie. V u
´vode do prenosu d´at typu ˇcasov´
ych priebehov som sa
venoval hlavne spˆosobom prenosu a aktu´alnym rieˇseniam, ktor´e s´
u pon´
ukan´e na
trhu.
V praktickej ˇcasti boli navrhnut´e a implementovan´e programy potrebn´e na generovanie a prenos d´at po sieti. Boli navrhnut´e tri programy. Jeden na generovanie
ˇ sie dva s´
ˇc´ısel a ich n´asledn´e zapisovanie do s´
uboru. Dalˇ
u urˇcen´e na prenos d´at medzi dvoma poˇc´ıtaˇcmi. V z´avere bol otestovan´
y vplyv r´
ychlosti generovania ˇc´ısel na
to, kol’kokr´at bolo prenesen´e jedno ˇc´ıslo. Bolo zisten´e, ˇze na jeden prenos jedn´eho
ˇc´ısla je potrebn´
ych pribliˇzne 20 milisek´
und. Zmena sa prejavila aˇz pri oneskoren´ı
nad tis´ıc milisek´
und pri generovan´ı ˇc´ısel. Druh´
ym meran´ım bolo overenie r´
ychlosti
41
FEI
KKUI
a kvality prenosu paketov na troch prenosov´
ych m´ediach. Tu neboli zaznamenan´e
vel’mi vel’k´e rozdiely, aj ked’ pripojenie cez wifi bolo o trochu pomalˇsie ako pripojenie
cez ehternetov´
y k´abel. Pripojenie cez wifi vˇsak malo podstatne v¨aˇcˇsie oneskorenia
paketov, ako tomu bolo pri ostatn´
ych dvoch pripojeniach. Tretie meranie sl´
uˇzilo na
porovnanie r´
ychlost´ı RTP protokolu, TCP protokolu a UDP protokolu. Potvrdili sa
oˇcak´avan´e v´
ysledky, pri ktor´
ych bolo zisten´e, ˇze najviac paketov bolo prenesen´
ych
cez UDP protokol. Za n´ım nasledoval TCP protokol, ktor´
y vˇsak bol spol’ahlivejˇs´ı. Pri
RTP protokole sa potvrdilo, ˇze pren´aˇsa 50 paketov za sekundu a po 60 sekund´ach
preniesol pribliˇzne 3000 paketov.
Program na generovanie ˇc´ısel ich zapisoval do jedn´eho s´
uboru jedno za druh´
ym. To
umoˇzn
ˇovalo po ukonˇcen´ı prenosu skontrolovat’ ˇci boli prenesen´e vˇsetky vygenerovan´e
ˇc´ısla a ˇci boli prenesen´e v spr´avnom porad´ı. Pri hl’adan´ı posledn´eho zap´ısan´eho
ˇc´ısla musel program na odosielanie ˇc´ısel prejst’ cel´
ym t´
ymto s´
uborom, ˇco pri vel’kom
poˇcte zap´ısan´
ych ˇc´ısel viedlo k spomaleniu cel´eho rieˇsenia. Toto by sa dalo odstr´anit’
zapisovan´ım iba posledn´eho vygenerovan´eho ˇc´ısla do s´
uboru alebo upravit’ program
na ˇc´ıtanie tak, aby hned’ naˇsiel a naˇc´ıtal posledn´e zap´ısan´e ˇc´ıslo.
42
FEI
KKUI
Literat´
ura
Perkins, C. 2003. RTP: Audio and Video for the Internet. In : Addison-Wesley, 2003.
414 s. ISBN 0-672-32249-8
Wikip´edia slovensko: Real-time Transport Protocol [zo dˇ
na 2012-4-18]. Dostupn´e na
internete: http://sk.wikipedia.org/wiki/Real-time_Transport_Protocol
Wikip´edia amerika: Real-time Transport Protocol [zo dˇ
na 2012-4-18]. Dostupn´e na
internete: http://en.wikipedia.org/wiki/Real-time_Transport_Protocol
Networksorcery RFCS [zo dˇ
na 2012-4-18]. Dostupn´e na internete: http://www.
networksorcery.com/enp/rfcs.htm
Networksorcery [zo dˇ
na 2012-4-18]. Dostupn´e na internete: http://www.
networksorcery.com/enp/protocol/rtp.htm
QuoteMedia [zo dˇ
na 2012-5-20]. Dostupn´e na internete: http://www.quotemedia.
com/
Weswit, Lightstreamer [zo dˇ
na 2012-5-20]. Dostupn´e na internete: http://www.
lightstreamer.com/index.htm
Muthukrishnan S.: Data Streams: Algorithms and Applications [zo dˇ
na 20125-20]. Dostupn´e na internete: http://www.cs.uwaterloo.ca/˜david/cs848/
Muthu-Survey.pdf
oRTP [cit 2012-4-18]. Dostupn´e na internete: http://download-mirror.savannah.
gnu.org/releases/linphone/ortp/sources/ortp-0.20.0.tar.gz
Arjan Durresi a Raj Jain: RTP,RTCP and RTSP - Internet protocols for Realtime multimedia communication [zo dˇ
na 2012-5-22]. Dostupn´e na internete: http:
//www.cse.wustl.edu/˜jain/papers/ftp/rtp.pdf
43
Zoznam pr´ıloh
Pr´ıloha A CD m´edium - z´avereˇcn´a pr´aca v elektronickej podobe, pr´ılohy v elektronickej podobe, zdorov´e k´ody programov.
Pr´ıloha B Pouˇz´ıvatel’sk´a pr´ıruˇcka
Pr´ıloha C Syst´emov´a pr´ıruˇcka
Technick´
a univerzita v Koˇ
siciach
Fakulta elektrotechniky a informatiky
Katedra kybernetiky umelej inteligencie
RTP stream d´
at typu ˇ
casov´
ych priebehov
Pouˇ
z´ıvatel’sk´
a pr´ıruˇ
cka
Pr´ıloha B
Martin Mikula
ˇ
’: Ing. Rudolf Jakˇsa, PhD.
Skolitel
Koˇ
sice 2012
FEI
KKUI
Funkcie programov
Na vysk´
uˇsanie prenosu medzi dvoma poˇc´ıtaˇcmi boli vytvoren´e tri programy. Prv´
y
ˇ sie dva s´
sl´
uˇzi na generovanie a z´apis ˇc´ısel do s´
uboru. Dalˇ
u urˇcen´e na prenos aktu´alneho
(posledn´eho zap´ısaneho) ˇc´ısla z jedn´eho poˇc´ıtaˇca na druh´
y. Program send naˇc´ıta
ˇc´ıslo zo s´
uboru a poˇsle ho programu recv. Ten ˇc´ıslo pr´ıjme a zap´ıˇse ho do nov´eho
s´
uboru.
Inˇ
stal´
acia
Hardwarove poˇ
ziadavky
Programy nie s´
u n´aroˇcn´e na technick´e poˇziadavky. Samotn´
y RTP protokol funguje
aj na VoIP telef´onoch.
Minim´
alne poˇ
ziadavky
• Procesor: Intel alebo AMD minim´alne 600 MHz
• 256 MB RAM
• 500 MB diskov´eho priestoru
• siet’ov´a karta
Odpor´
uˇ
can´
e poˇ
ziadavky
• Procesor: Intel alebo AMD minim´alne 2.66 GHz
• 512 MB RAM
• 800 MB - 2 GB diskov´eho priestoru
46
FEI
KKUI
• siet’ov´a karta
Softwarove poˇ
ziadavky
Pre u
´speˇsn´
u kompil´aciu je potrebne mat’ nainˇstalovan´
y gcc kompil´ator. Pre u
´speˇsn´e
zbehnutie kompil´acie je potrebn´e mat’ nainˇstalovan´
y oRTP protokol. Ten je moˇzn´e
stiahnut’ zo str´anky http://download-mirror.savannah.gnu.org/releases/linphone/
ortp/sources/ortp-0.20.0.tar.gz. Na prenos po sieti je potrebn´e mat’ nainˇstalovan´e
tieˇz ovl´adaˇce ku siet’ovej karte.
Inˇ
stal´
acia
cislo
Program sa v prostred´ı Linuxu skompiluje pomocou prikazu gcc -o [nazov spustiteln´eho s´
uboru] cislo.c.
send
Program sa v prostred´ı Linuxu skompiluje pomocou prikazu gcc -o [nazov spustiteln´eho s´
uboru] rtpsend.c -lortp.
recv
Program sa v prostred´ı Linuxu skompiluje pomocou prikazu gcc -o [nazov spustiteln´eho s´
uboru] rtprecv.c -lortp.
47
FEI
KKUI
Pouˇ
zitie programov
cislo
Program sa sp´
uˇst’a pr´ıkazom:
./cislo [zapis.txt] [oneskorenie]
zapis.txt - s´
ubor v txt form´ate, ktor´
y sl´
uˇzi na zaznamen´avanie generovan´
ych ˇc´ısel
oneskorenie - nastavenie oneskorenia pre generovanie n´ahodn´eho ˇc´ısla
send
Program sa sp´
uˇst’a pr´ıkazom:
./send [zapis.txt] [ip adresa] [port]
zapis.txt - tu sa nap´ıˇse n´azov s´
uboru, z ktor´eho bude program ˇc´ıtat’ ˇc´ısla
ip adresa - nastavenie IP adresy, na ktor´
u maj´
u byt’ odoslan´e d´ata
port - ˇc´ıslo portu, na ktorom bude prebiehat’ odosielanie d´at
Program je navrhut´
y tak, aby odosielal ˇc´ısla st´ale. Preto nie je moˇzn´e ho priamo
ukonˇcit’. Program posiela d´ata aj vtedy, ked’ nie je nadviazan´e spojenie. Toto rieˇsenie
bolo navrhnut´e pre pr´ıpady, ak by doˇslo poˇcas prenosu k nejak´emu preruˇseniu, ˇci
uˇz na prenosovom m´ediu alebo chybou na prij´ımacom zariaden´ı. Na obr´azku 5 – 1
je vidno ako bol testovac´ı program spusten´
y a chybov´e hl´asenie, ktor´e sa zobraz´ı v
pr´ıpade preruˇsenia odosielania.
recv
Program sa sp´
uˇst’a pr´ıkazom:
./recv [zapis.txt] [port]
48
FEI
KKUI
Obr. 5 – 1 Na obr´
azku je moˇzn´e vidiet’ zadanie pr´ıkazu na spustenie programu aj s jeho arguˇ
mentami. Dalej
vidno chybov´e hl´
asenie v pr´ıpade preruˇsenia spojenia.
zapis.txt - tu sa nap´ıˇse n´azov s´
uboru, do ktor´eho bude program zapisovat’ prenesen´e
ˇc´ısla
port - ˇc´ıslo portu, na ktorom bude prebiehat’ pr´ıjimanie d´at
Program je navrhut´
y tak, aby prij´ımal ˇc´ısla st´ale. Preto je potrebn´e ho ukonˇcit’
manu´alne a to staˇcen´ım kl´aves CTRL + [C]. Na obr´azku 5 – 2 vidno ako bol spusten´
y testovac´ı program a ako vyzer´a v´
ypis po ukonˇcen´ı prij´ımania. V´
ypis zobrazuje
niekol’ko inform´aci´ı:
• number of rtp packet sent (poˇcet odoslan´
ych paketov),
• number of rtp bytes sent (poˇcet odoslan´
ych bytov),
• number of rtp packet received (poˇcet prijat´
ych paketov),
49
FEI
KKUI
• number of rtp bytes received (poˇcet prijat´
ych bytov),
• number of incoming rtp bytes successfully delivered to the application (poˇcet
u
´speˇsne prijat´
ych bytov),
• number of rtp packet lost (poˇcet straten´
ych paketov),
• number of rtp packets received too late (poˇcet paketov prijat´
ych neskoro),
• number of bad formatted rtp packets (poˇcet zle naform´atovan´
ych paketov),
• number of packets discarded because of queue overflow (poˇcet zahoden´
ych
paketov).
Obr. 5 – 2 Na obr´
azku je moˇzn´e vidiet’ zadanie pr´ıkazu na spustenie programu aj s jeho argumentami. Pod n´ım sa nach´
adzaj´
u ˇstatistick´e inform´acie o prenose.
Chybov´
e hl´
asenia
V pr´ıpade zadania zl´
ych argumentov sa v pr´ıkazovom riadku zobraz´ı chybov´e hl´asenie.
To uˇz´ıvatel’a upozorn´ı ak´e argumenty s´
u potrebn´e na spr´avne spustenie programu.
Ak sa nezadaj´
u spr´avne argunety nedˆojde ani k spusteniu programu.
50
Technick´
a univerzita v Koˇ
siciach
Fakulta elektrotechniky a informatiky
Katedra kybernetiky umelej inteligencie
RTP stream d´
at typu ˇ
casov´
ych priebehov
Syst´
emov´
a pr´ıruˇ
cka
Pr´ıloha C
Martin Mikula
ˇ
’: Ing. Rudolf Jakˇsa, PhD.
Skolitel
Koˇ
sice 2012
FEI
KKUI
Funkcie programov
Na vysk´
uˇsanie prenosu medzi dvoma poˇc´ıtaˇcmi boli vytvoren´e tri programy. Prv´
y
ˇ sie dva s´
sl´
uˇzi na generovanie a z´apis ˇc´ısel do s´
uboru. Dalˇ
u urˇcen´e na prenos aktu´alneho
(posledn´eho zap´ısaneho) ˇc´ısla z jedn´eho poˇc´ıtaˇca na druh´
y. Program send naˇc´ıta
ˇc´ıslo zo s´
uboru a poˇsle ho programu recv. Ten ˇc´ıslo pr´ıjme a zap´ıˇse ho do nov´eho
s´
uboru.
Popis programov
Celkovo boli vytvoren´e tri programy. Jeden jednoduch´
y, ktor´
y generuje nahodn´e
ˇc´ısla. Tie n´asledne zapisuje do textov´eho s´
uboru. N´asledne program send, program
urˇcen´
y na odoielanie d´at, naˇc´ıta aktu´alne ˇc´ıslo, ˇc´ıslo zap´ısan´e ako posledn´e, a poˇsle
ho na zadan´
u IP adresu. Na tejto IP adrese ˇcak´a program recv, program urˇcen´
y na
pr´ıjem d´at, ktor´
y n´asledne dan´e ˇc´ıslo prijme a uloˇz´ı ho do textov´eho s´
uboru.
cislo - program urˇcen´
y na generovanie ˇc´ısel a ich z´apis do textov´eho s´
uboru
send - program pouˇz´ıvan´
y na naˇc´ıtanie a odoslanie ˇc´ısel
recv - program pouˇz´ıvan´
y na prij´ımanie ˇc´ısel a ich n´asledn´
y z´apis do textov´eho
s´
uboru
Popis u
´ dajov´
ych ˇ
strukt´
ur a funkci´ı
send
#include <o r t p / o r t p . h>
#include <s i g n a l . h>
52
FEI
KKUI
Obr. 5 – 3 V´
yvojov´
y diagram pre program send, program na odosielanie d´at.
53
FEI
KKUI
#include < s t d l i b . h>
#i f n d e f
WIN32
#include <s y s / t y p e s . h>
#include <s y s / time . h>
#include <s t d i o . h>
#include <time . h>
#endif
int runcond =1;
void s t o p h a n d l e r ( int signum )
{
runcond =0;
}
/∗ v ´y p i s , k t o r ´y sa z o b r a z´ı po z a d a n´ı n e s p r ´a v n y c h parametrov ∗/
s t a t i c const char ∗ h e l p=
” usage : send
f i l e n a m e d e s t i p 4 a d d r d e s t p o r t . \ n” ;
int main ( int argc , char ∗ argv [ ] ) {
RtpSession ∗ s e s s i o n ;
unsigned char b u f f e r [ 1 6 0 ] ; /∗ v y h r a d´ı 160 znakov na p r e n o s ˇc ´ı s l a ∗/
int i ;
FILE ∗ i n f i l e ; /∗ v s t u p n´y t e x t o v ´y s u
´ b o r ∗/
char ∗ s s r c ; /∗ p r´ıp r a v a SSRC∗/
u i n t 3 2 t u s e r t s =0; /∗ ˇc ´ı s l o pre timestamp ∗/
int e ;
char buf [ 1 6 0 ] ;
54
FEI
KKUI
/∗ o v e r e n i e p oˇc t u zadan´y ch argumentov ∗/
i f ( argc <4){
p r i n t f ( ”%s ” , h e l p ) ;
return −1;
}
/∗ i n i c i a l i z ´a c i a RTP p r o t o k o l u ∗/
ortp init ();
ortp scheduler init ();
o r t p s e t l o g l e v e l m a s k (ORTP MESSAGE|ORTP WARNING|ORTP ERROR) ;
s e s s i o n=r t p s e s s i o n n e w (RTP SESSION SENDONLY ) ;
rtp session set scheduling mode ( session , 1 ) ;
rtp session set blocking mode ( session , 1 ) ;
r t p s e s s i o n s e t c o n n e c t e d m o d e ( s e s s i o n ,TRUE) ;
r t p s e s s i o n s e t r e m o t e a d d r ( s e s s i o n , argv [ 2 ] , a t o i ( argv [ 3 ] ) ) ;
rtp session set payload type ( session , 0 ) ;
/∗ o t v o r e n i e t e x t o v e h o s u
´ b o r u na n a ˇc´ı t a n i e ˇc ´ı s e l ∗/
#i f n d e f
WIN32
i n f i l e =f o p e n ( argv [ 1 ] , ” r ” ) ;
#e l s e
i n f i l e =f o p e n ( argv [ 1 ] , ” rb ” ) ;
#endif
i f ( i n f i l e==NULL) {
p e r r o r ( ” Cannot open f i l e ” ) ;
return −1;
55
FEI
KKUI
}
s i g n a l ( SIGINT , s t o p h a n d l e r ) ;
/∗ a l g o r i t m u s urˇc en´y na p r e n o s ˇc ´ı s e l ∗/
while ( 1 ) {
while ( ! f e o f ( i n f i l e ) )
f s c a n f ( i n f i l e , ”%s ” , buf ) ;
s t r n c p y ( b u f f e r , buf , s i z e o f ( b u f f e r ) ) ;
i=s i z e o f ( b u f f e r ) ;
rtp session send with ts ( session , buffer , i , user ts ) ;
u s e r t s +=160;
rewind ( i n f i l e ) ;
}
/∗ u k o nˇc e n i e RTP p r o t o k o l u a v y p´ı s a n i e ˇs t a t i s t´ı k o p r e n o s e ∗/
fclose ( infile );
rtp session destroy ( session );
ortp exit ();
ortp global stats display ();
return 0 ;
}
recv
#include <o r t p / o r t p . h>
#include <s i g n a l . h>
56
FEI
KKUI
Obr. 5 – 4 V´
yvojov´
y diagram pre program recv, program na prij´ımanie d´at.
57
FEI
KKUI
#include < s t d l i b . h>
#i f n d e f
WIN32
#include <u n i s t d . h>
#include <s t d i o . h>
#include <s y s / t y p e s . h>
#include < s t d l i b . h>
#endif
int cond =1;
void s t o p h a n d l e r ( int signum )
{
cond =0;
}
void s s r c c b ( R t p S e s s i o n ∗ s e s s i o n )
{
p r i n t f ( ” hey , t he s s r c has changed ! \ n” ) ;
}
/∗ v ´y p i s , k t o r ´y sa z o b r a z´ı po z a d a n´ı n e s p r ´a v n y c h parametrov ∗/
s t a t i c char ∗ h e l p=” usage : r e c v
f i l e n a m e l o c p o r t \n” ;
#define MULAW 0
#define ALAW 1
#i f d e f i n e d (
hpux ) && HAVE SYS AUDIO H
#include <s y s / audio . h>
58
FEI
KKUI
#endif
int main ( int argc , char∗ argv [ ] ) {
RtpSession ∗ s e s s i o n ;
unsigned char b u f f e r [ 1 6 0 ] ; /∗ v y h r a d´ı 160 znakov na p r e n o s ˇc ´ı s l a ∗/
int e r r ;
u i n t 3 2 t t s =0; /∗ ˇc ´ı s l o pre timestamp ∗/
int s t r e a m r e c e i v e d =0; /∗ p oˇc e t p r i j a t ´y c h streamov ∗/
FILE ∗ o u t f i l e ; /∗ v´y s t u p n´y t e x t o v ´y s u
´ b o r ∗/
int l o c a l p o r t ; /∗ p o r t , na ktorom bude komunik´a cia ∗/
int have more ;
int i ;
b o o l t adapt=TRUE;
/∗ k o n t r o l a v s t u p n´y c h parametrov ∗/
i f ( argc <3){
p r i n t f ( ”%s ” , h e l p ) ;
return −1;
}
/∗ k o n t r o l a zadan´e ho ˇc ´ı s l a p o r t u ∗/
l o c a l p o r t=a t o i ( argv [ 2 ] ) ;
i f ( l o c a l p o r t <=0) {
p r i n t f ( ”%s ” , h e l p ) ;
return −1;
}
/∗ k o n t r o l a p r i p r a v e n o s t i t e x t o v ´e h o s u
´ b o r u ∗/
o u t f i l e=f o p e n ( argv [ 1 ] , ” a+” ) ;
i f ( o u t f i l e==NULL) {
p e r r o r ( ” Cannot open f i l e f o r w r i t i n g ” ) ;
59
FEI
KKUI
return −1;
}
/∗ i n i c i a l i z ´a c i a RTP p r o t o k o l u ∗/
ortp init ();
ortp scheduler init ();
ortp set log level mask
(ORTP DEBUG|ORTP MESSAGE|ORTP WARNING|ORTP ERROR) ;
s i g n a l ( SIGINT , s t o p h a n d l e r ) ;
s e s s i o n=r t p s e s s i o n n e w (RTP SESSION RECVONLY ) ;
rtp session set scheduling mode ( session , 1 ) ;
rtp session set blocking mode ( session , 1 ) ;
r t p s e s s i o n s e t l o c a l a d d r ( s e s s i o n , ” 0 . 0 . 0 . 0 ” , a t o i ( argv [ 2 ] ) ) ;
r t p s e s s i o n s e t c o n n e c t e d m o d e ( s e s s i o n ,TRUE) ;
r t p s e s s i o n s e t s y m m e t r i c r t p ( s e s s i o n ,TRUE) ;
rtp session set payload type ( session , 0 ) ;
rtp session signal connect
( s e s s i o n , ” s s r c c h a n g e d ” , ( RtpCallback ) s s r c c b , 0 ) ;
rtp session signal connect
( s e s s i o n , ” s s r c c h a n g e d ” , ( RtpCallback ) r t p s e s s i o n r e s e t , 0 ) ;
/∗ a l g o r i t m u s urˇc en´y na p r´ıj e m ˇc ´ı s e l ∗/
while ( cond )
{
have more =1;
while ( have more ){
e r r=r t p s e s s i o n r e c v w i t h t s ( s e s s i o n , b u f f e r , 1 6 0 , t s ,& have more ) ;
i f ( e r r >0) s t r e a m r e c e i v e d =1;
i f ( ( s t r e a m r e c e i v e d ) && ( e r r >0)) {
60
FEI
KKUI
int c = a t o i ( b u f f e r ) ;
f p r i n t f ( o u t f i l e , ”%i \n” , c ) ;
}
}
t s +=160;
}
/∗ u k o nˇc e n i e RTP p r o t o k o l u a v y p´ı s a n i e ˇs t a t i s t´ı k o p r e n o s e ∗/
fclose ( outfile );
rtp session destroy ( session );
ortp exit ();
ortp global stats display ();
return 0 ;
}
Inˇ
stal´
acia
Hardwarove poˇ
ziadavky
Programy nie s´
u n´aroˇcn´e na technick´e poˇziadavky. Samotn´
y RTP protokol funguje
aj na VoIP telef´onoch.
Minim´
alne poˇ
ziadavky
• Procesor: Intel alebo AMD minim´alne 600 MHz
• 256 MB RAM
61
FEI
KKUI
• 500 MB diskov´eho priestoru
• siet’ov´a karta
Odpor´
uˇ
can´
e poˇ
ziadavky
• Procesor: Intel alebo AMD minim´alne 2.66 GHz
• 512 MB RAM
• 800 MB - 2 GB diskov´eho priestoru
• siet’ov´a karta
Softwarove poˇ
ziadavky
Pre u
´speˇsn´
u kompil´aciu je potrebne mat’ nainˇstalovan´
y gcc kompil´ator. Pre u
´speˇsn´e
zbehnutie kompil´acie je potrebn´e mat’ nainˇstalovan´
y oRTP protokol. Ten je moˇzn´e
stiahnut’ zo str´anky http://download-mirror.savannah.gnu.org/releases/linphone/
ortp/sources/ortp-0.20.0.tar.gz. Na prenos po sieti je potrebn´e mat’ nainˇstalovan´e
tieˇz ovl´adaˇce ku siet’ovej karte.
Inˇ
stal´
acia
cislo
Program sa v prostred´ı Linuxu skompiluje pomocou prikazu gcc -o [nazov spustiteln´eho s´
uboru] cislo.c.
62
FEI
KKUI
send
Program sa v prostred´ı Linuxu skompiluje pomocou prikazu gcc -o [nazov spustiteln´eho s´
uboru] rtpsend.c -lortp.
recv
Program sa v prostred´ı Linuxu skompiluje pomocou prikazu gcc -o [nazov spustiteln´eho s´
uboru] rtprecv.c -lortp.
63
Download

RTP stream dát typu časových priebehov