Rpc protokoli. Masofaviy protseduralar: masofaviy protsedura qo'ng'iroqlari, ta'rifi va xususiyatlari

Tarmoq orqali muloqot qiladigan dasturlar aloqa mexanizmiga muhtoj. Pastki darajada, paketlar kelgandan so'ng, signal tarmoq signalini qayta ishlash dasturi tomonidan qayta ishlanadi. Yuqori darajada ada tilida qabul qilingan uchrashuv mexanizmi (rendezvous) ishlaydi. NFS mijoz server bilan muloqot qiladigan masofaviy protsedura chaqiruvi (RPC) mexanizmidan foydalanadi (1-rasmga qarang). Ushbu jarayonga muvofiq, mijoz birinchi navbatda serverga so'rov yuboradigan protseduraga kirishadi. So'rov bilan paket kelgandan so'ng, server uni ochish tartibini chaqiradi, so'ralgan xizmatni bajaradi, javob yuboradi va nazorat mijozga qaytariladi.

RPC interfeysini uchta qatlamdan iborat deb hisoblash mumkin:

Yuqori qavat butunlay shaffof. Ushbu darajadagi dastur, masalan, masofaviy kompyuterdagi foydalanuvchilar sonini qaytaradigan rnusers () ni chaqirishi mumkin. RPC mexanizmidan foydalanish haqida bilishingiz shart emas, chunki siz dasturda qo'ng'iroq qilyapsiz.

O'rta daraja eng keng tarqalgan ilovalar uchundir. Ushbu darajadagi RPC qo'ng'iroqlari registerrpc () va callrpc () tartiblari tomonidan amalga oshiriladi: registerrpc () butun tizim bo'ylab qorong'u kodni oladi va callrpc () masofaviy protsedura chaqiruvini amalga oshiradi. rnusers () chaqiruvi ushbu ikki tartib yordamida amalga oshiriladi.

Pastki daraja murakkabroq vazifalar uchun ishlatiladi, standart sozlamalarni protsedura parametrlarining qiymatlariga o'zgartiradi. Ushbu darajada siz RPC xabarlarini uzatish uchun ishlatiladigan rozetkalarni aniq boshqarishingiz mumkin.

Umumiy qoida sifatida siz yuqori qatlamdan foydalanishingiz va pastki qatlamlarni keraksiz ishlatishdan qochishingiz kerak.

Ushbu qo'llanmada biz faqat C tilidagi interfeysni ko'rib chiqsak ham, masofaviy protseduralarga qo'ng'iroqlarni istalgan tildan amalga oshirish mumkin. Turli xil mashinalardagi jarayonlar o'rtasidagi aloqani tashkil qilish uchun RPC mexanizmining ishi uning bitta mashinadagi ishidan farq qilmaydi.

RPC (Remote Procedure Call) masofaviy foydalanuvchilar va ushbu foydalanuvchilar tomonidan so'ralganda ishga tushiriladigan maxsus xost dasturlari o'rtasidagi interfeysdir. Xost uchun RPC xizmati odatda mijozlarga dasturlar to'plamini taqdim etadi. Bu dasturlarning har biri, o'z navbatida, bir yoki bir nechta masofaviy protseduralardan iborat. Masalan, RPC qo'ng'iroqlariga tayanadigan NFS masofaviy fayl tizimi xizmati faqat ikkita dasturdan iborat bo'lishi mumkin: masalan, bitta dastur yuqori darajadagi foydalanuvchi interfeyslari bilan o'zaro ta'sir qiladi, ikkinchisi esa past darajadagi I/U funktsiyalari bilan o'zaro ta'sir qiladi.

Har bir RPC qo'ng'irog'i ikkita tomonni o'z ichiga oladi: serverga protsedura chaqiruvi so'rovini yuboradigan faol mijoz va mijozga javob yuboradigan server.

Eslatma. Shuni yodda tutingki, bu holda "mijoz" va "server" atamalari ma'lum bir tranzaksiyani anglatadi.Ma'lum bir xost yoki dasturiy ta'minot (jarayon yoki dastur) mijoz yoki server vazifasini bajarishi mumkin. Masalan, masofaviy protseduralar xizmatini taqdim etuvchi dastur bir vaqtning o'zida tarmoq fayl tizimi uchun mijoz bo'lishi mumkin.

RPC mahalliy protsedura chaqiruvlariga o'xshash masofaviy protsedura chaqiruvi modeliga qurilgan. Mahalliy protsedurani chaqirganingizda, siz argumentlarni ma'lum bir xotira joyiga, stekga yoki muhit o'zgaruvchilariga surasiz va jarayonni boshqarishni ma'lum bir manzilga o'tkazasiz. Ishni tugatgandan so'ng, siz ma'lum bir manzilda natijalarni o'qiysiz va jarayoningizni davom ettirasiz.

Masofaviy protsedura holatida asosiy farq shundaki, masofaviy funktsiya chaqiruviga ikkita jarayon xizmat qiladi: mijoz jarayoni va server jarayoni.

Mijoz jarayoni serverga chaqirilgan protsedura parametrlarini o'z ichiga olgan xabar yuboradi va uning ish natijalari bilan javob xabarini kutadi. Javob kelganda, natija o'qiladi va jarayon davom etadi. Server tomonida qo'ng'iroqlarni qayta ishlash jarayoni kutish holatida bo'ladi va xabar kelganda u protsedura parametrlarini o'qiydi, uni bajaradi, javob yuboradi va keyingi qo'ng'iroq uchun kutish holatiga o'tadi.

RPC protokoli jarayonlar o'rtasidagi qo'shimcha ulanishlarga hech qanday talablar qo'ymaydi va bajarilgan funktsiyalarni sinxronlashtirishni talab qilmaydi, ya'ni qo'ng'iroqlar asinxron va mustaqil bo'lishi mumkin, shuning uchun mijoz javob kutayotganda boshqa protseduralarni bajarishi mumkin. RPC serveri har bir funktsiya uchun alohida jarayon yoki virtual mashinani ajratishi mumkin, shuning uchun oldingi so'rovlarning bajarilishini kutmasdan, u darhol keyingisini qabul qilishi mumkin.

Biroq, mahalliy va masofaviy protsedura chaqiruvlari o'rtasida bir nechta muhim farqlar mavjud:

1. Qayta ishlashda xatolik. Mijoz har qanday holatda serverda yoki tarmoqda masofaviy protseduralarni chaqirishda yuzaga keladigan xatolar haqida xabardor qilinishi kerak.

2. Global o'zgaruvchilar. Server mijozning manzil maydoniga kirish imkoniga ega emasligi sababli, siz masofaviy protsedura chaqiruvlarida global o'zgaruvchilar ko'rinishidagi yashirin parametrlardan foydalana olmaysiz.

3. Ishlash. Masofaviy protseduralarni bajarish tezligi, qoida tariqasida, shunga o'xshash mahalliy protseduralarni bajarish tezligidan bir yoki ikki daraja pastroqdir.

4. Autentifikatsiya. Masofaviy protsedura chaqiruvlari tarmoq orqali amalga oshirilganligi sababli, mijozning autentifikatsiya mexanizmlaridan foydalanish kerak.

Protokolni tuzish tamoyillari.

RPC protokoli bir nechta turli transport protokollaridan foydalanishi mumkin. RPC protokolining yagona majburiyatlari standartlarni qo'llash va xabarlarni uzatishni talqin qilishdir. Xabarni uzatishning ishonchliligi va ishonchliligi transport qatlami tomonidan to'liq ta'minlanadi.

Biroq, RPC transport protokolining tanlovi va ba'zi funktsiyalarini boshqarishi mumkin. RPC va transport protokoli o'rtasidagi o'zaro ta'sirga misol sifatida, RPC orqali dastur jarayoniga RPC portini belgilash tartibini ko'rib chiqing - Portmapper.

Ushbu funktsiya dinamik ravishda (talab bo'yicha) RPC ulanishiga ma'lum bir portni tayinlaydi. Funktsiya Portmapper tez-tez ishlatiladi, chunki RPC uchun ajratilgan transport portlari to'plami cheklangan va bir vaqtning o'zida ishlashi mumkin bo'lgan jarayonlar soni juda yuqori. Portmapper, masalan, NFS mijoz/server aloqa portlari tanlanganda chaqiriladi.

Xizmat Portmapper RPC eshittirish xabar mexanizmini ma'lum bir portga ishlatadi - III. Ushbu portda mijoz ma'lum bir RPC xizmati portiga so'rov yuboradi. Xizmat Portmapper soliq xabarini qayta ishlaydi, mahalliy RPC xizmatining manzilini aniqlaydi va mijozga javob yuboradi. RPC xizmati Portmapper TCP va UDP protokollari bilan ishlashi mumkin.

RPC turli xil transport protokollari bilan ishlashi mumkin, lekin u hech qachon ularning funktsiyalarini takrorlamaydi, ya'ni agar RPC TCP ustida ishlasa, RPC ulanishining ishonchliligi va haqiqiyligi haqidagi barcha tashvishlar TCP-ga joylashtiriladi. Biroq, agar RPC UDP ning tepasida o'rnatilgan bo'lsa, u xabarlarni yetkazib berish kafolatlanganligini ta'minlash uchun qo'shimcha mahalliy funksiyalarni taqdim etishi mumkin.

Eslatma. Ilovalar RPC protokolini JSR (Jump Subroutine Instruction) tarmog'i orqali belgilangan funksiya chaqiruvi protsedurasi sifatida ko'rishi mumkin.

RPC protokoli ishlashi uchun quyidagi shartlar bajarilishi kerak:

1. Berilgan xostdagi barcha masofadan chaqiriladigan protseduralarning yagona identifikatsiyasi. RPC so'rovlari identifikatorlarning uchta maydonini o'z ichiga oladi - masofaviy dastur (xizmat) raqami, masofaviy dasturning versiya raqami va belgilangan dasturning masofaviy protsedura raqami. Dastur raqami xizmat ishlab chiqaruvchisi tomonidan belgilanadi, protsedura raqami ushbu xizmatning o'ziga xos funktsiyasini ko'rsatadi

2. RPC protokoli versiyasini aniqlash. RPC xabarlari RPC protokoli versiyasi maydonini o'z ichiga oladi. Mijoz RPC ning turli versiyalari bilan ishlaganda uzatiladigan parametrlar formatlarini moslashtirish uchun foydalaniladi.

3. Mijozni serverga autentifikatsiya qilish mexanizmlarini taqdim etish. RPC protokoli xizmatdagi mijozni autentifikatsiya qilish tartibini va agar kerak bo'lsa, har bir so'rov bilan yoki mijozga javob yuborishni ta'minlaydi. Bundan tashqari, RPC turli xil qo'shimcha xavfsizlik mexanizmlariga imkon beradi.

RPC to'rt turdagi autentifikatsiya mexanizmlaridan foydalanishi mumkin:

AUTH_NULL - autentifikatsiyadan foydalanilmagan

AUTH_UNIX - UNIX standart autentifikatsiyasi

AUTH_SHORT - o'zining kodlash tuzilmasi bilan UNIX autentifikatsiyasi

AUTH_DES - DES autentifikatsiyasi

4. Tegishli so'rovlarga javob xabarlarini aniqlash. RPC javob xabarlari ular tuzilgan so'rov identifikatorini o'z ichiga oladi. Ushbu identifikatorni RPC chaqiruvining tranzaksiya identifikatori deb atash mumkin. Ushbu mexanizm, ayniqsa, asinxron rejimda ishlaganda va bir nechta RPC qo'ng'iroqlari ketma-ketligini bajarishda foydalidir.

5. Protokol xatolarini aniqlash. Barcha tarmoq yoki server xatolarining noyob identifikatorlari mavjud bo'lib, ular yordamida ulanish ishtirokchilarining har biri nosozlik sababini aniqlashi mumkin.

Protokol xabarlari tuzilmalari

RPC xabarlarini transport protokoli orqali uzatishda bir nechta RPC xabarlari bitta transport paketida joylashgan bo'lishi mumkin. Bir xabarni boshqasidan farqlash uchun yozuv belgisi (RM - Record Marker) qo'llaniladi. Har bir RPC xabari aynan bitta RM bilan "belgilangan".

RPC xabari bir nechta bo'laklardan iborat bo'lishi mumkin. Har bir qism to'rt bayt sarlavha va (0 dan 2 gacha ** 31-1) ma'lumotlardan iborat. Sarlavhaning birinchi biti bo'lak oxirgi ekanligini, qolgan 31 bit esa ma'lumotlar paketining uzunligini ko'rsatadi.

RPC tuzilishi rasmiy ravishda ma'lumotlar formatlarini tavsiflash va taqdim etish tilida tasvirlangan - protseduralar tavsifiga oid qo'shimchalar bilan XDR. Hatto aytishingiz mumkinki, RPC belgilash tili protseduralar bilan ishlash bilan to'ldirilgan XDR kengaytmasi hisoblanadi.

RPC paketining tuzilishi quyidagicha ko'rinadi:

struct rpc_msg (

imzosiz int xid;

birlashma kaliti (msg_type mtype) (

call_body cbody;

javob tanasi rbody;

bu yerda xid joriy tranzaksiya identifikatori, call_body so'rov paketi, reply_body javob paketi. So'rov tuzilishi quyidagicha ko'rinadi:

strukturaviy chaqiruv tanasi (

imzolanmagan int rpcvers;

unsigned int prog;

unsigned int vers;

unsigned int proc;

opaque_auth krediti;

opaque_auth verf;

/ * protsedura parametrlari * /

reply_body tuzilmasi xatolik yuz berganda uzatiladigan tuzilmani (bu holda u xato kodini o'z ichiga oladi) yoki so'rovni muvaffaqiyatli qayta ishlash uchun tuzilmani (bu holda qaytarilgan ma'lumotlarni o'z ichiga oladi) o'z ichiga olishi mumkin.

Yuqori darajadagi dasturlash interfeysi.

Dasturda subprogrammalardan foydalanish vazifani tuzish, uni aniqroq qilishning an'anaviy usuli hisoblanadi. Eng ko'p qo'llaniladigan pastki dasturlar kutubxonalarda to'plangan bo'lib, ular turli dasturlar tomonidan ishlatilishi mumkin. Bunda gap mahalliy (lokal) qo'ng'iroq haqida ketmoqda, ya'ni qo'ng'iroq qiluvchi ham, chaqirilayotgan ob'ektlar ham bitta kompyuterda bir dastur doirasida ishlaydi.

Masofaviy qo'ng'iroq bo'lsa, bitta kompyuterda ishlaydigan jarayon masofaviy kompyuterda jarayonni boshlaydi (ya'ni, aslida masofaviy kompyuterda protsedura kodini ishga tushiradi). Shubhasiz, masofaviy protsedura chaqiruvi an'anaviy mahalliydan sezilarli darajada farq qiladi, ammo dasturchi nuqtai nazaridan, bunday farqlar deyarli yo'q, ya'ni masofaviy protsedura chaqiruvi arxitekturasi mahalliy qo'ng'iroqni simulyatsiya qilish imkonini beradi.

Biroq, agar mahalliy qo'ng'iroq bo'lsa, dastur parametrlarni chaqirilgan protseduraga o'tkazsa va ish natijasini stek yoki umumiy xotira maydonlari orqali qabul qilsa, masofaviy qo'ng'iroqda parametrlarning uzatilishiga aylanadi. tarmoq orqali so'rovni uzatish va ishning natijasi olingan javobda.

Ushbu yondashuv taqsimlangan ilovalarni yaratish uchun mumkin bo'lgan asos bo'lib, ko'plab zamonaviy tizimlar ushbu mexanizmdan foydalanmasa ham, asosiy tushunchalar va atamalar ko'p hollarda saqlanib qoladi. RPC mexanizmini tavsiflashda biz an'anaviy ravishda qo'ng'iroq qilish jarayonini mijoz sifatida va server sifatida protsedurani amalga oshiradigan masofaviy jarayonni nazarda tutamiz.

Masofaviy protsedura chaqiruvi quyidagi bosqichlarni o'z ichiga oladi:

1. Mijoz dasturi stub deb ataladigan protseduraga mahalliy qo'ng'iroqni amalga oshiradi. Bunday holda, mijoz stubga qo'ng'iroq qilib, aslida server protsedurasiga qo'ng'iroq qilganga o'xshaydi. Haqiqatan ham, mijoz kerakli parametrlarni stubga o'tkazadi va u natijani qaytaradi. Biroq, mijoz buni aniq tasavvur qilganidek emas. Stubning vazifasi masofaviy protsedura uchun argumentlarni qabul qilish, ehtimol ularni qandaydir standart formatga aylantirish va tarmoq so'rovini shakllantirishdir. Argumentlarni to'plash va tarmoq so'rovini yuborish marshalling deb ataladi.

2. Tarmoq so'rovi tarmoq orqali masofaviy tizimga yuboriladi. Buning uchun stub tegishli qo'ng'iroqlardan foydalanadi, masalan, oldingi bo'limlarda muhokama qilinganlar. E'tibor bering, bu holda nafaqat TCP / IP oilasi, balki turli xil transport protokollaridan ham foydalanish mumkin.

3. Masofaviy hostda hamma narsa teskari tartibda sodir bo'ladi. Server stub so'rovni kutadi va qabul qilingandan so'ng parametrlarni - protsedura chaqiruvining argumentlarini oladi. Chiqarish (unmarshalling) zarur konvertatsiyalarni (masalan, baytlar tartibini o'zgartirish) o'z ichiga olishi mumkin.

4. Stub mijozning so'rovi yuboriladigan real server protsedurasiga qo'ng'iroq qiladi, unga tarmoq orqali olingan argumentlarni uzatadi.

5. Protsedurani tugatgandan so'ng, boshqaruv unga kerakli parametrlarni o'tkazib, server stubiga qaytadi. Mijoz stubiga o'xshab; server stub so'rov kelgan tizimga tarmoq orqali yuboriladigan tarmoq javob xabarini shakllantirish uchun protsedura tomonidan qaytarilgan qiymatlarni o'zgartiradi.

6. Operatsion tizim qabul qilingan xabarni mijoz stubiga uzatadi, u kerakli transformatsiyadan so'ng qiymatlarni (masofali protsedura tomonidan qaytariladigan qiymatlar) mijozga uzatadi, bu esa buni oddiy qaytish sifatida izohlaydi. protseduradan.

Shunday qilib, mijoz nuqtai nazaridan, u mahalliy uchun bo'lgani kabi masofaviy protsedura chaqiruvini amalga oshiradi. Server haqida ham shunday deyish mumkin: protsedura standart tarzda chaqiriladi, ob'ekt (server stub) mahalliy protsedurani chaqiradi va u tomonidan qaytarilgan qiymatlarni oladi. Mijoz stubni chaqiriladigan server protsedurasi sifatida ko'radi va server o'z stubini mijoz sifatida izohlaydi.

Shunday qilib, stublar RPC tizimining yadrosini tashkil qiladi, mijoz va masofaviy server (protsedura) o'rtasida xabarlarni yaratish va uzatishning barcha jihatlari uchun javobgardir, garchi mijoz ham, server ham qo'ng'iroqlar mahalliy ravishda amalga oshiriladi deb taxmin qiladi. Bu RPC ning asosiy tushunchasi - stub kodidagi o'zaro ta'sirning taqsimlangan (tarmoq) xususiyatini butunlay yashirish. Ushbu yondashuvning afzalliklari aniq: mijoz ham, server ham tarmoqni amalga oshirishdan mustaqil, ikkalasi ham taqsimlangan virtual mashina ichida ishlaydi va protsedura chaqiruvlari standart interfeysga ega.

O'tish parametrlari

Qiymat parametrlarini o'tkazish oddiy. Bunday holda, mijoz stub parametr qiymatini tarmoq so'roviga joylashtiradi, ehtimol standart shaklga o'tkazishni amalga oshiradi (masalan, bayt tartibini o'zgartirish). Parametr ularning qiymati emas, balki ma'lumotlarning manzili bo'lsa, o'tish ko'rsatkichlari bilan bog'liq vaziyat ancha murakkablashadi. So'rovda manzilni yuborish ma'nosiz, chunki masofaviy protsedura butunlay boshqa manzil maydonida amalga oshiriladi. Eng oddiy RPC yechimi mijozlarga qiymat bo'yicha emas, balki boshqa parametrlarni o'tkazishiga yo'l qo'ymaslikdir, garchi bu, albatta, jiddiy cheklovlarni qo'yadi.

Bog'lash

Mijoz masofaviy protseduraga qo'ng'iroq qilishdan oldin, u kerakli serverni joylashtiradigan masofaviy tizimga ulanishi kerak. Shunday qilib, ulanish vazifasi ikkiga bo'linadi:

Kerakli server bilan masofaviy xostni topish

Berilgan xostda kerakli server jarayonini topish

Xostni topish uchun turli yondashuvlardan foydalanish mumkin. Mumkin variant - xostlar o'z serverlarini e'lon qiladigan va mijoz, agar xohlasa, unga mos keladigan xost va protsedura manzilini tanlashi mumkin bo'lgan markazlashtirilgan katalogni yaratishdir.

Har bir RPC protsedurasi dastur va protsedura raqami bilan noyob tarzda aniqlanadi. Dastur raqami masofaviy protseduralar guruhini belgilaydi, ularning har biri o'z raqamiga ega. Har bir dasturga versiya raqami ham beriladi, shuning uchun dasturga kichik o'zgartirishlar kiritilganda (masalan, protsedura qo'shganda) uning raqamini o'zgartirishga hojat qolmaydi. Odatda, bitta dastur modulida bir nechta funktsional o'xshash protseduralar amalga oshiriladi, ular ishga tushirilganda ushbu protseduralar serveriga aylanadi va dastur raqami bilan aniqlanadi.

Shunday qilib, mijoz masofaviy protseduraga qo'ng'iroq qilmoqchi bo'lganida, u kerakli xizmatni ta'minlaydigan dastur, versiya va protsedura raqamlarini bilishi kerak.

So'rovni o'tkazish uchun mijoz, shuningdek, zarur protseduralarni ta'minlaydigan server dasturi bilan bog'langan xostning tarmoq manzilini va port raqamini bilishi kerak. Bu portmap (IM) daemoni (ba'zi tizimlarda rpcbind (IM) deb ataladi) yordamida amalga oshiriladi. Demon masofaviy protsedura xizmatini ta'minlovchi va taniqli port raqamidan foydalanadigan xostda ishlaydi. Server jarayoni ishga tushirilganda, u o'z tartiblarini va port raqamlarini portmapda (IM) qayd qiladi. Endi, mijoz ma'lum bir protsedurani chaqirish uchun port raqamini bilishi kerak bo'lganda, u portmap (IM) serveriga so'rov yuboradi, u o'z navbatida port raqamini qaytaradi yoki so'rovni to'g'ridan-to'g'ri RPC serveriga yo'naltiradi va uni amalga oshirgandan so'ng mijozga javob. Har qanday holatda, agar talab qilinadigan protsedura mavjud bo'lsa, mijoz portmap (IM) serveridan protsedura port raqamini oladi va keyingi so'rovlar to'g'ridan-to'g'ri ushbu portga yuborilishi mumkin.

Istisnolarni ko'rib chiqish

Mahalliy protseduralarni chaqirishda istisnolar bilan ishlash ayniqsa muammoli emas. UNIX nolga bo'linish, xotiraga kirish noto'g'ri va hokazo kabi jarayon xatolarini boshqaradi.Masofadagi protsedurani chaqirish xatolik holatlari ehtimolini oshiradi. Noto'g'ri tarmoq xabarini olish kabi xatolar server va stub xatolariga qo'shiladi.

Misol uchun, transport protokoli sifatida UDP dan foydalanilganda, xabarlar belgilangan vaqt tugashidan keyin qayta uzatiladi. Agar ma'lum miqdordagi urinishlardan so'ng serverdan javob olinmasa, xato mijozga qaytariladi. TCP protokoli ishlatilganda, agar server TCP ulanishini to'xtatgan bo'lsa, mijozga xatolik qaytariladi.

Qo'ng'iroq semantikasi

Mahalliy protsedurani bir ma'noda chaqirish uning bajarilishiga olib keladi, shundan so'ng boshqaruv asosiy dasturga qaytadi. Masofaviy protsedurani chaqirishda vaziyat boshqacha. Jarayon aniq qachon amalga oshirilishini, umuman amalga oshiriladimi yoki yo'qligini aniqlash mumkin emas va agar shunday bo'lsa, necha marta? Masalan, server dasturi anormal tarzda tugatilgandan so'ng so'rov masofaviy tizim tomonidan qabul qilinsa, protsedura umuman bajarilmaydi. Agar mijoz ma'lum vaqtdan so'ng javob olmaganida (taym-aut) so'rovni qayta yuborsa, javob allaqachon tarmoq orqali uzatilayotganda vaziyat yuzaga kelishi mumkin va takroriy so'rov qayta ishlash uchun qabul qilinadi. masofaviy protsedura orqali. Bunday holda, protsedura bir necha marta amalga oshiriladi.

Shunday qilib, masofaviy protseduraning bajarilishini quyidagi semantika bilan tavsiflash mumkin:

- Bir va faqat bir marta. Ushbu xatti-harakatni (ba'zi hollarda eng ma'qul bo'lgan) mumkin bo'lgan server ishdan chiqishi tufayli amalga oshirish qiyin.

- Maksimal vaqtlar. Bu shuni anglatadiki, protsedura umuman bajarilmagan yoki faqat bir marta amalga oshirilgan. Xuddi shunday bayonot oddiy javob o'rniga xatolik qabul qilinganda ham amalga oshirilishi mumkin.

- Kamida bir marta. Jarayon, ehtimol, bir marta amalga oshirilgan, ammo ko'proq bo'lishi mumkin. Bunday vaziyatda normal ishlashi uchun masofaviy protsedura idempotentlik xususiyatiga ega bo'lishi kerak (inglizcha idemponentdan). Bu xususiyat protseduraga ega bo'lib, uning takroriy bajarilishi kümülatif o'zgarishlarga olib kelmaydi. Masalan, faylni o'qish idempotent, lekin faylga matn qo'shish unchalik emas.

Ma'lumotlar taqdimoti

Mijoz va server bitta kompyuterda bir xil tizimda ishlaganda, ma'lumotlarning mos kelmasligi bilan bog'liq muammolar bo'lmaydi. Ikkilik ma'lumotlar mijoz va server uchun bir xil tarzda taqdim etiladi. Masofaviy qo'ng'iroq bo'lsa, masala mijoz va server turli xil ma'lumotlar ko'rinishlariga ega (masalan, suzuvchi nuqta ko'rinishi, bayt tartibi va boshqalar) turli xil arxitekturali tizimlarda ishlashi mumkinligi bilan murakkablashadi.

Ko'pgina RPC ilovalari so'rovlar va javoblarda uzatiladigan barcha qiymatlar o'zgartirilishi kerak bo'lgan ma'lumotlarning standart ko'rinishini belgilaydi.

Masalan, Sun Microsystems-dan RPC-da ma'lumotlarni taqdim etish formati quyidagicha:

Bayt tartibi - eng muhim - oxirgi

Suzuvchi nuqta tasviri - IEEE

Belgilarni ko'rsatish - ASCII

Funktsionallik nuqtai nazaridan RPC tizimi amaliy qatlam va transport qatlami o'rtasida oraliq hisoblanadi. OSI modeliga ko'ra, ushbu qoida taqdimot va sessiya qatlamlariga mos keladi. Shunday qilib, RPC nazariy jihatdan tarmoqni amalga oshirishdan, xususan, transport darajasidagi tarmoq protokollaridan mustaqildir.

Tizimning dasturiy ta'minoti, qoida tariqasida, bir yoki ikkita protokolni qo'llab-quvvatlaydi. Masalan, Sun Microsystems RPC tizimi TCP va UDP protokollari yordamida xabar almashishni qo'llab-quvvatlaydi. U yoki bu protokolni tanlash dastur talablariga bog'liq. UDP ni tanlash quyidagi xususiyatlarga ega ilovalar uchun asoslanadi:

Chaqirilgan protseduralar idempotentdir

O'tkazilgan argumentlar hajmi va qaytish natijasi UDP paketi hajmidan kamroq - 8 KB.

Server bir necha yuz mijozlar bilan ishlashni ta'minlaydi. TCP protokollari bilan ishlashda server har bir faol mijoz bilan aloqani saqlab turishga majbur bo'lganligi sababli, bu uning resurslarining katta qismini egallaydi. UDP bu borada kamroq resurs talab qiladi.

Boshqa tomondan, TCP quyidagi xususiyatlarga ega ilovalarning samarali ishlashini ta'minlaydi:

Ilova ishonchli uzatish protokolini talab qiladi

Chaqirilgan protseduralar bir xil emas

Argumentlar yoki qaytarilgan natija 8KB dan katta

Protokolni tanlash odatda mijozda qoladi va tizim turli usullar bilan xabarlarni shakllantirish va uzatishni tashkil qiladi. Shunday qilib, uzatiladigan ma'lumotlar baytlar oqimi bo'lgan TCP protokolidan foydalanganda, xabarlarni bir-biridan ajratish kerak. Buning uchun, masalan, RFC1057 "RPC: Remote Procedure Call Protocol spetsifikatsiyasi 2-versiya" da tasvirlangan yozuvni belgilash protokoli qo'llaniladi, u har bir xabardan oldin baytlarda xabar hajmini ko'rsatadigan 32 bitli tamsayı bilan keladi.

Qo'ng'iroqning semantikasi bilan vaziyat boshqacha. Misol uchun, agar RPC ishonchsiz transport protokoli (UDP) yordamida amalga oshirilsa, tizim xabarni qisqa vaqt oralig'ida (taym autlari) qayta uzatadi. Agar mijozning arizasi javob olmasa, protsedura nol yoki undan ko'p marta bajarilgan deb aytish mumkin. Agar javob olingan bo'lsa, ariza kamida bir marta protsedura bajarilgan degan xulosaga kelishi mumkin. Ishonchli transport protokoli (TCP) dan foydalanganda, agar javob olinsa, protsedura bir marta bajarilgan deb aytish mumkin. Agar javob olinmasa, protsedura bajarilmaganligini aniq aytish mumkin emas3.

U qanday ishlaydi?

Aslida, haqiqiy RPC tizimi mijoz dasturi va server dasturiga o'rnatilgan. Quvonarlisi, tarqatilgan ilovalarni ishlab chiqishda siz RPC protokoli yoki dastur xabarlarini qayta ishlash tafsilotlarini o'rganishingiz shart emas. Tizim amaliy dasturiy ta'minotni yaratuvchilarning hayotini sezilarli darajada osonlashtiradigan tegishli ishlab chiqish muhitining mavjudligini nazarda tutadi. RPC ning asosiy nuqtalaridan biri shundaki, taqsimlangan dasturni ishlab chiqish ob'ekt interfeysining ta'rifi - maxsus tilda qilingan server funktsiyalarining rasmiy tavsifi bilan boshlanadi. Ushbu interfeysdan mijoz va server stublari avtomatik ravishda yaratiladi. Shundan so'ng bajarilishi kerak bo'lgan yagona narsa - bu haqiqiy protsedura kodini yozish.

Misol sifatida Sun Microsystems kompaniyasining RPC-ni ko'rib chiqing. Tizim uchta asosiy qismdan iborat:

Rpcgen (1) masofaviy protsedura interfeysi tavsifi asosida C dasturlari sifatida mijoz va server stublarini yaratuvchi RPC kompilyatoridir.

XDR kutubxonasi (eXternal Data Representation), u har xil turdagi ma'lumotlarni mashinadan mustaqil shaklga aylantirish funktsiyalarini o'z ichiga oladi, bu heterojen tizimlar o'rtasida ma'lumot almashish imkonini beradi.

Butun tizimning ishlashini ta'minlaydigan modullar kutubxonasi.

Keling, asosiy taqsimlangan hodisalarni qayd qilish ilovasining misolini ko'rib chiqaylik. Mijoz ishga tushirilganda, masofaviy kompyuterning jurnal fayliga xabar yozish uchun masofaviy protsedurani chaqiradi.

Buning uchun siz kamida uchta fayl yaratishingiz kerak bo'ladi: log.x masofaviy protseduralari interfeyslarining spetsifikatsiyasi (interfeys tavsifi tilida), log.c masofaviy protseduralarining haqiqiy matni va matn. mijozning asosiy dasturi asosiy () - client.c (C tilida).

Rpcgen (l) kompilyatori log.x spetsifikatsiyasi asosida uchta fayl yaratadi: C mijozi va server stublari (log clnt.c va log svc.c) va ikkala stub tomonidan ishlatiladigan log.h taʼrif fayli.

Shunday qilib, keling, dasturlarning manba kodini ko'rib chiqaylik.

Ushbu fayl masofaviy protseduraning ro'yxatga olish parametrlarini - dastur, versiya va protsedura raqamlarini belgilaydi va qo'ng'iroq qiluvchi interfeysni - kirish argumentlari va qaytish qiymatlarini belgilaydi. Shunday qilib, RLOG protsedurasi aniqlanadi, u argument sifatida satrni oladi (u jurnalga yoziladi) va qaytariladigan qiymat, sukut bo'yicha, buyurtma qilingan operatsiyaning muvaffaqiyatli yoki muvaffaqiyatsizligini ko'rsatadi.

LOG_PROG dasturi (

LOG_VER versiyasi (

int RLOG (string) = 1;

) = 0x31234567;

rpcgen (l) kompilyatori log.h sarlavha faylini hosil qiladi, bunda, xususan, protseduralar aniqlanadi:

log.h

* Iltimos, ushbu faylni tahrirlamang.

* U rpcgen yordamida yaratilgan.

#ifndef _LOG_H_RPCGEN

#_LOG_H_RPCGENni aniqlang

#o'z ichiga oladi

/ * Dastur raqami * /

#define LOG_PROG ((uzoq imzosiz) (0x31234567))

#define LOG_VER ((unsigned long) (1)) / * Versiya raqami * /

#define RLOG ((unsigned long) (1)) / * Muntazam raqam * /

extern int * rlog_l ();

/ * Ichki protsedura - biz undan foydalanishimiz shart emas * / extern int log_prog_l_freeresult ();

#endif / *!_LOG_H_RPCGEN * /

Keling, ushbu faylni batafsil ko'rib chiqaylik. Kompilyator interfeys deskriptorida aniqlangan RLOG nomini rlog_1 ga tarjima qiladi, katta harflarni kichik harflar bilan almashtiradi va dastur versiyasi raqamini pastki chiziq bilan qo'shadi. Qaytish turi int dan int * ga o'zgartirildi. Bu qoida - RPC interfeysni tavsiflashda faqat e'lon qilingan parametrlarning manzillarini yuborish va qabul qilish imkonini beradi. Xuddi shu qoida argument sifatida berilgan satr uchun ham amal qiladi. Bu print.h faylidan kelib chiqmasa ham, aslida qatorning manzili rlog_l () funksiyasiga argument sifatida ham uzatiladi.

Sarlavha fayliga qo'shimcha ravishda rpcgen (l) kompilyatori mijoz stub va server stub modullarini yaratadi. Asosan, ushbu fayllar matni barcha masofaviy qo'ng'iroq kodini o'z ichiga oladi.

Server stub - mijoz bilan barcha tarmoq o'zaro ta'sirini boshqaradigan bosh dastur (aniqrog'i, uning stub bilan). Amaliyotni bajarish uchun server stub funksiyasiga mahalliy qo'ng'iroq qiladi, uning matni yozilishi kerak:

log.c

#o'z ichiga oladi

# "log.h" ni kiriting

int * rlog_1 (char ** arg)

/ * Qaytish qiymati statik sifatida belgilanishi kerak * /

statik int natijasi;

int fd; / * Jurnal fayli identifikatori * /

/ * 0 jurnal faylini oching (agar u mavjud bo'lmasa, uni yarating), muvaffaqiyatsiz bo'lsa, xato kodi natijasini qaytaring == 1. * /

agar ((fd = ochiq ("./ server .log",

O_CREAT | O_RDWR | O_APPEND))< 0) return (&result);

len = strlen (* arg);

agar (yozish (fd, * arg, strlen (* arg))! = len)

qaytish (& natija); / * Natijani qaytarish - manzil natijasi * /

Mijoz stub masofaviy protseduraga uzatilgan argumentni oladi, kerakli o'zgarishlarni amalga oshiradi, portmap (1M) serveriga so'rov beradi, masofaviy protsedura serveri bilan bog'lanadi va nihoyat mijozga qaytarish qiymatini uzatadi. Mijoz uchun masofaviy protsedura chaqiruvi stub qo'ng'iroq bo'lib, oddiy mahalliy qo'ng'iroqdan farq qilmaydi.

mijoz.c

#o'z ichiga oladi

# "log.h" ni kiriting

asosiy (int argc, char * argv)

char * server, * mystring, * clnttime;

agar (argc! = 2) (

fprintf (stderr, "Qo'ng'iroq formati:% s Host_address \ n",

/ * Mijoz deskriptorini oling. Muvaffaqiyatsiz bo'lsa, biz sizga bu haqda xabar beramiz

server bilan aloqa o'rnatishning mumkin emasligi * /

agar ((s1 = clnt_create (server,

LOG_PROG, LOG_VER, "udp")) == NULL) (

clnt_pcreateerror (server);

/ * Satr uchun bufer ajratish * /

mystring = (char *) malloc (100);

/ * Hodisa vaqtini aniqlang * /

bintime = vaqt ((time_t *) NULL);

clnttime = ctime (& bintime);

sprintf (mystring, "% s - mijoz ishga tushdi", clnttime);

/ * Jurnal uchun xabar yuboraylik - mijoz ish boshlagan vaqt. Muvaffaqiyatsiz bo'lsa, xato haqida xabar beramiz * /

agar ((natija = rlog_l (& mystring, cl)) == NULL) (

fprintf (stderr, "xato2 \ n");

clnt_perror (cl, server);

/ * Masofaviy kompyuterda ishlamay qolsa, biz xato haqida xabar beramiz * /

agar (* natija! = 0)

fprintf (stderr, "Jurnalga yozishda xato \ n");

/ * 0 deskriptordan ozod * /

cint yo'q qilish (cl);

Mijoz stub log_clnt.c mijozning bajarilishini olish uchun client.c moduli bilan kompilyatsiya qilingan.

cc -o rlog client.c log_clnt.c -Insl

Log_svc.c server stub va log.c dasturi bajariladigan serverni olish uchun tuzilgan.

cc -o logger log_svc.c log.c -Insl

Endi server.nowhere.ru xostlarida server jarayonini boshlash kerak:

Keyin, rlog mijozi boshqa mashinada ishga tushirilganda, server tegishli yozuvni jurnal fayliga qo'shadi.

Bu holda RPC ishlash sxemasi rasmda ko'rsatilgan. 1. Modullar quyidagicha oʻzaro taʼsir qiladi:

1. Server jarayoni boshlanganda, u UDP soketini yaratadi va har qanday mahalliy portni ushbu rozetkaga bog'laydi. Keyin server dastur raqamlari va versiya raqamlarini ro'yxatga olish uchun svc_register (3N) kutubxona funksiyasini chaqiradi. Buning uchun funksiya portmap (IM) jarayonini chaqiradi va kerakli qiymatlarni uzatadi. Portmap (IM) serveri odatda tizimni ishga tushirish vaqtida ishga tushiriladi va ba'zi taniqli portga ulanadi. Portmap (3N) endi dasturimiz va versiyamiz uchun port raqamini biladi. Server so'rovni qabul qilishni kutmoqda. E'tibor bering, barcha tasvirlangan harakatlar rpcgen (IM) kompilyatori tomonidan yaratilgan server stub tomonidan amalga oshiriladi.

2. Rlog ishga tushganda, u qiladigan birinchi narsa kutubxona funksiyasini clnt_create (3N) chaqirib, unga masofaviy tizim manzilini, dastur va versiya raqamlarini hamda transport protokolini beradi. Funktsiya server.nowhere.m masofaviy tizimning portmap (IM) serveriga so'rov yuboradi va jurnal serveri uchun masofaviy port raqamini oladi.

3. Mijoz mijoz stubida belgilangan rlog_1 () tartibini chaqiradi va boshqaruvni stubga o'tkazadi. Bu, o'z navbatida, so'rovni (argumentlarni XDR formatiga aylantirish) UDP paketi ko'rinishida shakllantiradi va uni portmap (IM) serveridan olingan masofaviy portga yo'naltiradi. Keyin u bir muncha vaqt javob kutadi va agar olinmasa, so'rovni qayta yuboradi. Qulay sharoitlarda so'rov logger serveri (server stub moduli) tomonidan qabul qilinadi. Stub qaysi funktsiya chaqirilganligini (protsedura raqami bo'yicha) aniqlaydi va log.c modulining rlog_1 () funksiyasini chaqiradi. Tekshirish stubga qaytgandan so'ng, stub rlog_1 () funktsiyasi tomonidan qaytarilgan qiymatni XDR formatiga o'zgartiradi va javobni UDP paketi shaklida ham shakllantiradi. Javobni olgandan so'ng, mijoz stub qaytarilgan qiymatni chiqaradi, uni o'zgartiradi va mijoz xostiga qaytaradi.

Windows operatsion tizimining har qanday modifikatsiyasi, XP versiyasidan boshlab, RPC sifatida belgilangan xizmat komponentini o'z ichiga oladi. Oddiy foydalanuvchilarning ko'pchiligi bu nima ekanligini bilishmaydi, bundan tashqari, ular bu xizmat nima uchun ekanligini va qanday ishlashini bilishmaydi. Shu munosabat bilan, keraksiz va murakkab texnik atamalarni tavsiflamasdan, komponentning o'zi, uning ishlash tamoyillari va foydalanish doirasi bilan bog'liq ba'zi asosiy jihatlarni ko'rib chiqish taklif etiladi. Keling, mumkin bo'lgan xizmat xatolari va ularni tezda bartaraf etish usullari haqida alohida to'xtalib o'tamiz.

Masofaviy protseduralar (masofaviy protsedura chaqiruvi): bu nima?

Ko'rinishidan, ko'plab foydalanuvchilar ushbu xizmat komponentining nomiga asoslanib, uning nima ekanligini allaqachon xulosa qilishgan. Darhaqiqat, masofaviy protseduralar (masofaviy protseduralarni chaqirish) mahalliy kompyuterda emas, balki masofadan boshqarish pultida (ko'pincha serverda) bajarilganda ba'zi harakatlarni nazarda tutadi.

Ya'ni, so'rov bir terminalda shakllantiriladi, so'ngra boshqasiga o'tkaziladi, u erda bajariladi, shundan so'ng birinchi kompyuterga bajarilishi to'g'risidagi javob (hisobot) qaytariladi. Ammo bu faqat ibtidoiy tushuntirish. Aslida, hamma narsa ancha murakkab, chunki bu erda siz ma'lumotlarni uzatish protokollarini (UDP, TCP, HTTP) va boshqa ko'plab mexanizmlarni hisobga olishingiz kerak.

Bu xizmat nima uchun?

Asosiy maqsadiga qaramay, RPC RPC turli xil kompyuterlarda emas, balki bitta kompyuterda ishlatilishi mumkin. Eng oddiy misol bitta dasturning funksiyasini boshqa ilovadan chaqirishdir. Virtual studiyalar va sekvenserlar bilan ishlaydigan ko'plab musiqachilar har bir bunday dastur o'z audio tahrirlash yoki qayta ishlash moduliga ega ekanligini bilishadi, bu har doim ham foydalanuvchi talablariga javob bermaydi. Va har qanday studiya o'rniga boshqa har qanday tashqi dasturni ulash imkonini beradi.

Masalan, FL Studio sequencer sozlamalarida siz asosiy dastur muhitida ovozli fayllarni (namunalarni) tahrirlash uchun sukut bo'yicha foydalaniladigan boshqa dasturni (masalan, Adobe Audition) belgilashingiz mumkin. Shu bilan birga, Adobe Audition-ni FL Studio-ga ulash VST, RTAS yoki DX kabi virtual xostlar orqali emas, balki to'g'ridan-to'g'ri masofaviy protsedura chaqiruvi xizmatidan foydalanish orqali amalga oshiriladi. O'z-o'zidan ma'lumki, bu misol yagona emas, chunki tavsiflangan komponentning ko'lami ancha kengroqdir.

Ko'pincha bu xizmat terminallarda hisoblash yukini taqsimlash bilan bog'liq bo'lib, ular o'rtasida interaktiv aloqa o'rnatiladi. Shu bilan birga, agar bir nechta kompyuterlarning hisoblash resurslariga yuk teng taqsimlangan bo'lsa, faqat kichik hajmdagi ma'lumotlar almashinuvi va komponentlar o'rtasida tezkor javob berilgan taqdirdagina maksimal ishlashga erishish mumkin.

Masofaviy protsedura qo'ng'irog'ining muvaffaqiyatsizligi: sababi nima?

Afsuski, bunday talab tufayli ushbu xizmat bilan bog'liq nosozliklar va xatolarning paydo bo'lishi juda keng tarqalgan.

Natijada, nafaqat komponentning o'zidan foydalanish mumkin bo'lmaydi. Ba'zida ba'zi tizim sozlamalariga kirishning iloji bo'lmaydi va Windows XP shunchaki ishdan chiqadi, shundan so'ng uni normal ish holatiga qaytarish juda muammoli bo'lishi mumkin. Yana bir muammo - bu operatsion tizimga kiritilgan onlayn DISM ta'mirlash vositasi.

1726-xatoning paydo bo'lishi uning ishidagi buzilishlar bilan bog'liq bo'lib, bu RPC xizmatining tarkibiy qismlarining ishlashiga bevosita ta'sir qiladi.

Bunday nosozliklarning asosiy sabablari DISM jarayoni faol bo'lganda yoki qulay tarzda chiqa olmasa (masalan, DISM va SFC vositalari bir vaqtning o'zida ikkita buyruq konsolidan ishga tushirilganda) tizim tekshiruvi yoki tiklash vositasini chaqirish deb ataladi; xizmat RPC komponentlariga xizmat ko'rsatish bilan parallel ravishda ishlaganda; xizmat antivirus dasturi tomonidan bloklanganda.

Shuning uchun, agar RPC Windows 7 va undan yuqori versiyalarda ishlamay qolsa, birinchi narsa DISM-dan chiqish, kompyuterni qayta ishga tushirish va xizmatni qayta ishga tushirishdir. Agar bu yordam bermasa, siz xavfsiz rejimga o'tishga urinib ko'rishingiz va tiklash vaqtida antivirus himoyasini butunlay o'chirib qo'yishingiz mumkin. Biz masofaviy protsedura qo'ng'irog'i va Windows-ning har qanday modifikatsiyasidagi har qanday nosozlikni tuzatishga yordam beradigan qo'shimcha choralar haqida to'xtalamiz. Ayni paytda, keling, ushbu tizim komponentini o'chirish bilan bog'liq masalalarni ko'rib chiqaylik (afsuski, masalaning mohiyatini bilmagan ko'plab foydalanuvchilar aynan shunday narsalarni qilishga harakat qilmoqda).

RPC xizmatini o'chirib qo'yishim mumkinmi?

Keling, RPCni o'chirish qanchalik real ekanligini ko'rib chiqaylik. Ishlab chiquvchilarning tavsiyalariga asoslangan masofaviy protseduralar hech qanday holatda o'chirib qo'yilmasligi kerak. Bu muhim! Aslida, uning o'zi bunga yo'l qo'ymaydi. Albatta, qo'shimcha dasturiy ta'minotdan foydalanishni o'z ichiga olgan ba'zi vaqtinchalik echimlar mavjud, ammo aniq sabablarga ko'ra bunday ilovalarning nomlari berilmagan, chunki ular noto'g'ri ishlatilsa, butun tizim yaroqsiz holga kelishi mumkin.

RPC jarayonlarini o'chirish oqibatlari

Agar foydalanuvchi qandaydir tarzda masofaviy protseduralarni (masofaviy protsedura qo'ng'iroqlari) o'chirib qo'yishga muvaffaq bo'lsa ham, oqibatlari, afsuski, juda kutilmagan bo'lishi mumkin. Yuqorida aytib o'tilganidek, Windows XP umuman ishlashni to'xtatib qo'yishi mumkin va undan yuqori darajaga ega bo'lgan operatsion tizimda, natijada juda ko'p sonli tizim nosozliklari paydo bo'lishi mumkin, ularni faqat muhim Windows sozlamalariga kirish imkoni yo'qligi sababli bartaraf etib bo'lmaydi. va parametrlar, bundan tashqari, hatto xavfsiz rejimda yoki olinadigan muhitdan boshlanganda. Biroq, Windows 10 yoki undan oldingi operatsion tizimlarda RPC-larga qo'ng'iroq qilishda nosozlikni tuzatishingiz mumkin. Usul eng oson emas, shuning uchun uni ishlatishda juda ehtiyot bo'lishingiz kerak.

Masofaviy kirishni aniqlashni o'chirib qo'ying

Shunday qilib, asosiy RPC xizmatini o'chirib bo'lmaydi. Ammo, ehtimol, unga hamroh bo'lgan ba'zi tarkibiy qismlarni o'chirish mantiqiydir? Ha, haqiqatan ham, agar siz tizim xizmatlari va ularning tarkibiy qismlari (services.msc) bo'limiga o'tsangiz, siz RPC lokator deb ataladigan narsani topishingiz mumkin.

Ammo uni halokatli oqibatlardan qo'rqmasdan o'chirib qo'yish mumkin. Uning parametrlarini tahrirlashni kiritganingizdan so'ng, siz komponentni to'xtatishingiz va ishga tushirish turini o'chirib qo'yishingiz kerak. Masofaviy protseduralardan foydalanishi mumkin bo'lgan dasturlar baribir (uning yordamisiz) masofaviy protsedura chaqiruvini amalga oshiradi.

Agar biron sababga ko'ra o'rnatilgan parametrlar ishlamasa, siz Windows o'rnatish diskidan foydalanishingiz mumkin, undan yuklashda buyruq qatoriga qo'ng'iroq qiling va quyidagilarni kiriting:

cd X: \ i386 (X - olinadigan diskning harfi);
explorer.ex_% TEMP% \ explorer.exe faylini kengaytirish;
svchost.ex_% TEMP% \ svchost.exe faylini kengaytiring.

Qayta ishga tushirilgandan so'ng, "Vazifa menejeri" chaqiriladi va u tugaydi, shundan so'ng buyruq satrida% TEMP% \ explorer.exe% SYSTEMROOT% / y kombinatsiyasi yoziladi, shundan so'ng "Vazifa menejeri" da barcha svchost jarayonlari mutlaqo tugatiladi. ". Endi siz ayniqsa ehtiyot bo'lishingiz kerak, chunki buyruqlar konsolida jarayonlarni atigi oltmish soniya ichida tugatgandan so'ng siz buyruqni yozishga vaqt topishingiz kerak copy% TEMP% \ svchost.exe% systemroot% \ system32 / y.

Agar foydalanuvchi, masalan, normal yoki xavfsiz rejimda tizim registriga kirish imkoniga ega bo'lsa, HKCC bo'limidagi muharrirda (regedit), CSConfigFlags parametrini toping va unga nol qiymatini belgilang.

1726 nosozliklarini bartaraf etish

Nihoyat, 1726-xato uchun muammolarni bartaraf etish ham ro'yxatga olish kitobi orqali amalga oshiriladi. Ammo bu holda, HKLM filialida siz RpcSs katalogini topishingiz va o'ng tomonda Start parametrining qiymatini tahrirlashingiz kerak.

Odatda sukut bo'yicha o'rnatilgan to'rttadan ikkitaga o'zgartirilishi kerak va keyin tizimni qayta ishga tushiring.

Keyingi so'z

RPC qo'ng'iroqlari uchun hamma narsa shu. Masofaviy protseduralar, ushbu komponentning ishlash tamoyillari kengaytirilgan versiyada juda uzoq vaqt davomida tavsiflanishi mumkin, ammo taqdim etilgan materialda asosiy e'tibor xizmat bilan umumiy tanishish va u mumkin bo'lgan xato va nosozliklarni bartaraf etishning ba'zi usullariga qaratildi. kompyuter tizimida sabab. Oddiy foydalanuvchilar sabrli bo'lishlari va juda ehtiyot bo'lishlari kerak, chunki ro'yxatga olish kitobidagi bitta noto'g'ri harakat operatsion tizimning to'liq ishdan chiqishiga olib kelishi mumkin.

Shuni esda tutingki, bunday nosozliklar boshqa vositalar bilan, masalan, optimallashtiruvchilar va Windows operatsion tizimining sozlamalari sozlagichlari bilan bartaraf etilmaydi. Barcha istaklar bilan, na buyruq qatori, na undan ham ko'proq, bunday dasturiy paketlardagi kalitlarni tahrirlash darajasida ro'yxatga olish kitobiga aralashuv ta'minlanmaydi.

4-ma'ruza

4.1 Masofaviy protsedura chaqiruvi tushunchasi

Masofaviy protseduralarni chaqirish g'oyasi (Masofadan protsedura chaqiruvi - RPC) Tarmoq orqali boshqarish va ma'lumotlarni uzatish uchun bitta mashinada ishlaydigan dastur doirasida boshqaruv va ma'lumotlarni uzatishning taniqli va yaxshi tushunilgan mexanizmini kengaytirishdan iborat. Masofaviy protsedura qo'ng'iroqlari vositalari taqsimlangan hisoblashni tashkil qilishni osonlashtirish uchun mo'ljallangan. RPC tezkor javob vaqtlari va nisbatan kam ma'lumotlarni uzatish bilan masofaviy komponentlar o'rtasida interaktiv aloqa mavjud bo'lgan ilovalarda eng samarali hisoblanadi. Bunday ilovalar RPC-yo'naltirilgan deb ataladi.

Mahalliy protseduralarga chaqiruvning xarakterli xususiyatlari quyidagilardir: assimetriya, ya'ni o'zaro ta'sir qiluvchi tomonlardan biri tashabbuskor; sinxronlik, ya'ni so'rov berilgan paytdan boshlab to'xtab, chaqirilgan protseduradan qaytgandan keyingina davom etadigan chaqiruv protsedurasining bajarilishi.

Masofaviy qo'ng'iroqlarni amalga oshirish mahalliy protsedura qo'ng'iroqlarini amalga oshirishdan ancha murakkabroq. Boshlash uchun, qo'ng'iroq qiluvchi va qo'ng'iroq qiluvchi turli xil mashinalarda bajarilganligi sababli, ular turli xil manzil bo'shliqlariga ega va bu parametrlar va natijalarni uzatishda muammolarni keltirib chiqaradi, ayniqsa mashinalar bir xil bo'lmasa. RPC umumiy xotiraga ishona olmasligi sababli, bu RPC parametrlarida stek bo'lmagan xotira joylariga ko'rsatgichlar bo'lmasligi va parametr qiymatlari bir kompyuterdan boshqasiga ko'chirilishi kerakligini anglatadi. RPC va mahalliy qo'ng'iroq o'rtasidagi keyingi farq shundaki, u majburiy ravishda asosiy aloqa tizimidan foydalanadi, ammo buni protseduralar ta'rifida ham, protseduralarning o'zida ham aniq ko'rsatmaslik kerak. Masofaviylik qo'shimcha muammolarni keltirib chiqaradi. Chaqiruvchi dastur va chaqirilayotgan mahalliy protsedurani bitta mashinada bajarish bitta jarayonda amalga oshiriladi. Ammo RPCni amalga oshirishda kamida ikkita jarayon mavjud - har bir mashinada bittadan. Agar ulardan biri ishlamay qolsa, quyidagi holatlar yuzaga kelishi mumkin: agar qo'ng'iroq qilish tartib-qoidasi ishlamay qolsa, masofadan turib chaqiriladigan protseduralar "etim" bo'lib qoladi, agar masofaviy protseduralar g'ayritabiiy tarzda tugatsa, qo'ng'iroq qiluvchilar qo'ng'iroq qiluvchilarning "mahrum ota-onalari"ga aylanadilar. masofaviy protseduralardan javob kuting.

Bundan tashqari, dasturlash tillari va operatsion muhitlarning heterojenligi bilan bog'liq bir qator muammolar mavjud: biron bir dasturlash tilida qo'llab-quvvatlanadigan ma'lumotlar tuzilmalari va protsedura chaqiruv tuzilmalari boshqa barcha tillarda bir xil tarzda qo'llab-quvvatlanmaydi.

Ushbu va boshqa ba'zi muammolar ko'plab tarqalgan operatsion tizimlar asosidagi keng tarqalgan RPC texnologiyasi tomonidan hal qilinadi.

Asosiy RPC operatsiyalari

RPC qanday ishlashini tushunish uchun avval avtonom ishlaydigan an'anaviy mashinada mahalliy protsedura chaqiruvini bajarishni ko'rib chiqing. Misol uchun, bu tizim chaqiruvi bo'lsin

hisoblash = o'qish (fd, buf, nbayt);

bu yerda fd butun son;

buf - belgilar massivi;

nbayt butun sondir.

Qo'ng'iroq qilish uchun qo'ng'iroq qilish protsedurasi parametrlarni teskari tartibda stekga suradi. O'qishga qo'ng'iroq amalga oshirilgandan so'ng, u qaytish qiymatini registrga joylashtiradi, qaytarish manzilini oldinga siljitadi va boshqaruvni chaqiruv protsedurasiga qaytaradi, bu parametrlarni stekdan chiqarib, uni dastlabki holatiga qaytaradi. Esda tutingki, C da parametrlar mos yozuvlar bo'yicha (nomi bo'yicha) yoki qiymat bo'yicha (qiymat bo'yicha) chaqirilishi mumkin. Chaqirilayotgan protseduraga kelsak, qiymat parametrlari ishga tushirilishi mumkin bo'lgan mahalliy o'zgaruvchilardir. Chaqirilayotgan protsedura ularni chaqiruvchi protsedurada ushbu o'zgaruvchilarning asl nusxalari qiymatiga ta'sir qilmasdan o'zgartirishi mumkin.

Agar o'zgaruvchiga ko'rsatgich chaqirilgan protseduraga o'tkazilsa, u holda ushbu o'zgaruvchining qiymatini chaqirilgan protsedura tomonidan o'zgartirilishi chaqiruvchi protsedura uchun ham ushbu o'zgaruvchining qiymatining o'zgarishiga olib keladi. Bu haqiqat RPC uchun juda muhimdir.

Parametrlarni o'tkazishning yana bir mexanizmi mavjud bo'lib, u C tilida ishlatilmaydi.U qo'ng'iroq bo'yicha nusxa ko'chirish/tiklash deb ataladi va chaqiruvchi dasturga o'zgaruvchilarni qiymat sifatida stekga nusxalash va keyin ularni nusxalash zaruratidan iborat. qo'ng'iroq qilish jarayonining dastlabki qiymatlari bo'yicha qo'ng'iroq qilinganidan keyin orqaga qaytish.

Qaysi parametrlarni uzatish mexanizmidan foydalanishni til dizaynerlari hal qiladi. Ba'zan bu uzatiladigan ma'lumotlar turiga bog'liq. Masalan, C tilida butun son va boshqa skalyar ma'lumotlar har doim qiymat bo'yicha, massivlar esa har doim havola orqali uzatiladi.

RPC ortidagi g'oya masofaviy protsedura chaqiruvini mahalliy protsedura chaqiruviga iloji boricha yaqinroq qilishdir. Boshqacha qilib aytganda, RPC ni shaffof qiling: qo'ng'iroq qiluvchi chaqirilgan protsedura boshqa mashinada ekanligini bilishi shart emas va aksincha.

RPC shaffoflikka quyidagi yo'l bilan erishadi. Agar chaqirilayotgan protsedura haqiqatan ham uzoq bo'lsa, mahalliy protsedura o'rniga, kutubxonaga mijoz stub (stub) deb nomlangan protseduraning boshqa versiyasi joylashtiriladi. Dastlabki protsedura singari, qo'ng'iroqlar ketma-ketligi yordamida stub chaqiriladi va yadroga kirishda uzilish sodir bo'ladi. Faqat dastlabki protseduradan farqli o'laroq, u registrlarga parametrlarni qo'ymaydi va yadrodan ma'lumot so'ramaydi, buning o'rniga masofaviy mashinaning yadrosiga yuborish uchun xabar yaratadi.

RPC bajarish bosqichlari

Masofaviy protsedura chaqiruvini bajarish jarayonida dasturiy ta'minot komponentlarining o'zaro ta'siri 2-rasmda tasvirlangan.

Rasm 2. Masofaviy protsedura chaqiruvi

Mijoz stub mijoz dasturi tomonidan chaqirilgandan so'ng, uning birinchi vazifasi buferni yuborilayotgan xabar bilan to'ldirishdir. Ba'zi tizimlarda mijoz stubida har safar yangi so'rov kelganda boshidan to'ldiriladigan yagona, qattiq uzunlikdagi bufer mavjud. Boshqa tizimlarda xabarlar buferi alohida xabar maydonlari uchun buferlar pulidir, bu buferlarning ba'zilari allaqachon to'lgan. Ushbu usul, ayniqsa, paket ko'p sonli maydonlar bilan formatlanganda mos keladi, ammo bu maydonlarning ko'pchiligining qiymatlari qo'ng'iroqdan qo'ng'iroqqa o'zgarmaydi.

Keyin parametrlar tegishli formatga aylantirilishi va xabar buferiga kiritilishi kerak. Bu vaqtda xabar jo'natishga tayyor, shuning uchun yadro chaqiruvida uzilish amalga oshiriladi.

Yadro boshqaruvni qo'lga kiritganida, u kontekstlarni almashtiradi, protsessor registrlarini va xotira xaritasini (sahifa deskriptorlari) saqlaydi va yadro rejimida ishlash uchun ishlatiladigan yangi xotira xaritasini o'rnatadi. Yadro va foydalanuvchi kontekstlari har xil bo'lganligi sababli, yadro xabarni aynan o'zining manzil maydoniga nusxalashi, unga kirishi, maqsad manzilini (va, ehtimol, sarlavhaning boshqa maydonlarini) eslab qolishi va uni tarmoqqa o'tkazishi kerak. interfeys. Bu mijoz tomonidagi ishni yakunlaydi. Uzatish taymeri yoqilgan va yadro javobni so'rashi yoki boshqaruvni boshqa jarayonni tanlashni rejalashtiruvchiga o'tkazishi mumkin. Birinchi holda, so'rovning bajarilishi tezlashadi, lekin ko'p dasturlash mavjud emas.

Server tomonida kiruvchi bitlar qabul qiluvchi apparat tomonidan o'rnatilgan buferga yoki RAMga joylashtiriladi. Barcha ma'lumotlar qabul qilinganda, uzilish hosil bo'ladi. Interrupt ishlov beruvchisi paket ma'lumotlarining to'g'riligini tekshiradi va qaysi stubdan o'tkazilishi kerakligini aniqlaydi. Agar stublardan hech biri ushbu paketni kutmasa, ishlov beruvchi uni buferga joylashtirishi yoki butunlay tashlab yuborishi kerak. Agar kutilayotgan stub bo'lsa, xabar unga ko'chiriladi. Nihoyat, kontekstni almashtirish amalga oshiriladi, buning natijasida registrlar va xotira xaritasi tiklanadi, ular stub qo'ng'iroqni qabul qilgan paytdagi qiymatlarni oladi.

Endi server stub ishlay boshlaydi. U parametrlarni ochadi va ularni stekga mos ravishda suradi. Hamma narsa tayyor bo'lgach, serverga qo'ng'iroq qilinadi. Jarayonni tugatgandan so'ng, server natijalarni mijozga yuboradi. Buning uchun yuqorida tavsiflangan barcha qadamlar faqat teskari tartibda amalga oshiriladi.

3-rasmda har bir RPC chaqiruvi uchun bajarilishi kerak bo'lgan buyruqlar ketma-ketligi ko'rsatilgan.

Shakl 3. RPC protsedurasining bosqichlari

RPC dan foydalanishning eng katta samaradorligi mavjud ilovalarda erishiladi masofaviy komponentlar o'rtasidagi interaktiv aloqa bilan qisqa javob vaqti va nisbatan kichik hajmdagi uzatilgan ma'lumotlar.Bunday ilovalar RPC-yo'naltirilgan deb ataladi.

Mahalliy protsedura chaqiruvlari quyidagilar bilan tavsiflanadi:

Asimmetriya, ya'ni o'zaro ta'sir qiluvchi tomonlardan biri tashabbuskor hisoblanadi;

Sinxronlik, ya'ni qo'ng'iroq qilish protsedurasining bajarilishi so'rov berilgan paytdan boshlab to'xtatiladi va faqat chaqirilgan protsedura qaytganidan keyin davom ettiriladi.

Masofaviy qo'ng'iroqlarni amalga oshirish mahalliy protsedura qo'ng'iroqlarini amalga oshirishdan ancha murakkabroq.

1. Bundan boshlaylik, chaqiruv va chaqirilgan protseduralar turli mashinalarda bajarilganligi sababli, ular turli manzil bo'shliqlariga ega va bu yaratadi parametrlar va natijalarni uzatishda muammolar, ayniqsa mashinalar bir xil bo'lmasa.

RPC umumiy xotiraga ishona olmasligi sababli, bu shuni anglatadi RPC parametrlarida stek bo'lmagan xotira joylariga ko'rsatgichlar bo'lmasligi kerak nima bo `pti parametr qiymatlari bir kompyuterdan ikkinchisiga ko'chirilishi kerak.

2. RPC va mahalliy qo'ng'iroq o'rtasidagi keyingi farq shundaki, u shartli ravishda asosiy aloqa tizimidan foydalanadi ammo bu tartiblarning ta'rifida ham, protseduralarning o'zida ham aniq ko'rinmasligi kerak .

Masofaviylik qo'shimcha muammolarni keltirib chiqaradi. Chaqiruvchi dasturni va chaqirilayotgan mahalliy protsedurani bitta mashinada bajarish doirasida amalga oshirildibitta jarayon... Lekin RPC amalga oshirishda ishtirok etadikamida ikkita jarayon - har bir mashinada bittadan... Agar ulardan biri qulab tushsa, quyidagi holatlar yuzaga kelishi mumkin:

agar qo'ng'iroq qilish protsedurasi buzilib qolsa, masofadan chaqirilgan protseduralar "etim" bo'lib qoladi va

masofaviy protseduralarning g'ayritabiiy ravishda tugatilishi qo'ng'iroq qiluvchilarni "noqulay ota-onalar" ga aylantiradi va masofaviy protseduralardan hech qanday natija kutmaydi.

Bundan tashqari, mavjud dasturlash tillari va operatsion muhitlarning heterojenligi bilan bog'liq bir qator muammolar : Birorta dasturlash tilida qo'llab-quvvatlanadigan ma'lumotlar tuzilmalari va protsedura chaqiruv tuzilmalari boshqa barcha tillarda bir xil tarzda qo'llab-quvvatlanmaydi.

Ushbu va boshqa ba'zi muammolar ko'plab tarqalgan operatsion tizimlar asosidagi keng tarqalgan RPC texnologiyasi tomonidan hal qilinadi.

RPC ortidagi g'oya masofaviy protsedura chaqiruvini mahalliy protsedura chaqiruviga iloji boricha yaqinroq qilishdir. Boshqacha qilib aytganda, RPC ni shaffof qiling: qo'ng'iroq qiluvchi chaqirilgan protsedura boshqa mashinada ekanligini bilishi shart emas va aksincha.

RPC shaffoflikka quyidagi yo'l bilan erishadi. Agar chaqirilayotgan protsedura haqiqatan ham uzoq bo'lsa, mahalliy protsedura o'rniga, kutubxonaga mijoz stub (stub) deb nomlangan protseduraning boshqa versiyasi joylashtiriladi. Dastlabki protsedura singari, stub chaqiruv ketma-ketligi yordamida chaqiriladi (3.1-rasmdagi kabi) va yadro uzilib qoladi. Faqat dastlabki protseduradan farqli o'laroq, u registrlarga parametrlarni qo'ymaydi va yadrodan ma'lumot so'ramaydi, buning o'rniga masofaviy mashinaning yadrosiga yuborish uchun xabar yaratadi..

Guruch... 3.2. Masofaviy protsedura chaqiruvi

Masofaviy protsedura chaqiruvi (RPC) Masofaviy protsedura chaqiruvi kontseptsiyasi

Masofaviy protsedura qo'ng'irog'i (RPC) g'oyasi tarmoq orqali boshqaruv va ma'lumotlarni uzatish uchun bitta mashinada ishlaydigan dastur doirasida boshqaruv va ma'lumotlarni uzatishning taniqli va tushunarli mexanizmini kengaytirishdir. Masofaviy protsedura qo'ng'iroqlari vositalari taqsimlangan hisoblashni tashkil qilishni osonlashtirish uchun mo'ljallangan. RPC tezkor javob vaqtlari va nisbatan kam ma'lumotlarni uzatish bilan masofaviy komponentlar o'rtasida interaktiv aloqa mavjud bo'lgan ilovalarda eng samarali hisoblanadi. Bunday ilovalar RPC-yo'naltirilgan deb ataladi.

Mahalliy protsedura chaqiruvlari quyidagilar bilan tavsiflanadi:

Asimmetriya, ya'ni o'zaro ta'sir qiluvchi tomonlardan biri tashabbuskor; Sinxronlik, ya'ni chaqiruv protsedurasining bajarilishi so'rov berilgan paytdan boshlab to'xtaydi va faqat chaqirilgan protseduradan qaytgandan keyin davom etadi.

Ushbu va boshqa ba'zi muammolar ko'plab tarqalgan operatsion tizimlar asosidagi keng tarqalgan RPC texnologiyasi tomonidan hal qilinadi.

Asosiy RPC operatsiyalari

RPC qanday ishlashini tushunish uchun avval avtonom ishlaydigan an'anaviy mashinada mahalliy protsedura chaqiruvini bajarishni ko'rib chiqing. Misol uchun, bu tizim chaqiruvi bo'lsin

Hisoblash = o'qish (fd, buf, nbayt);

bu erda fd butun son,
buf belgilar majmuasi,
nbayt butun sondir.

Qo'ng'iroq qilish uchun chaqiruv protsedurasi parametrlarni teskari tartibda stekga suradi (3.1-rasm). O'qishga qo'ng'iroq amalga oshirilgandan so'ng, u qaytish qiymatini registrga joylashtiradi, qaytarish manzilini oldinga siljitadi va boshqaruvni chaqiruv protsedurasiga qaytaradi, bu parametrlarni stekdan chiqarib, uni dastlabki holatiga qaytaradi. Esda tutingki, C da parametrlar mos yozuvlar bo'yicha (nomi bo'yicha) yoki qiymat bo'yicha (qiymat bo'yicha) chaqirilishi mumkin. Chaqirilayotgan protseduraga kelsak, qiymat parametrlari ishga tushirilishi mumkin bo'lgan mahalliy o'zgaruvchilardir. Chaqirilayotgan protsedura ularni chaqiruvchi protsedurada ushbu o'zgaruvchilarning asl nusxalari qiymatiga ta'sir qilmasdan o'zgartirishi mumkin.

Guruch. 3.1. a) O'qish chaqiruvi amalga oshirilishidan oldingi stek;
b) Protsedurani bajarish vaqtidagi stek;
c) Chaqiruvchi dasturga qaytgandan keyin stack

RPC shaffoflikka quyidagi yo'l bilan erishadi. Agar chaqirilayotgan protsedura haqiqatan ham uzoq bo'lsa, mahalliy protsedura o'rniga, kutubxonaga mijoz stub (stub) deb nomlangan protseduraning boshqa versiyasi joylashtiriladi. Dastlabki protsedura singari, stub chaqiruv ketma-ketligi yordamida chaqiriladi (3.1-rasmdagi kabi) va yadro uzilib qoladi. Faqat dastlabki protseduradan farqli o'laroq, u registrlarga parametrlarni qo'ymaydi va yadrodan ma'lumot so'ramaydi, buning o'rniga masofaviy mashinaning yadrosiga yuborish uchun xabar yaratadi.

RPC bajarish bosqichlari

Masofaviy protsedura chaqiruvini bajarish jarayonida dasturiy ta'minot komponentlarining o'zaro ta'siri 3.2-rasmda tasvirlangan. Mijoz stub mijoz dasturi tomonidan chaqirilgandan so'ng, uning birinchi vazifasi buferni yuborilayotgan xabar bilan to'ldirishdir. Ba'zi tizimlarda mijoz stubida har safar yangi so'rov kelganda boshidan to'ldiriladigan yagona, qattiq uzunlikdagi bufer mavjud. Boshqa tizimlarda xabarlar buferi alohida xabar maydonlari uchun buferlar pulidir, bu buferlarning ba'zilari allaqachon to'lgan. Ushbu usul, ayniqsa, paket ko'p sonli maydonlar bilan formatlanganda mos keladi, ammo bu maydonlarning ko'pchiligining qiymatlari qo'ng'iroqdan qo'ng'iroqqa o'zgarmaydi.

Keyin parametrlar tegishli formatga aylantirilishi va xabar buferiga kiritilishi kerak. Bu vaqtda xabar jo'natishga tayyor, shuning uchun yadro chaqiruvida uzilish amalga oshiriladi.

Guruch. 3.2. Masofaviy protsedura chaqiruvi

Server tomonida kiruvchi bitlar qabul qiluvchi apparat tomonidan o'rnatilgan buferga yoki RAMga joylashtiriladi. Barcha ma'lumotlar qabul qilinganda, uzilish hosil bo'ladi. Interrupt ishlov beruvchisi paket ma'lumotlarining to'g'riligini tekshiradi va qaysi stubdan o'tkazilishi kerakligini aniqlaydi. Agar stublardan hech biri ushbu paketni kutmasa, ishlov beruvchi uni buferlashi yoki butunlay tashlab yuborishi kerak. Agar kutilayotgan stub bo'lsa, xabar unga ko'chiriladi. Nihoyat, kontekstni almashtirish amalga oshiriladi, buning natijasida registrlar va xotira xaritasi tiklanadi, ular stub qo'ng'iroqni qabul qilgan paytdagi qiymatlarni oladi.

3.3-rasmda har bir RPC qo'ng'irog'i uchun bajarilishi kerak bo'lgan buyruqlar ketma-ketligi ko'rsatilgan va 3.4-rasmda tasvirlangan 14 bosqichning har birini bajarish uchun umumiy RPC bajarish vaqtining qancha qismi sarflanganligi ko'rsatilgan. Tadqiqot DEC Firefly multiprotsessorli ish stantsiyasida o'tkazildi va beshta protsessorning mavjudligi o'lchov natijalariga ta'sir qilgan bo'lsa-da, rasmda ko'rsatilgan gistogramma RPC bajarish jarayonining umumiy ko'rinishini beradi.

Guruch. 3.3. RPC protsedurasi bosqichlari

Guruch. 3.4. RPC bajarilishining 14 bosqichi o'rtasida vaqt ajratish

1. Qo'ng'iroq stub

2. Buferni tayyorlang

3. Paket parametrlari

4. Sarlavha maydonini to'ldiring

5. Xabardagi nazorat summasini hisoblang

6. Yadrogacha uzilish

7. Bajarish uchun paket navbati

8. QBUS orqali kontrollerga xabar yuborish

9. Ethernet orqali uzatish vaqti

10. Tekshirgichdan paketni oling

11. Interrupt bilan ishlash tartibi

12. Nazorat summasini hisoblash

13. Kontekstni foydalanuvchi maydoniga almashtirish

14. Server stubini bajarish

Dinamik ulanish

Mijoz server manzilini qanday belgilashi haqidagi savolni ko'rib chiqing. Ushbu muammoni hal qilish usullaridan biri mijoz dasturida serverning tarmoq manzilidan bevosita foydalanishdir. Ushbu yondashuvning nochorligi uning o'ta moslashuvchan emasligidir: server ko'chirilganda yoki serverlar soni ko'payganda yoki interfeys o'zgartirilganda, bu va boshqa ko'plab holatlarda, barcha dasturlarni qayta kompilyatsiya qilish kerak bo'ladi. server manzilini qiyin belgilash. Ushbu muammolarning barchasini oldini olish uchun ba'zi taqsimlangan tizimlar dinamik bog'lanish deb ataladigan narsadan foydalanadilar.

Dinamik ulanishning boshlang'ich nuqtasi serverning rasmiy ta'rifi (spetsifikatsiyasi) hisoblanadi. Spetsifikatsiya fayl serverining nomini, versiya raqamini va ushbu server tomonidan mijozlar uchun taqdim etilgan xizmat ko'rsatish protseduralari ro'yxatini o'z ichiga oladi (3.5-rasm). Har bir protsedura uchun uning parametrlarining tavsifi berilgan, bu parametr serverga nisbatan kirish yoki chiqish ekanligini ko'rsatadi. Ba'zi parametrlar ham kirish, ham chiqish bo'lishi mumkin - masalan, mijoz tomonidan serverga yuboriladigan, u erda o'zgartiriladigan va keyin mijozga qaytariladigan ba'zi massiv (nusxa olish / tiklash operatsiyasi).

Guruch. 3.5. RPC server spetsifikatsiyasi

Rasmiy server spetsifikatsiyasi mijoz va server stublarini yaratuvchi stub generator dasturiga kirish sifatida ishlatiladi. Keyin ular tegishli kutubxonalarga joylashtiriladi. Foydalanuvchi (mijoz) dasturi server spetsifikatsiyasida belgilangan har qanday protsedurani chaqirganda, tegishli stub protsedurasi dastur ikkilik bilan bog'lanadi. Xuddi shunday, server kompilyatsiya qilinganda, server stublari u bilan bog'lanadi.

Server ishga tushganda, u qiladigan birinchi narsa o'zining server interfeysini bog'lovchi deb nomlangan maxsus dasturga topshirishdir.Serverni ro'yxatdan o'tkazish jarayoni deb nomlanuvchi bu jarayon server o'z nomini, versiya raqamini, noyob identifikatorini va identifikatorini yuborishni o'z ichiga oladi. Deskriptor tizimdan mustaqil bo'lib, IP, Ethernet, X.500 yoki boshqa manzil bo'lishi mumkin, shuningdek, autentifikatsiya kabi boshqa ma'lumotlarni ham o'z ichiga olishi mumkin.

Mijoz birinchi marta masofaviy protseduralardan birini chaqirganda, masalan, o'qish, mijoz stub hali serverga ulanmaganligini ko'radi va biriktiruvchi dasturga to'g'ri versiyaning interfeysini import qilishni so'rab xabar yuboradi. kerakli serverdan. Agar shunday server mavjud bo'lsa, u holda bog'lovchi mijoz stubiga tutqich va noyob identifikatorni uzatadi.

Mijoz stub so'rov xabarini yuborishda manzil sifatida tavsiflovchidan foydalanadi. Xabarda server yadrosi kiruvchi xabarni to'g'ri serverga yo'naltirish uchun foydalanadigan parametrlar va noyob identifikatorni o'z ichiga oladi, agar ushbu mashinada ulardan bir nechtasi bo'lsa.

Interfeyslarni import qilish/eksport qilishning bu usuli juda moslashuvchan. Misol uchun, bir xil interfeysni qo'llab-quvvatlaydigan bir nechta serverlar bo'lishi mumkin va mijozlar serverlar o'rtasida tasodifiy taqsimlanadi. Ushbu usul doirasida serverlarni vaqti-vaqti bilan so'rash, ularning ishlashini tahlil qilish va ishlamay qolganda avtomatik ravishda o'chirish mumkin bo'ladi, bu tizimning umumiy nosozliklarga chidamliligini oshiradi. Ushbu usul mijozning autentifikatsiyasini ham qo'llab-quvvatlashi mumkin. Masalan, server faqat ma'lum bir ro'yxatdagi mijozlar tomonidan ishlatilishi mumkinligini aniqlashi mumkin.

Biroq, dinamik ulanishning kamchiliklari bor, masalan, interfeyslarni eksport qilish va import qilish uchun qo'shimcha xarajatlar (vaqt). Ushbu xarajatlarning kattaligi sezilarli bo'lishi mumkin, chunki ko'plab mijoz jarayonlari qisqa vaqt davomida mavjud va jarayonning har bir boshlanishida interfeysni import qilish jarayoni qayta bajarilishi kerak. Bundan tashqari, katta taqsimlangan tizimlarda bog'lovchi dastur darboğazga aylanishi mumkin va shunga o'xshash maqsadli bir nechta dasturlarni yaratish jarayonlarni yaratish va sinxronlashtirish uchun ortiqcha xarajatlarni ham oshiradi.

Muvaffaqiyatsizlik holatlarida RPC semantikasi

Ideal holda, RPC ishlamay qolganda to'g'ri ishlashi kerak. Muvaffaqiyatsizliklarning quyidagi sinflarini ko'rib chiqing:

Mijoz serverning joylashuvini aniqlay olmaydi, masalan, kerakli server ishlamay qolsa yoki mijoz dasturi uzoq vaqt oldin tuzilgan va server interfeysining eski versiyasidan foydalangan bo'lsa. Bunday holda, mijozning so'roviga javoban xato kodini o'z ichiga olgan xabar keladi. Mijozdan serverga so'rov yo'qolgan. Eng oddiy yechim - so'rovni ma'lum vaqtdan keyin takrorlash. Serverdan mijozga yo'qolgan javob xabari. Ushbu parametr avvalgisiga qaraganda ancha murakkab, chunki ba'zi protseduralar idempotent emas. Idempotent protsedura - bajarilish so'rovi bir necha marta takrorlanishi mumkin bo'lgan va natijasi o'zgarmaydigan protsedura. Bunday protseduraga faylni o'qish misol bo'ladi. Ammo bank hisobvarag'idan ma'lum miqdorni olish tartibi idempotent emas va javob yo'qolgan taqdirda, takroriy so'rov mijozning hisobvaraq holatini sezilarli darajada o'zgartirishi mumkin. Mumkin bo'lgan echimlardan biri barcha protseduralarni idempotent shaklga keltirishdir. Biroq, amalda bu har doim ham mumkin emas, shuning uchun boshqa usuldan foydalanish mumkin - mijoz yadrosi tomonidan barcha so'rovlarni ketma-ket raqamlash. Server yadrosi har bir mijozning so'nggi so'rovi sonini eslab qoladi va har bir so'rovni olgandan so'ng, bu so'rov asosiy yoki takroriyligini tahlil qiladi. So'rovni olgandan keyin server ishdan chiqdi. Bu erda idempotentlik xususiyati ham muhim, ammo afsuski, so'rovlarni raqamlash usulini qo'llash mumkin emas. Bunday holda, muvaffaqiyatsizlik qachon sodir bo'lganligi muhim - operatsiyadan oldin yoki keyin. Ammo mijoz yadrosi bu vaziyatlarni taniy olmaydi, faqat javob vaqti tugaganini biladi. Ushbu muammoning uchta yondashuvi mavjud: Server qayta ishga tushguncha kutib turing va qayta urinib ko'ring. Ushbu yondashuv RPC kamida bir marta va, ehtimol, ko'proq bajarilishini ta'minlaydi. Xato haqida darhol dasturga xabar bering. Ushbu yondashuv RPCning ko'pi bilan bir marta bajarilishini ta'minlaydi. Uchinchi yondashuv hech narsani kafolatlamaydi. Server ishlamay qolsa, mijozni qo'llab-quvvatlamaydi. RPC umuman yoki ko'p marta bajarilishi mumkin yoki bajarilmasligi mumkin. Har holda, bu usulni amalga oshirish juda oson.

Ushbu yondashuvlarning hech biri juda jozibali emas. Va bitta RPC bajarilishini kafolatlaydigan ideal variantni, umuman olganda, printsipial sabablarga ko'ra amalga oshirib bo'lmaydi. Faraz qilaylik, masalan, masofaviy operatsiya qandaydir matnni chop etmoqda, bu printer buferini yuklash va printerning qandaydir boshqaruv registrida bir bitni o'rnatishni o'z ichiga oladi, buning natijasida printer ishga tushadi. Server ishdan chiqishi nazorat biti o'rnatilgandan bir mikrosoniya oldin yoki mikrosoniyadan keyin sodir bo'lishi mumkin. Muvaffaqiyatsizlik momenti tiklanish jarayonini to'liq belgilaydi, ammo mijoz muvaffaqiyatsizlik momenti haqida bila olmaydi. Muxtasar qilib aytganda, serverning ishdan chiqishi ehtimoli RPC xususiyatini tubdan o'zgartiradi va markazlashtirilgan tizim va taqsimlangan tizim o'rtasidagi farqni aniq aks ettiradi. Birinchi holda, serverning ishdan chiqishi mijozning ishdan chiqishiga olib keladi va qayta tiklash mumkin emas. Ikkinchi holda, tizimni tiklash bo'yicha qadamlar ham mumkin, ham zarurdir.

Mijoz so'rov yuborgandan so'ng ishdan chiqdi. Bunday holda, hisob-kitoblar hech kim kutmagan natijalar bo'yicha amalga oshiriladi. Bunday hisob-kitoblar "yetimlar" deb ataladi. Yetimlarning mavjudligi turli xil muammolarni keltirib chiqarishi mumkin: protsessorning ortiqcha vaqti, resurslarni blokirovka qilish, joriy so'rovga javobni tizimni qayta ishga tushirishdan oldin mijoz mashinasi tomonidan berilgan so'rovga javob bilan almashtirish.

Yetimlar bilan nima qilish kerak? Keling, 4 ta mumkin bo'lgan yechimni ko'rib chiqaylik.

Vayronagarchilik. Mijoz stub RPC xabarini yuborishdan oldin, u hozir nima qilishini bildirish uchun jurnalga eslatma qo'yadi. Jurnal diskda yoki boshqa nosozliklarga chidamli xotirada saqlanadi. Baxtsiz hodisadan keyin tizim qayta ishga tushadi, jurnal tahlil qilinadi va etimlar yo'q qilinadi. Ushbu yondashuvning kamchiliklari, birinchidan, har bir RPC haqida diskka yozish bilan bog'liq xarajatlarning oshishi va ikkinchidan, birinchi avlod etimlari tomonidan chiqarilgan RPC qo'ng'iroqlari natijasida hosil bo'lgan ikkinchi avlod etimlarining paydo bo'lishi natijasida yuzaga kelishi mumkin bo'lgan samarasizlikni o'z ichiga oladi. Reenkarnasyon. Bunday holda, barcha muammolar disk yozishdan foydalanmasdan hal qilinadi. Usul vaqtni ketma-ket raqamlangan davrlarga bo'lishdan iborat. Mijoz qayta ishga tushganda, u yangi davrni boshlash uchun barcha mashinalarga translyatsiya qiladi. Ushbu xabarni olgandan so'ng, barcha masofaviy hisoblashlar tugatiladi. Albatta, agar tarmoq segmentlangan bo'lsa, unda ba'zi etimlar omon qolishi mumkin. Yumshoq reenkarnasyon oldingi holatga o'xshaydi, bundan mustasno, barcha masofaviy hisoblar topilmaydi va yo'q qilinadi, lekin faqat qayta yuklanadigan mijozning hisoblari. Muddati. Har bir so'rovga standart T vaqt oralig'i tayinlanadi, bu vaqt davomida u bajarilishi kerak. Agar so'rov belgilangan vaqt ichida bajarilmasa, u holda qo'shimcha kvant ajratiladi. Garchi bu qo'shimcha ishni talab qilsa-da, agar mijozning ishdan chiqishidan so'ng, mijoz qayta ishga tushishidan oldin server T oralig'ini kutsa, u holda barcha etimlar yo'q qilinadi.

Amalda, bu yondashuvlarning hech biri ma'qul emas, bundan tashqari, etimlarni o'ldirish vaziyatni yanada kuchaytirishi mumkin. Misol uchun, etim bir yoki bir nechta ma'lumotlar bazasi faylini qulflab qo'ygan deylik. Agar etim to'satdan yo'q qilingan bo'lsa, unda bu qulflar qoladi, bundan tashqari, yo'q qilingan etimlar turli xil tizim navbatlarida turishi mumkin, kelajakda ular yangi jarayonlarning bajarilishiga olib kelishi mumkin va hokazo.