Programmām, kas sazinās tīklā, ir nepieciešams saziņas mehānisms. Zemākā līmenī pēc pakešu saņemšanas signāls tiek nosūtīts un apstrādāts ar tīkla signālu apstrādes programmu. Augstākajā līmenī darbojas tikšanās mehānisms, kas pieņemts Ada valodā. NFS izmanto attālo procedūru izsaukuma (RPC) mehānismu, kurā klients sazinās ar serveri (sk. 1. attēlu). Saskaņā ar šo procesu klients vispirms izsauc procedūru, kas nosūta pieprasījumu serverim. Pēc pieprasījuma paketes saņemšanas serveris izsauc pakešu atvēršanas procedūru, veic pieprasīto pakalpojumu, nosūta atbildi un kontrole atgriežas klientam.

RPC saskarni var uzskatīt par tādu, kas sastāv no trim slāņiem:

1. Augšējais līmenis ir pilnīgi caurspīdīgs. Šī līmeņa programma var, piemēram, saturēt izsaukumu uz rnusers() procedūru, kas atgriež attālās mašīnas lietotāju skaitu. Jums nav jāzina par RPC mehānisma izmantošanu, jo jūs veicat zvanu programmā.
2. Vidējais līmenis ir paredzēts visizplatītākajiem lietojumiem. RPC izsaukumus šajā līmenī apstrādā registerrpc () un callrpc () apakšprogrammas: registerrpc () saņem sistēmas mēroga kodu, un callrpc () izpilda attālās procedūras izsaukumu. Rnusers () izsaukums tiek īstenots, izmantojot šīs divas rutīnas.
3. Zemākais līmenis tiek izmantots sarežģītākiem uzdevumiem, kas maina procedūras parametru noklusējuma vērtības. Šajā līmenī jūs varat nepārprotami manipulēt ar ligzdām, kas tiek izmantotas RPC ziņojumu pārsūtīšanai.

Parasti jums vajadzētu izmantot augstāko līmeni un izvairīties no zemāko līmeņu lietošanas, ja vien tas nav absolūti nepieciešams.

Neskatoties uz to, ka in šo rokasgrāmatu Mēs apsveram saskarni tikai C valodā; attālo procedūru izsaukumus var veikt no jebkuras valodas. RPC mehānisma darbība saziņas organizēšanai starp procesiem dažādās iekārtās neatšķiras no tā darbības vienā mašīnā.

RPC (Remote Procedure Call) ir saskarne starp attāliem lietotājiem un noteiktām resursdatora programmām, kas tiek palaistas pēc šo lietotāju pieprasījuma. Jebkura resursdatora RPC pakalpojums, kā likums, nodrošina klientus ar programmu komplektu. Katra no šīm programmām, savukārt, sastāv no vienas vai vairākām attālinātām procedūrām. Piemēram, attālais pakalpojums failu sistēma NFS, kas ir veidota uz RPC izsaukumiem, var sastāvēt tikai no divām programmām: piemēram, viena programma mijiedarbojas ar augsta līmeņa lietotāja saskarnēm, bet otra ar zema līmeņa I/O funkcijām.

Katrā attālās procedūras izsaukumā ir iesaistītas divas puses: aktīvais klients, kas nosūta procedūras izsaukuma pieprasījumu serverim, un serveris, kas nosūta klientam atbildi.

Piezīme. Jāpatur prātā, ka termini "klients" un "serveris" šajā gadījumā attiecas uz konkrētu darījumu.Konkrēts resursdators vai programmatūra (process vai programma) var darboties gan kā klients, gan kā serveris. Piemēram, programma, kas nodrošina attālo procedūru pakalpojumu, vienlaikus var būt klients darbam ar tīkla failu sistēmu.

RPC protokols ir veidots uz attālā procedūru izsaukuma modeļa, kas ir līdzīgs lokālajam procedūru izsaukuma mehānismam. Izsaucot lokālo procedūru, argumenti tiek virzīti uz noteiktu vietu atmiņā, stekā vai vides mainīgie un nodot procesa kontroli uz noteiktu adresi. Kad darbs ir pabeigts, jūs izlasiet rezultātus noteiktā adresē un turpiniet procesu.

Strādājot ar attālo procedūru, galvenā atšķirība ir tā, ka attālās funkcijas izsaukumu apstrādā divi procesi: klienta process un servera process.

Klienta process nosūta serverim ziņojumu, kurā ir iekļauti izsauktās procedūras parametri, un gaida atbildes ziņojumu ar sava darba rezultātiem. Kad tiek saņemta atbilde, rezultāts tiek nolasīts un process turpinās. Servera pusē zvanu apstrādātāja process atrodas gaidīšanas stāvoklī, un, kad pienāk ziņojums, tas nolasa procedūras parametrus, izpilda to, nosūta atbildi un nonāk nākamā zvana gaidīšanas stāvoklī.

RPC protokols neuzliek nekādas prasības papildu sakariem starp procesiem un neprasa veikto funkciju sinhronizāciju, tas ir, zvani var būt asinhroni un savstarpēji neatkarīgi, lai klients, gaidot atbildi, varētu veikt citas procedūras. RPC serveris katrai funkcijai var atvēlēt atsevišķu procesu vai virtuālo mašīnu, tāpēc, negaidot iepriekšējo pieprasījumu izpildi, var uzreiz pieņemt nākamos.

Tomēr pastāv vairākas būtiskas atšķirības starp vietējo un attālo procedūru izsaukumiem:

1. Kļūda apstrādē. Jebkurā gadījumā klientam jāsaņem paziņojums par kļūdām, kas rodas, izsaucot attālās procedūras serverī vai tīklā.
2. Globālie mainīgie. Tā kā serverim nav piekļuves klienta adrešu telpai, attālie procedūru izsaukumi nevar izmantot slēptos parametrus globālo mainīgo formā.
3. Performance. Attālināto procedūru izpildes ātrums parasti ir par vienu vai divām kārtām mazāks nekā līdzīgu vietējo procedūru izpildes ātrums.
4. Autentifikācija. Tā kā attālie procedūru izsaukumi notiek tīklā, ir jāizmanto klientu autentifikācijas mehānismi.

Protokolu veidošanas principi.

RPC protokols var izmantot vairākus dažādus transporta protokolus. RPC protokola pienākumi ir tikai nodrošināt standartus un interpretēt ziņojumu pārraidi. Ziņojumu pārraides uzticamību un uzticamību pilnībā nodrošina transporta slānis.

Tomēr RPC var kontrolēt transportēšanas protokola atlasi un dažas funkcijas. Kā piemēru mijiedarbībai starp RPC un transporta protokolu apsveriet procedūru RPC porta piešķiršanai lietojumprogrammas procesam, lai tas darbotos, izmantojot RPC — Portmapper.

Šī funkcija dinamiski (pēc pieprasījuma) piešķir RPC savienojumu noteiktam portam. Funkcija Portmapper tiek izmantota diezgan bieži, jo RPC rezervēto transporta portu kopums ir ierobežots, un procesu skaits, kas potenciāli var darboties vienlaikus, ir ļoti liels. Portmapper, piemēram, tiek izsaukts, atlasot portus mijiedarbībai starp klientu un NFS sistēmas serveri.

Portmapper pakalpojums izmanto mehānismu RPC ziņojumu pārraidīšanai uz noteiktu portu - III. Klients uz šo portu nosūta porta pieprasījuma apraides ziņojumu konkrētam RPC pakalpojumam. Portmapper pakalpojums apstrādā nodokļu ziņojumu, nosaka vietējā RPC pakalpojuma adresi un nosūta klientam atbildi. RPC Portmapper pakalpojums var darboties gan ar TCP, gan UDP protokoliem.

RPC var strādāt ar dažādiem transporta protokoliem, taču nekad nedublē to funkcijas, t.i., ja RPC darbojas virs TCP, visas bažas par RPC savienojuma uzticamību un derīgumu tiek attiecinātas uz TCP. Tomēr, ja RPC protokols ir instalēts papildus UDP, tas var nodrošināt papildu līdzekļus, lai nodrošinātu ziņojumu piegādes garantēšanu.

Piezīme.

Lietojumprogrammu uzdevumi var uzskatīt RPC protokolu par īpašu procedūru funkcijas izsaukšanai JSR (Jump Subroutine Instruction) tīklā.

Lai RPC protokols darbotos, ir jāievēro šādi nosacījumi:

1. Visu attāli izsaukto procedūru unikāla identifikācija noteiktā resursdatorā. RPC pieprasījumos ir trīs identifikatora lauki - attālās programmas (pakalpojuma) numurs, attālās programmas versijas numurs un attālās procedūras numurs. norādīto programmu. Programmas numuru piešķir servisa ražotājs, procedūras numurs norāda šī pakalpojuma konkrēto funkciju
2. RPC protokola versijas identifikācija. RPC ziņojumos ir ietverts RPC protokola versijas lauks. To izmanto, lai koordinētu nodoto parametru formātus, kad klients strādā ar dažādām RPC versijām.
3. Klienta autentifikācijas mehānismu nodrošināšana serverim. RPC protokols nodrošina klienta autentifikācijas procedūru pakalpojumam un, ja nepieciešams, katru reizi, kad klientam tiek veikts pieprasījums vai tiek nosūtīta atbilde. Turklāt RPC ļauj izmantot dažādus papildu drošības mehānismus.

RPC var izmantot četru veidu autentifikācijas mehānismus:

• AUTH_NULL — nav nepieciešama autentifikācija
• AUTH_UNIX - autentifikācija saskaņā ar UNIX standartu
• AUTH_SHORT — UNIX standarta autentifikācija ar savu kodēšanas struktūru
• AUTH_DES - autentifikācija saskaņā ar DES standartu

1. Atbilžu ziņojumu identificēšana atbilstošiem pieprasījumiem. RPC atbildes ziņojumi satur pieprasījuma identifikatoru, no kura tie tika izveidoti. Šo identifikatoru var saukt par RPC zvana transakcijas identifikatoru. Šis mehānisms ir īpaši nepieciešams, strādājot asinhronais režīms un izpildot vairāku RPC izsaukumu secību.
2. Protokola kļūdu identificēšana. Visām tīkla vai servera kļūdām ir unikāli identifikatori, pēc kuriem katrs no savienojuma dalībniekiem var noteikt kļūmes cēloni.

Protokola ziņojumu struktūras

Sūtot RPC ziņojumus, izmantojot transporta protokolu, vienā transporta paketē var atrasties vairāki RPC ziņojumi. Lai atdalītu vienu ziņojumu no cita, tiek izmantots ieraksta marķieris (RM - Record Marker). Katrs RPC ziņojums ir "atzīmēts" ar tieši vienu RM.

RPC ziņojums var sastāvēt no vairākiem fragmentiem. Katrs fragments sastāv no četriem galvenes baitiem un (no 0 līdz 2**31-1) datiem. Pirmais galvenes bits norāda, vai fragments ir pēdējais, bet atlikušais 31 bits norāda datu paketes garumu.

RPC struktūra formāli aprakstīta datu formātu aprakstīšanas un attēlošanas valodā - XDR ar papildinājumiem attiecībā uz procedūru aprakstu. Varētu pat teikt, ka RPC apraksta valoda ir XDR paplašinājums, ko papildina darbs ar procedūrām.

RPC paketes struktūra izskatās šādi:

Atbildes struktūrā (reply_body) var būt vai nu kļūdas struktūra (tādā gadījumā tajā ir kļūdas kods), vai veiksmīga pieprasījuma apstrādes struktūra (tādā gadījumā tajā ir atgriešanas dati).

Augsta līmeņa programmatūras interfeiss.

Apakšprogrammu izmantošana programmā ir tradicionāls veids, kā strukturēt uzdevumu un padarīt to skaidrāku. Biežāk lietotās rutīnas tiek apkopotas bibliotēkās, kur tās var izmantot dažādas programmas. Šajā gadījumā runa ir par lokālu (lokālu) zvanu, t.i., gan izsaucošais, gan izsauktais objekts darbojas vienas programmas ietvaros tajā pašā datorā.

Attālā zvana gadījumā process, kas darbojas vienā datorā, sāk procesu attālajā datorā (tas ir, tas faktiski palaiž procedūras kodu attālajā datorā). Acīmredzot attālināts procedūru izsaukums būtiski atšķiras no tradicionālā lokālā, taču no programmētāja viedokļa šādu atšķirību praktiski nav, t.i., attālinātās procedūras izsaukuma arhitektūra ļauj simulēt lokālo procedūru izsaukumu.

Taču, ja lokālā izsaukuma gadījumā programma nodod parametrus izsauktajai procedūrai un darba rezultātu saņem caur steku vai koplietotās atmiņas apgabaliem, tad attālinātā zvana gadījumā parametru pārsūtīšana pārvēršas par datu pārraidi. pieprasījums tīklā, un darba rezultāts ir saņemtajā atbildē.

Šī pieeja ir iespējamais pamats izplatīto lietojumprogrammu izveidei, un, lai gan daudzas mūsdienu sistēmas neizmanto šo mehānismu, daudzos gadījumos tiek saglabāti pamatjēdzieni un termini. Aprakstot RPC mehānismu, izsaukšanas procesu tradicionāli sauksim par klientu, bet attālo procesu, kas šo procedūru realizē, par serveri.

Attālās procedūras izsaukums ietver šādas darbības:

1. Klienta programma veic lokālu izsaukumu uz procedūru, ko sauc par stub. Šajā gadījumā klients “šķiet”, ka, izsaucot stub, viņš faktiski izsauc servera procedūru. Patiešām, klients nodod nepieciešamos parametrus stub, un tas atgriež rezultātu. Tomēr lietas nav gluži tā, kā klients iedomājas. Stubs uzdevums ir pieņemt attālajai procedūrai paredzētos argumentus, iespējams, pārvērst tos kādā standarta formātā un noformulēt tīkla pieprasījumu. Argumentu iesaiņošanu un tīkla pieprasījuma izveidi sauc par šķirošanu.
2. Tīkla pieprasījums tiek pārsūtīts pa tīklu uz attālo sistēmu. Lai to izdarītu, stub izmanto atbilstošus zvanus, piemēram, tos, kas tika apspriesti iepriekšējās sadaļās. Ņemiet vērā, ka var izmantot dažādus transporta protokolus, ne tikai TCP/IP saimi.
3. Attālajā resursdatorā viss notiek apgrieztā secībā. Servera stubs klausās pieprasījumu un pēc saņemšanas izgūst parametrus - procedūras izsaukuma argumentus. Atdalīšana var ietvert nepieciešamās transformācijas (piemēram, baitu secības izmaiņas).
4. Stubs izsauc reālo servera procedūru, kurai tiek adresēts klienta pieprasījums, nododot tai tīklā saņemtos argumentus.
5. Pēc procedūras pabeigšanas vadība atgriežas servera apakšdaļā, nododot tam nepieciešamos parametrus. Tāpat kā klienta stubs; Servera stubs pārvērš vērtības, kas atgrieztas procedūrā, ģenerējot tīkla atbildes ziņojumu, kas tīklā tiek pārsūtīts uz sistēmu, no kuras tika saņemts pieprasījums.
6. Operētājsistēma nosūta saņemto ziņojumu klienta stub, kas pēc nepieciešamās transformācijas nodod vērtības (kas ir attālinātās procedūras atgrieztās vērtības) klientam, kurš to uzskata par normālu atgriešanos no procedūru.

Tādējādi no klienta viedokļa tas izsauc attālo procedūru tāpat kā vietējai procedūrai. To pašu var teikt par serveri: procedūra tiek izsaukta standarta veidā, noteikts objekts (servera stubs) izsauc lokālo procedūru un saņem tās atgrieztās vērtības. Klients apstrādā stublu kā izsaucamu servera procedūru, un serveris savu apakšnodaļu uzskata par klientu.

Tādējādi stubs veido RPC sistēmas kodolu, kas ir atbildīgs par visiem ziņojumu ģenerēšanas un pārraides aspektiem starp klientu un attālo serveri (procedūra), lai gan gan klients, gan serveris uzskata, ka zvani notiek lokāli. Tas ir RPC pamatjēdziens - pilnībā paslēpt izkliedēto (tīkla) mijiedarbības raksturu pamatkodā. Šīs pieejas priekšrocības ir acīmredzamas: gan klients, gan serveris ir neatkarīgi no tīkla ieviešanas, abi darbojas noteiktā izkliedētā virtuālā iekārta, un procedūru izsaukumiem ir standarta interfeiss.

Parametru nodošana

Vērtību parametru nodošana īpašas grūtības nesagādā. Šajā gadījumā klienta apakšgrupa ievieto parametra vērtību tīkla pieprasījumā, iespējams, veicot konvertēšanu uz standarta formu (piemēram, mainot baitu secību). Situācija ir daudz sarežģītāka ar rādītāju nodošanu, kad parametrs apzīmē datu adresi, nevis tā vērtību. Adreses nodošana pieprasījumā ir bezjēdzīga, jo attālā procedūra tiek izpildīta pilnīgi citā adrešu telpā. Visvairāk vienkāršs risinājums, ko izmanto RPC, ir aizliegt klientiem nodot citus parametrus, nevis pēc vērtības, lai gan tas, protams, uzliek nopietnus ierobežojumus.

Saistošs

Lai klients varētu izsaukt attālo procedūru, tam ir jābūt saistītam ar attālo sistēmu, kas mitina nepieciešamo serveri. Tādējādi saistošais uzdevums ir sadalīts divās daļās:

1. Attālā saimniekdatora atrašana ar nepieciešamo serveri
2. Nepieciešamā servera procesa atrašana noteiktā resursdatorā

Saimnieka atrašanai var izmantot dažādas pieejas. Iespējamais variants- sava veida centralizēta direktorija izveide, kurā saimnieki paziņo par saviem serveriem un kur klients, ja vēlas, var izvēlēties sev piemērotu resursdatora un procedūras adresi.

Katra RPC procedūra ir unikāli identificēta ar programmas un procedūras numuru. Programmas numurs identificē attālo procedūru grupu, kurām katrai ir savs numurs. Katrai programmai tiek piešķirts arī versijas numurs, lai, veicot nelielas izmaiņas programmā (piemēram, pievienojot procedūru), tās numurs nav jāmaina. Parasti vienā programmatūras modulī tiek realizētas vairākas funkcionāli līdzīgas procedūras, kas, palaižot tās, kļūst par šo procedūru serveri un tiek identificētas pēc programmas numura.

Tādējādi, ja klients vēlas izsaukt attālo procedūru, viņam jāzina programma, versija un procedūru numuri, kas nodrošina nepieciešamo pakalpojumu.

Lai pārsūtītu pieprasījumu, klientam ir jāzina arī resursdatora tīkla adrese un porta numurs, kas saistīts ar servera programmu, kas nodrošina nepieciešamās procedūras. Šim nolūkam tiek izmantots portmap(IM) dēmons (dažās sistēmās to sauc par rpcbind(IM). Dēmons darbojas resursdatorā, kas nodrošina attālās procedūras pakalpojumu un izmanto labi zināmu porta numuru. Kad servera process tiek inicializēts, tas reģistrē savas procedūras un portu numurus portmap (IM). Tagad, kad klientam ir jāzina porta numurs, lai izsauktu konkrētu procedūru, tas nosūta pieprasījumu portmap (IM) serverim, kas savukārt vai nu atgriež porta numuru, vai pārsūta pieprasījumu tieši uz attālo procedūru serveri un pēc tam izpildot to, atgriež klientam atbildi. Jebkurā gadījumā, ja vajadzīgā procedūra pastāv, klients saņem procedūras porta numuru no portmap (IM) servera, un turpmākos pieprasījumus var veikt tieši uz šo portu.

Īpašu situāciju risināšana (izņēmums)

Izņēmumu apstrāde, izsaucot vietējās procedūras, nav īpaši problemātiska. UNIX nodrošina procesa kļūdu apstrādi, piemēram, dalīšanu ar nulli, piekļuvi nederīgam atmiņas apgabalam utt. Attālās procedūras izsaukšanas gadījumā kļūdu situāciju iespējamība palielinās. Papildus servera un nepilnības kļūdām tiek pievienotas kļūdas, kas saistītas, piemēram, ar kļūdaina tīkla ziņojuma saņemšanu.

Piemēram, izmantojot UDP kā transporta protokolu, ziņojumi tiek atkārtoti pārsūtīti pēc noteikta taimauta. Kļūda tiek atgriezta klientam, ja pēc noteikta mēģinājumu skaita atbilde no servera nav saņemta. Gadījumā, ja tiek izmantots TCP protokols, klientam tiek atgriezta kļūda, ja serveris ir slēdzis TCP savienojumu.

Zvana semantika

Vietējās procedūras izsaukšana viennozīmīgi noved pie tās izpildes, pēc kuras vadība atgriežas galvenajā programmā. Izsaucot attālināto procedūru, situācija ir citāda. Nav iespējams noteikt, kad tieši procedūra tiks veikta, vai tā vispār tiks veikta un ja jā, tad cik reizes? Piemēram, ja attālā sistēma saņem pieprasījumu pēc servera programmas avārijas, procedūra netiks izpildīta vispār. Ja klients, nesaņemot atbildi pēc noteikta laika perioda (taimauts), atkārtoti nosūta pieprasījumu, tad var rasties situācija, kad atbilde jau tiek pārsūtīta tīklā, un atkārtotais pieprasījums atkal tiek pieņemts apstrādei ar tālvadības pulti. procedūru. Šajā gadījumā procedūra tiks veikta vairākas reizes.

Tādējādi attālās procedūras izpildi var raksturot ar šādu semantiku:

• Vienreiz un tikai vienu reizi. Šo darbību (dažos gadījumos visvēlamāko) ir grūti pieprasīt iespējamo servera avāriju dēļ.
• Maksimālais reizes. Tas nozīmē, ka procedūra vai nu netika veikta vispār vai tika veikta tikai vienu reizi. Līdzīgu paziņojumu var izdarīt, saņemot kļūdu parastās atbildes vietā.
• Vismaz vienreiz. Iespējams, ka procedūra tika veikta vienu reizi, bet ir iespējams vairāk. Priekš normāla darbībašādā situācijā attālinātajai procedūrai ir jābūt idempotences īpašībai (no angļu valodas idemponent). Šis īpašums piemīt procedūrai, kuras atkārtota izpilde neizraisa kumulatīvās izmaiņas. Piemēram, faila lasīšana ir idempotenta, bet teksta pievienošana failam nav.

Datu prezentācija

Ja klients un serveris darbojas vienā un tajā pašā datorā, datu nesaderības problēmas nerodas. Gan klientam, gan serverim dati binārā formā tiek attēloti vienādi. Attālinātā zvana gadījumā situāciju sarežģī fakts, ka klients un serveris var darboties sistēmās ar atšķirīgu arhitektūru, kurām ir dažādi datu attēlojumi (piemēram, peldošā komata attēlojums, baitu secība utt.)

Lielākā daļa RPC sistēmu ieviešanu definē dažus standarta datu attēlojumus, uz kuriem ir jāpārvērš visas pieprasījumos un atbildēs nodotās vērtības.

Piemēram, Sun Microsystems datu prezentācijas RPC formāts ir šāds:

1. Baitu secība — visnozīmīgākā — pēdējā
2. Peldošā komata attēlojums — IEEE
3. Rakstzīmju attēlojums - ASCII

Tīkls

Funkcionalitātes ziņā RPC sistēma ieņem starpvietu starp lietojumprogrammas slāni un transporta slāni. Saskaņā ar OSI modeli šī pozīcija atbilst prezentācijas un sesijas slāņiem. Tādējādi RPC teorētiski ir neatkarīgs no tīkla ieviešanas, jo īpaši no transporta slāņa tīkla protokoliem.

Sistēmas programmatūras implementācijas, kā likums, atbalsta vienu vai divus protokolus. Piemēram, Sun Microsystems izstrādātā RPC sistēma atbalsta ziņojumu pārraidi, izmantojot TCP un UDP protokolus. Viena vai cita protokola izvēle ir atkarīga no lietojumprogrammas prasībām. UDP protokola izvēle ir pamatota lietojumprogrammām, kurām ir šādas īpašības:

• Izsauktās procedūras ir idempotentas
• Pārsūtīto argumentu un atgrieztā rezultāta lielums ir mazāks par UDP paketes izmēru - 8 KB.
• Serveris nodrošina darbu ar vairākiem simtiem klientu. Tā kā, strādājot ar TCP protokoliem, serveris ir spiests uzturēt savienojumu ar katru no aktīvajiem klientiem, tas aizņem ievērojamu daļu tā resursu. UDP protokols šajā ziņā ir mazāk resursietilpīgs

No otras puses, TCP nodrošina efektīvu lietojumprogrammu darbību ar šādām īpašībām:

• Lietojumprogrammai ir nepieciešams uzticams pārsūtīšanas protokols
• Izsauktās procedūras nav identiskas
• Argumentu vai atgriešanas rezultāta lielums pārsniedz 8 KB

Protokola izvēle parasti tiek atstāta klienta ziņā, un sistēma dažādos veidos organizē ziņojumu ģenerēšanu un pārraidi. Jā, lietojot TCP protokols, kuriem pārsūtītie dati ir baitu plūsma, ir nepieciešams atdalīt ziņojumus vienu no otra. Šim nolūkam tiek izmantots, piemēram, RFC1057 aprakstītais ierakstu marķēšanas protokols "RPC: Remote Procedure Call Protocol specifikācijas versija 2", kurā katra ziņojuma sākumā tiek ievietots 32 bitu vesels skaitlis, kas nosaka ziņojuma izmēru. baitos.

Situācija ir citāda ar zvana semantiku. Piemēram, ja RPC tiek veikts, izmantojot neuzticamu transporta protokolu (UDP), sistēma atkārtoti pārsūta ziņojumu ar īsiem intervāliem (taimautu). Ja klienta iesniegums nesaņem atbildi, tad ar pārliecību varam teikt, ka procedūra tika pabeigta nulle vai lielāks skaits vienreiz. Ja tiek saņemta atbilde, pieteikumā var secināt, ka procedūra ir veikta vismaz vienu reizi. Izmantojot uzticamu transporta protokolu (TCP), ja tiek saņemta atbilde, var teikt, ka procedūra ir veikta vienu reizi. Ja atbilde netiek saņemta, nav iespējams viennozīmīgi teikt, ka procedūra nav pabeigta3.

Kā tas strādā?

Būtībā pati RPC sistēma ir iebūvēta klienta programmā un servera programmā. Patīkami, ka, izstrādājot izplatītās lietojumprogrammas, nav jāiedziļinās RPC protokola vai programmas ziņojumu apstrādes detaļās. Sistēma uzņemas atbilstošas ​​izstrādes vides esamību, kas ievērojami atvieglo aplikācijas veidotāju dzīvi. programmatūra. Viens no galvenajiem punktiem RPC ir tas, ka izkliedētās lietojumprogrammas izstrāde sākas ar objekta interfeisa definēšanu - formālu servera funkciju aprakstu, kas uzrakstīts īpašā valodā. Pamatojoties uz šo interfeisu, pēc tam tiek automātiski ģenerēti klienta un servera stubs. Vienīgais, kas jums jādara pēc tam, ir jāuzraksta faktiskais procedūras kods.

Piemēram, apsveriet RPC no Sun Microsystems. Sistēma sastāv no trim galvenajām daļām:

• rpcgen(1) ir RPC kompilators, kas, pamatojoties uz attālās procedūras saskarnes aprakstu, ģenerē klienta un servera stubs C programmu veidā.
• XDR (eXternal Data Representation) bibliotēka, kas satur transformācijas funkcijas dažādi veidi datus no mašīnas neatkarīgā formā, kas ļauj apmainīties ar informāciju starp neviendabīgām sistēmām.
• Moduļu bibliotēka, kas nodrošina sistēmas darbību kopumā.

Apskatīsim vienkāršas izplatītas notikumu reģistrēšanas lietojumprogrammas piemēru. Kad klients startē, tas izsauc attālo procedūru, lai ierakstītu ziņojumu attālā datora žurnālfailā.

Lai to izdarītu, jums būs jāizveido vismaz trīs faili: attālo procedūru log.x saskarņu specifikācija (saskarnes apraksta valodā), attālo procedūru log.c faktiskais teksts un galvenā faila teksts. klienta programmas galvenais () - klients.c (C valodā).

Rpcgen(l) kompilators izveido trīs failus, pamatojoties uz log.x specifikāciju: klienta un servera stublu tekstu C valodā (log clnt.c un log svc.c) un apraksta failu log.h, ko izmanto abas stubs. .

Tātad, apskatīsim programmu pirmkodus.

Šis fails norāda attālās procedūras reģistrācijas parametrus - programmu, versiju un procedūru numurus, kā arī definē izsaukuma interfeisu - ievades argumentus un atgriešanas vērtības. Tādējādi tiek definēta RLOG procedūra, kas izmanto virkni kā argumentu (kas tiks ierakstīta žurnālā), un atgriešanas vērtība parasti norāda pasūtītās darbības veiksmi vai neveiksmi.

programma LOG_PROG( versija LOG_VER( starpt RLOG(virkne) = 1; ) = 1; ) = 0x31234567;

Rpcgen(l) kompilators izveido galvenes failu log.h, kur jo īpaši ir noteiktas procedūras:

Apskatīsim šo failu uzmanīgi. Kompilators interfeisa apraksta failā definēto RLOG nosaukumu pārvērš rlog_1, aizstājot lielos burtus ar mazajiem burtiem un pievienojot programmas versijas numuru ar pasvītrojumu. Atgriešanas veids ir mainīts no int uz int*. Šis ir noteikums - RPC ļauj pārsūtīt un saņemt tikai to parametru adreses, kas deklarēti, aprakstot saskarni. Tas pats noteikums attiecas uz virkni, kas nodota kā arguments. Lai gan tas neparādās no print.h, funkcija rlog_l() faktiski nodod virknes adresi kā argumentu.

Papildus galvenes failam rpcgen(l) kompilators rada klienta apakšdaļas un servera apakšmoduļus. Būtībā šo failu teksts satur visu attālā zvana kodu.

Servera stubs ir galvenā programma, kas apstrādā visas tīkla mijiedarbības ar klientu (precīzāk, ar tā stub). Lai veiktu operāciju, servera stubs veic lokālās funkcijas izsaukumu, kura teksts ir jāieraksta:

Klienta stubs pieņem attālajai procedūrai nodoto argumentu, veic nepieciešamos reklāmguvumus, izdod pieprasījumu portmap(1M) serverim, sazinās ar attālās procedūras serveri un visbeidzot nodod klientam atgriešanas vērtību. Klientam zvans uz attālo procedūru tiek samazināts līdz izsaukumam uz stub un neatšķiras no parastā vietējā zvana.

klients.c

#iekļauts #iekļauts"log.h" galvenais(starpt argc char*argv) ( KLIENTS *cl; char*serveris, *mystring, *clnttime; time_t bintime; starpt*rezultāts; ja(argc != 2) ( fprintf(stderr, "Zvana formāts: %s Host_Address\n", argv ); iziet (1) ; ) serveris = argv ; /*Iegūstiet klienta deskriptoru. Ja tas neizdosies, mēs jūs informēsim, ka nav iespējams izveidot savienojumu ar serveri*/ ja((c1 = clnt_create (serveris, LOG_PROG, LOG_VER, "udp")) == NULL) ( clnt_pcreateerror (serveris); iziet (2); ) /*Piešķirt līnijai buferi*/ mystring = ( char*)malloc(100); /*Noteikt notikuma laiku*/ bintime = laiks ((laiks_t *) NULL); clnttime = ctime(&bintime); sprintf (mystring, "%s — klients startēts", clnttime); /*Nosūtīt ziņu žurnālam - laiks, kad klients sāka strādāt. Ja neizdosies, ziņosim par kļūdu*/ ja((rezultāts = rlog_l(&mystring, cl)) == NULL) ( fprintf(stderr, "error2\n"); clnt_perror(cl, serveris); iziet(3); ) /*Attālā datora kļūmes gadījumā ziņosim par kļūdu*/ ja(*rezultāts !=0) fprintf(stderr, "Kļūda, rakstot žurnālā\n"); /*0atbrīvojiet rokturi*/ cint iznīcināt(cl); iziet(0); )

Klienta stubs log_clnt.c ir apkopots ar moduli client.c, lai izveidotu izpildāmu klienta programmu.

Tagad kādā resursdatorā server.nowhere.ru jums jāsāk servera process:

$logger

Pēc tam, palaižot rlog klientu citā datorā, serveris žurnāla failam pievienos atbilstošu ierakstu.

RPC darbības diagramma šajā gadījumā ir parādīta attēlā. 1. Moduļi mijiedarbojas šādi:

1. Kad servera process sākas, tas izveido UDP ligzdu un saista jebkuru vietējo portu ar šo ligzdu. Pēc tam serveris izsauc bibliotēkas funkciju svc_register(3N), lai reģistrētu programmu numurus un versijas. Lai to izdarītu, funkcija izsauc portmap(IM) procesu un nodod vajadzīgās vērtības. Portmap (IM) serveris parasti tiek palaists, kad sistēma ir inicializēta, un tas ir saistīts ar kādu labi zināmu portu. Tagad portmap(3N) zina mūsu programmas un versijas porta numuru. Serveris gaida pieprasījuma saņemšanu. Ņemiet vērā, ka visas aprakstītās darbības veic servera stubs, ko izveidojis rpcgen(IM) kompilators.
2. Kad rlog darbojas, vispirms tas izsauc bibliotēkas funkciju clnt_create(3N), piešķirot tai attālās sistēmas adresi, programmas un versiju numurus un transporta protokolu. Funkcija nosūta pieprasījumu attālās sistēmas server.nowhere.m portmap(IM) serverim un iegūst žurnāla servera attālā porta numuru.
3. Klients izsauc klienta apakšnodaļā definēto procedūru rlog_1() un nodod vadību uz apakšnodaļu. Tas savukārt ģenerē pieprasījumu (pārveidojot argumentus XDR formātā) UDP paketes veidā un nosūta to uz attālo portu, kas saņemts no portmap (IM) servera. Pēc tam tas kādu laiku gaida atbildi un, ja tas netiek saņemts, pieprasījumu nosūta atkārtoti. Labvēlīgos apstākļos pieprasījumu akceptē reģistrētāja serveris (servera stub modulis). Stub nosaka, kura funkcija tika izsaukta (pēc procedūras numura), un izsauc log.c moduļa funkciju rlog_1(). Pēc tam, kad vadīkla atgriežas apakšdaļā, tā pārvērš funkcijas rlog_1() atgriezto vērtību XDR formātā un ģenerē atbildi arī UDP paketes veidā. Saņemot atbildi, klients izņem atgriezto vērtību, pārveido to un atgriež klienta galvenajā programmā.

Zvanīt ar tālvadības pulti RPC procedūras Attālās procedūras izsaukuma koncepcija Remote Procedure Call — RPC ideja ir paplašināt labi zināmo un saprotamo mehānismu vadības un datu pārsūtīšanai programmā, kas darbojas vienā mašīnā, lai pārsūtītu vadību un datus tīklā. Attālās procedūru izsaukuma rīki ir paredzēti, lai atvieglotu izkliedētās skaitļošanas organizēšanu.Vislielākā RPC izmantošanas efektivitāte tiek sasniegta tajās lietojumprogrammās, kurās notiek interaktīva komunikācija starp attālinātajiem komponentiem ar īsu reakcijas laiku un salīdzinoši nelielu pārsūtīto datu apjomu.

Šādas lietojumprogrammas sauc par RPC orientētām. Vietējo procedūru izsaukšanas raksturīgās iezīmes ir asimetrija, tas ir, viena no mijiedarbības pusēm ir iniciators Sinhronitāte, tas ir, izsaukšanas procedūras izpilde apstājas no pieprasījuma izsaukšanas brīža un atsāk tikai pēc atgriešanās no izsauktās procedūras. Attālināto zvanu ieviešana ir daudz sarežģītāka nekā vietējo procedūru zvanu ieviešana.

Pirmkārt, tā kā izsaukšanas un izsaukšanas procedūras tiek izpildītas dažādās iekārtās, tām ir dažādas adrešu telpas, un tas rada problēmas parametru un rezultātu nodošanā, īpaši, ja mašīnas nav identiskas. Tā kā RPC nevar paļauties uz koplietojamo atmiņu, tas nozīmē ka RPC parametros nedrīkst būt norādes uz vietām, kas nav steka atmiņas vietas, un ka parametru vērtības ir jākopē no viena datora uz citu.

Nākamā atšķirība starp RPC un vietējo zvanu ir tāda, ka tajā obligāti tiek izmantota pamatā esošā sakaru sistēma, taču tam nevajadzētu būt skaidri redzamam ne procedūru definīcijā, ne pašās procedūrās. Attālums rada papildu problēmas. Izsaucošās programmas un izsauktās lokālās procedūras izpilde tajā pašā mašīnā tiek realizēta viena procesa ietvaros, bet RPC ieviešana ietver vismaz divus procesus - pa vienam katrā mašīnā.

Gadījumā, ja kāds no tiem avarē, var rasties šādas situācijas: ja izsaukšanas procedūra neizdodas, attālināti izsauktās procedūras kļūs par bāreņiem, un, ja tālvadības procedūras avarē, zvanīšanas procedūras kļūs par bāreņiem vecākiem, kuri velti gaidīs atbildi. no attālajām procedūrām. Turklāt pastāv vairākas problēmas, kas saistītas ar programmēšanas valodu un darbības vidi neviendabīgumu, datu struktūras un procedūru izsaukuma struktūras, kas tiek atbalstītas nevienā programmēšanas valodā, netiek atbalstītas vienādi visās citās valodas.

Šīs un dažas citas problēmas atrisina plaši izplatītā RPC tehnoloģija, kas ir daudzu izplatītu operētājsistēmu pamatā. RPC pamatdarbības Lai saprastu, kā darbojas RPC, vispirms apsveriet iespēju veikt lokālu procedūru izsaukumu parastai mašīnai, kas darbojas autonomi. sistēmas zvans skaitīt lasīt fd,buf,nbaitus, kur fd ir vesels skaitlis, buf ir rakstzīmju masīvs, nbaiti ir vesels skaitlis.

Lai veiktu zvanu, izsaukšanas procedūra nospiež parametrus uz steku apgrieztā secībā, kā parādīts 3.1. attēlā. Pēc lasīšanas zvana izpildes tas ievieto atgriešanas vērtību reģistrā, pārvieto atgriešanas adresi un atgriež vadību izsaukšanas procedūrā, kas ienes parametrus no steka, atgriežot to sākotnējais stāvoklisŅemiet vērā, ka C valodā parametrus var izsaukt vai nu ar atsauci pēc nosaukuma, vai pēc vērtības pēc vērtības. Saistībā ar izsaukto procedūru vērtību parametri ir inicializēti vietējie mainīgie.

Izsauktā procedūra var tos mainīt, neietekmējot šo mainīgo sākotnējās vērtības izsaukšanas procedūrā. Ja rādītājs uz mainīgo tiek nodots izsauktajai procedūrai, tad, mainot šī mainīgā lieluma vērtību ar izsaukto procedūru, tiek mainīta šī mainīgā vērtība izsaucējai procedūrai, kas ir ļoti nozīmīgs RPC. Ir arī cits mehānisms parametru nodošanai, kas netiek izmantots C. To sauc par izsaukuma atjaunošanu, un tas nozīmē, ka izsaucēja programma kopē mainīgos stekā kā vērtības un pēc tam kopē tos atpakaļ pēc izsaukuma, izmantojot oriģinālu. zvanīšanas procedūras vērtības.

Lēmumu par to, kuru parametru nodošanas mehānismu izmantot, pieņem valodas izstrādātāji. Dažreiz tas ir atkarīgs no nododamo datu veida. Piemēram, valodā C veseli skaitļi un citi skalārie dati vienmēr tiek nodoti pēc vērtības, un masīvi vienmēr tiek nodoti pēc atsauces.

Rīsi. 3.1. a Kaudzīte pirms lasīšanas izsaukuma izpildes b Kaudzīte procedūras izpildes laikā c Steka pēc atgriešanās pie izsaukšanas programmas RPC ideja ir panākt, lai attālās procedūras izsaukums izskatītos pēc iespējas līdzīgāks izsaukumam uz vietējā procedūra. Citiem vārdiem sakot, lai RPC padarītu caurspīdīgu, izsaukšanas procedūrai nav jāzina, ka izsauktā procedūra atrodas citā iekārtā, un otrādi. RPC nodrošina caurspīdīgumu šādā veidā.

Ja izsauktā procedūra faktiski ir attālināta, vietējās procedūras vietā bibliotēkā tiek ievietota cita procedūras versija, ko sauc par klienta stub. Līdzīgi kā sākotnējā procedūrā, stubs tiek izsaukts, izmantojot izsaukšanas secību, kā parādīts 3.1. attēlā, un, piekļūstot kodolam, notiek pārtraukums. Tikai atšķirībā no sākotnējās procedūras tā neievieto parametrus reģistros un nepieprasa datus no kodola; tā vietā tā ģenerē ziņojumu, kas jānosūta attālās mašīnas kodolam. RPC izpildes posmi Programmatūras komponentu mijiedarbība, veicot attālās procedūras izsaukumu, ir parādīta 3.2. attēlā. Pēc tam, kad klienta programma ir izsaukusi klienta apakšnodaļu, tās pirmais uzdevums ir aizpildīt buferi ar sūtāmo ziņojumu.

Dažās sistēmās klienta apakšdaļā ir viens fiksēta garuma buferis, kas tiek aizpildīts no paša sākuma ar katru jaunu pieprasījumu. Citās sistēmās ziņojumu buferis ir atsevišķu ziņojumu lauku buferu kopums, no kuriem daži jau ir pilni.

Šī metode ir īpaši piemērota gadījumiem, kad paketei ir formāts, kas sastāv no liela skaita lauku, bet daudzu šo lauku vērtības nemainās no zvana uz zvanu. Pēc tam parametri ir jāpārveido atbilstošā formātā un jāievieto ziņojumu buferī.Šajā brīdī ziņojums ir gatavs nosūtīšanai, tāpēc tiek izpildīts kodola izsaukuma pārtraukums. Rīsi. 3.2. Attālās procedūras izsaukšana Kad kodols iegūst kontroli, tas pārslēdz kontekstus, saglabā procesora reģistrus un atmiņas kartes lapu rokturus un instalē jaunu atmiņas karti, kas tiks izmantota, lai darbotos kodola režīmā. Tā kā kodola un lietotāja konteksti atšķiras, kodolam ziņojums ir precīzi jāiekopē savā adrešu telpā, lai tas varētu tai piekļūt, atcerēties galamērķa adresi un, iespējams, citus galvenes laukus, un tas jānosūta tīkla saskarnei.

Tas pabeidz darbu klienta pusē.

Pārraides taimeris ir ieslēgts, un kodols var vai nu cikliski aptaujāt atbildi, vai nodot vadību plānotājam, kas atlasīs kādu citu palaišanas procesu. Pirmajā gadījumā vaicājuma izpilde tiek paātrināta, bet nav daudzprogrammēšanas. Servera pusē ienākošos bitus izvieto saņemošā aparatūra vai nu iebūvētajā buferī, vai arī iekšā RAM.Kad visa informācija ir saņemta, tiek ģenerēts pārtraukums.

Pārtraukumu apdarinātājs pārbauda paketes datu derīgumu un nosaka, kuram blokam to nodot. Ja pakete nav sagaidāma, pārtraukumu apstrādātājam tā ir vai nu jābuferē, vai arī pilnībā jāizmet. Ja ir gaidīšanas stubs, ziņojums tiek kopēts uz to. Visbeidzot tiek veikta konteksta pārslēgšana, kā rezultātā tiek atjaunoti reģistri un atmiņas karte, ņemot vērā vērtības, kas tiem bija brīdī, kad stubs veica saņemšanas zvanu.

Tagad servera stubs sāk darboties. Tas izpako parametrus un atbilstoši nospiež tos uz kaudzes. Kad viss ir gatavs, tiek veikts zvans uz serveri. Pēc procedūras pabeigšanas serveris nosūta rezultātus klientam.Lai to izdarītu, tiek veiktas visas iepriekš aprakstītās darbības, tikai apgrieztā secībā. Attēlā 3.3 ir parādīta komandu secība, kas jāizpilda katram RPC izsaukumam, un 3.4. attēlā parādīta, kāda daļa no kopējā RPC izpildes laika tiek pavadīta katrā no aprakstītajām 14 darbībām.

Pārbaudes tika veiktas DEC Firefly vairāku procesoru darbstacijā, un, lai gan piecu procesoru klātbūtne noteikti ietekmēja mērījumu rezultātus, attēlā redzamā histogramma sniedz vispārēju priekšstatu par RPC izpildes procesu. Rīsi. 3.3. RPC procedūras posmi Fig. 3.4. Laika sadalījums starp 14 RPC izpildes posmiem 1. Izsaukt stub 2. Sagatavot buferi 3. Pakot parametrus 4. Aizpildiet galvenes lauku 5. Aprēķiniet ziņojuma kontrolsummu 6. Pārtraukums kodolam 7. Ievietojiet paketi izpildei rindā. 8. Pārsūtiet ziņojumu uz kontrolieri caur QBUS kopni 9. Pārsūtīšanas laiks pa Ethernet tīklu 10. Saņemiet paketi no kontrollera 11. Pārtraukumu apstrādes procedūra 12. Kontrolsummas aprēķināšana 13. Konteksta pārslēgšanās uz lietotāja telpu 14. Servera stubs veikšana Dinamiskā saistīšana Apskatīsim jautājumu par to, kā klients norāda servera atrašanās vietu.

Viena no metodēm šīs problēmas risināšanai ir tieša izmantošana tīkla adrese serveris klienta programmā.

Šīs pieejas trūkums ir tas, ka tā ir ārkārtīgi neelastīga, pārvietojot serveri vai palielinot serveru skaitu, vai mainot interfeisu; visos šajos un daudzos citos gadījumos ir nepieciešams pārkompilēt visas programmas, kas izmantoja cieto servera iestatījumu. Lai izvairītos no visām šīm problēmām, dažās izplatītajās sistēmās tiek izmantota tā sauktā dinamiskā saistīšana.

Dinamiskās saistīšanas sākumpunkts ir formāli definēt servera specifikāciju. Specifikācija satur failu servera nosaukumu, versijas numuru un pakalpojumu procedūru sarakstu, ko šis serveris nodrošina klientiem (3.5. attēls). Katrai procedūrai ir sniegts tās parametru apraksts, norādot, vai tā ir šis parametrs Ievade vai izvade attiecībā pret serveri. Daži parametri var būt gan ievade, gan izvade — piemēram, kāds masīvs, ko klients nosūta serverim, tur tiek modificēts un pēc tam tiek atgriezts klientam, veicot kopijas atjaunošanas darbību. Rīsi. 3.5. RPC servera specifikācija Formālā servera specifikācija tiek izmantota kā ievade stub ģeneratora programmai, kas izveido gan klienta, gan servera stubs.

Pēc tam tie tiek ievietoti attiecīgajās bibliotēkās. Kad lietotāja klienta programma izsauc jebkuru servera specifikācijā definētu procedūru, atbilstošā stub procedūra tiek saistīta ar programmas bināro kodu.

Tāpat, kad serveris tiek kompilēts, ar to tiek saistīti servera elementi. Kad serveris startē, tā pati pirmā darbība ir tā servera saskarnes pārsūtīšana īpaša programma, ko sauc par saistvielu. Šis process, kas pazīstams kā servera reģistrācijas process, ietver servera nosaukuma, versijas numura, unikālā identifikatora un servera atrašanās vietas deskriptora pārsūtīšanu. Deskriptors ir neatkarīgs no sistēmas un var būt IP, Ethernet, X.500 vai kāds cits. cita adrese.

Turklāt tajā var būt cita informācija, piemēram, saistīta ar autentifikāciju. Kad klients pirmo reizi izsauc kādu no attālajām procedūrām, piemēram, lasa, klienta stubs redz, ka tas vēl nav savienots ar serveri, un nosūta ziņojumu saistīšanas programmai ar lūgumu importēt saskarni. nepieciešamo versiju Ja šāds serveris eksistē, tad binder nodod klienta stub deskriptoru un unikālo identifikatoru.

Nosūtot ziņojumu ar pieprasījumu, klienta stubs kā adresi izmanto deskriptoru. Ziņojumā ir ietverti parametri un unikāls identifikators, ko servera kodols izmanto, lai maršrutētu ienākošo ziņojumu uz vēlamo serveri, ja šajā mašīnā ir vairāki no tiem. Šī saskarņu importēšanas un eksportēšanas metode ir ļoti elastīga, piemēram, var būt vairāki serveri, kas atbalsta vienu un to pašu interfeisu, un klienti tiek nejauši sadalīti starp serveriem.

Šīs metodes ietvaros kļūst iespējams periodiski aptaujāt serverus, analizēt to veiktspēju un kļūmes gadījumā automātiski izslēgt, kas palielina sistēmas kopējo kļūdu toleranci. Šī metode var arī atbalstīt klienta autentifikāciju. Piemēram, serveris var noteikt, ka to var izmantot tikai klienti no konkrēta saraksta. Tomēr dinamiskajai saistīšanai ir trūkumi, piemēram, papildu pieskaitāmās izmaksas un laiks, kas pavadīts saskarņu eksportēšanai un importēšanai.

Šo izmaksu apjoms var būt ievērojams, jo daudzi klienta procesi pastāv īsu laiku, un katru reizi, kad process sākas, saskarnes importēšanas procedūra ir jāveic vēlreiz. Turklāt lielās dalītās sistēmās saistīšanas programma var kļūt par vājo vietu, un vairāku programmu izveide ar vienu un to pašu mērķi palielina arī procesu izveides un sinhronizēšanas izmaksas.RPC semantika kļūmju gadījumā Ideālā gadījumā RPC būtu pareizi jāfunkcionē gadījumā. neveiksmēm.

Apsveriet šādas kļūmju klases: 1. Klients nevar atrast serveri, piemēram, ja vēlamais serveris neizdodas vai klienta programma ir kompilēta jau sen un izmantota. vecā versija servera saskarne. Šajā gadījumā, atbildot uz klienta pieprasījumu, tiek saņemts ziņojums ar kļūdas kodu. 2. Pieprasījums no klienta uz serveri tika pazaudēts Vienkāršākais risinājums ir atkārtot pieprasījumu pēc noteikta laika. 3. Atbildes ziņojums no servera klientam tiek pazaudēts.

Šī opcija ir sarežģītāka nekā iepriekšējā, jo dažas procedūras nav idempotiskas. Idempotenta procedūra ir procedūra, kuras izpildes pieprasījumu var atkārtot vairākas reizes, nemainot rezultātu. Šādas procedūras piemērs ir faila nolasīšana, taču noteiktas summas izņemšanas procedūra no bankas konta nav idempotena, un, ja atbilde tiek zaudēta, atkārtots pieprasījums var būtiski mainīt klienta konta stāvokli.

Viens no iespējamiem risinājumiem ir padarīt visas procedūras idempotentas. Tomēr praksē tas ne vienmēr ir iespējams, tāpēc var izmantot citu metodi - visu pieprasījumu secīgu numerāciju, ko veic klienta kodols. Servera kodols atceras katra klienta jaunākā pieprasījuma numuru un, saņemot katru pieprasījumu, analizē, vai šis pieprasījums ir primārais vai atkārtots. 4. Serveris avarēja pēc pieprasījuma saņemšanas.Šeit svarīga ir arī idempotency īpašība, bet diemžēl nevar pielietot pieeju ar pieprasījumu numerāciju.

Šajā gadījumā ir nozīme, kad kļūme radusies – pirms vai pēc operācijas. Taču klienta kodols nevar atpazīt šīs situācijas; tas zina tikai to, ka atbildes laiks ir beidzies. Šai problēmai ir trīs pieejas: Pagaidiet, līdz serveris tiek restartēts, un mēģiniet darbību vēlreiz. Šī pieeja nodrošina, ka RPC tiek pabeigta vismaz vienu reizi un, iespējams, vairāk. Nekavējoties ziņojiet par kļūdu lietojumprogrammai.

Šī pieeja nodrošina, ka RPC tiek izpildīts ne vairāk kā vienu reizi. Trešā pieeja neko negarantē. Ja serveris neizdodas, klientam netiek sniegts atbalsts. RPC var vai nu neizpildīt vispār, vai arī to var izpildīt vairākas reizes. Jebkurā gadījumā šo metodi ir ļoti viegli īstenot. Neviena no šīm pieejām nav īpaši pievilcīga, un ideāls variants, kas garantētu tieši vienu RPC izpildi, kopumā nav īstenojams principiālu apsvērumu dēļ.

Lai, piemēram, attālināta darbība ir teksta drukāšana, kas ietver printera bufera ielādi un viena bita iestatīšanu kādā printera vadības reģistrā, kā rezultātā printeris sāk darboties. Servera avārija var notikt vai nu mikrosekundi pirms, vai mikrosekundi pēc vadības bita iestatīšanas. Kļūmes brīdis pilnībā nosaka atgūšanas procedūru, bet klients nevar uzzināt par atteices brīdi.

Īsāk sakot, servera avārijas iespēja radikāli maina RPC būtību un skaidri atspoguļo atšķirību starp centralizētu un sadalītu sistēmu. Pirmajā gadījumā servera avārija izraisa klienta avāriju, un atkopšana nav iespējama. Otrajā gadījumā ir gan iespējams, gan nepieciešams veikt sistēmas atkopšanas darbības. 1. Klients avarēja pēc pieprasījuma nosūtīšanas. Šajā gadījumā tiek veikti aprēķini par rezultātiem, kurus neviens negaida.Šādus aprēķinus sauc par bāreņu aprēķiniem. Bāreņu klātbūtne var izraisīt dažādas problēmas izšķērdēts CPU laiks, bloķējot resursus, aizstājot atbildi uz pašreizējo pieprasījumu ar atbildi uz pieprasījumu, ko klienta mašīna izsniedza pirms sistēmas restartēšanas.

Kā rīkoties ar bāreņiem? Apskatīsim 4 iespējamos risinājumus. Iznīcināšana. Pirms klienta stubs nosūta RPC ziņojumu, tas žurnālā ieraksta, ko tas darīs tālāk.Žurnāls tiek saglabāts diskā vai citā kļūdu izturīgā atmiņā.

Pēc negadījuma sistēma tiek pārstartēta, žurnāls tiek analizēts un bāreņi tiek likvidēti. Šīs pieejas trūkumi ietver, pirmkārt, palielinātās pieskaitāmās izmaksas, kas saistītas ar katra RPC ierakstīšanu diskā, un, otrkārt, iespējamu neefektivitāti, ko izraisa otrās paaudzes bāreņu parādīšanās, ko ģenerē pirmās paaudzes bāreņu RPC zvani. Reinkarnācija.Šajā gadījumā visas problēmas tiek atrisinātas, neizmantojot diska ierakstīšanu. Metode sastāv no laika sadalīšanas secīgi numurētos periodos. Kad klients atsāknējas, tas pārraida ziņojumu visām mašīnām, lai paziņotu par jauna perioda sākumu.

Pēc šī ziņojuma saņemšanas visi attālie aprēķini tiek izslēgti. Protams, ja tīkls ir segmentēts, tad daži bāreņi var izdzīvot. Mīkstā reinkarnācija ir līdzīga iepriekšējam gadījumam, izņemot to, ka netiek atrasti un iznīcināti visi dzēstie aprēķini, bet tikai pārstartējošā klienta aprēķini. Derīguma termiņš. Katram pieprasījumam ir noteikts standarta laika periods T, kurā tas ir jāpabeidz.

Ja pieprasījums netiek izpildīts noteiktajā laikā, tiek piešķirts papildu kvants. Lai gan tas prasa papildu darbu, ja pēc klienta avārijas serveris gaida intervālu T pirms klienta pārstartēšanas, tad visi bāreņi noteikti tiek iznīcināti. Praksē neviena no šīm pieejām nav vēlama, patiesībā bāreņu iznīcināšana var pasliktināt situāciju . Piemēram, pieņemsim, ka bārenis ir bloķējis vienu vai vairākus datu bāzes failus.

Ja bārenis tiek pēkšņi iznīcināts, tad šīs slēdzenes paliks, turklāt iznīcinātie bāreņi var palikt stāvēt dažādās sistēmas rindās, nākotnē var izraisīt jaunu procesu izpildi utt.

Ko darīsim ar saņemto materiālu:

Ja šis materiāls jums bija noderīgs, varat to saglabāt savā lapā sociālajos tīklos:

Daudzi datorsistēmu lietotāji ir dzirdējuši par tādiem jēdzieniem kā attālās procedūras, attālo procedūru izsaukumi vai RPC. Bet ne visi saprot, kas ir šīs tehnoloģijas, kā tās darbojas un kam tās ir vajadzīgas. Taču daudzi no tiem, kuri ir atspējojuši šo pakalpojumu Windows sistēmās, bieži var saņemt kļūdas, kas saistītas ar kritiskām kļūmēm. Tas un daudz kas cits tiks apspriests tālāk.

Attālās procedūras zvans: kas tas ir?

Ir vērts sākt ar kādu teorētisku informāciju. Tiek uzskatīts, ka attālās procedūras (attālās procedūru izsaukumi) ir mehānisms, kas ļauj palaist vai izmantot jebkuras datorsistēmu funkcijas adrešu telpā, kas nav termināļa izmantotā adrese. Vienkārši sakot, tas ir veids, kā piekļūt attālam datoram, piemēram, izmantojot lokālo tīklu vai interneta savienojumu.

Tomēr attālās procedūras (attālināto procedūru izsaukumi), ko dēvē par RPC (saīsinājums no angļu valodas Remote Procedure Call), var attiecināt ne tikai uz attālie datori. Arī vietējā līmenī šādas tehnoloģijas tiek izmantotas. Vienkāršākais piemērs ir vienas programmas noteiktas funkcijas izsaukšana no citas lietojumprogrammas, mijiedarbojoties ar īpašām bibliotēkām.

Turklāt pilnīgi visā Windows versijas ir šāds serviss, un, ja tas ir atspējots vai neizdodas, XP modifikācija nedarbojas vispār.

Darbības princips

Kā likums, Remote Procedure Call RPC pakalpojumam ir nepieciešami vismaz divi galvenie komponenti, lai darbotos klienta-servera režīmā: tīkla protokols datu apmaiņai un serializācijas valoda (procesa vai informācijas datu struktūras pārveidošana bitu secībā).

Arhitektūras var būt pilnīgi atšķirīgas un atšķirties pēc savām iespējām. Bet datu apmaiņai tā sauktajā transporta līmenī visbiežāk tiek izmantoti UDP un TCP protokoli, retāk HTTP.

Lai neiedziļinātos tehniskajos aspektos, vienkāršākais šādu tehnoloģiju darbības principa skaidrojums var būt šāds piemērs: klienta process ģenerē serverim pieprasījumu, kurā aprakstīta izvēlētā procedūra ar norādītajiem parametriem, un nosūta to, pēc kura serveris izpilda nepieciešamo direktīvu un nosūta klientam atbildi, kas tiek parādīta klienta automašīnā. Taču pats servera apstrādātājs, tā teikt, ir gaidīšanas režīmā un tiek aktivizēts tikai tad, kad tiek saņemti klienta pieprasījumi. Tajā pašā laikā nepavisam nav nepieciešams, lai pieprasījuma-atbildes shēma tiktu izpildīta nekavējoties.

Šajā gadījumā maksimālais veiktspējas efekts tiek sasniegts, apmainoties ar salīdzinoši nelielu datu apjomu un īsu komponentu reakcijas laiku, starp kuriem tiek izveidota interaktīva komunikācija.

Attālās procedūras (attālināto procedūru izsaukumi): raksturojums un realizācijas

Tādējādi var izdalīt divas galvenās šo tehnoloģiju iezīmes:

• asimetrija (attālinātas procedūras uzsākšana, ko veic tikai viena no pusēm);
• sinhronitāte (zvanīšanas procedūras apturēšana no pieprasījuma uzsākšanas brīža un atsākšana pēc atbildes nosūtīšanas).

Runājot par ieviešanu, attālās procedūras (attālināto procedūru izsaukumi) mūsdienās izmanto vairākas pamata tehnoloģijas, no kurām visplašāk tiek izmantotas šādas:

• DCE/RPC - binārais protokols, kura pamatā ir TCP/IP, SMB/SIFC utt.;
• DCOM ir uz objektu orientēts papildinājums ar iespēju pārsūtīt atsauces uz objektiem un izsaukt metodes to apstrādei;
• JSON-RPC ir teksta protokols, kura pamatā ir HTTP;
• .NET Remoting ir binārs protokols, kura pamatā ir UDP, TCP un HTTP;
• JAVA RMI;
• ZIEPES;
• XML RPC;
• SUN RPC;
• ZeroC ICE;
• Routix.RPC utt.

Problēmas un izaicinājumi

Tagad daži vārdi par trūkumiem. Vissvarīgākā problēma un līdz ar to arī ieviešanas izaicinājums ir tāda, ka viena un tā pati attālās procedūras izsaukšanas darbība, izmantojot Remote Procedure Call pakalpojuma mezglu, ir jāizpilda vienlaikus dažādās iekārtās, bieži vien ar dažādām operētājsistēmām, adrešu telpām un arhitektūrām. Procesa laikā parametru dati ir jāpārkopē no viena termināļa uz otru. Šim nolūkam tiek izmantots ne tikai transporta protokols, bet arī serializācija, kas ļauj pārveidot dažāda veida datus baitu secībā.

Otrs punkts ir saistīts ar faktu, ka attālās procedūras (attālinātie procedūru izsaukumi) izmanto nevis vienu procesu, kā tas notiek vietējā līmenī, bet divus (klienta mašīnā un serverī). Tāpēc programmas ārkārtas izbeigšana vienā no termināliem var izraisīt tādu pašu reakciju otrā.

Visbeidzot, viena no galvenajām ir saderības problēma dažu programmēšanas valodu neviendabīguma dēļ, neskatoties uz noteiktajiem vienotajiem standartiem.

Galvenie apakšsistēmu veidi

Attālās procedūras izsaukšana operētājsistēmā Windows 10 vai jebkurā citā zemāka līmeņa sistēmā ietver īpašu apakšsistēmu izmantošanu:

• transporta apakšsistēma, kas izstrādāta, lai pārvaldītu izejošos un ienākošos savienojumus ar garantētu datu pakešu piegādi;
• pūla protokoli - procedūras izpildes jēdziens izsauktajā terminālī;
• serializācija (marshaling) - datu straumju konvertēšana standarta baitu kodos, neatkarīgi no arhitektūras;
• nosūtīto un saņemto pakešu šifrēšana ar tām uzliktu ciparparakstu;
• autentifikācijas un autorizācijas sistēma.

Kāda veida programmām ir nepieciešams RPC?

Ja mēs runājam par to, kuri operētājsistēmas programmatūras moduļi prasa, lai RPC pakalpojums būtu iespējots, tos visus vienkārši nav iespējams uzskaitīt.

Bet starp labi zināmajiem Windows sistēmu komponentiem var atzīmēt faksa pakalpojumu, kriptogrāfijas pakalpojumus, kļūdu reģistrēšanu, palīdzību un atbalstu, piekļuvi HID ierīcēm, ziņojumapmaiņas pakalpojumu (Messenger), disku un loģisko nodalījumu administrēšanu, noņemamo disku pārvaldību. , audio sistēma, Windows instalēšanas programma un citas Dievs zina, kas.

Manuprāt, šis saraksts ir pietiekams, lai saprastu, cik sistēmas komponentu un pats lietotājs ir atkarīgi no šī pakalpojuma.

Ko ietekmē RPC?

Kopumā, pamatojoties uz iepriekšējo aprakstu, var novērtēt RPC ietekmi. Piemēram, ir daudz gadījumu, kad, izslēdzot šo pakalpojumu, skaņa pilnībā pazuda, sistēmas atkopšana pēc kritiskām kļūmēm nebija iespējama vai tika zaudēta lietotāja iniciēta bezvadu tīkla iestatījumu atkopšana.

Bet skumjākais ir tas, ka, atspējojot RPC, dažreiz nav iespējams pat piekļūt pamata sistēmas iestatījumiem, pat ja lietotājs vismaz trīs reizes ir administrators savā terminālī.

Vai ir iespējams atslēgt šo pakalpojumu

Kopumā daudzi ir mēģinājuši (un mēģina) atspējot attālās procedūras zvanu pakalpojumu. To darīt ir stingri aizliegts. Parasti pati sistēma neļaus tam notikt, kad tiek veikts šāds mēģinājums, izsniedzot attiecīgu paziņojumu.

Bet ne visi zina, ka pakalpojumu sadaļā (services.msc) ir arī tāda lieta kā “RPC Remote Procedure Call Locator”. Tas ir tieši tas, ko sistēmai var nesāpīgi atspējot. Lietojumprogrammas, kas to var izmantot savā darbā, nepieciešamības gadījumā patstāvīgi izsauks pakalpojumu.

Avāriju un kļūdu problēmu novēršana

Visbeidzot, apskatīsim, ko varat darīt, ja attālās procedūras izsaukums rada kļūdu. Vienkāršākajā gadījumā varat mēģināt vēlreiz iespējot pakalpojumu (ja, protams, tas darbojas).

Lai to izdarītu, attiecīgajā sadaļā, kurā atrodas meklētais pakalpojums, veiciet dubultklikšķi uz parametru rediģēšanas izvēlnes, nospiediet pogu Iespējot un iestatiet iespējošanas veidu uz automātisku. Ja standarta sistēmas sāknēšanas laikā šādu procedūru nav iespējams veikt, varat mēģināt veikt līdzīgas darbības drošais režīms. Daži eksperti arī iesaka atspējot pretvīrusu programmatūru, veicot darbības, katram gadījumam.

Ja tas nepalīdz, bet jums ir pieejams sistēmas instalācijas vai atkopšanas disks, varat palaist komandu konsoli ar administratora tiesībām (nav nepieciešams sāknēt no diska) un ievadīt tajā šādas komandas:

• cd z:\i386 (Z ir optiskā diskdziņa burts) ;
• paplašināt explorer.ex_ %TEMP%\explorer.exe;
• izvērsiet svchost.ex_ %TEMP%\svchost.exe.

Pēc tam palaidiet "Uzdevumu pārvaldnieku" (Ctrl + Del + Alt vai tasmgr izvēlnē "Run") un pabeidziet Explorer.exe procesu.

Programmā “Dispečers” mēs apturam visus svhost.exe procesus, pēc kuriem 60 sekunžu laikā komandrindā jāievada rindas kopija %TEMP%\svchost.exe %systemroot%\system32 /y.

Visbeidzot, ja jums ir piekļuve redaktoram sistēmas reģistrs(regedit) ir atjaunots, jums ir jāseko HKCC filiālei caur sadaļām SYSTEM un CurrentControlSet un jānokļūst CSConfigFlags parametrā, mainot tā vērtību uz nulli.

Šīs nav visas ar RPC saistīto kļūdu labošanas metodes. Lieta ir tāda, ka, ja šis pakalpojums rada traucējumus citu pakalpojumu darbībā, var būt nepieciešams vispirms novērst to darbības problēmas un tikai pēc tam veikt darbības saistībā ar RPC. Un ne vienmēr ir iespējams iegūt pilnīgu piekļuvi iepriekš aprakstītajiem parametriem un iestatījumiem. Ja nekas neizdodas, lai cik nožēlojami tas izklausītos, jums būs pilnībā jāpārinstalē operētājsistēma, lai gan gribētos cerēt, ka līdz tam nenonāks.

Secinājums

Šeit ir īss kopsavilkums par visu, kas saistīts ar RPC tehnoloģiju un pakalpojumu. Patiesībā tas viss izskatās daudz sarežģītāk, nekā tika parādīts šis apraksts, un, lai pilnībā izprastu problēmu, jums ir jābūt vismaz pamatzināšanām. Bet, lai būtu vispārēja izpratne par RPC, pagaidām ar to pietiek.

Kas attiecas uz izslēgšanu, nemēģiniet veikt šādas darbības, pretējā gadījumā visa sistēma neizdosies. Dotie risinājumi kļūmju novēršanai parasti palīdz, taču pilnu garantiju tomēr nevar dot, jo pakalpojuma deaktivizēšana var izraisīt kļūmes citos komponentos.

Ideja izsaukt attālās procedūras (Attālās procedūras izsaukums — RPC) sastāv no labi zināmā un saprotamā mehānisma paplašināšanas vadības un datu pārsūtīšanai programmā, kas darbojas vienā mašīnā, līdz vadības un datu pārsūtīšanai tīklā. Attālās procedūru izsaukšanas rīki ir paredzēti, lai atvieglotu izkliedētās skaitļošanas organizēšanu.

Vislielākā RPC izmantošanas efektivitāte tiek sasniegta tajās lietojumprogrammās, kurās tas ir interaktīva saziņa starp attāliem komponentiem Ar īss reakcijas laiks Un salīdzinoši neliels pārsūtīto datu apjoms.Šādas lietojumprogrammas sauc par RPC orientētām.

Vietējo procedūru izsaukšanas raksturīgās iezīmes ir:

asimetrija, tas ir, viena no mijiedarbības pusēm ir iniciators;

sinhronitāte, tas ir, izsaukšanas procedūras izpilde tiek apturēta no pieprasījuma nosūtīšanas brīža un tiek atsākta tikai tad, kad izsauktā procedūra atgriežas.

Attālināto zvanu ieviešana ir daudz sarežģītāka nekā vietējo procedūru zvanu ieviešana.

1. Sāksim ar to, ka tā kā izsaukšanas un izsaukuma procedūras tiek izpildītas dažādās mašīnās, tās ir dažādas adrešu telpas, un tas rada problēmas, pārsūtot parametrus un rezultātus, īpaši, ja iekārtas nav identiskas.

Tā kā RPC nevar paļauties uz koplietojamo atmiņu, tas nozīmē, ka RPC parametri nedrīkst saturēt norādes uz vietām, kas nav steka atmiņas Nu ko parametru vērtības ir jākopē no viena datora uz citu.

2. Nākamā atšķirība starp RPC un vietējo zvanu ir tā obligāti izmanto pamatā esošo sakaru sistēmu, tomēr šis nedrīkst būt skaidri redzamiem ne procedūru definīcijā, ne pašās procedūrās .

Attālums rada papildu problēmas. Izsaucošās programmas un izsauktās vietējās procedūras izpilde tajā pašā mašīnā ietvarosviens process. Bet iesaistīts RPC īstenošanāvismaz divi procesi - pa vienam katrā automašīnā. Ja kāds no tiem neizdodas, var rasties šādas situācijas:

Ja izsaukšanas procedūra avarē, attālināti izsauktās procedūras kļūs par "bāreņiem" un

Ja attālinātās procedūras beidzas neparasti, zvanīšanas procedūras kļūs par "trūcīgiem vecākiem" un bez rezultātiem gaidīs atbildi no attālinātajām procedūrām.

Turklāt ir vairākas problēmas, kas saistītas ar programmēšanas valodu un darbības vides neviendabīgumu : datu struktūras un procedūru izsaukuma struktūras, kas tiek atbalstītas vienā programmēšanas valodā, netiek atbalstītas tādā pašā veidā visās citās valodās.

Šīs un dažas citas problēmas atrisina plaši izplatītā RPC tehnoloģija, kas ir daudzu izplatītu operētājsistēmu pamatā.

RPC ideja ir panākt, lai attālās procedūras izsaukums izskatītos pēc iespējas līdzīgāks vietējai procedūras izsaukumam. Citiem vārdiem sakot, padariet RPC caurspīdīgu: izsaukšanas procedūrai nav jāzina, ka izsauktā procedūra ir citā datorā, un otrādi.

RPC panāk caurspīdīgumu šādā veidā. Ja izsauktā procedūra faktiski ir attāla, vietējās procedūras vietā bibliotēkā tiek ievietota cita procedūras versija, ko sauc par klienta stub. Tāpat kā sākotnējā procedūra, stubs tiek izsaukts, izmantojot izsaukšanas secību (kā parādīts 3.1. attēlā), un, piekļūstot kodolam, notiek pārtraukums. Tikai atšķirībā no sākotnējās procedūras tā neievieto parametrus reģistros un nepieprasa datus no kodola; tā vietā tā ģenerē ziņojumu, kas jānosūta uz attālās mašīnas kodolu..

Rīsi. 3.2. Attālās procedūras izsaukums

4. lekcija

4.1. Attālās procedūras izsaukuma koncepcija

Ideja izsaukt attālās procedūras (Attālās procedūras izsaukums — RPC) sastāv no labi zināmā un saprotamā mehānisma paplašināšanas vadības un datu pārsūtīšanai programmā, kas darbojas vienā mašīnā, līdz vadības un datu pārsūtīšanai tīklā. Attālās procedūru izsaukšanas rīki ir paredzēti, lai atvieglotu izkliedētās skaitļošanas organizēšanu. Vislielākā RPC izmantošanas efektivitāte tiek sasniegta tajās lietojumprogrammās, kurās notiek interaktīva komunikācija starp attāliem komponentiem ar ātru reakcijas laiku un salīdzinoši nelielu pārsūtīto datu apjomu. Šādas lietojumprogrammas sauc par RPC orientētām.

Vietējo procedūru izsaukšanas raksturīgās iezīmes ir: asimetrija, tas ir, viena no mijiedarbības pusēm ir iniciators; sinhronitāte, tas ir, izsaukšanas procedūras izpilde apstājas no pieprasījuma izdošanas brīža un tiek atsākta tikai pēc izsauktās procedūras atgriešanās.

Attālināto zvanu ieviešana ir daudz sarežģītāka nekā vietējo procedūru zvanu ieviešana. Pirmkārt, tā kā izsaukšanas un izsaukšanas procedūras tiek izpildītas dažādās iekārtās, tām ir dažādas adrešu telpas, un tas rada problēmas, nododot parametrus un rezultātus, īpaši, ja mašīnas nav identiskas. Tā kā RPC nevar paļauties uz koplietojamo atmiņu, tas nozīmē, ka RPC parametros nedrīkst būt norādes uz atmiņas vietām, kas nav steka, un ka parametru vērtības ir jākopē no viena datora uz citu. Nākamā atšķirība starp RPC un vietējo zvanu ir tāda, ka tajā obligāti tiek izmantota pamatā esošā sakaru sistēma, taču tam nevajadzētu būt skaidri redzamam ne procedūru definīcijā, ne pašās procedūrās. Attālums rada papildu problēmas. Izsaucošās programmas un izsauktās lokālās procedūras izpilde tajā pašā mašīnā tiek īstenota vienā procesā. Bet RPC ieviešana ietver vismaz divus procesus - pa vienam katrā mašīnā. Ja kāds no tiem avarē, var rasties šādas situācijas: ja izsaukšanas procedūra avarē, attālināti izsauktās procedūras kļūs par “bāreņiem”, savukārt, ja tālvadības procedūras avarē, izsaukšanas procedūras kļūs par “bāreņu vecākiem”, velti gaidot atbilde no attālinātajām procedūrām.

Turklāt ir vairākas problēmas, kas saistītas ar programmēšanas valodu un darbības vides neviendabīgumu: datu struktūras un procedūru izsaukuma struktūras, kas tiek atbalstītas vienā programmēšanas valodā, netiek atbalstītas vienādi visās citās valodās.

Šīs un dažas citas problēmas atrisina plaši izplatītā RPC tehnoloģija, kas ir daudzu izplatītu operētājsistēmu pamatā.

RPC pamatdarbības

Lai saprastu, kā darbojas RPC, vispirms apsveriet iespēju veikt vietējās procedūras izsaukumu tipiskā datorā, kas darbojas bezsaistē. Lai tas būtu, piemēram, sistēmas izsaukums

count=lasīt(fd,buf,nbaiti);

kur fd ir vesels skaitlis;

buf – rakstzīmju masīvs;

nbaiti ir vesels skaitlis.

Lai veiktu zvanu, izsaukšanas procedūra nospiež parametrus uz steku apgrieztā secībā. Pēc lasīšanas zvana izpildes tas ievieto atgriešanas vērtību reģistrā, pārvieto atgriešanas adresi un atgriež vadību izsaukšanas procedūrā, kas izspiež parametrus no steka, atgriežot to sākotnējā stāvoklī. Ņemiet vērā, ka C valodā parametrus var izsaukt pēc atsauces (pēc nosaukuma) vai pēc vērtības (pēc vērtības). Saistībā ar izsaukto procedūru vērtību parametri ir inicializēti vietējie mainīgie. Izsauktā procedūra var tos mainīt, neietekmējot šo mainīgo sākotnējās vērtības izsaukšanas procedūrā.

Ja rādītājs uz mainīgo tiek nodots izsauktajai procedūrai, mainot šī mainīgā vērtību, izmantojot izsaukto procedūru, ir jāmaina šī mainīgā vērtība izsaucējai procedūrai. Šis fakts ir ļoti nozīmīgs RPC.

Ir arī cits parametru nodošanas mehānisms, kas netiek izmantots C. To sauc par kopēšanu/atjaunošanu, kas prasa zvanītājam kopēt mainīgos stekā kā vērtības un pēc tam tos kopēt atpakaļ pēc zvana pabeigšanas. izsaukšanas procedūras sākotnējās vērtības.

Lēmumu par to, kuru parametru nodošanas mehānismu izmantot, pieņem valodas izstrādātāji. Dažreiz tas ir atkarīgs no pārsūtāmo datu veida. Piemēram, programmā C veseli skaitļi un citi skalārie dati vienmēr tiek nodoti pēc vērtības, un masīvi vienmēr tiek nodoti pēc atsauces.

RPC ideja ir panākt, lai attālās procedūras izsaukums izskatītos pēc iespējas līdzīgāks vietējai procedūras izsaukumam. Citiem vārdiem sakot, padariet RPC caurspīdīgu: izsaukšanas procedūrai nav jāzina, ka izsauktā procedūra ir citā datorā, un otrādi.

RPC panāk caurspīdīgumu šādā veidā. Ja izsauktā procedūra faktiski ir attāla, vietējās procedūras vietā bibliotēkā tiek ievietota cita procedūras versija, ko sauc par klienta stub. Tāpat kā sākotnējā procedūra, stub tiek izsaukta, izmantojot izsaukšanas secību, un, piekļūstot kodolam, notiek pārtraukums. Tikai atšķirībā no sākotnējās procedūras tā neievieto parametrus reģistros un nepieprasa datus no kodola; tā vietā tā ģenerē ziņojumu, kas jānosūta attālās mašīnas kodolam.

RPC izpildes posmi

Programmatūras komponentu mijiedarbība, veicot attālo procedūru izsaukumu, ir parādīta 2. attēlā.

2. attēls. Attālās procedūras izsaukums

Pēc tam, kad klienta programma ir izsaukusi klienta apakšnodaļu, tās pirmais uzdevums ir aizpildīt buferi ar sūtāmo ziņojumu. Dažās sistēmās klienta apakšdaļā ir viens fiksēta garuma buferis, kas tiek aizpildīts no paša sākuma ar katru jaunu pieprasījumu. Citās sistēmās ziņojumu buferis ir atsevišķu ziņojumu lauku buferu kopums, no kuriem daži jau ir pilni. Šī metode ir īpaši piemērota gadījumiem, kad paketei ir formāts, kas sastāv no liela skaita lauku, bet daudzu šo lauku vērtības nemainās no zvana uz zvanu.

Pēc tam parametri ir jāpārveido atbilstošā formātā un jāievieto ziņojumu buferī. Šajā brīdī ziņojums ir gatavs nosūtīšanai, tāpēc tiek izpildīts kodola izsaukuma pārtraukums.

Kad kodols iegūst kontroli, tas pārslēdz kontekstus, saglabā procesora reģistrus un atmiņas karti (lapu rokturi) un instalē jaunu atmiņas karti, kas tiks izmantota, lai palaistu kodola režīmā. Tā kā kodola un lietotāja konteksti ir atšķirīgi, kodolam ziņojums ir precīzi jāiekopē savā adrešu telpā, lai tas varētu tai piekļūt, atcerēties galamērķa adresi (un, iespējams, citus galvenes laukus) un tas jānosūta tīkla saskarnei. Tas pabeidz darbu klienta pusē. Pārraides taimeris ir ieslēgts, un kodols var vai nu cikliski aptaujāt atbildi, vai nodot vadību plānotājam, kas atlasīs kādu citu palaišanas procesu. Pirmajā gadījumā vaicājuma izpilde tiek paātrināta, bet nav daudzprogrammēšanas.

Servera pusē ienākošos bitus izvieto saņemošā aparatūra vai nu mikroshēmas buferī, vai RAM. Kad visa informācija ir saņemta, tiek ģenerēts pārtraukums. Pārtraukumu apstrādātājs pārbauda pakešu datu pareizību un nosaka, uz kuru stublu tie jānosūta. Ja neviens no stubiem negaida šo paketi, apstrādātājam tā ir jābuferē vai jāizmet pavisam. Ja ir gaidīšanas stubs, ziņojums tiek kopēts uz to. Visbeidzot tiek veikta konteksta pārslēgšana, kā rezultātā tiek atjaunoti reģistri un atmiņas karte, ņemot vērā vērtības, kas tiem bija brīdī, kad stubs veica saņemšanas zvanu.

Tagad servera stubs sāk darboties. Tas izpako parametrus un atbilstoši nospiež tos uz kaudzes. Kad viss ir gatavs, tiek veikts zvans uz serveri. Pēc procedūras izpildes serveris nosūta rezultātus klientam. Lai to izdarītu, veiciet visas iepriekš aprakstītās darbības, tikai apgrieztā secībā.

3. attēlā parādīta komandu secība, kas jāizpilda katram RPC izsaukumam.

3. attēls. RPC procedūras soļi