3. Remote Procedure Call (RPC)

HTML
DOWNLOAD

Storlek: px

Starta visningen från sidan:

Download "3. Remote Procedure Call (RPC)"

Gösta Hermansson
för 10 år sedan
Visningar:

1 Remote Procedure Call (RPC) Allmän kommunikationsparadigm: request / reply En klientprocess sänder en förfrågan till en serverprocess som svarar med ett svarsmeddelande klient förfrågan server blockerad Klienten / servern är blockeradmedandenväntar på svar / förfrågningar blockerad exekverande Ett RPC-system tillåter att program anropar både lokala och icke-lokala procedurer. Dvs. RPC är en mekanism för att strukturera distribuerade system och består av två komponenter: Ett tillförlitligt protokoll för överföring av fråge- / svars meddelanden mellan en klient(anropande process) och server (anropad process). Kompilator-stump (stub): understöd i programmeringsspråkets kompilator för att svar omforma anropets argument till ett frågemeddelande omforma frågemeddelandet tillbaka till anropets argument omforma resultatet till ett svarsmeddelande omforma svarsmeddelandet tillbaka till procedurresultatet blockerad Om de anropade procedurerna är metoder för icke-lokala objekt i ett objektorienterar språk kallas RPC RMI (remote method invocation) Anropande process (klient) Anropad process (server) argument resultat argument resultat Klient-stub Server-stub förfrågan svar förfrågan svar RPCprotokoll RPCprotokoll

blockerad Klienten / servern är blockeradmedandenväntar på svar / förfrågningar blockerad exekverande Ett RPC-system tillåter att program anropar både lokala och icke-lokala procedurer. Dvs.

2 5.19 Varför? Varje RPC protkoll måste: Kunna identifiera de anropade procedurerna Namnrymden bör vara hierarkisk och implementeras m.h.a. ett fält för varje nivå i request-meddelandet. Synkronisera frågor och svar Varje request/reply-par identifieras m.h.a. ett id-nummer i ett IDfält i meddelandena. Problem: En klient maskin som sänt en begäran kan om den crachar sända en orelaterad begäran med samma idnummer efter att den boot at. Servern förkastar denna som duplikat Lösning: Boot-ID används dvs. ett request/reply-par identifieras av sitt id-nummer och boot-id. Dessutom erbjuds ofta, om RPC utnyttjar underliggande protokoll som ej erbjuder dessa tjänster (t.ex. UDP/IP) eller dessa tjänster kan implementeras effektivare av RPC-protokollet : Pålitlig överföring av meddelanden Understöd för överföring av stora meddelanden m.h.a. framentering/reasemblering Pålitlig överföring Klient Server Både klienten och servern en klocka vid sändning av ett meddelande och sparar en kopia tills meddelandet blivit kvitterat. Om utlöper sänds meddelandet på nytt. Detta sker ett antal gånger innan klienten / servern ger upp. Request ACK Reply ACK. Boot ID är ett nummer som inkrementeras varje gång maskinen rebootar svaret produceras

Problem: En klient maskin som sänt en begäran kan om den crachar sända en orelaterad begäran med samma idnummer efter att den boot at.

3 5.20 Varför? Implicit kvittering: Om protokollet är sekventiellt (klienten sänder ej en ny fråga förrän svaret på den föregående mottagits): kvitterar Reply-meddelandet ett Klient Server Request-meddelandet och ett Request-meddelande kvitterar det föregående Reply-meddelandet. Problem: Ett sekventiellt protokoll är för ineffektivt Lösning: RPC implementerar en kanal abstraktion m.h.a. ett kanal- ID - i meddelandena ingår ett kanalid-fält och högst en aktiv transaktion per kanal tillåts Request 1 Reply 1 Request 2 Reply 2. Problem: Tiden för serverprocessen att producera ett svar kan vara hur lång som helst. Klienten bör kunna skilja mellan en långsam server och en "död" server. Lösning: Klienten sänder periodiskt ett are-you-alive - meddelande (m.h.a en klocka) som servern besvarar med ett ACK-meddelande. (smart sender - dumb resierver principen ger mera skalbara system) Högst-en-gång (at-most-once) semantik: Högst en kopia av varje request-meddelande levereras åt server (eller ingen alls om nätet eller servern ej fungerar). Kan implementeras m.h.a sekvensnummer: request-meddelandena på varje kanal numreras och servern håller reda på aktuellt nummer för varje kanal.

ett Request-meddelande kvitterar det föregående Reply-meddelandet. Problem: Ett sekventiellt protokoll är för ineffektivt Lösning: RPC implementerar en kanal abstraktion m.h.a. ett kanal- ID - i meddelandena ingår ett kanalid-fält och högst en aktiv transaktion per kanal tillåts Request 1 Reply 1 Request 2 Reply 2.

4 5.21 Framentering/reasemblering Sändaren (klient eller server) indelar ett långt meddelande i fragment (numrerade 0,1,2,...) Varje fragment innehåller sekvensnumret samt en flagga som anger om fragmentet är det sista eller ej eller om hela meddelandet ingår i fragmentet Mottagaren kvitterar varje fragment med sekvensnummeret för det senas korrekt mottagna fragmentet i ordningsföljd samt alla saknade fragments nummer (impl. bitvektor relatift det korrekta numret). Dessutom kvitterar mottagaren varje korrekt frament som ej mottagits i ordningsföljd Sändaren sänder de saknade fragmenten på nytt. Klient Server fragt 5 fragt 6 frag 7 frag 8 frag 9 frag 10 kvitteringar ej utritade Fack Fack: 5 0x06=10110 frag 6 frag 9 kvitteringar ej utritade frag 10

med sekvensnummeret för det senas korrekt mottagna fragmentet i ordningsföljd samt alla saknade fragments nummer (impl. bitvektor relatift det korrekta numret).

5 Real-Time Transport Protocol (RTP) Transportprotokoll för realtids och multimedia applikationer. Realtids applikation = applikation med höga krav på att meddelanden anländer i tid. Multimedia applikationer (involverar ljud, bild och data) indelas i två klasser: Interaktiva applikationer. T.ex. Internet telefoni, videokonferensverktyg (vic), audiokonferensverktyg (vat). Strömmande applikationer, överför ljud och bild streams från en server till en klient - ej lika höga realtids krav Ett RTP-protokoll måste vara tillräckligt allmänt för att kunna betjäna olika typer applikationer och bör tillåta interaktion mellan olika applikationer. Protokoll stack för multimedia applikationer Applikation RTP UDP IP subnät

Multimedia applikationer (involverar ljud, bild och data) indelas i två klasser: Interaktiva applikationer. T.ex.

6 5.25 Krav och funktionelitet: 1. Ett RTP-protokoll bör tillåta att likartade applikationer opererar tillsammans (deltagarna i en audiokonferens bör ej behöva använda samma audiokonferens implementation) Detta innebär att protokollet bör tillåta att man kommer överens om vilka metoder som skall användas för att koda och packa ljud och video.=> RTP kan meddela val av kodningsmetod eg. kodningsalgoritm. 2. Mottagaren av en dataström bör kunna räkna ut tidsförhållandena mellan mottagen data (data placeras i en playback buffert för att jämna ut jitter, varifrån det spelas upp). Detta kräver att data måste tidstämplas. => Tidstämpling av paket 3. Synkronisation av flere mediaströmmar, t.ex. ljud och bild från en sändare. 4. Omtransmission är vanligen ej möjligt p.g.a. de höga realtidskraven (applikationerna kan hantera paketförlust om de är medvetna om detta). Applikationer kan minska behovet av bandbredd vid rusning genom att sänka kvaliteten på överförd data (ändra parametrarna i kodningsalgoritmen). Detta kräver att mottagaren meddelar sändaren om förlust av paket => Indikation av paket förlust 5. Indikation av ram gränser, t.ex. sammanhängande ljud (talkspurt) kan indelas i ramar separerade av perioder av tystnad. 6. Identifiering av sändare på ett användarvänligt sätt (dvs. ej IPadresser) => Assosiering av teckensträngar, med sändare 7. Ett RTP-protokoll bör utnyttja bandbredden väl, dvs. overhead bitar i headern bör undvikas om möjligt. (Ljud sänds i små paket) => Korta pakethuvud

bör tillåta att man kommer överens om vilka metoder som skall användas för att koda och packa ljud och video.=> RTP kan meddela val av kodningsmetod eg. kodningsalgoritm. 2.

7 5.26 V (2 bitar): Versions nummer = P (1 bit): Indikerar utfyllnad (padding)en V P X CC M PT Sequence nr biträcker ty storleken på padfältet Timestamp placeras i padfältet SSRC id X (1 bit): Indikerar att ett extra pakethuvud CSRC id ingår i paketet... CC (4 bitar): Antal sändare Extension header M (1 bit): Markerar början på en ram RTP payload PT (7 bitar): Payload Type, anger vilken typ av multimedia paketet innehåller Paketformat Användningen av M- och PT-fälten bestäms av applikationen Timestamp Tidsstämpel SSRC id Synchronization source identifikation, identifierar en RTP ströms sändare (oberoende av lågnivå-protokoll, det kan finnas flera i en värd CSRC id Contributing source identifikation, används endast om flera datastömmar sänds som en ström (SSRC är id för strömmen, CSRC listar delatagarna) Extension header

.. CC (4 bitar): Antal sändare Extension header M (1 bit): Markerar början på en ram RTP payload PT (7 bitar): Payload Type, anger vilken typ av multimedia paketet innehåller Paketformat Användningen

8 5.27 Kontroll protokoll, RTCP RTCP tillhandahåller en kontrollström assossierad med en data ström för en multimedia applikation. De viktigaste funktionerna är: Ge respons på applikationens och nätverkets prestation Korrelera och synkronisera olika mediaströmmar från samma sändare Överföra en sändares identitet till ett användargränssnitt Synkronisation av mediaströmmar: RTCP definierar följande pakettyper Sändar raport - med vilket aktiva sändare meddela statistik om trafiken (sändningar/mottagningar) Mottagar raport - med vilket mottagare som ej är sändare meddela statistik om mottagningar Källbeskrivning - överför information t.ex. CNAME på sändare, vem pratar,... Applikationsspesifik kontroll raport.

identitet till ett användargränssnitt Synkronisation av mediaströmmar: RTCP definierar följande pakettyper Sändar raport - med vilket aktiva sändare meddela statistik om

Relevanta dokument

DIG IN TO Nätverksteknologier

DIG IN TO Nätverksteknologier CCNA 1 Transportskiktet Agenda Transportskiktets syfte Kommunikationskontroller Tillförlitligt och otillförlitlig transport protokoll TCP och UDP protokoll TCP Header TCP