Attālās procedūras izsaukums (RPC) ir spēcīgs konstruēšanas paņēmiens izplatītas, uz klientu serveriem balstītas lietojumprogrammas . Tas ir balstīts uz parastās vietējās procedūras izsaukšanas paplašināšanu, lai izsauktajai procedūrai nav jābūt tajā pašā adrešu telpā, kur izsaucējai procedūrai . Abi procesi var būt vienā sistēmā vai arī dažādās sistēmās ar tīklu, kas tos savieno.

Veicot attālās procedūras zvanu:

1. Zvanīšanas vide tiek apturēta, procedūras parametri tiek pārsūtīti pa tīklu uz vidi, kurā procedūra ir jāizpilda, un procedūra tiek izpildīta tur.

java pseidokods

2. Kad procedūra beidzas un rada rezultātus, tās rezultāti tiek pārsūtīti atpakaļ uz izsaukšanas vidi, kur izpilde tiek atsākta, it kā atgriežoties no parastās procedūras izsaukuma.

PIEZĪME: RPC ir īpaši labi piemērots klientam-serverim (piem., vaicājums-atbilde) mijiedarbība, kurā plūsma kontrole pārmaiņus starp zvanītāju un izsaucamo . Konceptuāli klients un serveris neizpilda vienlaikus. Tā vietā izpildes pavediens pāriet no zvanītāja uz izsaucamo un pēc tam atkal atpakaļ.

RPC darbība

kas ir 10 no 60

RPC laikā tiek veiktas šādas darbības:

1. Klients izsauc a klienta stub procedūra , nododot parametrus parastajā veidā. Klienta stubs atrodas paša klienta adrešu telpā.
2. Klienta stubs maršali (paka) parametrus ziņojumā. Sakārtošana ietver parametru attēlojuma pārveidošanu standarta formātā un katra parametra kopēšanu ziņojumā.
3. Klienta apakšgrupa nosūta ziņojumu transporta slānim, kas to nosūta attālā servera mašīnai.
4. Serverī transporta slānis nosūta ziņojumu servera apakšdaļai, kas demaršals (izpakot) parametrus un izsauc vēlamo servera rutīnu, izmantojot parasto procedūru izsaukšanas mehānismu.
5. Kad servera procedūra ir pabeigta, tas atgriežas servera apakšdaļā (piemēram, izmantojot parasto procedūru, zvanot atpakaļ) , kas atgriežamās vērtības sadala ziņojumā. Pēc tam servera apakšdaļa nodod ziņojumu transporta slānim.
6. Transporta slānis nosūta rezultāta ziņojumu atpakaļ uz klienta transporta slāni, kas nodod ziņojumu atpakaļ klienta apakšgrupai.
7. Klienta stubs demarshall atgriešanas parametrus, un izpilde atgriežas zvanītājam.

Galvenie apsvērumi RPC sistēmu projektēšanā un ieviešanā ir:

Drošība: tā kā RPC ietver saziņu tīklā, drošība ir galvenā problēma. Lai novērstu nesankcionētu piekļuvi un aizsargātu sensitīvos datus, ir jāievieš tādi pasākumi kā autentifikācija, šifrēšana un autorizācija. Mērogojamība: pieaugot klientu un serveru skaitam, RPC sistēmas veiktspēja nedrīkst pasliktināties. Slodzes līdzsvarošanas metodes un efektīva resursu izmantošana ir svarīga mērogojamībai. Kļūdu tolerance: RPC sistēmai jābūt izturīgai pret tīkla kļūmēm, servera avārijām un citiem negaidītiem notikumiem. Tādi pasākumi kā atlaišana, kļūmjpārlēce un gracioza degradācija var palīdzēt nodrošināt kļūdu toleranci. Standartizācija: ir pieejami vairāki RPC ietvari un protokoli, un ir svarīgi izvēlēties standartizētu un plaši pieņemtu, lai nodrošinātu savietojamību un savietojamību dažādās platformās un programmēšanas valodās. Veiktspējas regulēšana: ir svarīgi precīzi noregulēt RPC sistēmu optimālai veiktspējai. Tas var ietvert tīkla protokola optimizāciju, tīklā pārsūtīto datu samazināšanu un latentuma un pieskaitāmās izmaksas, kas saistītas ar RPC zvaniem.

RPC PROBLĒMAS :
Problēmas, kas jārisina:

1. RPC izpildlaiks:
RPC izpildlaika sistēma ir rutīnu bibliotēka un pakalpojumu kopums, kas apstrādā tīkla sakarus, kas ir RPC mehānisma pamatā. RPC zvana laikā klienta un servera puses izpildlaika sistēmu koda apstrādā saistīt, izveidot sakarus, izmantojot atbilstošu protokolu, nodot zvanu datus starp klientu un serveri un apstrādāt sakaru kļūdas.

2. Stub:
Stubs funkcija ir nodrošināt programmētāja rakstītā lietojumprogrammas koda caurspīdīgumu .

Klienta pusē stubs apstrādā saskarni starp klienta lokālo procedūru izsaukumu un izpildlaika sistēmu, kārto un atdala datus, izsauc RPC izpildlaika protokolu un, ja tiek pieprasīts, veic dažas saistošās darbības. Servera pusē stub nodrošina līdzīgu saskarni starp izpildlaika sistēmu un vietējā pārvaldnieka procedūrām, kuras izpilda serveris.

3. Saistīšana: kā klients zina, kam zvanīt un kur atrodas pakalpojums?
Elastīgākais risinājums ir izmantot dinamisko saistīšanu un atrast serveri izpildes laikā, kad pirmo reizi tiek izveidots RPC. Pirmo reizi izsaucot klienta apakšnodaļu, tas sazinās ar nosaukumu serveri, lai noteiktu transporta adresi, kurā atrodas serveris.

Iesiešana sastāv no divām daļām:

iskcon pilna forma

• Mēs:
• Atrašanās vieta:

Serveris, kuram ir piedāvāts pakalpojums, eksportē tam saskarni. Eksportējot saskarni, tā tiek reģistrēta sistēmā, lai klienti to varētu izmantot. Klientam ir jāimportē (eksportētais) interfeiss, lai varētu sākt saziņu.

4. Ar RPC saistītā izsaukuma semantika:
To galvenokārt iedala šādās izvēlēs:

Mēģināt vēlreiz pieprasījuma ziņojums —
Vai atkārtoti mēģināt nosūtīt pieprasījuma ziņojumu, ja serveris ir atteicies vai saņēmējs nav saņēmis ziņojumu. Dublēta filtrēšana —
Noņemiet servera pieprasījumu dublikātus. Rezultātu retranslācija –
Lai atkārtoti nosūtītu pazaudētos ziņojumus, atkārtoti neizpildot darbības servera pusē.

PRIEKŠROCĪBAS:

1. RPC nodrošina ABSTRAKCIJA i., tīkla komunikācijas ziņojumu nodošanas raksturs ir paslēpts no lietotāja.
2. RPC bieži izlaiž daudzus protokola slāņus, lai uzlabotu veiktspēju. Pat neliels veiktspējas uzlabojums ir svarīgs, jo programma bieži var izsaukt RPC.
3. RPC ļauj izmantot lietojumprogrammas izplatītajā vidē, ne tikai vietējā vidē.
4. Izmantojot RPC kodu, tiek samazinātas pārrakstīšanas/atkārtotas izstrādes pūles.
5. Uz procesu orientēti un uz pavedieniem orientēti modeļi, kurus atbalsta RPC.

Atsauces:

• https://web.cs.wpi.edu/~cs4514/b98/week8-rpc/week8-rpc.html
• https://users.cs.cf.ac.uk/Dave.Marshall/C/node33.html
• Datoru tīkli: FOROUZAN pieeja no augšas uz leju