SzgHalok 11. teszt (UDP TCP, Multimédia 1. (RTP,..), Multimédia 2. (SIP) diasor)

Ez az oldal a korábbi SCH wiki-ről lett áthozva. Az eredeti változata itt érhető el.

Ha úgy érzed, hogy bármilyen formázási vagy tartalmi probléma van vele, akkor kérlek javíts rajta egy rövid szerkesztéssel.

Ha nem tudod, hogyan indulj el, olvasd el a migrálási útmutatót

Ekkor szerepelt:

• 2007. 12. 03.
• 2008. ??. ??.

További segítség:

• 2007-es válaszok
• 2007-es összes

Mit kell érteni azon, hogy a TCP pufferelt átvitelt valósít meg?

• Egyik válasz sem jó. (=> a folyamatból a datagramm megtöltéséhez szükséges adatokat küldi el)
• Az alkalmazásnak kell tárolni a még nem nyugtázott adatokat.
• A TCP fárolja az adatokat, és csakis az alkalmazás parancsára továbbítja azokat

Hogyan oldja meg az RTCP az általa keltett forgalom ésszerű határokon belül tartását?

• Egyik válasz sem jó.
• Csak a vevő-végpontok küldenek jelentéseket.
• A szinkronizáló forrás (SSRC) meghatározza a végpontok ripotjainak gyakoriságát.

Mit jelent a TCP bájt-stream szállítási szolgáltatásában a struktúrálatlanság?

• Egyik válasz sem jó
• Nincs tekintettel a bájt-sorrendre.
• Nem veszi tekintetve az alkalmazás által használt tördelést.

Milyen módon működik együtt a Session Initiation Protocoll esetén a Proxy Server és a Location Server?

• Nincs közöttük semmilyen együttműködés
• Egyik válasz sem jó
• A proxy Server a User Agent Client-től érkező INVITE üzenet címzettjét ellenőrzi a Location Servernél, és ezután továbbítja a hívotthoz.

Milyen feladatokat lát el a Session Initiation Protocol?

• Egyik válasz sem jó
• Kezeli a felhasználók helyzetinformációit, támogatja pl. a hívásátadást
• Egy kommunikációs "esemény" (session) megnyitásával, fenntartásával, jellemzőivel kapcsolatos információkat továbbítja, kezeli
• Támogatja a mobilitást

Mi szükség van a média-folyam darabjainak "időbélyegzésére"?

• Egyik válasz sem jó. (=> Azért, hogy később sorrenthelyesen illeszthető legyen például egy beszédfolyamat.)
• Valójában nem feltétlenül szükséges, mert a sorszámok és a típusra vonatkozó jellemzők alapján egyébként is lehetséges a helyes rekonstrukció.
• Azért kell, mert a küldő és fogadó órái nem járnak pontosan együtt.

Miért dolgoztak ki két szállítási protokollt a TCP/IP architektúrában?

• Lényegében kidolgoztak egy bonyolultabb (jobb szolgáltatást nyújtó), és egy egyszerűbb protokollt kevés szolgáltatással.
• Az első használatánál nyert tapasztalatok alapján javítottak.
• Egyik válasz sem jó.
• Mindkét protokoll ugyanazt a szolgáltatást nyújtja, így lényegében versenytársai egymásnak.

Milyen szolgáltatás(oka)t nyújt az UDP?

• Portkezelést.
• Hibavédő-kódolást a teljes UDP PDU-ra.
• Torlódásvezérlést
• Egyik felsorolt szolgáltatást sem nyújtja.
• Sorrendhelyes átvitelt.

Mj1.: 0.75 pontot kaptam erre: Portkezelést, Sorrendhelyes átvitelt

Mj2.: Az UDP másik gyakran alkalmazott társával, az TCP-vel szemben nem ellenőrzi az adatok sértetlen átvitelét, ezért nem képes az elveszett vagy sérült csomagok pótlására. Ezen kívül a fogadás sorrendjét sem garantálja a vételi oldalon. Ezen jellemzői miatt az UDP-t kizárólag olyan esetekben alkalmazzák, ahol a küldött adatok viszonylag kis részének elvesztése nem okoz működési problémát, sőt, esetleg kívánatos is (pl. torlódás esetén), mint pl. a műsorszórás; vagy ahol ezen hibák korrigálásáról egy magasabb szintű protokoll gondoskodik.

Mj3.:A sorrend helytelen, hiszen semmi nincs az UDP headerben ami erre utal! Portkezeles persze van! A torlodasvezerles annyibol all, hogy ha torlodas van, akkor dobjuk el. Ezt szerintem nem tekinthetjuk torlodasvezerlesnek, igy az sem helyes. Hibavedo-kodolasa nincs, csak egy ellenorzo osszeg. Tehat szerintem csak a portkezeles a helyes es a kollega azert kapott 0.75 pontot, mert rosszat is bejelolt!

Milyen hátrányt jelent a rétegezett protokollarchitektúra a médiafolyam továbbítása szempontjából?

• Egyik válasz sem jó.
• A rövid, kisméretű (sokszor nem több, mint 100 bájt) adatcsomaghoz képest túl nagy fejet használnak az egymásra rakódó protokollok.
• Ugyanazt, mint bármilyen más adattovábbítás esetén.

Hány bájt az RTP minimális fejrésze?

• 8
• 16
• 32
• Egyik válasz sem jó (=> 3x4 = 12 byte)

Melyik NEM tartozik a SIP építőelemek közé az alábbiak közül?

• User Agent
• Egyik válasz sem jó (=> nem jó)
• Foreign Agent
• Registrar
• Redirection Server

Az alábbiak közül mely(ek) NEM a TCP feladata(i)?

• Sorrendhelyes átvitel
• Forgalom-szabályozás
• 4. rétegbeli útvonalválasztás
• A fentiek közül mindegyik a TCP feladata.
• Torlódásvezérlés

A Real-time Transport Protocol által használt időbélyeg (timestamp) lehetővé teszi:

• A csomagvesztés kiderítését.
• Egyik válasz sem jó (=> nem jó)
• A csomag tartalmának a megfelelő időben történő megjelenítését

Mi azonosítja egy UDP adatmezőjének feladóját és címzettjét?

• Egyik válasz sem jó
• Az ellenőrző összeg, mivel az igen nagy valószínűséggel egyedi
• Kizárólag az IP címek, mivel az UDP pszeudo fejen keresztül beleszólnak az ellenőrző összegbe
• Kizárólag a port-számok, mivel azok egyediek

Melyek a Session Initiation Protocol legfontosabb jellemzői?

• Kombinálható mindenféle web-alapú szolgáltatással
• Állapot alapú, bináris protokoll
• IP központú
• Egyik válasz sem jó

Miért nevezzük az RTP-t real-time protokollnak?

• Mert késleltetés és vesztés nélkül átviszi a valósidejű forgalmat
• Mert segíti a valósidejű forgalom továbbítását fontos jellemzők átvitelével
• Mert folyamatosan átviszi a valódi időt
• Egyik válasz sem helyes

Melyek a Real Time Streaming Protocol (RTSP) legfőbb jellemzői?

• Ez egy vezérlő protokoll, amely nem veszt részt a felhasználói adatok szállításában.
• Ezt dolgozták ki az RTP felváltására.
• Egyik válasz sem jó.

Miben különbözik egymástól a Session Initiation Protocol-ban a Request és a Response üzenetek felépítése?

• Csak az üzenetek törzsrésze (body) különbözik
• Egyik válasz sem jó (=> ugyanaz a formátumuk az első sor kivételével)
• Az üzenetek fejrésze teljesen különböző (=> ezt tuti nem jó)

-- Panyi - 2008.06.04.

-- dnet - 2008.04.29.

-- OBrien - 2008.02.19.

- Estrica - 2008.04.29.

- Tommy - 2008.04.29.