Wakati sisi, tunazungumza kwenye simu ya IP, tunasikia sauti ya mpatanishi kwenye simu, au, kwa kutumia mfumo wa mkutano wa video, tunawasiliana na wenzetu na jamaa, tunabadilisha mkondo unaoendelea wa data. Wakati wa kusambaza data ya utiririshaji kama vile sauti na video kwenye mtandao wa pakiti, ni muhimu sana kutumia njia zinazotatua matatizo yafuatayo:

• Kuondoa Athari ya Kupoteza Pakiti
• Kurejesha utaratibu na kudhibiti kuwasili kwa pakiti
• Athari ya kuchelewesha laini (jitter)

Ilitengenezwa kwa madhumuni haya RTP(Itifaki ya Usafiri ya Wakati Halisi) ni itifaki ya uhamishaji ya wakati halisi ambayo itajadiliwa katika makala ya leo. Itifaki iliundwa na Kikundi Kazi cha Usafiri wa Sauti na Video cha IETF na inaelezwa katika mapendekezo ya RFC 3550.

Kama kanuni, RTP inafanya kazi juu ya itifaki ya UDP (Itifaki ya Datagram ya Mtumiaji), kwani wakati wa kusambaza data ya multimedia ni muhimu sana kuhakikisha utoaji wake kwa wakati.

RTP inajumuisha uwezo wa kubainisha aina ya upakiaji na kugawa nambari ya mfuatano wa pakiti kwenye mtiririko, pamoja na matumizi ya mihuri ya muda.

Kwa upande wa kutuma, kila pakiti imewekwa alama na muhuri wa muda, upande wa kupokea huipokea na huamua ucheleweshaji wa jumla, baada ya hapo tofauti katika ucheleweshaji wa jumla huhesabiwa na jitter imedhamiriwa. Kwa hivyo, inakuwa inawezekana kuweka kuchelewa mara kwa mara kwa kutoa pakiti na hivyo kupunguza athari za jitter.

Kazi nyingine ya RTP inahusishwa na hasara zinazowezekana za pakiti wakati wa kupitia mtandao wa IP, ambao unaonyeshwa kwa kuonekana kwa pause za muda mfupi katika mazungumzo. Ukimya wa ghafla kwenye simu, kama sheria, una athari mbaya kwa msikilizaji, kwa hivyo, na uwezo wa itifaki ya RTP, vipindi kama hivyo vya ukimya hujazwa na kinachojulikana kama "kelele za faraja"

RTP inafanya kazi kwa kushirikiana na itifaki nyingine ya IETF, yaani RTCP (Itifaki ya Udhibiti wa Usafiri wa Wakati Halisi), ambayo imefafanuliwa katika RFC 3550. RTCP imeundwa kukusanya taarifa za takwimu, kuamua ubora wa huduma QoS (Ubora wa Huduma), na pia kwa usawazishaji kati ya mitiririko ya media ya vipindi vya RTP.

Kazi kuu ya RTCP ni kutoa maoni kwa programu ili kuripoti ubora wa habari iliyopokelewa. Washiriki katika kipindi cha RTCP wanabadilishana taarifa kuhusu idadi ya pakiti zilizopokelewa na kupotea, thamani ya jitter, kuchelewa, n.k. Kulingana na uchambuzi wa habari hii, uamuzi unafanywa kubadili vigezo vya maambukizi, kwa mfano, kupunguza uwiano wa ukandamizaji wa habari ili kuboresha ubora wa maambukizi yake.

Ili kutekeleza majukumu haya, RTCP hutuma ujumbe maalum wa aina fulani:

• S.R. - Ripoti ya Mtumaji - ripoti ya chanzo yenye maelezo ya takwimu kuhusu kipindi cha RTP
• R.R. - Ripoti ya Mpokeaji - ripoti ya mpokeaji yenye maelezo ya takwimu kuhusu kipindi cha RTP
• SDES - ina maelezo ya vigezo vya chanzo, ikiwa ni pamoja na cname (jina la mtumiaji)
• BYE – Huanzisha kusitishwa kwa uanachama wa kikundi
• APP - Maelezo ya kazi za maombi

RTP ni itifaki ya unidirectional, hivyo kuandaa mawasiliano ya njia mbili, vikao viwili vya RTP vinahitajika, moja kwa kila upande.

Kikao cha RTP kinatambuliwa na anwani za IP za washiriki, pamoja na jozi ya bandari za UDP zisizohifadhiwa kutoka kwa aina mbalimbali 16384 - 32767. Kwa kuongeza, kuandaa maoni na maombi, ni muhimu pia kuanzisha RTCP ya njia mbili. kipindi. Kwa vipindi vya RTCP, milango yenye nambari moja kubwa kuliko RTP hutumiwa. Kwa mfano, ikiwa bandari 19554 imechaguliwa kwa RTP, basi kipindi cha RTCP kitachukua bandari 19555. Uundaji wa kipindi cha RTP/RTCP umeonyeshwa wazi katika mchoro ulio hapa chini.

Habari za mchana

Jumla: mfumo wa ufuatiliaji ni changamano iliyounganishwa katika hali isiyoingiliana na n-idadi ya viungo 10-gigabit Ethernet, ambayo "hufuatilia" upitishaji wa mitiririko yote ya video ya RTP iliyopo kwenye trafiki na kuchukua vipimo kwa wakati fulani. muda ili kuzihifadhi baadaye kwenye hifadhidata. Kulingana na data kutoka kwa hifadhidata, ripoti hutolewa mara kwa mara kwa kamera zote.

Ni nini kigumu kuhusu hilo?

Katika mchakato wa kutafuta suluhisho, shida kadhaa ziligunduliwa mara moja:

• Muunganisho usioingilia. Mfumo wa ufuatiliaji unaunganishwa na njia tayari za uendeshaji ambazo viunganisho vingi (kupitia RTSP) tayari vimeanzishwa, seva na mteja tayari wanajua ni bandari gani zinazobadilishwa, lakini hatujui hili mapema. Kuna bandari inayojulikana tu kwa itifaki ya RTSP, lakini mito ya UDP inaweza kupitia bandari za kiholela (kwa kuongeza, ikawa kwamba mara nyingi hukiuka mahitaji ya SHOULD kwa usawa wa usawa / usio wa kawaida wa bandari, angalia rfc3550). Jinsi ya kuamua kuwa pakiti fulani kutoka kwa anwani fulani ya IP ni ya mkondo wa video? Kwa mfano, itifaki ya BitTorrent inafanya kazi vivyo hivyo - katika hatua ya uanzishaji wa unganisho, mteja na seva hukubaliana kwenye bandari, halafu trafiki yote ya UDP inaonekana kama "mkondo mdogo".
• Viungo vilivyounganishwa vinaweza kuwa na zaidi ya mitiririko ya video. Kunaweza kuwa na HTTP, BitTorrent, SSH, na itifaki zingine zozote tunazotumia leo. Kwa hivyo, mfumo lazima utambue kwa usahihi mitiririko ya video ili kuwatenganisha na trafiki nyingine. Jinsi ya kufanya hivyo kwa wakati halisi na viungo 8 vya gigabit kumi? Bila shaka, kwa kawaida sio 100% kamili, hivyo trafiki ya jumla haitakuwa gigabits 80 / s, lakini kuhusu 50-60, lakini hii sio kidogo sana.
• Scalability. Ambapo tayari kuna mitiririko mingi ya video, kunaweza kuwa na zaidi yao, kwani ufuatiliaji wa video umejidhihirisha kwa muda mrefu kuwa zana bora. Hii inaonyesha kwamba lazima kuwe na hifadhi kwa ajili ya uzalishaji na hifadhi ya viungo.

Tunatafuta suluhisho linalofaa ...

Kwa kawaida tulitafuta kutumia uzoefu wetu kikamilifu. Wakati uamuzi ulipofanywa, tayari tulikuwa na utekelezaji wa usindikaji wa pakiti za ethernet kwenye kifaa kinachoendeshwa na FPGA cha Berkut-MX (rahisi - MX). Kwa kutumia Berkut-MX, tuliweza kupata sehemu muhimu za uchambuzi kutoka kwa vichwa vya pakiti za Ethernet. Kwa bahati mbaya, hatukuwa na uzoefu wa kuchakata kiasi kama hicho cha trafiki kwa kutumia seva za "kawaida", kwa hivyo tuliangalia suluhisho kama hilo kwa tahadhari ...

Ingeonekana kuwa tulichopaswa kufanya ni kutumia tu njia kwa pakiti za RTP na ufunguo wa dhahabu ungekuwa mfukoni mwetu, lakini MX inaweza tu kuchakata trafiki, haina uwezo wa uhasibu na kuhifadhi takwimu. Hakuna kumbukumbu ya kutosha katika FPGA kuhifadhi miunganisho iliyopatikana (mchanganyiko wa bandari ya IP-IP), kwa sababu kwenye kiunga cha 2x10-gigabit kinachoingia kwenye pembejeo kunaweza kuwa na mitiririko ya video elfu 15, na kwa kila moja unahitaji " kumbuka” idadi ya pakiti zilizopokelewa , idadi ya pakiti zilizopotea, na kadhalika... Zaidi ya hayo, kutafuta kwa kasi hiyo na kwa kiasi hicho cha data, chini ya usindikaji usio na hasara, inakuwa kazi isiyo ya kawaida.

Ili kupata suluhu, ilitubidi "kuchimba zaidi" na kubaini ni kanuni gani tutatumia kupima ubora na kutambua mitiririko ya video.

Ni nini kinachoweza kupimwa kwa kutumia sehemu za pakiti ya RTP?

Kutoka kwa maelezo ni wazi kuwa kutoka kwa mtazamo wa vipimo vya ubora katika pakiti ya RTP, tunavutiwa na nyanja zifuatazo:

• nambari ya mlolongo - counter 16-bit ambayo huongezeka kwa kila pakiti iliyotumwa;
• timestamp - timestamp, kwa h.264 thamani ya sampuli ni 1/90000 s (yaani inalingana na mzunguko wa 90 KHz);
• Alama kidogo. Katika rfc3550 inaelezewa kwa ujumla kuwa biti hii imekusudiwa kuonyesha matukio "muhimu", lakini kwa kweli, kamera mara nyingi hutumia biti hii kuashiria mwanzo wa fremu ya video na pakiti maalum zilizo na habari ya SPS/PPS.

Ni dhahiri kuwa nambari ya mlolongo hukuruhusu kuamua vigezo vifuatavyo vya mtiririko:

• kupoteza sura;
• tuma tena pakiti (duplicate);
• kubadilisha utaratibu wa kuwasili (kupanga upya);
• kuanzisha upya kamera ikiwa kuna "pengo" kubwa katika mlolongo.

Muhuri wa saa hukuruhusu kupima:

• kuchelewesha tofauti (pia huitwa jitter). Katika kesi hii, counter ya 90 KHz lazima ifanye kazi kwenye upande wa kupokea;
• kimsingi, kuchelewa kwa kifungu cha pakiti. Lakini ili kufanya hivyo, unahitaji kusawazisha wakati wa kamera na muhuri wa muda, na hii inawezekana ikiwa kamera itasambaza ripoti za mtumaji (RTCP SR), ambayo kwa ujumla sio sahihi, kwa sababu. katika maisha halisi, kamera nyingi hupuuza ujumbe wa RTCP SR (karibu nusu ya kamera ambazo tumefanya kazi nazo).

Kweli, M-bit hukuruhusu kupima kiwango cha fremu. Kweli, fremu za SPS/PPS za itifaki ya h.264 zinaleta hitilafu, kwa sababu sio fremu za video. Lakini inaweza kupunguzwa kwa kutumia taarifa kutoka kwa kichwa cha kitengo cha NAL, ambacho hufuata kichwa cha RTP kila wakati.

Algorithms ya kina ya vigezo vya kupimia ni zaidi ya upeo wa kifungu; sitaingia kwa kina. Ikiwa una nia, rfc3550 ina msimbo wa mfano wa kuhesabu hasara na fomula ya kuhesabu jitter. Hitimisho kuu ni kwamba kupima sifa za msingi za mkondo wa usafiri, mashamba machache tu kutoka kwa pakiti za RTP na vitengo vya NAL vinatosha. Lakini habari iliyobaki haihusiki katika vipimo na inaweza na inapaswa kutupwa!

Jinsi ya kutambua mitiririko ya RTP?

Ili kudumisha takwimu, maelezo yaliyopatikana kutoka kwa kichwa cha RTP lazima "yaunganishwe" kwa kitambulishi fulani cha kamera (mtiririko wa video). Kamera inaweza kutambuliwa kipekee na vigezo vifuatavyo:

• Chanzo na anwani za IP
• Chanzo na bandari fikio
• SSRC. Ni muhimu sana wakati mito kadhaa inatangazwa kutoka kwa IP moja, i.e. katika kesi ya encoder multiport.

Kinachofurahisha ni kwamba mwanzoni tulitambua kamera kwa kutumia IP na SSRC pekee, tukitegemea wazo kwamba SSRC inapaswa kuwa nasibu, lakini katika mazoezi ilibainika kuwa kamera nyingi ziliweka SSRC kwa thamani isiyobadilika (sema 256). Inaonekana hii ni kutokana na kuokoa rasilimali. Kwa hivyo, tulilazimika kuongeza milango kwenye kitambulisho cha kamera. Hii ilitatua tatizo la pekee kabisa.

Jinsi ya kutenganisha pakiti za RTP kutoka kwa trafiki zingine?

Swali linabaki: Berkut-MX, baada ya kupokea pakiti, ataelewaje kuwa ni RTP? Kichwa cha RTP hakina kitambulisho dhahiri kama IP, hakina cheki, kinaweza kupitishwa kupitia UDP na nambari za bandari ambazo huchaguliwa kwa nguvu wakati wa kuanzisha muunganisho. Lakini kwa upande wetu, viunganisho vingi tayari vimeanzishwa kwa muda mrefu na unaweza kungojea kwa muda mrefu sana kwa kusanikisha tena.

Ili kutatua tatizo hili, rfc3550 (Kiambatisho A.1) inapendekeza kuangalia bits za toleo la RTP - hii ni bits mbili, na aina ya aina ya malipo (PT) ni bits saba, ambayo katika kesi ya aina ya nguvu inachukua aina ndogo. Tumegundua kwa vitendo kuwa kwa kamera nyingi tunazofanya kazi nazo, PT iko kati ya 96 hadi 100.

Kuna sababu nyingine - usawa wa bandari, lakini kama mazoezi yameonyesha, haizingatiwi kila wakati, kwa hivyo ilibidi iachwe.

Kwa hivyo, tabia ya Berkut-MX ni kama ifuatavyo.

1. Tunapokea kifurushi, tukichanganue kwenye uwanja;
2. ikiwa toleo ni 2 na aina ya malipo iko ndani ya mipaka maalum, basi tunatuma vichwa kwa seva.

Kwa wazi, kwa njia hii kuna mazuri ya uongo, kwa sababu Sio tu pakiti za RTP zinaweza kuanguka chini ya vigezo rahisi kama hivyo. Lakini ni muhimu kwetu kwamba hakika hatutakosa pakiti ya RTP, na seva itachuja vifurushi "vibaya".

Ili kuchuja kesi za uwongo, seva hutumia utaratibu unaosajili chanzo cha trafiki ya video katika pakiti kadhaa zilizopokelewa kwa mpangilio (pakiti ina nambari ya mlolongo!). Ikiwa pakiti kadhaa zilifika na nambari zinazofuatana, basi hii sio bahati mbaya na tunaanza kufanya kazi na mtiririko huu. Algorithm hii iligeuka kuwa ya kuaminika sana.

Tuendelee...

Baada ya kugundua kuwa habari zote zinazokuja kwenye pakiti hazihitajiki kupima ubora na kutambua mitiririko, tuliamua kuweka kazi kubwa na muhimu ya wakati wa kupokea na kutenganisha sehemu za pakiti za RTP kwenye Berkut-MX, ambayo ni, kwenye FPGA. "Inapata" mkondo wa video, huchanganua pakiti, huacha tu mashamba muhimu na kuituma kwenye handaki ya UDP kwenye seva ya kawaida. Seva huchukua vipimo kwa kila kamera na kuhifadhi matokeo kwenye hifadhidata.

Matokeo yake, seva haifanyi kazi na 50-60 Gigabit / s, lakini kwa kiwango cha juu cha 5% (hii ni sawa na uwiano wa data iliyotumwa kwa ukubwa wa wastani wa pakiti). Hiyo ni, pembejeo ya mfumo mzima ni 55 Gigabit / s, na si zaidi ya 3 Gigabit / s hufikia seva!

Kama matokeo, tulimaliza na usanifu ufuatao:

Na tulipokea matokeo ya kwanza katika usanidi huu wiki mbili baada ya kuweka vipimo vya awali vya kiufundi!

Je, seva inaishia kufanya nini?

Kwa hivyo seva hufanya nini katika usanifu wetu? Kazi zake:

• sikiliza tundu la UDP na usome sehemu zilizo na vichwa vilivyojaa kutoka kwake;
• changanua pakiti zinazoingia na utoe sehemu za vichwa vya RTP pamoja na vitambulisho vya kamera;
• unganisha sehemu zilizopokelewa na zile zilizopokelewa hapo awali, na uelewe ikiwa pakiti zilipotea, ikiwa pakiti zilitumwa tena, ikiwa mpangilio wa kuwasili ulibadilika, ni tofauti gani ya ucheleweshaji wa pakiti (jitter), nk;
• rekodi data iliyopimwa kwenye hifadhidata na kumbukumbu ya wakati;
• kuchambua hifadhidata na kutoa ripoti, tuma arifa kuhusu matukio muhimu (hasara kubwa ya pakiti, upotezaji wa pakiti kutoka kwa kamera fulani, nk).

Ikizingatiwa kuwa jumla ya trafiki kwenye pembejeo ya seva ni kama Gigabit/s 3, seva hustahimili hata ikiwa hatutumii DPDK yoyote, lakini fanya kazi tu kupitia tundu la Linux (hapo awali tumeongeza saizi ya bafa ya tundu, bila shaka). Kwa kuongeza, itawezekana kuunganisha viungo vipya na MX, kwa sababu ukingo wa utendaji unabaki.

Hivi ndivyo sehemu ya juu ya seva inavyoonekana (hii ni sehemu ya juu ya kontena moja la lxc, ripoti hutolewa katika nyingine):

Inaonyesha kuwa mzigo mzima wa kuhesabu vigezo vya ubora na kuzingatia takwimu husambazwa sawasawa katika michakato minne. Tulifaulu kufikia usambazaji kama huo kwa kutumia hashing katika FPGA: chaguo la kukokotoa la heshi hukokotolewa na IP, na vipande vya mpangilio wa chini vya heshi inayotokana huamua nambari ya bandari ya UDP ambayo takwimu zitaenda. Ipasavyo, kila mchakato unaosikiliza kwenye bandari yake hupokea takriban kiasi sawa cha trafiki.

Hasara na faida

Ni wakati wa kujisifu na kukubali mapungufu ya suluhisho.

Nitaanza na faida:

• hakuna hasara kwenye kiolesura kilicho na viungo vya 10G. Kwa kuwa FPGA inachukua "athari" nzima, tunaweza kuwa na uhakika kwamba kila pakiti itachambuliwa;
• ili kufuatilia kamera 55,000 (au zaidi) unahitaji seva moja tu na kadi moja ya 10G. Kwa sasa tunatumia seva kulingana na Xeons 2 zilizo na cores 4 za 2400 MHz kila moja. Kutosha kwa vipuri: sambamba na ukusanyaji wa habari, ripoti zinazalishwa;
• ufuatiliaji wa "dazeni" 8 (viungo vya 10G) inafaa katika vitengo 2-3 tu: sio daima kuna nafasi nyingi na nguvu katika rack kwa mfumo wa ufuatiliaji;
• wakati wa kuunganisha viungo kutoka kwa MXs kwa njia ya kubadili, unaweza kuongeza viungo vipya bila kuacha ufuatiliaji, kwa sababu huna haja ya kuingiza bodi yoyote kwenye seva na huna haja ya kuizima ili kufanya hivyo;
• seva haijapakiwa na data, inapokea tu kile kinachohitajika;
• vichwa vya habari kutoka kwa MX vinakuja kwenye pakiti kubwa ya Ethernet, ambayo inamaanisha kuwa processor haitazidiwa na usumbufu (zaidi ya hayo, hatusahau kuhusu kuunganisha kwa kukatiza).

Ili kuwa wa haki, nitazingatia pia hasara:

• kwa sababu ya uboreshaji madhubuti wa kazi mahususi, kuongeza usaidizi kwa sehemu mpya au itifaki kunahitaji mabadiliko kwenye msimbo wa FPGA. Hii inasababisha muda mwingi uliotumika kuliko ikiwa tulifanya vivyo hivyo kwenye kichakataji. Wote katika maendeleo na kupima, na katika kupelekwa;
• habari za video hazijachanganuliwa hata kidogo. Huenda kamera inarekodi kioo kinachoning'inia mbele yake, au inaweza kuwa inaelekea upande usiofaa. Ukweli huu hautazingatiwa. Sisi, bila shaka, tulitoa uwezo wa kurekodi video kutoka kwa kamera iliyochaguliwa, lakini operator hawezi kupitia kamera zote 55,000!
• seva na vifaa vinavyoendeshwa na FPGA ni ghali zaidi kuliko seva moja au mbili;)

Muhtasari

Mwishowe, tuliishia na programu na changamano ya maunzi ambayo tunaweza kudhibiti sehemu inayochanganua pakiti kwenye violesura na sehemu inayohifadhi takwimu. Udhibiti kamili juu ya nodi zote za mfumo ulituokoa kihalisi wakati kamera zilipoanza kubadilishwa hadi kwa modi iliyoingiliana ya RTSP/TCP. Kwa sababu katika kesi hii, kichwa cha RTP haipatikani tena kwenye pakiti kwa kukabiliana na fasta: inaweza kupatikana popote, hata kwenye mpaka wa pakiti mbili (nusu ya kwanza katika moja, ya pili kwa nyingine). Ipasavyo, algorithm ya kupata kichwa cha RTP na sehemu zake imebadilika sana. Ilitubidi kufanya TCP kukusanyika tena kwenye seva kwa miunganisho yote 50,000 - kwa hivyo mzigo mkubwa juu.

Hatukuwa tumewahi kufanya kazi katika uga wa maombi ya upakiaji wa juu hapo awali, lakini tuliweza kutatua tatizo kwa kutumia ujuzi wetu wa FPGA na ikawa vizuri sana. Kuna hata hifadhi iliyoachwa - kwa mfano, mito mingine 20-30,000 inaweza kushikamana na mfumo na kamera 55,000.

Niliacha urekebishaji wa mifumo ndogo ya Linux (usambazaji wa foleni za kukatiza, kuongezeka kwa buffers, ugawaji wa moja kwa moja wa cores kwa michakato maalum, n.k.) nje ya upeo wa makala, kwa sababu Mada hii tayari imefunikwa vizuri sana.

Sijaelezea kila kitu, nimekusanya reki nyingi, kwa hivyo usisite kuuliza maswali :)

Shukrani nyingi kwa kila mtu ambaye alisoma hadi mwisho!

itifaki za RTP na RSVP,

http://www.isuct.ru/~ivt/books/NETWORKING/NET10/269/pa.html

Programu za kisasa haziwezi kumudu pakiti zao kuchelewa kufika. Itifaki mbili (RTP na PSVP) huhakikisha utoaji kwa wakati huku zikidumisha ubora wa huduma.

Ukuaji unaoendelea wa Mtandao na mitandao ya kibinafsi huweka mahitaji mapya kwenye bandwidth. Programu za seva ya mteja ni bora zaidi kuliko Telnet kulingana na kiasi cha data iliyohamishwa. Mtandao Wote wa Ulimwenguni umesababisha ongezeko kubwa la grafu ya habari ya picha. Leo, kwa kuongeza, maombi ya sauti na video huweka mahitaji yao maalum kwenye mitandao iliyojaa tayari.

Ili kukidhi mahitaji haya yote, kuongeza uwezo wa mtandao pekee haitoshi. Kinachohitajika sana ni usimamizi mzuri wa ratiba na udhibiti wa mzigo wa kazi.

Kihistoria, mitandao inayotegemea IP imetoa programu zote huduma rahisi tu ya kutoa data kila inapowezekana. Walakini, mahitaji yamebadilika kwa wakati. Mashirika ambayo yametumia mamilioni ya dola kusakinisha mtandao unaotegemea IP ili kusafirisha data kati ya LAN sasa yanapata kuwa usanidi kama huo hauwezi kuauni programu mpya za media titika za wakati halisi.

ATM ndiyo teknolojia pekee ya mtandao ambayo iliundwa awali ili kusaidia trafiki ya kawaida ya TCP na UDP pamoja na trafiki ya wakati halisi. Hata hivyo, kuzingatia ATM kunamaanisha ama kuunda miundombinu mpya ya mtandao kwa trafiki ya wakati halisi au kuchukua nafasi ya usanidi uliopo wa msingi wa IP, ambao wote watakuwa ghali sana.

Kwa hivyo, hitaji la kusaidia aina nyingi za trafiki na ubora tofauti wa mahitaji ya huduma ndani ya usanifu wa TCP/IP ni kubwa sana. Zana mbili muhimu zimeundwa kutatua tatizo hili: Itifaki ya Usafiri wa Wakati Halisi (RTP) na Itifaki ya Kuhifadhi Rasilimali (RSVP).

RTP huhakikisha uwasilishaji wa data kwa mpokeaji mmoja au zaidi kwa kuchelewa ndani ya mipaka maalum. Hii inamaanisha kuwa data inaweza kuchezwa kwa wakati halisi. RSVP inaruhusu mifumo ya mwisho kuhifadhi rasilimali za mtandao ili kupata ubora unaohitajika wa huduma, hasa rasilimali za trafiki ya wakati halisi kupitia itifaki ya RTP.

Itifaki ya safu ya usafiri inayotumiwa sana ni TCP. Ingawa TCP inaweza kusaidia aina mbalimbali za programu zilizosambazwa, haifai kwa programu za wakati halisi.

Katika programu za wakati halisi, mtumaji hutengeneza mtiririko wa data kwa kasi isiyobadilika, na mpokeaji(wa)pokeaji lazima atoe data hiyo kwa programu kwa kiwango sawa. Programu kama hizo ni pamoja na mikutano ya sauti na video, usambazaji wa video wa moja kwa moja (kwa uchezaji mara moja), nafasi za kazi zinazoshirikiwa, uchunguzi wa matibabu wa mbali, simu ya kompyuta, uigaji mwingiliano uliosambazwa, michezo ya kubahatisha na ufuatiliaji wa wakati halisi.

Kutumia TCP kama itifaki ya usafiri kwa programu hizi hakuwezekani kwa sababu kadhaa. Kwanza, itifaki hii inaruhusu tu muunganisho kuanzishwa kati ya ncha mbili na kwa hiyo haifai kwa uwasilishaji wa multicast. Inaruhusu utumaji upya wa sehemu zilizopotea ambazo hufika wakati programu ya wakati halisi haijazitarajia tena. Zaidi ya hayo, TCP haina utaratibu unaofaa wa kuhusisha maelezo ya saa na sehemu, ambayo pia ni hitaji la utumaji programu katika wakati halisi.

Itifaki nyingine ya safu ya usafiri inayotumiwa sana, UDP haina mbili za kwanza

mapungufu (viunganisho vya uhakika na uhamishaji wa sehemu zilizopotea), lakini haitoi habari muhimu ya maingiliano. Kwa hivyo, UDP yenyewe haina zana za madhumuni ya jumla ya programu za wakati halisi.

Ingawa kila programu ya wakati halisi inaweza kuwa na njia zake za kuauni utumaji wa wakati halisi, zina mfanano mwingi unaofanya kufafanua itifaki moja kuhitajika sana. Itifaki ya kawaida ya aina hii ni RTP, iliyofafanuliwa katika RFC 1889.

Katika mazingira ya kawaida ya muda halisi, mtumaji huzalisha pakiti kwa kiwango cha mara kwa mara. Wanatumwa kwao kwa vipindi vya kawaida, husafiri kupitia mtandao na hupokelewa na mpokeaji, ambaye huzalisha data kwa wakati halisi baada ya kupokea.

Hata hivyo, kutokana na tofauti ya muda wa kusubiri wakati pakiti zinasafiri kwenye mtandao, hufika kwa vipindi visivyo kawaida. Ili kulipa fidia kwa athari hii, pakiti zinazoingia zimehifadhiwa, zimehifadhiwa kwa muda, na kisha hutolewa kwa kiwango cha mara kwa mara kwa programu inayozalisha pato. Ili mpango huu ufanye kazi, kila pakiti imewekwa muhuri wa muda ili mpokeaji aweze kucheza tena data inayoingia kwa kasi sawa na ya mtumaji.

RTP inasaidia uhamishaji wa data kwa wakati halisi kati ya washiriki wengi wa kipindi. (Kipindi ni muunganisho wa kimantiki kati ya watumiaji wawili au zaidi wa RTP ambao hudumishwa kwa muda wa uhamishaji data. Mchakato wa kufungua kipindi uko nje ya mawanda ya RTP.)

Ingawa RTP inaweza kutumika kwa uwasilishaji wa wakati halisi wa unicast, nguvu yake iko katika usaidizi wake wa utumaji wa utangazaji anuwai. Ili kufanikisha hili, kila kizuizi cha data cha RTP kina kitambulisho cha mtumaji kinachoonyesha ni mshiriki gani anazalisha data. Vizuizi vya data vya RTP pia vina muhuri wa wakati ili data iweze kuchezwa tena kwa vipindi sahihi na mwisho wa kupokea.

Kwa kuongeza, RTP inafafanua muundo wa malipo ya data iliyopitishwa. Kuhusiana moja kwa moja na hii ni dhana ya maingiliano, ambayo mchanganyiko, utaratibu wa utangazaji wa RTP, unawajibika kwa sehemu. Kwa kupokea mitiririko ya pakiti za RTP kutoka kwa chanzo kimoja au zaidi, inazichanganya na kutuma mtiririko mpya wa pakiti za RTP kwa mpokeaji mmoja au zaidi. Mchanganyiko unaweza tu kuchanganya data na pia kubadilisha muundo wake.

Mfano wa maombi ya kichanganyaji ni kuchanganya vyanzo vingi vya sauti. Kwa mfano, tuseme kwamba sehemu ya mifumo katika kipindi fulani cha sauti kila moja itazalisha mtiririko wake wa RTP. Mara nyingi, ni chanzo kimoja tu kinachofanya kazi, ingawa wakati mwingine vyanzo kadhaa "huzungumza" kwa wakati mmoja.

Ikiwa mfumo mpya unataka kushiriki katika kipindi, lakini kiunga chake kwenye mtandao hakina uwezo sahihi wa kutosha wa kuunga mkono mitiririko yote ya RTP, basi kichanganyaji hupokea mitiririko hiyo yote, inaichanganya kuwa moja, na kupitisha mwisho kwa mjumbe mpya wa kikao. Wakati wa kupokea mitiririko mingi, kichanganyaji huongeza maadili ya urekebishaji wa msimbo wa mapigo. Kichwa cha RTP kinachozalishwa na kichanganyaji kinajumuisha vitambulisho vya mtumaji ambaye data yake iko kwenye pakiti.

Kifaa rahisi huzalisha pakiti moja ya RTP inayotoka kwa kila pakiti ya RTP inayoingia. Utaratibu huu, unaoitwa mfasiri, unaweza kubadilisha umbizo la data kwenye pakiti au kutumia seti tofauti ya itifaki za kiwango cha chini kuhamisha data kutoka kikoa kimoja hadi kingine. Kwa mfano, mpokeaji anayetarajiwa asiweze kuchakata mawimbi ya video ya kasi ya juu inayotumiwa na washiriki wengine kwenye kipindi. Kisha mfasiri hubadilisha video hadi umbizo la ubora wa chini ambalo halihitaji kiwango cha juu cha uhamishaji data.

Kila pakiti ya RTP ina kichwa kikuu, na ikiwezekana sehemu za ziada za programu mahususi. Mchele. 4 inaonyesha muundo wa kichwa kikuu. Oktet 12 za kwanza zinajumuisha nyanja zifuatazo:

• shamba la toleo (2 bits): toleo la sasa - pili;
• sehemu ya kuweka pedi (biti 1): Sehemu hii inaashiria uwepo wa pweza mwishoni mwa mzigo. (Padding hutumika wakati programu inahitaji saizi ya upakiaji kuwa mgawo wa, kwa mfano, biti 32.) Katika kesi hii, oktet ya mwisho inabainisha idadi ya pweza za pedi;
• uga wa upanuzi wa kichwa (kidogo 1): uga huu unapowekwa, kichwa kikuu kinafuatwa na kichwa kimoja cha ziada kinachotumiwa katika viendelezi vya RTP vya majaribio;
• idadi ya sehemu ya watumaji (biti 4): sehemu hii ina idadi ya vitambulishi vya mtumaji ambao data yao iko kwenye pakiti, na vitambulisho vyenyewe vikifuata kichwa kikuu;
• sehemu ya alama (biti 1): Maana ya biti ya alama inategemea aina ya malipo. Alama kidogo hutumiwa kuonyesha mipaka ya mtiririko wa data. Kwa upande wa video, inabainisha mwisho wa fremu. Katika kesi ya sauti, inabainisha mwanzo wa hotuba baada ya muda wa kimya;
• Sehemu ya Aina ya Upakiaji (biti 7): Sehemu hii inabainisha aina ya upakiaji na umbizo la data, ikiwa ni pamoja na mbano na usimbaji fiche. Katika hali ya utulivu, mtumaji hutumia aina moja tu ya upakiaji wakati wa kipindi, lakini anaweza kuibadilisha kulingana na mabadiliko ya hali ikiwa imeashiriwa na Itifaki ya Udhibiti wa Usafiri wa Wakati Halisi;
• sehemu ya nambari ya mfuatano (biti 16): kila chanzo huanza kuhesabu pakiti kwa nambari nasibu, ambayo inaongezwa kwa moja kwa kila pakiti ya data ya RTP iliyotumwa. Hii hukuruhusu kugundua upotezaji wa pakiti na kuamua mpangilio wa pakiti zilizo na muhuri wa wakati sawa. Pakiti nyingi zinazofuatana zinaweza kuwa na muhuri wa muda sawa ikiwa kimantiki zilitoka kwa papo hapo (kwa mfano, pakiti za fremu sawa ya video);
• sehemu ya muhuri wa wakati (biti 32): Hii hurekodi hatua kwa wakati ambapo oktet ya data ya upakiaji wa kwanza ilitolewa. Vipimo ambavyo muda umebainishwa katika sehemu hii hutegemea aina ya malipo. Thamani inabainishwa na saa ya ndani ya mtumaji;
• Sehemu ya Kitambulisho cha Chanzo cha Sawazisha: Nambari inayozalishwa bila mpangilio maalum ambayo hutambulisha chanzo ndani ya kipindi.

Kichwa kikuu kinaweza kufuatiwa na sehemu moja au zaidi zinazowatambulisha watumaji ambao data yao iko kwenye mzigo wa malipo. Vitambulisho hivi huingizwa na kichanganyaji.

Itifaki ya RTP inatumika tu kusambaza data ya mtumiaji - kwa kawaida matangazo mengi - kwa washiriki wote kwenye kipindi. Itifaki tofauti ya Kudhibiti Usafiri wa Wakati Halisi (RTCP) hufanya kazi na maeneo mengi ili kutoa maoni kwa watumaji wa RTP na washiriki wengine wa kipindi.

RTCP hutumia itifaki ya msingi ya usafiri kama RTP (kawaida UDP), lakini nambari ya bandari tofauti. Kila mshiriki wa kipindi hutuma pakiti ya RTCP mara kwa mara kwa washiriki wengine wote wa kipindi. RFC 1889 inaeleza kazi tatu zinazofanywa na RTCP.

Kazi ya kwanza ni kutoa ubora wa huduma na maoni katika kesi ya overload. Kwa sababu pakiti za RTCP ni za utangazaji anuwai, washiriki wote katika kipindi wanaweza kutathmini jinsi washiriki wengine wanavyofanya na kupokea vizuri. Ujumbe wa mtumaji huruhusu wapokeaji kutathmini kasi ya data na ubora wa utumaji. Barua pepe za wapokeaji zina maelezo kuhusu matatizo wanayokumbana nayo, ikiwa ni pamoja na kupoteza pakiti na mshtuko mwingi. Kwa mfano, kasi ya biti ya programu ya sauti/video inaweza kupunguzwa ikiwa laini haitoi ubora unaohitajika wa huduma kwa kasi fulani ya biti.

Maoni kutoka kwa wapokeaji pia ni muhimu kwa kutambua makosa katika usambazaji.

Kwa kuchanganua ujumbe kutoka kwa washiriki wote katika kipindi, msimamizi wa mtandao anaweza kubaini kama tatizo fulani linahusu mshiriki mmoja au ni la kawaida.

Kazi kuu ya pili ya RTCP ni kitambulisho cha mtumaji. Pakiti za RTCP zina maelezo ya kawaida ya maandishi ya mtumaji. Hutoa maelezo zaidi kuhusu mtumaji wa pakiti za data kuliko kitambulisho cha chanzo cha kusawazisha kilichochaguliwa kwa nasibu. Pia husaidia mtumiaji kutambua nyuzi za vipindi tofauti. Kwa hivyo, huruhusu mtumiaji kuamua kuwa vipindi tofauti vya sauti na video vinafunguliwa kwa wakati mmoja.

Kazi ya tatu ni kukadiria ukubwa wa kikao na ukubwa. Ili kuhakikisha ubora wa huduma na maoni kwa madhumuni ya kudhibiti msongamano, na pia kwa madhumuni ya kutambua mtumaji, washiriki wote hutuma pakiti za RTCP mara kwa mara. Mzunguko wa maambukizi ya pakiti hizi hupungua kadri idadi ya washiriki inavyoongezeka.

Kwa idadi ndogo ya washiriki, pakiti moja ya RTCP hutumwa kwa zaidi ya kila sekunde tano. RFC 1889 inafafanua algoriti ambapo washiriki hupunguza kiwango cha pakiti za RTCP kulingana na jumla ya idadi ya washiriki. Lengo ni kuweka trafiki ya RTCP isizidi 5% ya jumla ya trafiki ya kipindi.

Madhumuni ya mtandao wowote ni kuwasilisha data kwa mpokeaji yenye ubora wa huduma iliyohakikishwa, ikiwa ni pamoja na matokeo, muda wa kusubiri na ustahimilivu wa mabadiliko ya muda. Kadiri idadi ya watumiaji na programu inavyoongezeka, inakuwa vigumu zaidi kuhakikisha huduma bora.

Kujibu tu juu ya upakiaji haitoshi tena. Kinachohitajika ni chombo ambacho kinaweza kusaidia kuzuia msongamano kabisa, yaani, kuwezesha programu kuhifadhi rasilimali za mtandao kulingana na ubora wa huduma unaohitajika.

Hatua za kuzuia ni muhimu kwa upitishaji wa unicast na upeperushaji anuwai. Katika unicast, maombi mawili yanajadili kiwango maalum cha ubora wa huduma kwa kipindi fulani. Ikiwa mtandao umejaa sana, huenda usiweze kutoa ubora unaohitajika wa huduma. Katika hali hii, maombi yatalazimika kuahirisha kikao hadi nyakati bora au kujaribu kupunguza ubora wa mahitaji ya huduma, ikiwezekana.

Suluhisho katika kesi hii ni kwa maombi ya unicast kuhifadhi rasilimali ili kutoa kiwango kinachohitajika cha huduma. Vipanga njia kwenye njia iliyokusudiwa kisha kutenga rasilimali (kwa mfano, nafasi ya foleni na baadhi ya uwezo wa kiungo kinachotoka). Ikiwa kipanga njia hakiwezi kutenga rasilimali kwa sababu ya ahadi za hapo awali, inaarifu programu. Katika hali hii, programu inaweza kujaribu kuanzisha kipindi kingine chenye ubora wa chini wa mahitaji ya huduma au kukipanga upya hadi tarehe ya baadaye.

Multicast inatoa changamoto ngumu zaidi za kuhifadhi rasilimali. Inaongoza kwa uzalishaji wa kiasi kikubwa cha grafu ya mtandao - katika kesi ya maombi kama vile video, kwa mfano, au wakati kuna kundi kubwa na kutawanywa la wapokeaji. Walakini, trafiki kutoka kwa chanzo cha utangazaji anuwai inaweza kimsingi kupunguzwa kwa kiasi kikubwa.

Kuna sababu mbili za hii. Kwanza, baadhi ya washiriki wa kikundi huenda wasihitaji data kuwasilishwa kutoka chanzo fulani katika muda fulani. Kwa hivyo, washiriki wa kikundi kimoja wanaweza kupokea habari wakati huo huo kupitia njia mbili (kutoka kwa vyanzo viwili), lakini mpokeaji anaweza kuwa na hamu ya kupokea chaneli moja tu.

Pili, baadhi ya wanakikundi wanaweza kuchakata sehemu tu ya habari inayotumwa na mtumaji. Kwa mfano, mtiririko wa video unaweza kuwa na vipengele viwili: kimoja chenye ubora wa chini wa picha na kingine chenye ubora wa juu wa picha. Umbizo hili lina idadi ya algoriti za ukandamizaji wa video: hutengeneza kijenzi cha msingi na picha ya ubora wa chini na kipengee cha ziada chenye msongo wa juu zaidi.

Baadhi ya vipokezi huenda visiwe na nguvu ya kutosha ya kuchakata vipengele vya msongo wa juu, au vinaweza kuunganishwa kwenye mtandao kupitia subnet au kiungo ambacho hakina uwezo wa kutosha wa kubeba mawimbi kamili.

Uhifadhi wa rasilimali huruhusu vipanga njia kubaini mapema kama vinaweza kuwasilisha trafiki ya upeperushaji anuwai kwa wapokeaji wote.

Katika majaribio ya awali ya kutekeleza uhifadhi wa rasilimali na katika relay ya sura na mbinu za ATM, rasilimali muhimu zinaombwa na chanzo cha mkondo wa data. Njia hii ni ya kutosha katika kesi ya maambukizi ya unicast kwa sababu maombi ya kutuma hupeleka data kwa kiwango fulani, na kiwango kinachohitajika cha ubora wa huduma kinajengwa katika muundo wa maambukizi.

Hata hivyo, mbinu hii haiwezi kutumika kwa multicast. Washiriki wa timu tofauti wanaweza kuwa na mahitaji tofauti ya rasilimali. Ikiwa mtiririko asili unaweza kugawanywa katika mipasho midogo, basi baadhi ya washiriki wa kikundi wanaweza kutaka kupokea moja tu kati yao. Hasa, baadhi ya wapokeaji wataweza tu kuchakata kijenzi cha video cha ubora wa chini. Au ikiwa watumaji kadhaa watatangaza kwa kikundi kimoja, basi mpokeaji anaweza kuchagua mtumaji mmoja tu au baadhi yao. Hatimaye, ubora wa mahitaji ya huduma ya wapokeaji tofauti unaweza kutofautiana kulingana na vifaa vya kutoa, nguvu ya kichakataji na kasi ya kiungo.

Kwa sababu hii, uhifadhi wa rasilimali na mpokeaji unaonekana kuwa bora. Watumaji wanaweza kupeana vipanga njia sifa za jumla za trafiki (kama vile kiwango cha data na tofauti), lakini wapokeaji lazima wabaini kiwango cha ubora wa huduma wanachohitaji. Vipanga njia basi hujumlisha maombi ya ugawaji wa rasilimali katika sehemu za kawaida za mti wa usambazaji.

RSVP inategemea dhana tatu zinazohusiana na mtiririko wa data: kipindi, vipimo vya mtiririko, na vipimo vya kichujio. Kipindi ni mtiririko wa data unaotambuliwa na lengwa lake. Kumbuka kuwa dhana hii ni tofauti na ile ya kipindi cha RTP, ingawa vipindi vya RSVP na RTP vinaweza kuwa na mawasiliano ya moja kwa moja. Mara tu kipanga njia huhifadhi rasilimali kwa lengwa mahususi, huchukulia hili kama mwanzo wa kipindi na kutenga rasilimali kwa muda wa kipindi hicho.

Ombi la kuhifadhi nafasi kutoka kwa mfumo wa mwisho wa kupokea, unaoitwa kielezi cha mtiririko, lina vipimo vya mtiririko na kichujio. Uainishaji wa mtiririko huamua ubora unaohitajika wa huduma na hutumiwa na nodi kuweka vigezo vya mpangilio wa pakiti. Kipanga njia hupeleka mbele pakiti zilizo na seti fulani ya mapendeleo kulingana na vipimo vya sasa vya mtiririko.

Vipimo vya Kichujio inafafanua seti ya vifurushi ambavyo rasilimali zinaombwa. Pamoja na kipindi, inafafanua seti ya pakiti (au mtiririko) ambayo ubora unaohitajika wa huduma lazima utolewe. Pakiti zingine zozote zinazotumwa mahali hapa huchakatwa kwa kiwango ambacho mtandao unaweza kufanya hivyo.

RSVP haifafanui maudhui ya vipimo vya mtiririko, inatuma ombi tu. Vipimo vya mtiririko kwa kawaida hujumuisha darasa la huduma, Rspec (R inawakilisha hifadhi) na Tspec (T inawakilisha trafiki). Vigezo vingine viwili ni seti ya nambari. Kigezo cha Rspec kinafafanua ubora unaohitajika wa huduma, na parameter ya Tspec inaelezea mtiririko wa data. Yaliyomo katika Rspec na Tspec ni wazi kwa RSVP.

Kimsingi, vipimo vya kichungi huelezea sehemu ndogo ya pakiti kutoka kwa kikao kimoja (yaani, pakiti hizo ambazo marudio yake yameamuliwa na kipindi hicho). Kwa mfano, vipimo vya kichujio vinaweza kutambua watumaji mahususi pekee, au vinaweza kutambua itifaki au pakiti ambazo sehemu zake za kichwa cha itifaki zinalingana na zile zilizobainishwa.

Mchele. 3 inaonyesha uhusiano kati ya kipindi, vipimo vya mtiririko, na vipimo vya kichujio. Kila pakiti inayoingia ni ya angalau kipindi kimoja na inazingatiwa kulingana na mtiririko wa kimantiki wa kipindi hicho. Ikiwa pakiti sio ya kikao chochote, basi inatolewa mradi tu kuna rasilimali za bure.

Ugumu kuu na RSVP ni multicast. Mfano wa usanidi wa multicast unaonyeshwa kwenye Mtini. 6. Usanidi huu unajumuisha ruta nne. Kiungo kati ya vipanga njia viwili, vinavyowakilishwa na mstari, kinaweza kuwa kiungo cha moja kwa moja au subnet. Majeshi matatu - Gl, G2 na G3 - ni ya kundi moja na kupokea datagrams na anwani ya kikundi sambamba. Data kwa anwani hii inatumwa na wapangishi wawili - S1 na S2. Mstari mwekundu unalingana na mti wa kuelekeza kwa S1 na kikundi hiki, na mstari wa bluu kwa S2 na kikundi hiki. Mistari yenye mishale inaonyesha mwelekeo wa maambukizi ya pakiti kutoka S1 (nyekundu) na kutoka S2 (bluu).

Takwimu inaonyesha kuwa ruta zote nne lazima zifahamu uhifadhi wa rasilimali wa kila mpokeaji. Kwa hivyo, maombi ya ugawaji wa rasilimali hueneza nyuma kupitia mti wa kuelekeza.

RSVP hutumia aina mbili kuu za ujumbe: Resv na Njia. Ujumbe wa Resv huzalishwa na wapokeaji na kuenezwa juu ya mti, na kila nodi njiani ikichanganya na kuunganisha tena pakiti kutoka kwa vipokezi tofauti kila inapowezekana. Ujumbe huu husababisha kipanga njia kuingia katika hali ya uhifadhi wa rasilimali kwa kipindi hicho (anwani ya matangazo mengi). Hatimaye, jumbe zote za Resv zilizojumlishwa huwafikia wapangishi wanaotuma. Kulingana na habari iliyopokelewa, huweka vigezo sahihi vya udhibiti wa ratiba kwa hop ya kwanza.

Mchele. 7 inaonyesha mtiririko wa ujumbe wa Resv. Tafadhali kumbuka: ujumbe umeunganishwa; kwa hivyo, ni ujumbe mmoja tu unaotumwa kwenye tawi lolote la mti wa uwasilishaji uliojumuishwa. Hata hivyo, ni lazima jumbe hizi zitumwe tena mara kwa mara ili kuongeza muda wa kuhifadhi rasilimali.

Ujumbe wa Njia hutumiwa kueneza habari kuhusu njia ya kurudi. Itifaki zote za kisasa za uelekezaji wa onyesho nyingi huunga mkono tu njia ya moja kwa moja katika mfumo wa mti wa uenezi (chini kutoka kwa mtumaji). Lakini ujumbe wa Resv lazima usambazwe kwa mwelekeo wa kinyume kupitia vipanga njia vyote vya kati kwa wapangishi wote wanaotuma.

Kwa kuwa itifaki ya uelekezaji haitoi maelezo ya njia ya kurudi nyuma, inabebwa na RSVP katika ujumbe wa Njia. Mpangishi yeyote anayetaka kuwa mtumaji hutuma ujumbe wa Njia kwa washiriki wote wa kikundi. Njiani, kila kipanga njia na kila seva pangishi lengwa huingia katika hali ya njia inayoonyesha kwamba pakiti za mtumaji huyo zinapaswa kutumwa kwa nodi ya upitishaji ambapo pakiti ilipokelewa. Mchele. 5 inaonyesha kuwa pakiti za Njia hupitishwa kwa njia sawa na pakiti za data.

Hebu tuangalie jinsi itifaki ya RSVP inavyofanya kazi. Kwa mtazamo wa mwenyeji, utendakazi wa itifaki una hatua zifuatazo (hatua mbili za kwanza katika mlolongo huu wakati mwingine ziko katika mpangilio wa nyuma).

1. Mpokeaji anajiunga na kikundi cha utangazaji anuwai kwa kutuma ujumbe wa IGMP kwa kipanga njia cha jirani.
2. Mtumaji anayetarajiwa hutuma ujumbe kwa anwani ya kikundi.
3. Mpokeaji hupokea ujumbe wa Njia inayomtambulisha mtumaji.
4. Sasa kwa kuwa mpokeaji ana maelezo ya njia ya kurudi nyuma, inaweza kutuma ujumbe wa Resv na maelezo ya mtiririko.
5. Ujumbe wa resv hupitishwa kupitia mtandao hadi kwa mtumaji.
6. Mtumaji huanza usambazaji wa data.
7. Mpokeaji huanza kupokea pakiti za data.

Njia za jana za kufanya kazi na idadi kubwa ya graphics hazifai kabisa kwa mifumo ya kisasa. Bila zana mpya, haiwezekani kukidhi mahitaji yanayokua ya uwasilishaji wa data kwa sababu ya ukuaji wa kiasi cha data, kuenea kwa programu za wakati halisi na usambazaji wa utangazaji anuwai. RTP na RSVP hutoa msingi thabiti kwa kizazi kijacho cha LAN.

Mfano wa utumizi halisi wa itifaki hizi ni modeli ya VoIP (Voice over IP) - utumaji sauti kupitia mitandao ya IP, ambayo imefafanuliwa katika kiwango cha H.232 na hutoa utumaji wa taarifa za sauti, video na data kupitia mtandao wa IP. . Katika kesi hii, itifaki ya wakati halisi ya RTP hutumiwa kuanzisha uunganisho, na itifaki ya RSVP hutumiwa kuhifadhi rasilimali za mtandao.

Tatizo kubwa zaidi ni ukosefu wa nafasi ya anwani, ambayo inahitaji kubadilisha muundo wa anwani.

Tatizo jingine ni ukosefu wa scalability ya utaratibu wa uelekezaji - msingi wa mitandao ya IP. Ukuaji wa haraka wa mtandao hupakia ruta, ambazo tayari zinalazimika kudumisha meza za uelekezaji na makumi na mamia ya maelfu ya maingizo, na pia kushughulikia shida za kugawanyika kwa pakiti. Unaweza kufanya kazi ya routers rahisi, hasa, kwa kuboresha itifaki ya IP.

Pamoja na kuanzisha vitendaji vipya moja kwa moja kwenye itifaki ya IP, inashauriwa kuhakikisha mwingiliano wa karibu na itifaki mpya kwa kuanzisha sehemu mpya kwenye kichwa cha pakiti.

Kama matokeo, iliamuliwa kurekebisha itifaki ya IP ya kisasa, kufuata malengo makuu yafuatayo:

• kuunda mpango mpya wa kushughulikia anwani;
• kuboresha uboreshaji wa mtandao kwa kupunguza kazi za ruta za uti wa mgongo;
• kuhakikisha ulinzi wa data.

Shughulikia upanuzi wa nafasi. Itifaki ya IP hutatua tatizo linalowezekana la uhaba wa anwani kwa kupanua urefu wa anwani hadi 128. Hata hivyo, ongezeko hili kubwa la urefu wa anwani lilifanywa kwa kiasi kikubwa si kupunguza tatizo la uhaba wa anwani, lakini kuboresha ufanisi wa mitandao kulingana na itifaki hii. Lengo kuu lilikuwa kubadili kimuundo mfumo wa kushughulikia na kupanua utendaji wake.

Badala ya viwango viwili vilivyopo vya uongozi wa anwani (nambari ya mtandao na nambari ya nodi), IPv6 inapendekeza kutumia viwango vinne, ambayo ina maana ya utambulisho wa ngazi tatu wa mitandao na ngazi moja ya kutambua nodi.

Anwani sasa imeandikwa kwa hexadecimal, na kila tarakimu nne zikitenganishwa na koloni, kwa mfano:

FEDC:0A96:0:0:0:0:7733:567A.

Kwa mitandao inayotumia matoleo yote mawili ya itifaki za IPv4 na IPv6, inawezekana kutumia nukuu ya jadi ya desimali kwa baiti 4 za chini, na nukuu ya heksadesimali kwa baiti za juu zaidi:

0:0:0:0:FFFF 194.135.75.104.

Ndani ya mfumo wa anwani wa IPv6, pia kuna nafasi maalum ya anwani kwa matumizi ya ndani, yaani, kwa mitandao isiyo kwenye Mtandao. Kuna aina mbili anwani za mitaa: kwa mitandao "gorofa" isiyogawanywa katika subnets (Link-Local), na kwa mitandao iliyogawanywa katika subnets (Site-Local), ambayo hutofautiana katika thamani ya kiambishi awali.

Kubadilisha muundo wa vichwa vya pakiti. Hii inaweza kutekelezwa kwa kutumia mpango mpya wa kuandaa "vichwa vya kiota", ambayo inahakikisha kwamba kichwa kinagawanywa katika moja kuu, ambayo ina kiwango cha chini cha habari kinachohitajika, na zile za ziada, ambazo zinaweza kukosa. Mbinu hii inafungua uwezekano mkubwa wa kupanua itifaki kwa kufafanua vichwa vipya vya hiari, na kufanya itifaki kufunguka.

Kichwa kikuu cha datagram ya IPv6, urefu wa byte 40, ina muundo wafuatayo (Mchoro 2.4).

Shamba Darasa la Trafiki sawa katika kusudi kwa shamba Aina ya Huduma, na shamba Kikomo cha Hop- shamba Muda Wa Kuishi Itifaki ya IPv4.

Shamba Lebo ya Mtiririko hukuruhusu kutenga na kuchakata haswa mitiririko ya data ya kibinafsi bila kulazimika kuchanganua yaliyomo kwenye pakiti. Hii ni muhimu sana kutoka kwa mtazamo wa kupunguza mzigo kwenye routers.

Shamba Kichwa Kinachofuata ni sawa na uga wa Itifaki ya IPv4 na huamua aina ya kichwa kinachofuata kile kikuu. Kila kichwa cha ziada kinachofuata pia kina sehemu ya Kijajuu Kinachofuata.

2.3.3. Itifaki ya TCP

Itifaki ya kudhibiti Itifaki ya Kudhibiti Usambazaji (TCP) iliundwa ili kusaidia mawasiliano shirikishi kati ya kompyuta. Itifaki ya TCP inahakikisha uaminifu na uaminifu wa kubadilishana data kati ya michakato kwenye kompyuta ambayo ni sehemu ya mtandao wa kawaida.

Kwa bahati mbaya, itifaki ya TCP haifai kwa kusambaza habari za media titika. Sababu kuu ni upatikanaji wa udhibiti wa utoaji. Ufuatiliaji huchukua muda mwingi kusambaza taarifa nyeti zaidi za kusubiri. Kwa kuongeza, TCP hutoa taratibu za udhibiti wa viwango ili kuepuka msongamano wa mtandao. Data ya sauti na video, hata hivyo, inahitaji viwango vilivyobainishwa vya usambaaji, ambavyo haviwezi kubadilishwa kiholela.

Kwa upande mmoja, itifaki ya TCP inaingiliana na itifaki ya maombi ya mtumiaji, na kwa upande mwingine, na itifaki ambayo hutoa uelekezaji wa "kiwango cha chini" na kazi za kushughulikia pakiti ambazo IP hufanya kawaida.

Muundo wa kimantiki wa programu ya mtandao unaotumia itifaki za familia za TCP/IP katika kila nodi ya Mtandao umeonyeshwa kwenye Mtini. 2.5.

Mistatili inawakilisha moduli zinazochakata data, na mistari inayounganisha mistatili inawakilisha njia za uhamishaji data. Mstari wa usawa chini ya takwimu unawakilisha mtandao wa Ethernet, ambao hutumiwa kama mfano wa kati ya kimwili.

Mchele. 2.5.

Ili kuanzisha uhusiano kati ya michakato miwili kwenye kompyuta tofauti kwenye mtandao, unahitaji kujua sio tu anwani za mtandao za kompyuta, lakini pia namba za bandari za TCP (soketi) ambazo taratibu hutumia kwenye kompyuta hizi. Muunganisho wowote wa TCP kwenye Mtandao unatambuliwa kwa njia ya kipekee na anwani mbili za IP na nambari mbili za bandari za TCP.

Itifaki ya TCP inaweza kushughulikia pakiti zilizoharibika, zilizopotea, zilizorudiwa au zisizo za mpangilio. Hii inafanikiwa kupitia utaratibu wa kugawa nambari ya mlolongo kwa kila pakiti iliyopitishwa na utaratibu wa kuthibitisha upokeaji wa pakiti.

TCP inapotuma sehemu ya data, nakala ya data hiyo huwekwa kwenye foleni ya utumaji upya na kipima muda cha kukiri kinaanza.

2.3.4. Itifaki ya UDP

Itifaki ya Datagram ya Mtumiaji (UDP) imekusudiwa kwa ubadilishanaji wa datagramu kati ya michakato ya kompyuta iliyo katika mfumo jumuishi wa mitandao ya kompyuta.

Itifaki ya UDP inategemea itifaki ya IP na hutoa huduma za usafiri kwa michakato ya maombi ambayo si tofauti sana na ile ya itifaki ya IP. Itifaki ya UDP hutoa utoaji wa data usio na uhakika, yaani hauhitaji uthibitisho wa kupokea kwake; Kwa kuongeza, itifaki hii haihitaji kuanzisha uhusiano kati ya chanzo na mpokeaji wa habari, yaani, kati ya modules za UDP.

2.3.5. Itifaki za RTP na RTCP

Dhana za Msingi

Itifaki ya usafiri wa wakati halisi ya RTP hutoa uwasilishaji wa wakati halisi hadi wa mwisho wa data ya medianuwai kama vile sauti shirikishi na video. Itifaki hii hutekeleza utambuzi wa aina ya trafiki, nambari za mlolongo wa pakiti, udhibiti wa stempu za wakati, na udhibiti wa upokezaji.

Itifaki ya RTP hufanya kazi kwa kukabidhi mihuri ya muda kwa kila pakiti inayotoka. Kwenye upande wa kupokea, alama za nyakati za pakiti zinaonyesha katika mlolongo gani na kwa ucheleweshaji gani zinahitaji kuchezwa. Usaidizi wa RTP na RTCP huruhusu mpangishi anayepokea kupanga pakiti zilizopokewa kwa mpangilio ufaao, kupunguza athari za tofauti za muda wa mtandao kwenye ubora wa mawimbi, na kurejesha usawazishaji kati ya sauti na video ili taarifa zinazoingia ziweze kusikika na kutazamwa ipasavyo na watumiaji.

Kumbuka kuwa RTP yenyewe haina utaratibu wowote wa kuhakikisha uhamishaji wa data kwa wakati na ubora wa huduma, lakini hutumia huduma za msingi kutoa hii. Haizuii pakiti za nje, lakini haifikiri kwamba mtandao wa msingi ni wa kuaminika kabisa na hupeleka pakiti katika mlolongo sahihi. Nambari za mfuatano zilizojumuishwa katika RTP huruhusu mpokeaji kuunda upya mlolongo wa pakiti za mtumaji.

Itifaki ya RTP inaauni mawasiliano ya njia mbili na uhamishaji data kwa kikundi cha marudio ikiwa utangazaji anuwai utaauniwa na mtandao msingi. RTP imeundwa ili kutoa taarifa zinazohitajika na maombi ya mtu binafsi, na katika hali nyingi ni kuunganishwa katika uendeshaji wa maombi.

Ingawa RTP inachukuliwa kuwa itifaki ya safu ya usafiri, kwa kawaida hufanya kazi juu ya itifaki nyingine ya safu ya usafiri, UDP (Itifaki ya Data ya Mtumiaji). Itifaki zote mbili huchangia sehemu yao ya utendakazi wa safu ya usafirishaji. Ikumbukwe kwamba RTP na RTCP hazitegemei safu za msingi za usafirishaji na mtandao, kwa hivyo RTP/RTCP inaweza kutumika pamoja na itifaki zingine zinazofaa za usafirishaji.

Data ya itifaki huzuia RTP/RTCP huitwa pakiti. Pakiti zinazozalishwa kwa mujibu wa itifaki ya RTP na kutumika kusambaza data ya multimedia huitwa pakiti za habari au pakiti za data, na pakiti zinazozalishwa kwa mujibu wa itifaki ya RTCP na kutumika kusambaza habari za huduma zinazohitajika kwa uendeshaji wa kuaminika. mikutano ya simu, huitwa pakiti za kudhibiti au pakiti za kudhibiti. Pakiti ya RTP inajumuisha kichwa kisichobadilika, kiendelezi cha hiari cha kichwa cha kutofautiana, na sehemu ya data. Pakiti ya RTCP huanza na sehemu ya kudumu (sawa na sehemu ya kudumu ya pakiti za habari za RTP), ikifuatiwa na vipengele vya kimuundo ambavyo vina urefu wa kutofautiana.

Ili itifaki ya RTP iwe rahisi zaidi na inaweza kutumika kwa matumizi mbalimbali, baadhi ya vigezo vyake vinafanywa kuwa wazi kwa makusudi, lakini inajumuisha dhana ya wasifu. Profaili ni seti ya vigezo vya itifaki za RTP na RTCP kwa darasa maalum la programu, ambayo huamua sifa za utendaji wao. Wasifu unafafanua: utumiaji wa sehemu za vichwa vya pakiti mahususi, aina za trafiki, pedi za vichwa na viendelezi vya vichwa, aina za pakiti, huduma za usalama za mawasiliano na algoriti, matumizi ya msingi ya itifaki, n.k. Kila programu hufanya kazi na wasifu mmoja tu, na Aina ya wasifu ni maalum kwa kuchagua programu inayofaa. Hakuna dalili ya wazi ya aina ya wasifu kwa nambari ya mlango, kitambulisho cha itifaki, n.k.

Kwa hivyo, vipimo kamili vya RTP kwa programu mahususi lazima vijumuishe hati za ziada, zinazojumuisha maelezo ya wasifu, pamoja na maelezo ya umbizo la trafiki inayofafanua jinsi aina fulani ya trafiki, kama vile sauti au video, itakavyochakatwa katika RTP.

Mkutano wa sauti wa kikundi

Mkutano wa sauti wa kikundi unahitaji anwani ya kikundi cha watumiaji wengi na milango miwili. Katika kesi hii, bandari moja inahitajika kwa kubadilishana data ya sauti, na nyingine hutumiwa kwa pakiti za udhibiti wa itifaki ya RTCP. Anwani ya kikundi na maelezo ya bandari hutumwa kwa washiriki waliokusudiwa mikutano ya simu. Ikiwa usiri unahitajika, basi pakiti za habari na udhibiti zinaweza kusimbwa, katika hali ambayo ufunguo kusambazwa usimbaji fiche.

Programu ya mikutano ya sauti inayotumiwa na kila mshiriki wa mkutano hutuma data ya sauti katika sehemu ndogo, kama vile 20 ms. Kila kipande cha data ya sauti kinatanguliwa na kichwa cha RTP; Kichwa cha RTP na data huundwa kwa njia mbadala (imeambatanishwa) kuwa pakiti ya UDP. Kijajuu cha RTP kinaonyesha ni aina gani ya usimbaji wa sauti (kama vile PCM, ADPCM, au LPC) ilitumika kutoa data kwenye pakiti. Hii inafanya uwezekano wa kubadilisha aina ya usimbaji wakati wa mkutano, kwa mfano, wakati mshiriki mpya anaonekana ambaye anatumia kiungo cha chini cha bandwidth, au wakati kuna msongamano wa mtandao.

Kwenye Mtandao, kama ilivyo kwa mitandao mingine ya data iliyobadilishwa kwa pakiti, pakiti wakati mwingine hupotea na kupangwa upya, na hucheleweshwa kwa viwango tofauti vya muda. Ili kukabiliana na matukio haya, kichwa cha RTP kina muhuri wa muda na nambari ya mfuatano ambayo inaruhusu wapokeaji kuweka upya muda ili, kwa mfano, sehemu za mawimbi ya sauti zichezwe kila mara na spika kila baada ya milisekunde 20. Urekebishaji huu wa muda unafanywa kando na kwa kujitegemea kwa kila chanzo cha pakiti za RTP ndani mikutano ya simu. Nambari ya mfuatano inaweza pia kutumiwa na mpokeaji kukadiria idadi ya pakiti zilizopotea.

Tangu washiriki mikutano ya simu wanaweza kujiunga na kuondoka wakati mkutano unaendelea, ni muhimu kujua ni nani anayeshiriki kwa sasa na jinsi washiriki wa mkutano huo wanapokea data ya sauti. Kwa madhumuni haya, kila tukio la programu ya sauti wakati wa kongamano mara kwa mara hutoa ujumbe kwa lango dhibiti (bandari ya RTCP) kwa ajili ya maombi ya washiriki wengine wote kuhusu upokeaji wa pakiti zinazoonyesha jina la mtumiaji wake. Ujumbe wa kupokea unaonyesha jinsi spika ya sasa inavyosikika vizuri na inaweza kutumika kudhibiti visimbaji vinavyobadilika. Kando na jina la mtumiaji, maelezo mengine ya kitambulisho kwa udhibiti wa kipimo data yanaweza pia kujumuishwa. Wakati wa kuondoka kwenye mkutano, tovuti hutuma pakiti ya RTCP BYE.

Mkutano wa video

Ikiwa ndani mikutano ya simu Ikiwa ishara zote za sauti na video zinatumiwa, hupitishwa kando. Ili kusambaza kila aina ya trafiki bila ya nyingine, vipimo vya itifaki huanzisha dhana ya kipindi cha mawasiliano cha RTP. Kipindi hufafanuliwa na jozi mahususi ya anwani za usafiri lengwa (anwani moja ya mtandao pamoja na jozi ya bandari za RTP na RTCP). Pakiti za kila aina ya trafiki hutumwa kwa kutumia jozi mbili tofauti za bandari za UDP na/au anwani za upeperushaji anuwai. Hakuna muunganisho wa moja kwa moja wa RTP kati ya vipindi vya sauti na video, isipokuwa tu kwamba mtumiaji anayeshiriki katika vipindi vyote viwili lazima atumie jina moja la kisheria katika pakiti za RTCP za vipindi vyote viwili ili vipindi hivyo vihusishwe.

Sababu moja ya utengano huu ni kwamba baadhi ya washiriki wa mkutano lazima waruhusiwe kupokea aina moja tu ya trafiki ikiwa wanataka kufanya hivyo. Licha ya utenganisho, uchezaji kisawazishaji wa media chanzo (sauti na video) unaweza kupatikana kwa kutumia maelezo ya saa ambayo hubebwa katika pakiti za RTCP kwa vipindi vyote viwili.

Dhana ya wachanganyaji na watafsiri

Sio tovuti zote zinaweza kupokea data ya media titika katika umbizo sawa. Fikiria kisa ambapo washiriki kutoka eneo moja wameunganishwa kupitia kiungo cha kasi ya chini kwa wengi wa washiriki wengine wa mkutano ambao wana ufikiaji wa mtandao kwa njia pana. Badala ya kulazimisha kila mtu kutumia kipimo data cha chini na usimbaji wa sauti wa ubora wa chini, kituo cha mawasiliano cha safu ya RTP kinachoitwa kichanganyaji kinaweza kuwekwa katika eneo la kipimo cha chini. Kichanganyaji hiki husawazisha upya pakiti za sauti zinazoingia ili kurejesha vipindi asili vya 20-ms, huchanganya mitiririko hii ya sauti iliyoundwa upya hadi mtiririko mmoja, husimba mawimbi ya sauti kwa kipimo data finyu, na husambaza mtiririko wa pakiti kwenye kiungo cha kasi ya chini. Katika kesi hii, pakiti zinaweza kushughulikiwa kwa mpokeaji mmoja au kikundi cha wapokeaji wenye anwani tofauti. Ili kuhakikisha dalili sahihi wakati wa kupokea miisho chanzo cha ujumbe, kichwa cha RTP kinajumuisha njia za wachanganyaji kutambua vyanzo vilivyoshiriki katika uundaji wa pakiti iliyochanganywa.

Baadhi ya washiriki katika mkutano wa sauti wanaweza kuunganishwa kwa viungo vya broadband, lakini huenda wasipatikane kupitia mikutano ya kikundi kwa kutumia itifaki ya IP (IPM - IP multicast). Kwa mfano, zinaweza kuwa nyuma ya ngome ya safu ya programu ambayo haitaruhusu pakiti zozote za IP kupitishwa. Kwa matukio hayo, huhitaji mixers, lakini aina nyingine ya vifaa vya mawasiliano ya kiwango cha RTP, kinachoitwa watafsiri. Kati ya relay mbili, moja imewekwa nje ya ngome na inapeleka mbele pakiti zote za utangazaji anuwai zilizopokelewa kwa muunganisho salama kwa upeanaji mwingine uliowekwa nyuma ya ngome. Relay nyuma ya ngome huzisambaza tena kama pakiti za upeperushaji anuwai kwa kikundi cha watumiaji wengi kilichozuiliwa kwa mtandao wa ndani wa tovuti.

Wachanganyaji na watafsiri wanaweza kuundwa kwa madhumuni kadhaa. Mfano: Kichanganyaji cha video ambacho hukadiri picha za video za watu binafsi kwenye mitiririko huru ya video na kuzitunga katika mtiririko mmoja wa video, kuiga tukio la kikundi.

Itifaki ya udhibiti wa RTCP

Maeneo yote ya pakiti za RTP/RTCP hupitishwa kwenye mtandao kwa ka (octets); baiti muhimu zaidi hupitishwa kwanza. Data zote za sehemu ya kichwa hupangwa kulingana na urefu wake. Oktet zilizoteuliwa kuwa za hiari zina thamani ya sifuri.

Itifaki ya kudhibiti RTCP (RTCP - Itifaki ya Udhibiti wa Wakati Halisi) inategemea usambazaji wa pakiti za mara kwa mara usimamizi kwa washiriki wote katika kipindi cha mawasiliano kwa kutumia utaratibu wa usambazaji sawa na itifaki ya RTP. Itifaki ya msingi lazima itoe kuzidisha pakiti za maelezo na udhibiti, kwa mfano, kwa kutumia nambari tofauti za mlango wa UDP. Itifaki ya RTCP hufanya kazi kuu nne.

1. Kazi kuu ni kutoa maoni ili kutathmini ubora wa usambazaji wa data. Hili ni kazi muhimu ya RTCP kama itifaki ya usafiri na inahusiana na udhibiti wa mtiririko na kazi za msongamano wa itifaki nyingine za usafiri. Maoni yanaweza kuwa muhimu moja kwa moja katika kudhibiti usimbaji unaobadilika, lakini majaribio ya utumaji mwingi wa IP yameonyesha kuwa maoni kwa wapokeaji pia ni muhimu kwa kutambua kasoro katika usambazaji wa taarifa. Kutuma ripoti za maoni kuhusu mapokezi ya data kwa washiriki wote hukuruhusu kutathmini kama matatizo ni ya ndani au ya kimataifa unapotazama matatizo. Kwa utaratibu wa usambazaji wa IPM, huluki kama vile watoa huduma za mtandao zinaweza pia kupokea maelezo ya maoni na kufanya kama mfuatiliaji wa watu wengine wakati wa kuchunguza matatizo ya mtandao. Kitendaji hiki cha maoni hutolewa na ripoti za mtumaji na mpokeaji wa RTCP.
2. RTCP hudumisha safu ya uchukuzi ya kitambulishi cha chanzo cha data cha RTP kinachoitwa jina la kisheria (CNAME). Kwa sababu Kitambulisho cha SSRC kinaweza kubadilika ikiwa mgogoro utatambuliwa au programu imeanzishwa upya, wapokeaji wanahitaji CNAME ya kisheria ili kufuatilia kila mshiriki. Wapokeaji pia wanahitaji CNAME ya weka onyesho mtiririko wa taarifa kutoka kwa mshiriki fulani hadi vipindi vingi vinavyohusiana vya RTP, kwa mfano wakati wa kusawazisha mawimbi ya sauti na video.
3. Kazi mbili za kwanza zinahitaji washiriki wote kutuma pakiti za RTCP, kwa hiyo, ili kuruhusu kuongeza idadi ya washiriki, RTP lazima idhibiti mzunguko wa maambukizi ya pakiti hizo. Inapotumwa na kila mshiriki mikutano ya simu kudhibiti vifurushi kwa washiriki wengine wote, kila mmoja anaweza kukadiria kwa uhuru jumla ya idadi ya washiriki.
4. Kitendo cha nne, cha hiari cha RTCP lazima kitoe maelezo ya udhibiti wa kipindi (kwa mfano, kitambulisho cha mshiriki) ambacho kitaonyeshwa kwenye kiolesura cha mtumiaji. Hii ina uwezekano mkubwa wa kuwa na manufaa katika vipindi vya "kudhibitiwa kwa urahisi", ambapo washiriki hujiunga na kuondoka kwenye kikundi bila kudhibiti uanachama au kukubaliana juu ya vigezo.

Chaguo za kukokotoa moja hadi tatu zinahitajika wakati RTP inatumiwa katika utangazaji anuwai wa IP na kupendekezwa katika visa vingine vyote. Wasanidi programu wa RTP wanahimizwa kuepuka mbinu zinazofanya kazi kwa njia mbili pekee na hazibadiliki ili kuongeza idadi ya watumiaji.

Kiwango cha Usambazaji wa Pakiti ya RTCP

Itifaki ya RTP inaruhusu programu kuongeza kiotomatiki uwakilishi wa kipindi cha mawasiliano, kuanzia washiriki wachache hadi elfu kadhaa. Kwa mfano, katika mkutano wa sauti, trafiki ya data kimsingi inajizuia kwa sababu ni mtu mmoja au wawili tu wanaweza kuzungumza kwa wakati mmoja, na kwa usambazaji wa kikundi, kiwango cha data kwenye kiungo chochote kinasalia kwa kiasi, bila kujali idadi ya washiriki. Walakini, udhibiti wa trafiki haujiwekei kikomo. Iwapo ripoti za kupokea kutoka kwa kila mshiriki zitatumwa kwa kasi isiyobadilika, basi trafiki ya udhibiti itaongezeka kwa mstari kadiri idadi ya washiriki inavyoongezeka. Kwa hiyo, utaratibu maalum unapaswa kutolewa ili kupunguza mzunguko wa maambukizi ya pakiti za udhibiti.

Kwa kila kipindi, trafiki ya data inachukuliwa kufikia kikomo cha jumla kinachoitwa kipimo data cha kipindi, ambacho kinashirikiwa na washiriki wote. Bandwidth hii inaweza kuhifadhiwa na kikomo chake kinawekwa na mtandao. Bandwidth ya kipindi haitegemei aina ya usimbaji wa midia, lakini chaguo la aina ya usimbaji inaweza kuzuiwa na kipimo data cha kipindi. Mpangilio wa kipimo data cha kipindi unatarajiwa kutolewa na programu ya usimamizi wa kipindi inapoita programu ya maudhui, lakini programu za maudhui zinaweza pia kuweka thamani chaguomsingi kulingana na kipimo data cha mtumaji mmoja kwa aina ya usimbaji iliyochaguliwa kwa kipindi fulani.

Mahesabu ya Bandwidth kwa udhibiti na trafiki ya data hufanywa kwa kuzingatia itifaki za msingi za usafiri na safu ya mtandao (kwa mfano, UDP na IP). Vijajuu vya safu ya kiungo cha data (DLC) hazizingatiwi katika hesabu kwa sababu pakiti inaweza kuwekewa vichwa tofauti vya safu ya DLC inapopitishwa.

Udhibiti wa trafiki unapaswa kuwa mdogo kwa sehemu ndogo na inayojulikana ya bandwidth ya kikao: ndogo ya kutosha kwamba kazi ya msingi ya itifaki ya usafiri - maambukizi ya data - haiathiriwa; inajulikana ili trafiki ya udhibiti iweze kujumuishwa katika vipimo vya kipimo data vilivyopewa itifaki uhifadhi wa rasilimali, na ili kila mshiriki aweze kujitegemea kuhesabu sehemu yake. Inachukuliwa kuwa sehemu ya kipimo data cha kipindi kilichogawiwa RTCP inapaswa kuwekwa kuwa 5%. Washiriki wote wa kipindi lazima watumie kiasi sawa cha kipimo data cha RTCP ili viwango vya muda vilivyokokotolewa vya pakiti ya upitishaji vifanane. Kwa hivyo viunga hivi lazima viwekwe kwa kila wasifu.

Algorithm ya kuhesabu muda kati ya kutuma pakiti za RTCP za mchanganyiko ili kugawa kipimo data kilichotengwa kwa udhibiti wa trafiki kati ya washiriki ina sifa kuu zifuatazo:

• watumaji kwa pamoja hutumia angalau 1/4 ya kipimo data cha trafiki kama katika vikao na wapokeaji wengi lakini watumaji wachache; Kwa kuwa hawajaanzisha muunganisho, washiriki wanapokea CNAME ya tovuti zinazotuma ndani ya muda mfupi;
• Inahitajika kuwa muda uliohesabiwa kati ya pakiti za RTCP uwe angalau zaidi ya sekunde 5 ili kuepuka kupasuka kwa pakiti za RTCP kuzidi kipimo kinachoruhusiwa wakati idadi ya washiriki ni ndogo na trafiki haijafanywa kwa mujibu wa sheria ya idadi kubwa;
• Muda kati ya pakiti za RTCP hubadilishwa nasibu ndani ya nusu moja hadi moja na nusu ya vipindi vilivyokokotolewa ili kuepuka kusawazisha washiriki wote bila kukusudia. Pakiti ya kwanza ya RTCP iliyotumwa baada ya kuingia kwenye kipindi pia hucheleweshwa nasibu (hadi nusu ya muda wa chini wa RTCP) ikiwa programu itaanzishwa katika tovuti nyingi kwa wakati mmoja, kama vile wakati wa kutangaza kuanza kwa kipindi;
• ili kukabiliana kiotomatiki na mabadiliko katika kiasi cha taarifa za udhibiti zinazopitishwa, makadirio ya nguvu ya ukubwa wa wastani wa pakiti ya RTCP yenye mchanganyiko huhesabiwa kwa kutumia pakiti zote zilizopokelewa na kutumwa;
• algorithm hii inaweza kutumika kwa vipindi ambavyo upitishaji wa pakiti unakubalika kwa washiriki wote. Katika hali hii, kigezo cha kipimo data cha kipindi ni kipimo data cha mtumaji binafsi kilichozidishwa na idadi ya washiriki, na kipimo data cha RTP kinategemea itifaki ya msingi kutoa kiashiria cha urefu. Urefu wa juu wa pakiti za RTP ni mdogo tu na itifaki za msingi.

  Pakiti kadhaa za itifaki za RTP zinaweza kubebwa katika kizuizi cha data cha itifaki ya safu ya chini, kama vile pakiti ya UDP. Hii inapunguza upungufu wa vichwa na kurahisisha ulandanishi kati ya nyuzi tofauti.