پرو هوسٽر > بلاگ > انتظاميه > IP(TS) اسٽريمز کي مانيٽر ڪرڻ لاءِ TSDuck استعمال ڪندي

IP(TS) اسٽريمز کي مانيٽر ڪرڻ لاءِ TSDuck استعمال ڪندي

اڄ، IP (TS) اسٽريمز جي نگراني لاءِ تيار ڪيل (مالڪدار) حل آهن، مثال طور VB и iQ، انهن وٽ ڪمن جو هڪ ڪافي امير سيٽ آهي ۽ عام طور تي ٽي وي سروسز سان ڊيل ڪندڙ وڏن آپريٽرن وٽ اهڙا حل آهن. هي آرٽيڪل بيان ڪري ٿو هڪ حل جي بنياد تي هڪ اوپن سورس پروجيڪٽ TSDuckCC (continuity counter) counter and bitrate ذريعي IP(TS) اسٽريمز جي گھٽ ۾ گھٽ ڪنٽرول لاءِ ٺهيل. هڪ ممڪن ايپليڪيشن آهي پيڪٽ جي نقصان کي ڪنٽرول ڪرڻ يا پوري وهڪري کي ليز ٿيل L2 چينل ذريعي (جنهن کي عام طور تي مانيٽر نٿو ڪري سگهجي، مثال طور، قطار ۾ نقصان جي ڳڻپيندڙن کي پڙهڻ سان).

TSDuck بابت تمام مختصر

TSDuck هڪ اوپن سورس (2-Clause BSD لائسنس) سافٽ ويئر آهي (ڪنسول يوٽيلٽيز جو هڪ سيٽ ۽ ڪسٽم يوٽيلٽيز يا پلگ ان کي ترقي ڪرڻ لاءِ لائبريري) TS اسٽريمز کي هٿي ڏيڻ لاءِ. ان پٽ جي طور تي، اهو IP (multicast/unicast)، http، hls، dvb tuners، dektec dvb-asi demodulator سان ڪم ڪري سگھي ٿو، اتي ھڪڙو اندروني TS-stream جنريٽر آھي ۽ فائلن مان پڙھڻ. ٻاھر ھڪڙي فائل، IP (multicast/unicast)، hls، dektec dvb-asi ۽ HiDes modulators، پليئرز (mplayer، vlc، xine) ۽ ڊراپ تي لکي سگھجي ٿو. ان پٽ ۽ آئوٽ پٽ جي وچ ۾ مختلف ٽريفڪ پروسيسرز شامل ڪري سگھجن ٿا، مثال طور، پي آءِ ڊي ريمپنگ، اسڪرامبلنگ/ڊيسڪرامبنگ، سي سي ڪائونٽر اينالائسز، بٽريٽ حساب ڪتاب، ۽ TS اسٽريمز لاءِ ٻيا عام عمل.

هن آرٽيڪل ۾، IP اسٽريمز (ملٽي ڪاسٽ) هڪ ان پٽ طور استعمال ڪيا ويندا، پروسيسرز bitrate_monitor (نالو مان اهو واضح آهي ته اهو ڇا آهي) ۽ تسلسل (سي سي ڳڻپيندڙن جو تجزيو) استعمال ڪيو ويندو. توھان آساني سان IP ملٽي ڪاسٽ کي تبديل ڪري سگھو ٿا ٻئي ان پٽ قسم سان جيڪو TSDuck جي مدد سان.

دستياب سرڪاري تعميرات / پيڪيجز TSDuck سڀ کان وڌيڪ موجوده آپريٽنگ سسٽم لاء. اهي ڊيبين لاءِ دستياب نه آهن ، پر اسان انهن کي بنا ڪنهن پريشاني جي ڊيبين 8 ۽ ڊيبين 10 جي تحت منظم ڪيو.

اڳيون، نسخو TSDuck 3.19-1520 استعمال ڪيو ويندو آهي، لينڪس استعمال ڪيو ويندو آهي OS طور (debian 10 استعمال ڪيو ويو حل تيار ڪرڻ لاء، CentOS 7 حقيقي استعمال لاء استعمال ڪيو ويو)

TSDuck ۽ OS تيار ڪرڻ

حقيقي وهڪري جي نگراني ڪرڻ کان پهريان، توهان کي پڪ ڪرڻ جي ضرورت آهي ته TSDuck صحيح طريقي سان ڪم ڪري ٿو ۽ نيٽ ورڪ ڪارڊ يا او ايس (ساکٹ) سطح تي ڪو به ڦوٽو نه آهي. اهو ضروري آهي ته پوءِ اندازو نه لڳايو وڃي ته قطرا ڪٿي آيا آهن - نيٽ ورڪ تي يا ”سرور جي اندر“. توهان ethtool -S ethX ڪمانڊ سان نيٽ ورڪ ڪارڊ جي سطح تي بوند چيڪ ڪري سگهو ٿا، ٽيوننگ ساڳئي ايٿول ذريعي ڪيو ويندو آهي (عام طور تي، توهان کي RX بفر (-G) وڌائڻ جي ضرورت آهي ۽ ڪڏهن ڪڏهن ڪجهه آف لوڊ (-K) کي غير فعال ڪرڻ جي ضرورت آهي). عام سفارش جي طور تي، تجزيو ٿيل ٽرئفڪ حاصل ڪرڻ لاءِ هڪ الڳ بندرگاهه استعمال ڪرڻ جي صلاح ڏني وڃي ٿي، جيڪڏهن ممڪن هجي ته، اهو ان حقيقت سان جڙيل غلط مثبتن کي گهٽائي ٿو ته ڊراپ بلڪل تجزيي واري بندرگاهه تي ٻين ٽرئفڪ جي موجودگي جي ڪري ٿيو. جيڪڏهن اهو ممڪن نه آهي (هڪ بندرگاهه سان هڪ مني ڪمپيوٽر/NUC استعمال ڪيو ويو آهي)، پوء اهو انتهائي گهربل آهي ته تجزيو ٿيل ٽرئفڪ جي ترجيح کي ترتيب ڏيڻ جي حوالي سان باقي ڊوائيس تي جنهن جو تجزيو ڪندڙ ڳنڍيل آهي. مجازي ماحول جي حوالي سان، هتي توهان کي محتاط رهڻ جي ضرورت آهي ۽ ڳولڻ جي قابل ٿي پيڪٽ ڊراپس هڪ فزيڪل پورٽ کان شروع ٿيندڙ ۽ هڪ مجازي مشين اندر ايپليڪيشن سان ختم ٿيڻ.

ميزبان جي اندر هڪ وهڪرو جي پيداوار ۽ استقبال

TSDuck تيار ڪرڻ ۾ پھرين قدم جي طور تي، اسان netns استعمال ڪندي ھڪڙي ھوسٽ اندر ٽرئفڪ پيدا ۽ وصول ڪنداسين.

ماحول جي تياري:

ip netns add P #создаём netns P, в нём будет происходить анализ трафика
ip link add type veth #создаём veth-пару - veth0 оставляем в netns по умолчанию (в этот интерфейс будет генерироваться трафик)
ip link set dev veth1 netns P #veth1 - помещаем в netns P (на этом интерфейсе будет приём трафика)
ip netns exec P ifconfig veth1 192.0.2.1/30 up #поднимаем IP на veth1, не имеет значения какой именно
ip netns exec P ip ro add default via 192.0.2.2 #настраиваем маршрут по умолчанию внутри nents P
sysctl net.ipv6.conf.veth0.disable_ipv6=1 #отключаем IPv6 на veth0 - это делается для того, чтобы в счётчик TX не попадал посторонний мусор
ifconfig veth0 up #поднимаем интерфейс veth0
ip route add 239.0.0.1 dev veth0 #создаём маршрут, чтобы ОС направляла трафик к 239.0.0.1 в сторону veth0

ماحول تيار آهي. اسان ٽريفڪ تجزيي کي شروع ڪريون ٿا:

ip netns exec P tsp --realtime -t 
 -I ip 239.0.0.1:1234 
 -P continuity 
 -P bitrate_monitor -p 1 -t 1 
 -O drop

جتي "-p 1 -t 1" جو مطلب آهي ته توهان کي هر سيڪنڊ ۾ بٽريٽ جي حساب ڪرڻ جي ضرورت آهي ۽ هر سيڪنڊ بٽريٽ بابت معلومات ڏيکاري ٿي.
اسان 10Mbps جي رفتار سان ٽرئفڪ جنريٽر شروع ڪريون ٿا:

tsp -I craft 
 -P regulate -b 10000000 
 -O ip -p 7 -e --local-port 6000 239.0.0.1:1234

جتي "-p 7 -e" جو مطلب آهي ته توهان کي 7 TS پيڪيٽ کي 1 IP پيڪٽ ۾ پيڪ ڪرڻ جي ضرورت آهي ۽ ان کي محنت ڪريو (-e)، يعني. هميشه انتظار ڪريو 7 TS پيڪٽس آخري پروسيسر کان هڪ IP پيڪٽ موڪلڻ کان اڳ.

تجزيه ڪندڙ متوقع پيغامن کي ڪڍڻ شروع ڪري ٿو:

* 2020/01/03 14:55:44 - bitrate_monitor: 2020/01/03 14:55:44, TS bitrate: 9,970,016 bits/s
* 2020/01/03 14:55:45 - bitrate_monitor: 2020/01/03 14:55:45, TS bitrate: 10,022,656 bits/s
* 2020/01/03 14:55:46 - bitrate_monitor: 2020/01/03 14:55:46, TS bitrate: 9,980,544 bits/s

ھاڻي ڪجھ ڦڙا شامل ڪريو:

ip netns exec P iptables -I INPUT -d 239.0.0.1 -m statistic --mode random --probability 0.001 -j DROP

۽ پيغام هن طرح ظاهر ٿيندا آهن:

* 2020/01/03 14:57:11 - continuity: packet index: 80,745, PID: 0x0000, missing 7 packets
* 2020/01/03 14:57:11 - continuity: packet index: 83,342, PID: 0x0000, missing 7 packets

جنهن جي توقع آهي. پيڪٽ جي نقصان کي بند ڪريو (ip netns exec P iptables -F) ۽ ڪوشش ڪريو جنريٽر بٽريٽ کي 100Mbps تائين وڌائڻ جي. تجزيه نگار CC غلطين جو هڪ گروپ ۽ 75 جي بدران 100 Mbps جي رپورٽ ڪري ٿو. اسان اهو سمجهڻ جي ڪوشش ڪري رهيا آهيون ته ذميوار ڪير آهي - جنريٽر وٽ وقت ناهي يا مسئلو ان ۾ ناهي، ان لاءِ اسان هڪ مقرر ٿيل نمبر پيدا ڪرڻ شروع ڪريون ٿا. پيڪٽس (700000 TS پيڪٽس = 100000 IP پيڪٽس):

# ifconfig veth0 | grep TX
       TX packets 151825460  bytes 205725459268 (191.5 GiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
# tsp -I craft -c 700000 -P regulate -b 100000000 -P count -O ip -p 7 -e --local-port 6000 239.0.0.1:1234
* count: PID    0 (0x0000):    700,000 packets
# ifconfig veth0 | grep TX
        TX packets 151925460  bytes 205861259268 (191.7 GiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

جئين توهان ڏسي سگهو ٿا، بلڪل 100000 IP پيڪيٽ ٺاهيا ويا (151925460-151825460). تنهن ڪري اچو ته اهو سمجهون ته تجزيي سان ڇا ٿي رهيو آهي، ان لاءِ اسين چيڪ ڪريون ٿا RX ڪائونٽر veth1 تي، اهو سختي سان ويٿ0 تي TX کاؤنٽر جي برابر آهي، پوءِ ڏسون ٿا ته ساکٽ جي سطح تي ڇا ٿئي ٿو:

# ip netns exec P cat /proc/net/udp                                                                                                           
  sl  local_address rem_address   st tx_queue rx_queue tr tm->when retrnsmt   uid  timeout inode ref pointer drops             
  133: 010000EF:04D2 00000000:0000 07 00000000:00000000 00:00000000 00000000     0        0 72338 2 00000000e0a441df 24355

هتي توهان بوندن جو تعداد = 24355 ڏسي سگهو ٿا. TS پيڪٽس ۾، اهو 170485 جو 24.36 يا 700000٪ آهي، تنهنڪري اسان ڏسون ٿا ته اهي ساڳيا 25٪ گم ٿيل بٽريٽ udp ساکٽ ۾ قطرا آهن. UDP ساکٽ ۾ ڦڙا عام طور تي بفر جي کوٽ جي ڪري ٿينديون آهن، ڊفالٽ ساکٽ بفر سائيز ۽ وڌ ۾ وڌ ساکٽ بفر سائيز کي ڏسو:

# sysctl net.core.rmem_default
net.core.rmem_default = 212992
# sysctl net.core.rmem_max
net.core.rmem_max = 212992

اهڙيء طرح، جيڪڏهن ايپليڪيشنون واضح طور تي بفر سائيز جي درخواست نه ڪن، ساکٽ 208 KB جي بفر سان ٺاهيا ويا آهن، پر جيڪڏهن اهي وڌيڪ درخواست ڪن ٿا، اهي اڃا تائين حاصل نه ڪندا جيڪي درخواست ڪئي وئي هئي. جيئن ته توهان IP ان پٽ (-buffer-size) لاءِ tsp ۾ بفر جي سائيز کي سيٽ ڪري سگھو ٿا، اسان ڊفالٽ ساکٽ جي سائيز کي نه ڇڪينداسين، پر صرف وڌ ۾ وڌ ساکٽ بفر سائيز کي سيٽ ڪريو ۽ بفر جي سائيز کي واضح طور تي tsp دليلن ذريعي بيان ڪريو:

sysctl net.core.rmem_max=8388608
ip netns exec P tsp --realtime -t -I ip 239.0.0.1:1234 -b 8388608 -P continuity -P bitrate_monitor -p 1 -t 1 -O drop

ساکٽ بفر جي ھن ٽيوننگ سان، ھاڻي ڄاڻايل بٽريٽ اٽڪل 100Mbps آھي، ڪابہ CC نقص نھ آھي.

سي پي يو جي استعمال جي مطابق tsp ايپليڪيشن پاڻ کي. هڪ ڪور i5-4260U CPU @ 1.40GHz سان لاڳاپيل، 10Mbps وهڪري جي تجزيي جي ضرورت پوندي 3-4٪ CPU، 100Mbps - 25٪، 200Mbps - 46٪. جڏهن سيٽنگ % Packet Loss، سي پي يو تي لوڊ عملي طور تي نه وڌندو آهي (پر گهٽجي سگهي ٿو).

وڌيڪ پيداواري هارڊويئر تي، بنا ڪنهن پريشاني جي 1Gb/s کان وڌيڪ اسٽريمز ٺاهڻ ۽ تجزيو ڪرڻ ممڪن هو.

حقيقي نيٽ ورڪ ڪارڊ تي جاچ

ويٿ پيئر تي جاچ ڪرڻ کان پوءِ، توهان کي هڪ ميزبان جا ٻه ميزبان يا ٻه بندرگاهون کڻڻ گهرجن، بندرگاهن کي هڪ ٻئي سان ڳنڍڻ، هڪ تي جنريٽر شروع ڪرڻ، ۽ ٻئي تي تجزيهڪار. هتي ڪا به تعجب نه هئي، پر حقيقت ۾ اهو سڀ ڪجهه لوهه تي منحصر آهي، ڪمزور، وڌيڪ دلچسپ هتي ٿيندو.

مانيٽرنگ سسٽم پاران وصول ڪيل ڊيٽا استعمال ڪندي (Zabbix)

tsp وٽ ڪو به مشين پڙهڻ لائق API نه آهي جهڙوڪ SNMP يا ساڳيو. CC پيغامن کي گهٽ ۾ گهٽ 1 سيڪنڊن لاءِ گڏ ڪيو وڃي (پيڪٽ جي نقصان جي وڏي فيصد سان، اتي ٿي سگهي ٿو سئو/هزارين/ ڏهه هزار في سيڪنڊ، بٽريٽ جي لحاظ کان).

اهڙيءَ طرح، ٻنهي معلومات کي محفوظ ڪرڻ ۽ CC جي غلطين ۽ بٽريٽ لاءِ گراف ٺاهڻ ۽ ڪجهه قسم جا حادثا ڪرڻ لاءِ، هيٺيان آپشن ٿي سگهن ٿا:

  1. پارس ۽ مجموعي (CC پاران) ٽي ايس پي جي پيداوار، يعني. ان کي مطلوب شڪل ۾ تبديل ڪريو.
  2. tsp پاڻ کي ختم ڪريو ۽/يا پروسيسر پلگ ان bitrate_monitor ۽ continuity ته جيئن نتيجو مشين پڙهڻ جي قابل فارم ۾ ڏنو وڃي جيڪو مانيٽرنگ سسٽم لاءِ موزون هجي.
  3. tsduck لائبريري جي چوٽي تي پنھنجي درخواست لکو.

ظاهر آهي، اختيار 1 ڪوشش جي لحاظ کان تمام آسان آهي، خاص طور تي غور ڪيو ته tsduck پاڻ کي گهٽ سطح (جديد معيار جي مطابق) ٻولي (C ++) ۾ لکيو ويو آهي.

هڪ سادي بيش پارسر + ايگريگيٽر پروٽوٽائپ ڏيکاري ٿو ته 10 ايم بي پي ايس اسٽريم ۽ 50٪ پيڪٽ نقصان تي (بدترين صورت ۾) ، بش پروسيس پاڻ کي ٽي ايس پي پروسيس کان 3-4 ڀيرا وڌيڪ سي پي يو استعمال ڪيو. هي منظرنامو ناقابل قبول آهي. واقعي هيٺ ڏنل هن پروٽوٽائپ جو هڪ ٽڪرو

مٿي تي نوڊلز

#!/usr/bin/env bash

missingPackets=0
ccErrorSeconds=0
regexMissPackets='^* (.+) - continuity:.*missing ([0-9]+) packets$'
missingPacketsTime=""

ip netns exec P tsp --realtime -t -I ip -b 8388608 "239.0.0.1:1234" -O drop -P bitrate_monitor -p 1 -t 1  -P continuity 2>&1 | 
while read i
do
    #line example:* 2019/12/28 23:41:14 - continuity: packet index: 6,078, PID: 0x0100, missing 5 packets
    #line example 2: * 2019/12/28 23:55:11 - bitrate_monitor: 2019/12/28 23:55:11, TS bitrate: 4,272,864 bits/s
    if [[ "$i" == *continuity:* ]] 
    then
        if [[ "$i" =~ $regexMissPackets ]]
        then
            missingPacketsTimeNew="${BASH_REMATCH[1]}" #timestamp (seconds)
            if [[ "$missingPacketsTime" != "$missingPacketsTimeNew" ]] #new second with CC error
            then
                ((ccErrorSeconds += 1))
            fi
            missingPacketsTime=$missingPacketsTimeNew
            packets=${BASH_REMATCH[2]} #TS missing packets
            ((missingPackets += packets))
        fi
    elif [[ "$i" == *bitrate_monitor:* ]]
    then
        : #...
    fi
done

ناقابل قبول سست ٿيڻ کان علاوه، بش ۾ ڪي به نارمل ٿريڊ نه آهن، بش جاب الڳ الڳ عمل آهن، ۽ مون کي مسنگ پيڪٽس جي قيمت لکڻي هئي هڪ سيڪنڊ ۾ هڪ ڀيرو پاسي واري اثر تي (جڏهن بٽريٽ پيغام وصول ڪري رهيا آهن جيڪي هر سيڪنڊ ۾ اچن ٿا). نتيجي طور، بش اڪيلو رهجي ويو ۽ اهو فيصلو ڪيو ويو ته گولنگ ۾ هڪ لفافي (parser + aggregator) لکڻ. ساڳي گولنگ ڪوڊ جي سي پي يو جو استعمال 4-5 ڀيرا گھٽ آهي tsp پروسيس کان. گولنگ سان بش جي بدلي جي ڪري ريپر جي رفتار تقريبن 16 ڀيرا ٿي وئي ۽ عام طور تي نتيجو قابل قبول آهي (سي پي يو اوور هيڊ 25 سيڪڙو کان وڌيڪ بدترين حالت ۾). گولنگ ماخذ فائل واقع آهي هتي.

چادر چاڙهڻ

ريپر کي شروع ڪرڻ لاءِ، سسٽم ڊي لاءِ آسان ترين سروس ٽيمپليٽ ٺاهيو ويو (هتي). لفافي پاڻ کي بائنري فائل ۾ مرتب ڪيو وڃي ٿو (go build tsduck-stat.go) ۾ واقع آهي /opt/tsduck-stat/. اهو فرض ڪيو ويو آهي ته توهان گولانگ استعمال ڪري رهيا آهيو monotonic ڪلاڪ جي حمايت سان (> = 1.9).

خدمت جو هڪ مثال ٺاهڻ لاء، توهان کي هلائڻ جي ضرورت آهي systemctl فعال حڪم [ايميل محفوظ ٿيل]: 1234 پوء systemctl شروع سان هلائي [ايميل محفوظ ٿيل]: 1234.

Zabbix کان دريافت

زبڪس لاءِ ڊوڙندڙ خدمتون دريافت ڪرڻ جي قابل ٿي، اهو ڪيو ويو آهي گروپ لسٽ جنريٽر (discovery.sh)، Zabbix دريافت لاء گهربل فارميٽ ۾، اهو فرض ڪيو ويو آهي ته اهو ساڳئي جڳهه تي واقع آهي - /opt/tsduck-stat ۾. زبڪس-ايجنٽ ذريعي دريافت کي هلائڻ لاء، توهان کي شامل ڪرڻ جي ضرورت آهي .conf فائل زبڪس-ايجنٽ جي ترتيب واري ڊاريڪٽري ڏانهن يوزر پيٽرولر شامل ڪرڻ لاء.

Zabbix ٽيمپليٽ

ٺهيل ٽيمپليٽ (tsduck_stat_template.xml) تي مشتمل آهي خودڪار دريافت قاعدو، شيون پروٽوٽائپ، گراف، ۽ ٽرگر.

مختصر چيڪ لسٽ (چڱو، ڇا جيڪڏهن ڪو ماڻهو ان کي استعمال ڪرڻ جو فيصلو ڪري ٿو)

  1. پڪ ڪريو ته ٽي ايس پي "مثالي" حالتن جي تحت پيڪيٽ نه ڇڏي (جنريٽر ۽ تجزيه ڪندڙ سڌو سنئون ڳنڍيل آهن)، جيڪڏهن قطرا آهن، پيراگراف 2 يا هن معاملي تي آرٽيڪل جو متن ڏسو.
  2. وڌ ۾ وڌ ساکٽ بفر کي ٽيوننگ ڪريو (net.core.rmem_max=8388608).
  3. tsduck-stat.go مرتب ڪريو (tsduck-stat.go تعمير ڪريو).
  4. سروس ٽيمپليٽ کي /lib/systemd/system ۾ رکو.
  5. سسٽم سي ٽي ايل سان خدمتون شروع ڪريو، چيڪ ڪريو ته ڪائونٽر ظاهر ٿيڻ شروع ٿي ويا آهن (grep "" /dev/shm/tsduck-stat/*). ملٽي ڪاسٽ اسٽريمز جي تعداد جي حساب سان خدمتن جو تعداد. هتي توهان کي ملٽي ڪاسٽ گروپ ڏانهن رستو ٺاهڻ جي ضرورت پوندي، شايد rp_filter کي غير فعال ڪريو يا ذريعو ip ڏانهن رستو ٺاهيو.
  6. Discovery.sh هلايو، پڪ ڪريو ته اهو json ٺاهي ٿو.
  7. زبڪس ايجنٽ ترتيب شامل ڪريو، زبڪس ايجنٽ کي ٻيهر شروع ڪريو.
  8. ٽيمپليٽ کي زبڪس تي اپلوڊ ڪريو، ان کي ميزبان تي لاڳو ڪريو جيڪو مانيٽر ڪيو پيو وڃي ۽ زبڪس-ايجنٽ نصب ٿيل آهي، اٽڪل 5 منٽ انتظار ڪريو، ڏسو ته ڇا نوان شيون، گرافس ۽ محرڪ آهن.

نتيجي ۾

IP(TS) اسٽريمز کي مانيٽر ڪرڻ لاءِ TSDuck استعمال ڪندي

پيٽ جي نقصان کي ڳولڻ جي ڪم لاء، اهو تقريبا ڪافي آهي، گهٽ ۾ گهٽ اهو بهتر آهي ته مانيٽرنگ کان سواء.

درحقيقت، CC "نقصان" ٿي سگهي ٿو جڏهن وڊيو ٽڪرا کي ضم ڪرڻ (جيتري قدر مون کي خبر آهي، روسي فيڊريشن ۾ مقامي ٽي وي سينٽرن تي داخل ٿيڻ جو طريقو آهي، يعني سي سي انسداد کي ٻيهر ڳڻڻ کان سواء)، اهو ياد رکڻ گهرجي. ملڪيت جا حل جزوي طور تي SCTE-35 ليبلز (جيڪڏهن وهڪرو جنريٽر پاران شامل ڪيا ويا) کي ڳولڻ سان هن مسئلي کي ختم ڪن ٿا.

ٽرانسپورٽ جي معيار جي نگراني جي لحاظ کان، جٽ مانيٽرنگ (IAT) جي کوٽ آهي. ٽي وي سامان (هيءُ ماڊيولٽر هجي يا آخر ڊوائيسز) هن پيراميٽر لاءِ گهرجون آهن ۽ اهو هميشه ممڪن ناهي ته جٽ بفر کي لامحدوديت ڏانهن وڌايو وڃي. ۽ جٽٽر فلوٽ ٿي سگهي ٿو جڏهن وڏي بفرن سان گڏ سامان ٽرانزٽ ۾ استعمال ڪيو ويندو آهي ۽ QoS ترتيب نه ڏنو ويو آهي يا اهڙي حقيقي وقت ٽرئفڪ کي منتقل ڪرڻ لاء ڪافي ترتيب نه آهي.

جو ذريعو: www.habr.com

تبصرو شامل ڪريو