Programi koji komuniciraju preko mreže trebaju komunikacijski mehanizam. Na nižem nivou, po dolasku paketa, signal se šalje i obrađuje programom za obradu mrežnog signala. Na najvišem nivou funkcioniše mehanizam susreta, usvojen na jeziku Ada. NFS koristi mehanizam udaljenog poziva procedure (RPC) u kojem klijent komunicira sa serverom (vidi sliku 1). Prema ovom procesu, klijent prvo poziva proceduru koja šalje zahtjev serveru. Po pristizanju paketa zahtjeva, server poziva proceduru otvaranja paketa, obavlja traženu uslugu, šalje odgovor i kontrola se vraća klijentu.

RPC interfejs se može zamisliti kao da se sastoji od tri sloja:

1. Gornji nivo je potpuno transparentan. Program na ovom nivou može, na primjer, sadržavati poziv proceduri rnusers() koja vraća broj korisnika na udaljenoj mašini. Ne morate znati o korištenju RPC mehanizma jer pozivate u programu.
2. Srednji sloj je namijenjen za najčešće primjene. RPC pozivima na ovom nivou rukuju potprogrami registerrpc() i callrpc(): registerrpc() prima sistemski kod, a callrpc() izvršava poziv udaljene procedure. Poziv rnusers() implementiran je pomoću ove dvije rutine.
3. Niži nivo se koristi za složenije zadatke koji mijenjaju zadane vrijednosti parametara procedure. Na ovom nivou, možete eksplicitno manipulisati utičnicama koje se koriste za prenos RPC poruka.

Kao opće pravilo, trebali biste koristiti gornji nivo i izbjegavati korištenje nižih nivoa osim ako je apsolutno neophodno.

Uprkos činjenici da u ovaj priručnik Razmatramo interfejs samo u C-u da se pozivi udaljenim procedurama mogu izvršiti iz bilo kog jezika; Rad RPC mehanizma za organizovanje komunikacije između procesa na različitim mašinama ne razlikuje se od njegovog rada na jednoj mašini.

RPC (Remote Procedure Call) je sučelje između udaljenih korisnika i određenih host programa koji se pokreću na zahtjev ovih korisnika. RPC usluga bilo kojeg hosta, u pravilu, klijentima pruža skup programa. Svaki od ovih programa sastoji se, zauzvrat, od jedne ili više udaljenih procedura. Na primjer, usluga na daljinu sistem podataka NFS, koji je izgrađen na RPC pozivima, može se sastojati od samo dva programa: na primjer, jedan program komunicira sa korisničkim interfejsima visokog nivoa, a drugi sa I/O funkcijama niskog nivoa.

Svaki udaljeni poziv procedure uključuje dvije strane: aktivni klijent, koji šalje zahtjev za poziv procedure serveru, i server, koji šalje odgovor klijentu.

Bilješka. Treba imati na umu da se pojmovi "klijent" i "server" u ovom slučaju odnose na određenu transakciju. Određeni host ili softver (proces ili program) mogu djelovati i kao klijent i kao server. Na primjer, program koji pruža uslugu udaljene procedure može u isto vrijeme biti klijent za rad sa mrežnim sistemom datoteka.

RPC protokol je izgrađen na modelu udaljenog poziva procedure, slično lokalnom mehanizmu poziva procedure. Kada pozovete lokalnu proceduru, gurate argumente na određenu lokaciju u memoriji, u stog ili varijable okruženja i prenijeti kontrolu nad procesom na određenu adresu. Kada je posao završen, pročitate rezultate na određenoj adresi i nastavite sa svojim procesom.

Kada radite s udaljenom procedurom, glavna razlika je u tome što pozivom udaljene funkcije rukuju dva procesa: klijentski proces i serverski proces.

Klijentski proces šalje serveru poruku koja uključuje parametre pozvane procedure i čeka poruku odgovora sa rezultatima svog rada. Kada se dobije odgovor, rezultat se čita i proces se nastavlja. Na strani servera, proces rukovaoca pozivom je u stanju čekanja, a kada stigne poruka, on čita parametre procedure, izvršava je, šalje odgovor i postaje u stanju čekanja za sledeći poziv.

RPC protokol ne nameće nikakve zahtjeve za dodatne komunikacije između procesa i ne zahtijeva sinhronizaciju izvršenih funkcija, odnosno pozivi mogu biti asinhroni i međusobno nezavisni, tako da klijent može obavljati druge procedure dok čeka odgovor. RPC server može dodijeliti poseban proces ili virtuelnu mašinu za svaku funkciju, stoga, bez čekanja da se prethodni zahtjevi dovrše, može odmah prihvatiti sljedeće.

Međutim, postoji nekoliko važnih razlika između lokalnih i udaljenih poziva procedura:

1. Greška u obradi. U svakom slučaju, klijent bi trebao dobiti obavijest o greškama koje se javljaju prilikom pozivanja udaljenih procedura na serveru ili mreži.
2. Globalne varijable. Budući da server nema pristup klijentovom adresnom prostoru, pozivi udaljenih procedura ne mogu koristiti skrivene parametre u obliku globalnih varijabli.
3. Performanse. Brzina izvršavanja udaljenih procedura je obično za jedan ili dva reda veličine niža od brzine izvršavanja sličnih lokalnih procedura.
4. Autentifikacija. Budući da se pozivi udaljenih procedura javljaju preko mreže, moraju se koristiti mehanizmi provjere autentičnosti klijenta.

Principi konstrukcije protokola.

RPC protokol može koristiti nekoliko različitih transportnih protokola. Odgovornosti RPC protokola su samo da obezbedi standarde i interpretira prenos poruka. Pouzdanost i pouzdanost prijenosa poruka je u potpunosti osigurana transportnim slojem.

Međutim, RPC može kontrolirati izbor i neke funkcije transportnog protokola. Kao primjer interakcije između RPC-a i transportnog protokola, razmotrite proceduru za dodjelu RPC porta za proces aplikacije za rad kroz RPC - Portmapper.

Ova funkcija dinamički (na zahtjev) dodjeljuje RPC vezu određenom portu. Funkcija Portmapper se koristi prilično često jer je skup transportnih portova rezerviranih za RPC ograničen, a broj procesa koji se potencijalno mogu pokrenuti istovremeno je vrlo velik. Portmapper, na primjer, se poziva kada se biraju portovi za interakciju između klijenta i servera NFS sistema.

Portmapper servis koristi mehanizam za emitovanje RPC poruka na određeni port - III. Klijent šalje poruku emitovanja zahtjeva za portom za određenu RPC uslugu na ovaj port. Portmapper servis obrađuje poreznu poruku, određuje adresu lokalnog RPC servisa i šalje odgovor klijentu. RPC Portmapper servis može raditi sa TCP i UDP protokolima.

RPC može raditi sa različitim transportnim protokolima, ali nikada ne duplira njihove funkcije, tj. ako RPC radi na vrhu TCP-a, sve brige oko pouzdanosti i valjanosti RPC veze se pripisuju TCP-u. Međutim, ako je RPC protokol instaliran na vrhu UDP-a, on može pružiti dodatne karakteristike kako bi osigurao da je isporuka poruka zagarantovana.

Bilješka.

Zadaci aplikacije mogu razmatrati RPC protokol kao specifičnu proceduru za pozivanje funkcije preko mreže JSR (Jump Subroutine Instruction).

Da bi RPC protokol funkcionisao, moraju biti ispunjeni sledeći uslovi:

1. Jedinstvena identifikacija svih daljinski pozvanih procedura na datom hostu. RPC zahtjevi sadrže tri polja identifikatora - broj udaljenog programa (servisa), broj verzije udaljenog programa i broj udaljene procedure navedeni program. Broj programa dodeljuje proizvođač servisa, broj procedure označava specifičnu funkciju ove usluge
2. Identifikacija verzije RPC protokola. RPC poruke sadrže polje verzije RPC protokola. Koristi se za koordinaciju formata proslijeđenih parametara kada klijent radi s različitim verzijama RPC-a.
3. Pružanje mehanizama provjere autentičnosti klijenta serveru. RPC protokol pruža proceduru za autentifikaciju klijenta za uslugu, i, ako je potrebno, svaki put kada se uputi zahtjev ili se pošalje odgovor klijentu. Osim toga, RPC dozvoljava korištenje raznih dodatnih sigurnosnih mehanizama.

RPC može koristiti četiri tipa mehanizama provjere autentičnosti:

• AUTH_NULL - nije potrebna autentifikacija
• AUTH_UNIX - autentifikacija prema UNIX standardu
• AUTH_SHORT - UNIX standardna autentifikacija s vlastitom strukturom kodiranja
• AUTH_DES - autentifikacija prema DES standardu

1. Identifikacija poruka odgovora na odgovarajuće zahtjeve. RPC odgovorne poruke sadrže identifikator zahtjeva iz kojeg su konstruirane. Ovaj identifikator se može nazvati identifikator transakcije RPC poziva. Ovaj mehanizam je posebno neophodan kada se radi u asinhroni način rada i kada se izvršava niz višestrukih RPC poziva.
2. Identifikacija grešaka u protokolu. Sve greške mreže ili servera imaju jedinstvene identifikatore, pomoću kojih svaki od učesnika veze može odrediti uzrok kvara.

Strukture poruka protokola

Prilikom slanja RPC poruka preko transportnog protokola, više RPC poruka može biti locirano unutar jednog transportnog paketa. Da bi se jedna poruka odvojila od druge, koristi se marker zapisa (RM - Record Marker). Svaka RPC poruka je "označena" sa tačno jednim RM.

RPC poruka se može sastojati od nekoliko fragmenata. Svaki fragment se sastoji od četiri bajta zaglavlja i (0 do 2**31-1) podataka. Prvi bit zaglavlja pokazuje da li je fragment posljednji, a preostali 31 bit označava dužinu paketa podataka.

RPC struktura je formalno opisana u jeziku za opisivanje i predstavljanje formata podataka - XDR sa dodacima u vezi sa opisom procedura. Moglo bi se čak reći da je RPC jezik opisa proširenje XDR-a, dopunjen radom sa procedurama.

Struktura RPC paketa izgleda ovako:

Struktura odgovora (reply_body) može sadržavati ili strukturu greške (u tom slučaju sadrži kod greške) ili uspješnu strukturu obrade zahtjeva (u tom slučaju sadrži povratne podatke).

Softverski interfejs visokog nivoa.

Upotreba potprograma u programu je tradicionalan način da se strukturira zadatak i učini jasnijim. Najčešće korišćene rutine skupljene su u bibliotekama gde ih mogu koristiti različiti programi. U ovom slučaju govorimo o lokalnom (lokalnom) pozivu, tj. i pozivni i pozvani objekti rade u okviru istog programa na istom računaru.

U slučaju udaljenog poziva, proces koji se izvodi na jednom računaru pokreće proces na udaljenom računaru (to jest, zapravo pokreće kod procedure na udaljenom računaru). Očigledno, udaljeni poziv procedure značajno se razlikuje od tradicionalnog lokalnog, ali sa stanovišta programera, takve razlike praktički ne postoje, tj. arhitektura poziva udaljene procedure omogućava vam da simulirate poziv lokalne procedure.

Međutim, ako u slučaju lokalnog poziva program prosledi parametre pozvanoj proceduri i primi rezultat rada kroz stog ili dijeljena memorijska područja, tada se u slučaju udaljenog poziva prijenos parametara pretvara u prijenos zahtjev preko mreže, a rezultat rada je u primljenom odgovoru.

Ovaj pristup je moguća osnova za kreiranje distribuiranih aplikacija, i iako mnogi moderni sistemi ne koriste ovaj mehanizam, osnovni koncepti i termini su u mnogim slučajevima zadržani. Kada opisujemo RPC mehanizam, tradicionalno ćemo proces pozivanja nazvati klijentom, a udaljeni proces koji implementira proceduru serverom.

Udaljeni poziv procedure uključuje sljedeće korake:

1. Klijentski program upućuje lokalni poziv proceduri koja se zove stub. U ovom slučaju, klijent “čini se” da pozivanjem stuba zapravo poziva serversku proceduru. Zaista, klijent prosljeđuje potrebne parametre stubu, a on vraća rezultat. Međutim, stvari nisu baš onako kako klijent zamišlja. Posao stubića je da prihvati argumente namenjene udaljenoj proceduri, eventualno ih pretvori u neki standardni format i formuliše mrežni zahtev. Pakovanje argumenata i kreiranje mrežnog zahtjeva naziva se maršaliranje.
2. Mrežni zahtjev se prosljeđuje preko mreže na udaljeni sistem. Da bi to učinio, stub koristi odgovarajuće pozive, na primjer, one o kojima se govorilo u prethodnim odjeljcima. Imajte na umu da se mogu koristiti različiti transportni protokoli, a ne samo TCP/IP porodica.
3. Na udaljenom hostu sve se događa obrnutim redoslijedom. Serverski stub sluša zahtjev i, po prijemu, preuzima parametre - argumente poziva procedure. Unmarshalling može uključivati ​​neophodne transformacije (na primjer, promjene reda bajtova).
4. Stub poziva stvarnu serversku proceduru kojoj je adresiran zahtjev klijenta, prosljeđujući joj argumente primljene preko mreže.
5. Nakon što je procedura završena, kontrola se vraća na stub servera, prenoseći mu potrebne parametre. Kao klijentski stub; Serverski stub konvertuje vrijednosti vraćene procedurom, generirajući poruku mrežnog odgovora koja se prenosi preko mreže na sistem iz kojeg je došao zahtjev.
6. Operativni sistem prosljeđuje primljenu poruku klijentskom stubu, koji, nakon potrebne transformacije, prosljeđuje vrijednosti (a to su vrijednosti vraćene udaljenom procedurom) klijentu, koji to tretira kao normalan povratak iz procedura.

Dakle, sa stanovišta klijenta, on poziva udaljenu proceduru kao što bi to učinio za lokalnu. Isto se može reći i za server: procedura se poziva na standardni način, određeni objekat (server stub) poziva lokalnu proceduru i prima vrednosti koje ona vraća. Klijent tretira stub kao serversku proceduru koja se može pozvati, a server svoj sopstveni stub tretira kao klijenta.

Dakle, stubovi čine jezgro RPC sistema, odgovorni za sve aspekte generisanja i prenosa poruka između klijenta i udaljenog servera (procedura), iako i klijent i server veruju da se pozivi odvijaju lokalno. Ovo je osnovni koncept RPC-a - potpuno sakriti distribuiranu (mrežnu) prirodu interakcije u stub kodu. Prednosti ovog pristupa su očigledne: i klijent i server su nezavisni od implementacije mreže, oba rade u okviru određene distribuirane virtuelna mašina, i pozivi procedura imaju standardni interfejs.

Prenos parametara

Prenošenje parametara vrijednosti ne uzrokuje posebne poteškoće. U ovom slučaju, klijentski stub postavlja vrijednost parametra u mrežni zahtjev, eventualno izvodeći konverzije u standardni obrazac (na primjer, obrnuti redoslijed bajtova). Situacija je mnogo komplikovanija sa prosleđivanjem pokazivača, kada parametar predstavlja adresu podatka, a ne njegovu vrednost. Prosljeđivanje adrese u zahtjevu je besmisleno, jer se udaljena procedura izvršava u potpuno drugom adresnom prostoru. Najviše jednostavno rješenje, koji se koristi u RPC-u, je da zabrani klijentima da prosljeđuju parametre osim vrijednosti, iako to, naravno, nameće ozbiljna ograničenja.

Uvezivanje

Prije nego što klijent može pozvati udaljenu proceduru, ona mora biti povezana s udaljenim sistemom koji hostuje traženi server. Dakle, zadatak vezivanja se rastavlja na dva:

1. Pronalaženje udaljenog hosta sa potrebnim serverom
2. Pronalaženje potrebnog serverskog procesa na datom hostu

Za pronalaženje domaćina mogu se koristiti različiti pristupi. Moguća varijanta- stvaranje svojevrsnog centraliziranog direktorija u kojem hostovi najavljuju svoje servere, a gdje klijent po želji može odabrati host i adresu procedure koja mu odgovara.

Svaka RPC procedura je jedinstveno identificirana programom i brojem procedure. Broj programa identifikuje grupu udaljenih procedura, od kojih svaka ima svoj broj. Svakom programu je također dodijeljen broj verzije, tako da ako unesete manje izmjene u program (na primjer, dodate proceduru), nema potrebe da mijenjate njegov broj. Obično je nekoliko funkcionalno sličnih procedura implementirano u jednom softverskom modulu, koji kada se pokrene, postaje server ovih procedura i koji se identifikuje brojem programa.

Stoga, kada klijent želi pozvati udaljenu proceduru, mora znati program, verziju i brojeve procedura koje pružaju potrebnu uslugu.

Da bi prenio zahtjev, klijent također mora znati mrežnu adresu domaćina i broj porta koji je povezan sa serverskim programom koji pruža potrebne procedure. Za to se koristi portmap(IM) demon (na nekim sistemima se zove rpcbind(IM)). Daemon radi na hostu koji pruža uslugu udaljene procedure i koristi dobro poznati broj porta. Kada se serverski proces inicijalizira, on registruje svoje procedure i brojeve portova u portmap(IM). Sada, kada klijent treba da zna broj porta da pozove određenu proceduru, on šalje zahtev portmap(IM) serveru, koji zauzvrat ili vraća broj porta ili prosleđuje zahtev direktno serveru udaljenih procedura i, nakon izvršavajući ga, vraća odgovor klijentu. U svakom slučaju, ako postoji potrebna procedura, klijent prima broj porta procedure od portmap(IM) servera, a daljnji zahtjevi se mogu uputiti direktno na ovaj port.

Postupanje u posebnim situacijama (izuzetak)

Rukovanje izuzecima prilikom pozivanja lokalnih procedura nije posebno problematično. UNIX obezbeđuje obradu grešaka procesa kao što je deljenje sa nulom, pristup nevažećem memorijskom području, itd. U slučaju udaljenog poziva procedure, verovatnoća grešaka se povećava. Osim grešaka servera i stubića, dodaju se i greške povezane, na primjer, s primanjem pogrešne mrežne poruke.

Na primjer, kada se koristi UDP kao transportni protokol, poruke se ponovo šalju nakon određenog vremenskog ograničenja. Greška se vraća klijentu ako nakon određenog broja pokušaja nije primljen odgovor od servera. U slučaju kada se koristi TCP protokol, klijentu se vraća greška ako je server zatvorio TCP vezu.

Semantika poziva

Pozivanje lokalne procedure nedvosmisleno vodi njenom izvršavanju, nakon čega se kontrola vraća glavnom programu. Situacija je drugačija kod pozivanja udaljene procedure. Nemoguće je odrediti kada će tačno zahvat biti obavljen, da li će se uopšte raditi, i ako da, koliko puta? Na primjer, ako udaljeni sistem primi zahtjev nakon što se serverski program sruši, procedura se uopće neće izvršiti. Ako klijent, kada ne primi odgovor nakon određenog vremenskog perioda (timeout), ponovo pošalje zahtjev, tada može nastati situacija kada je odgovor već poslan preko mreže, a ponovljeni zahtjev ponovo bude prihvaćen na obradu od strane daljinskog upravljača. procedura. U tom slučaju, postupak će se izvoditi nekoliko puta.

Dakle, izvršenje udaljene procedure može biti okarakterisano sledećom semantikom:

• Jednom i samo jednom. Ovo ponašanje (u nekim slučajevima i najpoželjnije) je teško zahtijevati zbog mogućih padova servera.
• Maksimalna vremena. To znači da postupak ili nije urađen uopće ili je obavljen samo jednom. Slična izjava se može dati kada se primi greška umjesto normalnog odgovora.
• Barem jednom. Zahvat je vjerovatno obavljen jednom, ali moguće je i više. Za normalan rad u takvoj situaciji, udaljeni postupak mora imati svojstvo idempotencije (od engleskog idemponent). Ovo svojstvo posjeduje procedura čije ponovljeno izvršavanje ne uzrokuje kumulativne promjene. Na primjer, čitanje datoteke je idempotentno, ali dodavanje teksta u datoteku nije.

Prezentacija podataka

Kada klijent i server rade na istom sistemu na istom računaru, nema problema sa nekompatibilnošću podataka. I za klijenta i za server, podaci u binarnom obliku su predstavljeni na isti način. U slučaju udaljenog poziva, stvar se komplikuje činjenicom da klijent i server mogu raditi na sistemima sa različitim arhitekturama, sa različitim prikazima podataka (na primjer, reprezentacija u pokretnom zarezu, redoslijed bajtova itd.)

Većina implementacija RPC sistema definira neke standardne reprezentacije podataka u koje se moraju konvertirati sve vrijednosti proslijeđene u zahtjevima i odgovorima.

Na primjer, format za predstavljanje podataka u RPC-u kompanije Sun Microsystems je sljedeći:

1. Redoslijed bajtova - Najznačajniji - posljednji
2. Reprezentacija u pokretnom zarezu - IEEE
3. Reprezentacija znakova - ASCII

Net

U pogledu funkcionalnosti, RPC sistem zauzima srednje mjesto između sloja aplikacije i transportnog sloja. Prema OSI modelu, ova odredba odgovara slojevima prezentacije i sesije. Dakle, RPC je teoretski nezavisan od implementacije mreže, posebno od mrežnih protokola transportnog sloja.

Softverske implementacije sistema, po pravilu, podržavaju jedan ili dva protokola. Na primjer, RPC sistem koji je razvio Sun Microsystems podržava prijenos poruka korištenjem TCP i UDP protokola. Izbor jednog ili drugog protokola ovisi o zahtjevima aplikacije. Izbor UDP protokola je opravdan za aplikacije koje imaju sljedeće karakteristike:

• Pozvane procedure su idempotentne
• Veličina prenesenih argumenata i vraćenog rezultata je manja od veličine UDP paketa - 8 KB.
• Server omogućava rad sa nekoliko stotina klijenata. Pošto je pri radu sa TCP protokolima server primoran da održava vezu sa svakim od aktivnih klijenata, to zauzima značajan dio njegovih resursa. UDP protokol je manje intenzivan u pogledu resursa

S druge strane, TCP omogućava efikasan rad aplikacija sa sljedećim karakteristikama:

• Aplikacija zahtijeva pouzdan protokol prijenosa
• Pozvane procedure nisu identične
• Veličina argumenata ili povratnog rezultata prelazi 8 KB

Izbor protokola je obično prepušten klijentu, a sistem na različite načine organizuje generisanje i prenos poruka. Da, prilikom upotrebe TCP protokol, za koji je preneseni podatak tok bajtova, potrebno je poruke odvojiti jednu od druge. U tu svrhu, na primjer, koristi se protokol za označavanje zapisa opisan u RFC1057 "RPC: Remote Procedure Call Protocol specifikacija verzija 2", u kojem se 32-bitni cijeli broj stavlja na početak svake poruke, definirajući veličinu poruke u bajtovima.

Drugačija je situacija sa semantikom poziva. Na primjer, ako se RPC izvodi korištenjem nepouzdanog transportnog protokola (UDP), sistem ponovo šalje poruku u kratkim intervalima (istek vremena). Ako klijentska aplikacija ne dobije odgovor, tada možemo sa sigurnošću reći da je procedura završena nula ili veći broj jednom. Ako se dobije odgovor, aplikacija može zaključiti da je postupak obavljen barem jednom. Kada se koristi pouzdan transportni protokol (TCP), ako je primljen odgovor, može se reći da je procedura obavljena jednom. Ukoliko se ne dobije odgovor, nemoguće je sa sigurnošću reći da postupak nije završen3.

Kako radi?

U suštini, sam RPC sistem je ugrađen u program klijenta i serverski program. Lijepo je što kada razvijate distribuirane aplikacije, ne morate ulaziti u detalje RPC protokola ili programske obrade poruka. Sistem pretpostavlja postojanje odgovarajućeg razvojnog okruženja, što umnogome olakšava život kreatorima aplikacije. softver. Jedna od ključnih tačaka u RPC-u je da razvoj distribuirane aplikacije počinje definicijom interfejsa objekta - formalnog opisa funkcija servera, napisanog na posebnom jeziku. Na osnovu ovog interfejsa, klijentski i serverski stubovi se zatim automatski generišu. Jedina stvar koju trebate učiniti nakon ovoga je napisati stvarni kod za proceduru.

Kao primjer, uzmite RPC kompanije Sun Microsystems. Sistem se sastoji od tri glavna dela:

• rpcgen(1) je RPC kompajler koji, na osnovu opisa interfejsa udaljene procedure, generiše klijentske i serverske stubove u obliku C programa.
• XDR (eksterno predstavljanje podataka) biblioteka, koja sadrži funkcije za transformaciju razne vrste podatke u mašinski nezavisan oblik, omogućavajući razmenu informacija između heterogenih sistema.
• Biblioteka modula koji osiguravaju rad sistema u cjelini.

Pogledajmo primjer jednostavne distribuirane aplikacije za evidentiranje događaja. Kada se klijent pokrene, on poziva udaljenu proceduru da napiše poruku u log datoteku udaljenog računara.

Da biste to učinili, morat ćete kreirati najmanje tri datoteke: specifikaciju sučelja udaljenih procedura log.x (na jeziku opisa sučelja), stvarni tekst udaljenih procedura log.c i tekst glavnog klijentski program main () - client.c (u C jeziku).

Kompajler rpcgen(l) kreira tri datoteke zasnovane na log.x specifikaciji: tekst klijentskih i serverskih stubova u C (log clnt.c i log svc.c) i fajl opisa log.h, koji koriste oba stuba .

Dakle, pogledajmo izvorne kodove programa.

Ova datoteka specificira parametre registracije udaljene procedure - brojeve programa, verzije i procedure, a također definira interfejs poziva - ulazne argumente i povratne vrijednosti. Dakle, definirana je RLOG procedura koja uzima string kao argument (koji će biti zapisan u dnevnik), a povratna vrijednost standardno ukazuje na uspjeh ili neuspjeh naručene operacije.

program LOG_PROG( verzija LOG_VER( int RLOG(string) = 1; ) = 1; ) = 0x31234567;

rpcgen(l) kompajler kreira datoteku zaglavlja log.h, gdje su posebno definirane procedure:

Pogledajmo pažljivo ovaj fajl. Kompajler prevodi ime RLOG definisano u datoteci opisa interfejsa u rlog_1, zamenjujući velika slova malim slovima i dodajući broj verzije programa sa donjom crtom. Tip povratka se promijenio iz int u int*. Ovo je pravilo - RPC vam omogućava da prenosite i primate samo adrese parametara deklariranih pri opisu interfejsa. Isto pravilo vrijedi i za string proslijeđen kao argument. Iako se ne pojavljuje iz print.h, funkcija rlog_l() zapravo prosljeđuje adresu stringa kao argument.

Pored datoteke zaglavlja, rpcgen(l) kompajler proizvodi klijentske stubove i serverske stub module. U suštini, tekst ovih datoteka sadrži sav kod za udaljeni poziv.

Serverski stub je glavni program koji upravlja svim mrežnim interakcijama sa klijentom (tačnije, sa svojim stubom). Da bi izvršio operaciju, stub servera vrši poziv lokalne funkcije, čiji tekst mora biti napisan:

Klijentski stub prihvata argument prosleđen udaljenoj proceduri, vrši potrebne konverzije, izdaje zahtev portmap(1M) serveru, komunicira sa serverom udaljenih procedura i konačno prenosi povratnu vrednost klijentu. Za klijenta, poziv udaljenoj proceduri se svodi na poziv stuba i ne razlikuje se od običnog lokalnog poziva.

klijent.c

#include #include"log.h" main(int argc char*argv) ( KLIJENT *cl; char*server, *mystring, *clnttime; time_t bintime; int*rezultat; ako(argc != 2) ( fprintf(stderr, "Format poziva: %s Host_Address\n", argv ); exit (1) ; ) server = argv ; /*Nabavite deskriptor klijenta. Ako ne uspije, obavijestit ćemo vas da je nemoguće uspostaviti vezu sa serverom*/ ako((c1 = clnt_create (server, LOG_PROG, LOG_VER, "udp")) == NULL) ( clnt_pcreateerror (server); izlaz (2); ) /*Dodijeliti bafer za liniju*/ mystring = ( char*)malloc(100); /*Odredite vrijeme događaja*/ bintime = vrijeme ((time_t *) NULL); clnttime = ctime(&bintime); sprintf (mystring, "%s - Klijent je pokrenut", clnttime); /*Pošalji poruku za dnevnik - vrijeme kada je klijent počeo s radom. Ako ne uspije, prijavit ćemo grešku*/ ako((rezultat = rlog_l(&mystring, cl)) == NULL) ( fprintf(stderr, "error2\n"); clnt_perror(cl, server); exit(3); ) /*U slučaju kvara na udaljenom računaru, prijavićemo grešku*/ ako(*rezultat !=0) fprintf(stderr, "Greška pri pisanju u log\n"); /*0oslobodite ručku*/ cint uništiti (cl); izlaz(0); )

Klijentski stub log_clnt.c kompajliran je sa modulom client.c da bi se proizveo izvršni klijentski program.

Sada na nekom host serveru.nowhere.ru morate pokrenuti serverski proces:

$logger

Zatim, kada pokrenete rlog klijenta na drugoj mašini, server će dodati odgovarajući unos u log fajl.

Radni dijagram RPC u ovom slučaju prikazan je na Sl. 1. Moduli međusobno djeluju na sljedeći način:

1. Kada se serverski proces pokrene, on kreira UDP utičnicu i veže bilo koji lokalni port za tu utičnicu. Zatim, server poziva funkciju biblioteke svc_register(3N) da registruje brojeve i verzije programa. Da bi to učinila, funkcija poziva proces portmap(IM) i prosljeđuje tražene vrijednosti. Portmap(IM) server se obično pokreće kada se sistem inicijalizira i veže na neki dobro poznati port. Sada portmap(3N) zna broj porta za naš program i verziju. Server čeka da primi zahtjev. Imajte na umu da se sve opisane akcije izvode od strane serverskog stuba kreiranog od strane rpcgen(IM) kompajlera.
2. Kada se rlog pokrene, prva stvar koju uradi je da pozove bibliotečku funkciju clnt_create(3N), dajući joj adresu udaljenog sistema, brojeve programa i verzije i transportni protokol. Funkcija šalje zahtjev portmap(IM) serveru udaljenog sistema server.nowhere.m i dobiva broj udaljenog porta za poslužitelj dnevnika.
3. Klijent poziva proceduru rlog_1() definisanu u klijentskom stubu i prenosi kontrolu na stub. To, zauzvrat, generiše zahtev (konvertujući argumente u XDR format) u obliku UDP paketa i šalje ga na udaljeni port primljen od portmap (IM) servera. Zatim čeka na odgovor neko vrijeme i, ako nije primljen, ponovo šalje zahtjev. Pod povoljnim okolnostima, zahtjev prihvata logger server (server stub modul). Stub određuje koja je funkcija pozvana (po broju procedure) i poziva funkciju rlog_1() modula log.c. Nakon što se kontrola vrati na stub, potonji pretvara vrijednost koju vraća funkcija rlog_1() u XDR format i generiše odgovor također u obliku UDP paketa. Nakon primitka odgovora, klijentski stub izvlači vraćenu vrijednost, transformira je i vraća u glavni program klijenta.

Pozovi daljinski RPC procedure Koncept udaljenog poziva procedura Ideja Remote Procedure Call - RPC je proširiti dobro poznati i razumljiv mehanizam za prijenos kontrole i podataka unutar programa koji radi na jednom stroju za prijenos kontrole i podataka preko mreže. Alati za daljinsko pozivanje procedura su dizajnirani da olakšaju organizaciju distribuiranog računarstva. Najveća efikasnost korišćenja RPC-a postiže se u onim aplikacijama u kojima postoji interaktivna komunikacija između udaljenih komponenti sa kratkim vremenom odziva i relativno malom količinom prenetih podataka.

Takve aplikacije se nazivaju RPC orijentisane. Karakteristične karakteristike pozivanja lokalnih procedura su Asimetrija, odnosno jedna od interakcijskih strana je inicijator Sinhronicitet, odnosno izvršenje pozivajuće procedure prestaje od trenutka izdavanja zahtjeva i nastavlja se tek nakon povratka iz pozvane procedure. Implementacija udaljenih poziva je mnogo složenija od implementacije poziva na lokalne procedure.

Za početak, pošto se pozivne i pozvane procedure izvode na različitim mašinama, one imaju različite adresne prostore, a to stvara probleme pri prenošenju parametara i rezultata, posebno ako mašine nisu identične, jer se RPC ne može osloniti na zajedničku memoriju da RPC parametri ne bi trebali sadržavati pokazivače na memorijske lokacije koje nisu stog i da bi vrijednosti parametara trebale biti kopirane s jednog računala na drugi.

Sledeća razlika između RPC-a i lokalnog poziva je u tome što on nužno koristi osnovni komunikacioni sistem, ali to ne bi trebalo da bude eksplicitno vidljivo ni u definiciji procedura ni u samim procedurama. Udaljenost donosi dodatne probleme. Izvršenje pozivajućeg programa i pozvane lokalne procedure na istoj mašini se implementira unutar jednog procesa, ali implementacija RPC-a uključuje najmanje dva procesa - po jedan u svakoj mašini.

U slučaju da se jedna od njih sruši, mogu se pojaviti sljedeće situacije: ako se pozivna procedura sruši, udaljene procedure će postati siroče, a ako se udaljene procedure sruše, pozivne procedure će postati roditelji bez roditelja, koji će uzalud čekati na odgovor Osim toga, postoji niz problema povezanih s heterogenošću programskih jezika i operativnih okruženja, strukture podataka i strukture poziva procedura koje su podržane u bilo kojem programskom jeziku nisu podržane na isti način u svim ostalim. jezicima.

Ovi i neki drugi problemi rješavaju se široko rasprostranjenom RPC tehnologijom, koja je u osnovi mnogih distribuiranih operativnih sistema. Osnovne RPC operacije Da bismo razumjeli kako RPC radi, hajde da prvo razmotrimo pozivanje lokalne procedure na normalnoj mašini koja radi autonomno. Neka ovo, na primjer, bude sistemski poziv count read fd,buf,nbytes gdje je fd cijeli broj, buf je niz znakova, nbytes je cijeli broj.

Da bi izvršila poziv, procedura pozivanja gura parametre u stek obrnutim redoslijedom kao na slici 3.1. Nakon što se izvrši poziv read, on postavlja povratnu vrijednost u registar, pomiče povratnu adresu i vraća kontrolu pozivnoj proceduri, koja dohvaća parametre iz steka, vraćajući ih u početno stanje Imajte na umu da se u jeziku C parametri mogu pozvati ili po referenci po imenu ili po vrijednosti po vrijednosti. U odnosu na pozvanu proceduru, parametri vrijednosti su inicijalizirane lokalne varijable.

Pozvana procedura ih može promijeniti bez utjecaja na originalne vrijednosti ovih varijabli u proceduri koja poziva. Ako je pokazivač na varijablu proslijeđen pozvanoj proceduri, onda promjena vrijednosti ove varijable od strane pozvane procedure podrazumijeva promjenu vrijednosti ove varijable za proceduru koja poziva. Ova činjenica je vrlo značajna za RPC. Postoji i drugi mehanizam za prosljeđivanje parametara koji se ne koristi u C. Zove se vraćanje poziva po kopiju i uključuje pozivni program koji kopira varijable u stog kao vrijednosti, a zatim ih kopira nazad nakon što je poziv upućen preko originala vrijednosti procedure pozivanja.

Odluku o tome koji mehanizam za prenošenje parametara koristiti donose programeri jezika. Ponekad to zavisi od tipa podataka koji se prosleđuju U C-u, na primer, celi brojevi i drugi skalarni podaci se uvek prosleđuju po vrednosti, a nizovi se uvek prosleđuju po referenci.

Rice. 3.1. a Stek pre izvršenja poziva read b Stek tokom izvršavanja procedure c Stek nakon povratka u program koji poziva Ideja iza RPC-a je da učini da poziv udaljenoj proceduri izgleda što je moguće sličnije pozivu lokalni postupak. Drugim riječima, da bi RPC bio transparentan, pozivajuća procedura ne mora znati da je pozvana procedura na drugom stroju, i obrnuto, RPC postiže transparentnost na sljedeći način.

Kada je pozvana procedura zapravo udaljena, umjesto lokalne procedure, u biblioteku se postavlja druga verzija procedure, nazvana klijentski stub. Slično originalnoj proceduri, stub se poziva pomoću sekvence poziva kao na slici 3.1, a prekid se javlja prilikom pristupa kernelu. Samo, za razliku od originalne procedure, ne postavlja parametre u registre i ne traži podatke od kernela, već generiše poruku koja se šalje jezgru udaljene mašine; Faze izvršenja RPC-a Interakcija softverskih komponenti prilikom izvođenja udaljenog poziva procedure ilustrovana je na slici 3.2. Nakon što klijentski program pozove klijentski stub, njegov prvi zadatak je da ispuni bafer porukom koja se šalje.

U nekim sistemima, klijentski stub ima jedan bafer fiksne dužine koji se puni od samog početka sa svakim novim zahtjevom. U drugim sistemima, bafer poruka je skup bafera za pojedinačna polja poruka, od kojih su neka već puna.

Ova metoda je posebno pogodna za slučajeve kada paket ima format koji se sastoji od velikog broja polja, ali se vrijednosti mnogih od ovih polja ne mijenjaju od poziva do poziva. Parametri se zatim moraju konvertovati u odgovarajući format i umetnuti u međuspremnik poruka. U ovom trenutku, poruka je spremna za slanje, tako da se izvršava prekid poziva. Rice. 3.2. Poziv udaljene procedure Kada kernel dobije kontrolu, mijenja kontekste, sprema registre procesora i ručke stranice memorijske mape i instalira novu memorijsku mapu koja će se koristiti za pokretanje u kernel modu. Budući da su konteksti kernela i korisnika različiti, kernel mora kopirati poruku tačno u svoj adresni prostor kako bi joj mogao pristupiti, zapamtiti odredišnu adresu i eventualno druga polja zaglavlja i mora je proslijediti mrežnom sučelju.

Ovim je završen posao na strani klijenta.

Tajmer prijenosa je uključen, a kernel može ili ciklički tražiti odgovor ili proslijediti kontrolu planeru, koji će odabrati neki drugi proces za pokretanje. U prvom slučaju, izvršenje upita je ubrzano, ali izostaje multiprogramiranje. Na strani servera, dolazni bitovi se postavljaju od strane prijemnog hardvera ili u ugrađeni bafer ili u RAM.Kada su sve informacije primljene, generira se prekid.

Rukovalac prekida provjerava valjanost podataka paketa i određuje kojem stubu će ga proslijediti. Ako postoji stub čekanja, poruka se kopira u njega. Konačno, vrši se prebacivanje konteksta, kao rezultat čega se vraćaju registri i memorijska mapa, uzimajući vrijednosti koje su imali u trenutku kada je stub uputio prijemni poziv.

Sada stub servera počinje da radi. Raspakira parametre i gura ih na odgovarajući način u stog. Kada je sve spremno, vrši se poziv serveru. Nakon završetka procedure, server prenosi rezultate klijentu, izvode se svi gore opisani koraci, samo obrnutim redoslijedom. Slika 3.3 prikazuje redoslijed naredbi koje se moraju izvršiti za svaki RPC poziv, a slika 3.4 pokazuje koliki je udio ukupnog vremena izvršenja RPC-a potrošen na svaki od 14 opisanih koraka.

Testovi su sprovedeni na višeprocesorskoj radnoj stanici DEC Firefly i dok je prisustvo pet procesora nužno uticalo na rezultate merenja, histogram prikazan na slici daje opštu predstavu o procesu izvršavanja RPC-a. Rice. 3.3. Faze RPC procedure Sl. 3.4. Vremenska distribucija između 14 faza izvršavanja RPC-a 1. Pozovite stub 2. Pripremite bafer 3. Parametri pakovanja 4. Popunite polje zaglavlja 5. Izračunajte kontrolnu sumu u poruci 6. Prekinite kernel 7. Stavite paket u red za izvršenje 8. Prenesite poruku u kontroler preko QBUS magistrale 9. Vrijeme prijenosa preko Ethernet mreže 10. Primite paket od kontrolera 11. Procedura rukovanja prekidom 12. Kalkulacija kontrolne sume 13. Prebacivanje konteksta na korisnički prostor 14. Izvođenje serverskog stuba Dinamičko povezivanje Razmotrimo pitanje kako klijent specificira lokaciju servera.

Jedna metoda za rješavanje ovog problema je direktna upotreba mrežna adresa server u klijentskom programu.

Nedostatak ovakvog pristupa je što je krajnje nefleksibilan prilikom premeštanja servera, odnosno povećanja broja servera, ili promene interfejsa u svim ovim i mnogim drugim slučajevima, potrebno je ponovo kompajlirati sve programe koji koriste hard setove servera Da bi se izbjegli svi ovi problemi, u nekim distribuiranim sistemima koriste se ono što se zove dinamičko povezivanje.

Polazna tačka za dinamičko vezivanje je da se formalno definiše specifikacija servera. Specifikacija sadrži ime servera datoteka, broj verzije i listu uslužnih procedura koje ovaj server pruža klijentima (slika 3.5). Za svaku proceduru dat je opis njenih parametara, ukazujući da li jeste ovaj parametar ulaz ili izlaz u odnosu na server Neki parametri mogu biti i ulaz i izlaz - na primjer, neki niz koji klijent šalje serveru se tamo mijenja, a zatim se vraća nazad klijentu operacijom vraćanja. Rice. 3.5. Specifikacija RPC servera Formalna specifikacija servera se koristi kao ulaz u program generatora stubova, koji kreira i klijentske i serverske stubove.

Zatim se stavljaju u odgovarajuće biblioteke. Kada korisnički klijentski program pozove bilo koju proceduru definiranu u specifikaciji poslužitelja, odgovarajuća stub procedura je pridružena binarnom kodu programa.

Slično, kada se server kompajlira, serverski stubovi su povezani s njim. Kada se server pokrene, njegova prva radnja je da prenese svoj serverski interfejs poseban program, koji se zove vezivo. Ovaj proces, poznat kao proces registracije servera, uključuje server koji prenosi svoje ime, broj verzije, jedinstveni identifikator i deskriptor lokacije servera. Deskriptor je nezavisan od sistema i može biti IP, Ethernet, X.500 ili neki drugi druga adresa.

Osim toga, može sadržavati i druge informacije, na primjer vezane za autentifikaciju. Kada klijent prvi put pozove jednu od udaljenih procedura, na primjer, read, klijentski stub vidi da još nije povezan sa serverom i šalje poruku programu za vezivanje tražeći da uveze sučelje potrebnu verzijuželjeni server ako takav server postoji, onda binder prosljeđuje deskriptor i jedinstveni identifikator klijentskom stubu.

Prilikom slanja poruke sa zahtjevom, klijentski stub koristi deskriptor kao adresu. Poruka sadrži parametre i jedinstveni identifikator koji jezgro servera koristi za usmjeravanje dolazne poruke na željeni server ako ih ima nekoliko na ovoj mašini. Ova metoda uvoza i izvoza sučelja je vrlo fleksibilna. Na primjer, može postojati nekoliko servera koji podržavaju isti interfejs, a klijenti su nasumično raspoređeni među serverima.

U okviru ove metode, postaje moguće periodično anketirati servere, analizirati njihove performanse i, u slučaju kvara, automatski isključiti, čime se povećava ukupna tolerancija sistema na greške. Ova metoda također može podržati autentifikaciju klijenta. Na primjer, server može odrediti da ga mogu koristiti samo klijenti sa određene liste. Međutim, dinamičko vezivanje ima nedostatke, kao što su dodatni troškovi i vrijeme utrošeno na izvoz i uvoz interfejsa.

Veličina ovih troškova može biti značajna, budući da mnogi klijentski procesi postoje kratko vrijeme, a svaki put kada proces započne, procedura uvoza interfejsa mora se ponoviti. Osim toga, u velikim distribuiranim sistemima, program za vezivanje može postati usko grlo, a kreiranje više programa sa istom svrhom takođe povećava troškove kreiranja i sinhronizacije RPC semantike u slučaju kvarova neuspjeha.

Razmotrite sljedeće klase grešaka: 1. Klijent ne može locirati server, na primjer, ako željeni server ne uspije, ili zato što je klijentski program preveden davno i korišten stara verzija serverski interfejs. U tom slučaju, kao odgovor na zahtjev klijenta, prima se poruka koja sadrži kod greške. 2. Zahtjev od klijenta do servera je izgubljen. Najjednostavnije rješenje je ponoviti zahtjev nakon određenog vremena. 3. Poruka odgovora od servera do klijenta je izgubljena.

Ova opcija je komplikovanija od prethodne, jer neke procedure nisu idempotentne. Idempotentna procedura je procedura čiji se zahtjev za izvršenje može ponoviti nekoliko puta bez promjene rezultata. Primjer takvog postupka je čitanje fajla, ali postupak podizanja određenog iznosa sa bankovnog računa nije idempotentan, a ako se odgovor izgubi, ponovljeni zahtjev može značajno promijeniti stanje računa klijenta.

Jedno od mogućih rješenja je da sve procedure budu idempotentne. Međutim, u praksi to nije uvijek moguće, pa se može koristiti i drugi metod - sekvencijalno numerisanje svih zahtjeva od strane jezgre klijenta. Jezgro servera pamti broj posljednjeg zahtjeva od svakog klijenta i po prijemu svakog zahtjeva analizira da li je ovaj zahtjev primarni ili ponovljen. 4. Server se srušio nakon prijema zahtjeva Svojstvo idempotencije je također važno ovdje, ali se nažalost pristup sa numeracijom zahtjeva ne može primijeniti.

U ovom slučaju je važno kada je došlo do kvara - prije ili nakon operacije. Ali klijentsko jezgro ne može prepoznati ove situacije; ono samo zna da je vrijeme odgovora isteklo. Postoje tri pristupa ovom problemu: Sačekajte da se server ponovo pokrene i pokušajte ponovo sa operacijom. Odmah prijavite grešku aplikaciji.

Ovaj pristup osigurava da se RPC izvrši najviše jednom. Treći pristup ne garantuje ništa. Kada server pokvari, klijentu se ne pruža podrška. RPC se može ili ne izvršiti uopšte, ili se može izvršiti mnogo puta. U svakom slučaju, ova metoda je vrlo jednostavna za implementaciju. Nijedan od ovih pristupa nije baš atraktivan, a idealna opcija, koja bi garantovala tačno jedno izvršenje RPC-a, u opštem slučaju ne može se implementirati iz principijelnih razloga.

Neka, na primjer, operacija na daljinu bude ispisivanje nekog teksta, što uključuje učitavanje bafera pisača i postavljanje jednog bita u neki kontrolni registar pisača, zbog čega se pisač pokreće nakon što je kontrolni bit postavljen. Trenutak kvara u potpunosti određuje proceduru oporavka, ali klijent ne može saznati za trenutak kvara.

Ukratko, mogućnost pada servera radikalno mijenja prirodu RPC-a i jasno odražava razliku između centraliziranog i distribuiranog sistema. U prvom slučaju, pad servera dovodi do pada klijenta, a oporavak je nemoguć. U drugom slučaju, moguće je i potrebno izvršiti radnje oporavka sistema. 1. Klijent je pao nakon slanja zahtjeva. U ovom slučaju, proračuni se izvode na osnovu rezultata koje niko ne očekuje. Prisustvo siročadi može uzrokovati razne probleme izgubljeno CPU vrijeme, blokiranje resursa, zamjena odgovora na trenutni zahtjev odgovorom na zahtjev koji je izdala klijentska mašina prije ponovnog pokretanja sistema.

Kako se nositi sa siročadi? Pogledajmo 4 moguća rješenja. Uništenje. Prije nego što klijentski stub pošalje RPC poruku, on bilježi u dnevniku što će učiniti sljedeće. Dnevnik se pohranjuje na disk ili drugu memoriju otpornu na greške.

Nakon nesreće, sistem se ponovo pokreće, analizira se dnevnik i eliminišu se siročad. Nedostaci ovog pristupa uključuju, prvo, povećana opterećenja povezana sa pisanjem svakog RPC-a na disk, i, drugo, moguću neefikasnost zbog pojavljivanja siročadi druge generacije generiranih RPC pozivima koje izdaju siročad prve generacije. Reinkarnacija U ovom slučaju, svi problemi se rješavaju bez snimanja na disk. Metoda se sastoji od podjele vremena u sekvencijalno numerisane periode. Kada se klijent ponovo pokrene, emituje poruku svim mašinama da najavi početak novog perioda.

Nakon prijema ove poruke, svi daljinski proračuni se eliminišu. Naravno, ako je mreža segmentirana, onda bi neka siročad mogla preživjeti. Meka reinkarnacija je slična prethodnom slučaju, samo što se ne pronalaze i uništavaju svi izbrisani proračuni, već samo kalkulacije klijenta koji se ponovo pokreće. Istek Svaki zahtjev ima standardni vremenski period T u kojem se mora ispuniti.

Ako se zahtjev ne ispuni u zadanom vremenu, tada se dodjeljuje dodatni iznos. Iako ovo zahtijeva dodatni rad, ako nakon pada klijenta server čeka na interval T prije ponovnog pokretanja klijenta, onda su sva siročad nužno uništena. U praksi nijedan od ovih pristupa nije poželjan, uništavanje siročadi može pogoršati situaciju . Na primjer, pretpostavimo da je siroče zaključalo jednu ili više datoteka baze podataka.

Ako se siročad iznenada uništi, tada će ove brave ostati, osim toga, uništena siročad mogu ostati stajati u raznim sistemskim redovima, u budućnosti mogu uzrokovati izvršavanje novih procesa itd.

Šta ćemo sa primljenim materijalom:

Ako vam je ovaj materijal bio koristan, možete ga spremiti na svoju stranicu na društvenim mrežama:

Mnogi korisnici računarskih sistema čuli su za koncepte kao što su udaljene procedure, pozivi udaljenih procedura ili RPC. Ali ne razumeju svi šta su ove tehnologije, kako rade i za šta su potrebne. Ali mnogi od onih koji su onemogućili ovu uslugu na Windows sistemima često mogu dobiti greške vezane za kritične kvarove. O tome i još mnogo toga će se dalje raspravljati.

Poziv udaljene procedure: šta je to?

Vrijedi početi s nekim teorijskim informacijama. Vjeruje se da su udaljene procedure (pozivi udaljenih procedura) mehanizam koji vam omogućava da pokrenete ili koristite bilo koju funkciju računarskih sistema u adresnom prostoru koji nije onaj koji koristi terminal. Jednostavno rečeno, to je način pristupa udaljenom računaru, na primjer putem lokalne mreže ili internetske veze.

Međutim, udaljene procedure (pozivi udaljenih procedura), koji se nazivaju RPC (skraćenica za engleski Remote Procedure Call), mogu se pripisati ne samo udaljeni računari. Na lokalnom nivou se takve tehnologije također koriste. Najjednostavniji primjer je pozivanje određene funkcije jednog programa iz druge aplikacije kroz interakciju kroz posebne biblioteke.

Štaviše, u apsolutno svim Windows verzije postoji takva usluga, a ako je onemogućena ili ne uspije, modifikacija XP-a uopće ne radi.

Princip rada

Po pravilu, usluga Remote Procedure Call RPC zahteva najmanje dve glavne komponente za rad u klijent-server režimu: mrežni protokol za razmenu podataka i jezik serijalizacije (prevođenje strukture podataka procesa ili informacija u sekvencu bitova).

Arhitekture mogu biti potpuno različite i razlikuju se po svojim mogućnostima. Ali za razmjenu podataka na takozvanom transportnom nivou najčešće se koriste UDP i TCP protokoli, a rjeđe HTTP.

Da ne ulazimo u tehničke aspekte, najjednostavnije objašnjenje principa rada takvih tehnologija može biti sljedeći primjer: klijentski proces generiše zahtjev serveru koji opisuje odabranu proceduru sa navedenim parametrima i šalje ga, nakon čega server izvršava potrebnu direktivu i šalje odgovor klijentu, koji se prikazuje na automobilu klijenta. Međutim, sam rukovalac servera je, da tako kažemo, u stanju pripravnosti i aktivira se samo kada se primi zahtev klijenta. U isto vrijeme, uopće nije potrebno da se shema zahtjev-odgovor izvrši odmah.

U ovom slučaju, maksimalni učinak performansi se postiže razmjenom relativno malih količina podataka i kratkim vremenom odziva komponenti između kojih se uspostavlja interaktivna komunikacija.

Udaljene procedure (udaljeni pozivi procedura): karakteristike i implementacije

Dakle, mogu se razlikovati dvije glavne karakteristike ovih tehnologija:

• asimetrija (pokretanje postupka na daljinu od strane samo jedne od stranaka);
• sinhronicitet (pauziranje procedure pozivanja od trenutka kada je zahtjev pokrenut i nastavak nakon slanja odgovora).

Što se implementacija tiče, udaljene procedure (remote procedure calls) danas koriste nekoliko osnovnih tehnologija, među kojima su sljedeće najčešće korištene:

• DCE/RPC - binarni protokol baziran na TCP/IP, SMB/SIFC, itd.;
• DCOM je objektno orijentirani dodatak sa mogućnošću prijenosa referenci na objekte i poziva metoda za njihovu obradu;
• JSON-RPC je tekstualni protokol baziran na HTTP-u;
• .NET Remoting je binarni protokol baziran na UDP, TCP i HTTP;
• JAVA RMI;
• SOAP;
• XML RPC;
• SUN RPC;
• ZeroC ICE;
• Routix.RPC, itd.

Problemi i izazovi

Sada nekoliko riječi o nedostacima. Najvažniji problem, a samim tim i izazov implementacije, je da ista operacija poziva udaljenog postupka preko servisnog čvora Remote Procedure Call mora biti izvršena istovremeno na različitim mašinama, često sa različitim operativnim sistemima, adresnim prostorima i arhitekturama. Tijekom procesa, podaci o parametrima moraju se kopirati s jednog terminala na drugi. Za to se koristi ne samo transportni protokol, već i serijalizacija, koja vam omogućava da pretvorite različite vrste podataka u niz bajtova.

Druga stvar se odnosi na činjenicu da udaljene procedure (udaljeni pozivi procedura) koriste ne jedan proces, kao na lokalnom nivou, već dva (na klijentskoj mašini i na serveru). Stoga, hitni prekid programa na jednom od terminala može uzrokovati istu reakciju na drugom.

Konačno, jedan od glavnih je problem kompatibilnosti zbog heterogenosti nekih programskih jezika, uprkos utvrđenim jedinstvenim standardima.

Glavne vrste podsistema

Daljinski poziv procedure u Windows 10 ili bilo kom drugom sistemu nižeg ranga uključuje upotrebu posebnih podsistema:

• transportni podsistem dizajniran za upravljanje odlaznim i dolaznim vezama uz garantovanu isporuku paketa podataka;
• pool protokoli - koncept izvršavanja procedure na pozvanom terminalu;
• serijalizacija (marshaling) - konverzija tokova podataka u standardne bajt kodove, nezavisno od arhitekture;
• enkripcija poslanih i primljenih paketa sa digitalnim potpisom na njih;
• sistem autentikacije i autorizacije.

Koje vrste programa zahtijevaju RPC?

Ako govorimo o tome koji softverski moduli operativnog sistema zahtijevaju da RPC servis bude uključen, jednostavno ih je nemoguće sve nabrojati.

Ali među dobro poznatim komponentama Windows sistema možemo istaći uslugu faksa, usluge kriptografije, evidenciju grešaka, pomoć i podršku, pristup HID uređajima, servis za razmenu poruka (Messenger), administraciju diskova i logičkih particija, upravljanje prenosivim diskovima , audio sistem, Windows instalater i još Bog zna šta.

Mislim da je ova lista dovoljna da shvatimo koliko komponenti sistema, a i sam korisnik, zavisi od ove usluge.

Na šta RPC utiče?

Generalno, na osnovu prethodnog opisa, može se proceniti uticaj RPC-a. Na primjer, postoji mnogo slučajeva u kojima je, kada je ova usluga isključena, zvuk potpuno nestao, oporavak sistema nakon kritičnih kvarova bio je nemoguć ili je izgubljen oporavak postavki bežične mreže koji je pokrenuo korisnik.

Ali najtužnije je to što ako onemogućite RPC, ponekad je nemoguće pristupiti ni osnovnim sistemskim postavkama, čak i ako je korisnik barem tri puta administrator na svom terminalu.

Da li je moguće onemogućiti ovu uslugu

Uglavnom, mnogi su pokušali (i pokušavaju) da onemoguće uslugu udaljenog poziva procedure. Ovo je strogo zabranjeno. Generalno, sam sistem neće dozvoliti da se to dogodi kada se takav pokušaj napravi, izdavanjem odgovarajućeg obaveštenja.

Ali ne znaju svi da u odjeljku usluga (services.msc) postoji i nešto kao "RPC Remote Procedure Call Locator". To je upravo ono što se može bezbolno onemogućiti za sistem. Aplikacije koje ga mogu koristiti u svom radu će po potrebi samostalno pozvati servis.

Rješavanje kvarova i grešaka

Na kraju, pogledajmo šta možete učiniti ako poziv udaljene procedure dovede do greške. U najjednostavnijem slučaju, možete pokušati ponovo omogućiti uslugu (ako, naravno, radi).

Da biste to učinili, u odgovarajućem odjeljku gdje se nalazi usluga koju tražite, dvaput kliknite na meni za uređivanje parametara, pritisnite dugme za uključivanje i podesite tip omogućavanja na automatski. Ako nije moguće izvršiti takvu proceduru tokom standardnog pokretanja sistema, možete pokušati izvršiti slične radnje u siguran način. Neki stručnjaci savjetuju i onemogućavanje antivirusnog softvera tokom izvođenja radnji, za svaki slučaj.

Ako ovo ne pomogne, ali imate pri ruci disk za instalaciju ili oporavak sistema, možete pokrenuti komandnu konzolu sa administratorskim pravima (nema potrebe za podizanjem sistema sa diska) i u nju uneti sledeće komande:

• cd z:\i386 (Z je slovo optičke disk jedinice) ;
• proširi explorer.ex_ %TEMP%\explorer.exe;
• proširi svchost.ex_ %TEMP%\svchost.exe.

Nakon toga pokrenite "Task Manager" (Ctrl + Del + Alt ili taskmgr u meniju "Run") i završite proces Explorer.exe.

U “Dispatcher-u” zaustavljamo sve procese svhost.exe, nakon čega u roku od 60 sekundi morate unijeti kopiju reda %TEMP%\svchost.exe %systemroot%\system32 /y u komandnu liniju.

Konačno, ako imate pristup uređivaču sistemski registar(regedit) je vraćen, morate pratiti granu HKCC kroz odeljke SYSTEM i CurrentControlSet i doći do parametra CSConfigFlags, mijenjajući njegovu vrijednost na nulu.

Ovo nisu sve metode za popravljanje grešaka u vezi sa RPC-om. Poenta je da ako ova usluga uzrokuje smetnje drugim servisima, možda će biti potrebno prvo riješiti probleme s njihovim radom, a tek onda poduzeti neke radnje u vezi sa RPC-om. I nije uvijek moguće dobiti potpun pristup gore opisanim parametrima i postavkama. Ako ništa ne uspije, ma koliko žalosno zvučalo, morat ćete potpuno ponovo instalirati operativni sistem, mada se nadam da do toga neće doći.

Zaključak

Evo kratkog sažetka svega što se odnosi na RPC tehnologiju i uslugu. Zapravo, sve ovo izgleda mnogo komplikovanije nego što je predstavljeno ovaj opis, a da biste u potpunosti razumjeli problem morate imati barem osnovno znanje. Ali da bismo imali opšte razumevanje RPC-a, ovo je za sada dovoljno.

Što se tiče gašenja, ne pokušavajte da radite takve stvari, inače će cijeli sistem propasti. Navedena rješenja za otklanjanje kvarova obično pomažu, ali potpuna garancija se i dalje ne može dati, jer bi deaktiviranje usluge moglo uzrokovati kvarove na drugim komponentama.

Ideja pozivanja udaljenih procedura (Poziv daljinske procedure - RPC) sastoji se od proširenja dobro poznatog i razumljivog mehanizma za prijenos kontrole i podataka unutar programa koji radi na jednom stroju na prijenos kontrole i podataka preko mreže. Alati za daljinsko pozivanje procedura su dizajnirani da olakšaju organizaciju distribuiranog računarstva.

Najveća efikasnost korištenja RPC-a postiže se u onim aplikacijama u kojima postoji interaktivna komunikacija između udaljenih komponenti With kratko vrijeme odgovora I relativno mala količina prenesenih podataka.Takve aplikacije se nazivaju RPC orijentisane.

Karakteristične karakteristike pozivanja lokalnih procedura su:

asimetrija, odnosno, jedna od strana u interakciji je inicijator;

sinkronicitet, odnosno izvršenje pozivajuće procedure se obustavlja od trenutka izdavanja zahtjeva i nastavlja tek kada se pozvana procedura vrati.

Implementacija udaljenih poziva je mnogo složenija od implementacije poziva lokalnih procedura.

1. Počnimo s činjenicom da pošto se pozivne i pozvane procedure izvršavaju na različitim mašinama, imaju različite adresne prostore, a ovo stvara problemi pri prenosu parametara i rezultata, posebno ako mašine nisu identične.

Pošto se RPC ne može osloniti na zajedničku memoriju, to znači da RPC parametri ne smiju sadržavati pokazivače na memorijske lokacije koje nisu stog Pa šta vrijednosti parametara moraju se kopirati s jednog računara na drugi.

2. Sljedeća razlika između RPC-a i lokalnog poziva je u tome što nužno koristi osnovni komunikacijski sistem, međutim ovo ne bi trebalo biti jasno vidljivo ni u definiciji procedura ni u samim procedurama .

Udaljenost donosi dodatne probleme. Izvršavanje pozivajućeg programa i pozvane lokalne procedure na istom stroju implementirano unutarsingle proces. Ali uključeni u implementaciju RPC-anajmanje dva procesa - po jedan u svakom autu. Ako jedan od njih ne uspije, mogu se pojaviti sljedeće situacije:

Ako se pozivna procedura sruši, udaljeno pozvane procedure će postati "siroče" i

Ako se udaljene procedure završe nenormalno, procedure pozivanja će postati "osiromašeni roditelji" i čekati odgovor udaljenih procedura bez uspjeha.

Osim toga, postoji niz problema povezanih s heterogenošću programskih jezika i operativnih okruženja : Strukture podataka i strukture poziva procedura koje podržava bilo koji programski jezik nisu podržane na isti način u svim drugim jezicima.

Ovi i neki drugi problemi rješavaju se široko rasprostranjenom RPC tehnologijom, koja je u osnovi mnogih distribuiranih operativnih sistema.

Ideja iza RPC-a je da poziv udaljene procedure izgleda što je moguće sličnije lokalnom pozivu procedure. Drugim riječima, učinite RPC transparentnim: pozivajuća procedura ne mora znati da je pozvana procedura na drugom stroju, i obrnuto.

RPC postiže transparentnost na sljedeći način. Kada je pozvana procedura zapravo udaljena, druga verzija procedure, koja se zove klijentski stub, postavlja se u biblioteku umjesto lokalne procedure. Kao i originalna procedura, stub se poziva pomoću sekvence poziva (kao na slici 3.1), a prekid se javlja prilikom pristupa kernelu. Samo, za razliku od originalne procedure, ne postavlja parametre u registre i ne traži podatke od kernela, već generiše poruku koja se šalje jezgru udaljene mašine;.

Rice. 3.2. Poziv na daljinu

Predavanje 4

4.1 Koncept poziva udaljenog postupka

Ideja pozivanja udaljenih procedura (Poziv daljinske procedure - RPC) sastoji se od proširenja dobro poznatog i razumljivog mehanizma za prijenos kontrole i podataka unutar programa koji radi na jednom stroju na prijenos kontrole i podataka preko mreže. Alati za daljinsko pozivanje procedura su dizajnirani da olakšaju organizaciju distribuiranog računarstva. Najveća efikasnost korištenja RPC-a postiže se u onim aplikacijama u kojima postoji interaktivna komunikacija između udaljenih komponenti sa brzim vremenom odziva i relativno malom količinom prenesenih podataka. Takve aplikacije se nazivaju RPC orijentisane.

Karakteristične karakteristike pozivanja lokalnih procedura su: asimetrija, odnosno jedna od strana u interakciji je inicijator; sinhronicitet, odnosno izvršenje pozivajuće procedure prestaje od trenutka izdavanja zahtjeva i nastavlja se tek nakon što se pozvana procedura vrati.

Implementacija udaljenih poziva je mnogo složenija od implementacije poziva lokalnih procedura. Za početak, pošto se pozivne i pozvane procedure izvršavaju na različitim mašinama, one imaju različite adresne prostore, a to stvara probleme prilikom prosleđivanja parametara i rezultata, posebno ako mašine nisu identične. Budući da se RPC ne može osloniti na dijeljenu memoriju, to znači da RPC parametri ne smiju sadržavati pokazivače na memorijske lokacije koje nisu stog i da se vrijednosti parametara moraju kopirati s jednog računala na drugi. Sledeća razlika između RPC-a i lokalnog poziva je u tome što on nužno koristi osnovni komunikacioni sistem, ali to ne bi trebalo da bude eksplicitno vidljivo ni u definiciji procedura ni u samim procedurama. Udaljenost donosi dodatne probleme. Izvršenje pozivajućeg programa i pozvane lokalne procedure na istom stroju se implementira unutar jednog procesa. Ali implementacija RPC-a uključuje najmanje dva procesa - po jedan na svakoj mašini. Ako se jedna od njih sruši, mogu se pojaviti sljedeće situacije: ako se procedura pozivanja sruši, udaljeno pozvane procedure će postati „siroče“, a ako se udaljene procedure sruše, pozivne procedure će postati „roditelji bez roditelja“, uzalud čekajući odgovor udaljenih procedura.

Osim toga, postoji niz problema povezanih s heterogenošću programskih jezika i operativnih okruženja: strukture podataka i strukture poziva procedura koje podržava bilo koji programski jezik nisu podržane na isti način u svim drugim jezicima.

Ovi i neki drugi problemi rješavaju se široko rasprostranjenom RPC tehnologijom, koja je u osnovi mnogih distribuiranih operativnih sistema.

Osnovne RPC operacije

Da bismo razumjeli kako RPC funkcionira, prvo razmotrimo pozivanje lokalne procedure na tipičnoj mašini koja radi van mreže. Neka ovo bude, na primjer, sistemski poziv

count=read(fd,buf,nbytes);

gdje je fd cijeli broj;

buf – niz znakova;

nbytes je cijeli broj.

Za upućivanje poziva, procedura pozivanja gura parametre na stek obrnutim redoslijedom. Nakon što se izvrši poziv za čitanje, on postavlja povratnu vrijednost u registar, pomiče povratnu adresu i vraća kontrolu pozivnoj proceduri, koja izbacuje parametre iz steka, vraćajući ga u prvobitno stanje. Imajte na umu da se u jeziku C parametri mogu pozivati ​​ili po referenci (po imenu) ili po vrijednosti (po vrijednosti). U odnosu na pozvanu proceduru, parametri vrijednosti su inicijalizirane lokalne varijable. Pozvana procedura ih može promijeniti bez utjecaja na originalne vrijednosti ovih varijabli u proceduri koja poziva.

Ako je pokazivač na varijablu proslijeđen pozvanoj proceduri, tada promjena vrijednosti ove varijable pozvanom procedurom podrazumijeva promjenu vrijednosti ove varijable za proceduru koja poziva. Ova činjenica je veoma značajna za RPC.

Takođe postoji još jedan mehanizam za prosleđivanje parametara koji se ne koristi u C. Zove se poziv-by-copy/restore, koji zahteva od pozivaoca da kopira varijable u stog kao vrednosti, a zatim ih kopira nazad nakon što se poziv izvrši preko originalne vrijednosti procedure pozivanja.

Odluku o tome koji mehanizam za prenošenje parametara koristiti donose programeri jezika. Ponekad zavisi od vrste podataka koji se prenose. U C-u se, na primjer, cijeli brojevi i drugi skalarni podaci uvijek prosljeđuju po vrijednosti, a nizovi se uvijek prosljeđuju po referenci.

Ideja iza RPC-a je da poziv udaljene procedure izgleda što je moguće sličnije lokalnom pozivu procedure. Drugim riječima, učinite RPC transparentnim: pozivajuća procedura ne mora znati da je pozvana procedura na drugom stroju, i obrnuto.

RPC postiže transparentnost na sljedeći način. Kada je pozvana procedura zapravo udaljena, druga verzija procedure, koja se zove klijentski stub, postavlja se u biblioteku umjesto lokalne procedure. Kao i originalna procedura, stub se poziva pomoću sekvence poziva, a prekid se javlja prilikom pristupa kernelu. Samo, za razliku od originalne procedure, ne postavlja parametre u registre i ne traži podatke od kernela, već generiše poruku koja se šalje jezgru udaljene mašine;

Faze izvršenja RPC-a

Interakcija softverskih komponenti prilikom izvođenja udaljenog poziva procedure ilustrovana je na slici 2.

Slika 2. Poziv udaljene procedure

Nakon što klijentski program pozove klijentski stub, njegov prvi zadatak je da ispuni bafer porukom koja se šalje. U nekim sistemima, klijentski stub ima jedan bafer fiksne dužine koji se puni od samog početka sa svakim novim zahtjevom. U drugim sistemima, bafer poruka je skup bafera za pojedinačna polja poruka, od kojih su neka već puna. Ova metoda je posebno pogodna za slučajeve kada paket ima format koji se sastoji od velikog broja polja, ali se vrijednosti mnogih od ovih polja ne mijenjaju od poziva do poziva.

Parametri se zatim moraju konvertovati u odgovarajući format i umetnuti u međuspremnik poruka. U ovom trenutku, poruka je spremna za slanje, tako da se izvršava prekid poziva kernela.

Kada kernel dobije kontrolu, on mijenja kontekste, sprema registre procesora i memorijsku mapu (ručnici stranica) i instalira novu memorijsku mapu koja će se koristiti za rad u kernel modu. Budući da su konteksti kernela i korisnika različiti, kernel mora kopirati poruku tačno u svoj adresni prostor kako bi joj mogao pristupiti, zapamtiti odredišnu adresu (i eventualno druga polja zaglavlja) i mora je proslijediti mrežnom sučelju. Ovim je završen posao na strani klijenta. Tajmer prijenosa je uključen, a kernel može ili ciklički tražiti odgovor ili proslijediti kontrolu planeru, koji će odabrati neki drugi proces za pokretanje. U prvom slučaju, izvršenje upita je ubrzano, ali izostaje multiprogramiranje.

Na strani servera, dolazni bitovi se postavljaju od strane prijemnog hardvera ili u bafer na čipu ili u RAM. Kada su sve informacije primljene, generira se prekid. Rukovalac prekida provjerava ispravnost paketnih podataka i određuje kojem stubu treba biti poslan. Ako nijedan od stubova ne očekuje ovaj paket, rukovalac ga mora ili baferovati ili ga potpuno odbaciti. Ako postoji stub čekanja, poruka se kopira u njega. Konačno, vrši se prebacivanje konteksta, kao rezultat čega se vraćaju registri i memorijska mapa, uzimajući vrijednosti koje su imali u trenutku kada je stub uputio prijemni poziv.

Sada stub servera počinje da radi. Raspakira parametre i gura ih na odgovarajući način u stog. Kada je sve spremno, vrši se poziv serveru. Nakon izvršenja procedure, server prenosi rezultate klijentu. Da biste to učinili, izvršite sve gore opisane korake, samo obrnutim redoslijedom.

Slika 3 prikazuje redoslijed naredbi koje se moraju izvršiti za svaki RPC poziv.

Slika 3. Koraci RPC procedure