დისტანციური პროცედურების დარეკვა (rpc - Remote Procedure Call). დისტანციური პროცედურები: დისტანციური პროცედურის გამოძახება, განმარტება და ფუნქციები RPC შესრულების ეტაპები

ლექცია 4

4.1 დისტანციური პროცედურის ზარის კონცეფცია

დისტანციური პროცედურების გამოძახების იდეა (დისტანციური პროცედურის ზარი - RPC)მოიცავს ერთ მანქანაზე გაშვებული პროგრამის ფარგლებში კონტროლისა და მონაცემების გადაცემის კარგად ცნობილი და გასაგები მექანიზმის გაფართოებას კონტროლისა და მონაცემების ქსელში გადაცემამდე. დისტანციური პროცედურის გამოძახების ხელსაწყოები შექმნილია განაწილებული გამოთვლის ორგანიზების გასაადვილებლად. RPC გამოყენების ყველაზე დიდი ეფექტურობა მიიღწევა იმ აპლიკაციებში, რომლებშიც არის ინტერაქტიული კომუნიკაცია დისტანციურ კომპონენტებს შორის სწრაფი რეაგირების დროით და შედარებით მცირე რაოდენობით გადაცემული მონაცემებით. ასეთ აპლიკაციებს უწოდებენ RPC-ზე ორიენტირებულს.

ლოკალური პროცედურების გამოძახების დამახასიათებელი ნიშნებია: ასიმეტრია, ანუ ერთ-ერთი ურთიერთდამოკიდებული მხარე არის ინიციატორი; სინქრონულობა, ანუ გამოძახების პროცედურის შესრულება ჩერდება მოთხოვნის გაცემის მომენტიდან და განახლდება მხოლოდ გამოძახებული პროცედურის დაბრუნების შემდეგ.

დისტანციური ზარების განხორციელება ბევრად უფრო რთულია, ვიდრე ადგილობრივი პროცედურების ზარების განხორციელება. დასაწყისისთვის, ვინაიდან გამოძახების და გამოძახების პროცედურები შესრულებულია სხვადასხვა მანქანებზე, მათ აქვთ მისამართის სხვადასხვა სივრცე და ეს ქმნის პრობლემებს პარამეტრებისა და შედეგების გადაცემისას, განსაკუთრებით იმ შემთხვევაში, თუ მანქანები არ არის იდენტური. ვინაიდან RPC არ შეიძლება დაეყრდნოს გაზიარებულ მეხსიერებას, ეს ნიშნავს, რომ RPC პარამეტრები არ უნდა შეიცავდეს მითითებებს მეხსიერების არადაწყობის ადგილებზე და რომ პარამეტრის მნიშვნელობები უნდა დაკოპირდეს ერთი კომპიუტერიდან მეორეზე. შემდეგი განსხვავება RPC-სა და ლოკალურ ზარს შორის არის ის, რომ ის აუცილებლად იყენებს საკომუნიკაციო სისტემას, მაგრამ ეს არ უნდა იყოს აშკარად ხილული არც პროცედურების განსაზღვრაში და არც თავად პროცედურებში. დისტანციურობა დამატებით პრობლემებს იწვევს. გამოძახების პროგრამის და გამოძახებული ლოკალური პროცედურის შესრულება იმავე მანქანაზე ხორციელდება ერთი პროცესის ფარგლებში. მაგრამ RPC-ის განხორციელება მოიცავს მინიმუმ ორ პროცესს - თითო თითოეულ მანქანაზე. თუ ერთ-ერთი მათგანი ავარიულია, შეიძლება წარმოიშვას შემდეგი სიტუაციები: თუ გამოძახების პროცედურა ავარიულია, დისტანციურად გამოძახებული პროცედურები „ობოლი“ გახდება, ხოლო თუ დისტანციური პროცედურები ავარიულია, გამოძახების პროცედურები გახდებიან „ობოლი მშობლები“, რომლებიც ამაოდ ელოდებიან პასუხი დისტანციური პროცედურებიდან.

გარდა ამისა, არსებობს მთელი რიგი პრობლემები, რომლებიც დაკავშირებულია პროგრამირების ენების და ოპერაციული გარემოს არაერთგვაროვნებასთან: მონაცემთა სტრუქტურები და პროცედურების გამოძახების სტრუქტურები, რომლებიც მხარდაჭერილია რომელიმე პროგრამირების ენაზე, არ არის ერთნაირად მხარდაჭერილი ყველა სხვა ენაზე.

ეს და ზოგიერთი სხვა პრობლემა მოგვარებულია ფართოდ გავრცელებული RPC ტექნოლოგიით, რომელიც საფუძვლად უდევს ბევრ განაწილებულ ოპერაციულ სისტემას.

ძირითადი RPC ოპერაციები

იმის გასაგებად, თუ როგორ მუშაობს RPC, ჯერ განვიხილოთ ლოკალური პროცედურების ზარი ტიპიურ მანქანაზე, რომელიც მუშაობს ოფლაინ რეჟიმში. მოდით ეს იყოს, მაგალითად, სისტემური ზარი

count=read(fd,buf,nbytes);

სადაც fd არის მთელი რიცხვი;

buf – სიმბოლოთა მასივი;

nbytes არის მთელი რიცხვი.

ზარის განსახორციელებლად, დარეკვის პროცედურა უბიძგებს პარამეტრებს დასტაზე საპირისპირო თანმიმდევრობით. წაკითხული ზარის შესრულების შემდეგ, ის ათავსებს დაბრუნების მნიშვნელობას რეესტრში, გადააქვს დაბრუნების მისამართი და აბრუნებს კონტროლს გამოძახების პროცედურას, რომელიც აბრუნებს პარამეტრებს სტეკიდან და აბრუნებს მას თავდაპირველ მდგომარეობაში. გაითვალისწინეთ, რომ C ენაში პარამეტრების გამოძახება შესაძლებელია მითითებით (სახელით) ან მნიშვნელობით (მნიშვნელობით). გამოძახებულ პროცედურასთან დაკავშირებით, მნიშვნელობის პარამეტრები არის ინიციალიზებული ლოკალური ცვლადები. გამოძახებულ პროცედურას შეუძლია შეცვალოს ისინი გამოძახების პროცედურაში ამ ცვლადების თავდაპირველ მნიშვნელობებზე გავლენის გარეშე.

თუ ცვლადის მაჩვენებელი გადაეცემა გამოძახებულ პროცედურას, მაშინ ამ ცვლადის მნიშვნელობის შეცვლა გამოძახებული პროცედურებით იწვევს ამ ცვლადის მნიშვნელობის შეცვლას გამოძახების პროცედურისთვის. ეს ფაქტი ძალიან მნიშვნელოვანია RPC-სთვის.

ასევე არის სხვა პარამეტრის გადაცემის მექანიზმი, რომელიც არ გამოიყენება C-ში. მას ეწოდება call-by-copy/restore, რომელიც მოითხოვს აბონენტს დააკოპიროს ცვლადები დასტაზე როგორც მნიშვნელობები და შემდეგ დააკოპიროს ისინი ზარის განხორციელების შემდეგ. გამოძახების პროცედურის ორიგინალური მნიშვნელობები.

გადაწყვეტილებას, თუ რომელი პარამეტრის გადაცემის მექანიზმი გამოიყენოს, იღებენ ენის შემქმნელებს. ზოგჯერ ეს დამოკიდებულია გადაცემული მონაცემების ტიპზე. მაგალითად, C-ში მთელი რიცხვები და სხვა სკალარული მონაცემები ყოველთვის გადაეცემა მნიშვნელობით, ხოლო მასივები ყოველთვის გადაეცემა მითითებით.

RPC-ის მიღმა არის იდეა, რომ დისტანციური პროცედურის გამოძახება მაქსიმალურად ჰგავს ადგილობრივ პროცედურულ ზარს. სხვა სიტყვებით რომ ვთქვათ, გახადეთ RPC გამჭვირვალე: გამოძახების პროცედურამ არ უნდა იცოდეს, რომ გამოძახებული პროცედურა სხვა მანქანაზეა და პირიქით.

RPC აღწევს გამჭვირვალობას შემდეგი გზით. როდესაც გამოძახებული პროცედურა რეალურად არის დისტანციური, პროცედურის სხვა ვერსია, რომელსაც ეწოდება კლიენტის ნაკერი, განთავსებულია ბიბლიოთეკაში ლოკალური პროცედურის ნაცვლად. ორიგინალური პროცედურის მსგავსად, stub იწოდება გამოძახების თანმიმდევრობით და ხდება შეფერხება ბირთვზე წვდომისას. მხოლოდ, ორიგინალური პროცედურისგან განსხვავებით, ის არ ათავსებს პარამეტრებს რეგისტრებში და არ ითხოვს მონაცემებს ბირთვიდან; ამის ნაცვლად, ის ქმნის შეტყობინებას, რომელიც უნდა გაიგზავნოს დისტანციური აპარატის ბირთვში.

RPC შესრულების ეტაპები

პროგრამული უზრუნველყოფის კომპონენტების ურთიერთქმედება დისტანციური პროცედურის ზარის შესრულებისას ილუსტრირებულია სურათზე 2.

სურათი 2. დისტანციური პროცედურის ზარი

მას შემდეგ, რაც კლიენტის სათაური გამოიძახება კლიენტის პროგრამის მიერ, მისი პირველი ამოცანაა ბუფერის შევსება გაგზავნილი გზავნილით. ზოგიერთ სისტემაში, კლიენტის შტაბს აქვს ერთი ფიქსირებული სიგრძის ბუფერი, რომელიც თავიდანვე ივსება ყოველი ახალი მოთხოვნით. სხვა სისტემებში შეტყობინებების ბუფერი არის ბუფერების აუზი ინდივიდუალური შეტყობინების ველებისთვის, რომელთაგან ზოგიერთი უკვე სავსეა. ეს მეთოდი განსაკუთრებით შესაფერისია იმ შემთხვევებისთვის, როდესაც პაკეტს აქვს ფორმატი, რომელიც შედგება ველების დიდი რაოდენობით, მაგრამ ამ ველის მნიშვნელობები არ იცვლება ზარიდან ზარამდე.

პარამეტრები შემდეგ უნდა გადაკეთდეს შესაბამის ფორმატში და ჩასვათ შეტყობინებების ბუფერში. ამ მომენტში შეტყობინება მზად არის გასაგზავნად, ამიტომ ბირთვის გამოძახების შეწყვეტა შესრულდება.

როდესაც ბირთვი აკონტროლებს, ის ცვლის კონტექსტს, ინახავს პროცესორის რეგისტრებს და მეხსიერების რუკას (გვერდის სახელურები) და აყენებს ახალ მეხსიერების რუკას, რომელიც გამოყენებული იქნება ბირთვის რეჟიმში გასაშვებად. იმის გამო, რომ ბირთვი და მომხმარებლის კონტექსტი განსხვავებულია, ბირთვმა უნდა დააკოპიროს შეტყობინება ზუსტად მის მისამართთა სივრცეში, რათა შეძლოს მასზე წვდომა, დაიმახსოვროს დანიშნულების მისამართი (და შესაძლოა სხვა სათაურის ველები) და უნდა გადასცეს ის ქსელის ინტერფეისს. ეს ასრულებს სამუშაოს კლიენტის მხარეს. გადაცემის ტაიმერი ჩართულია და ბირთვს შეუძლია ან ციკლურად გამოკითხოს პასუხი ან გადასცეს კონტროლი განრიგს, რომელიც შეარჩევს სხვა პროცესს გასაშვებად. პირველ შემთხვევაში, შეკითხვის შესრულება დაჩქარებულია, მაგრამ მულტიპროგრამირება არ არის.

სერვერის მხარეს, შემომავალი ბიტები მოთავსებულია მიმღები აპარატურის მიერ ან ჩიპზე ბუფერში ან RAM-ში. როდესაც ყველა ინფორმაცია მიიღება, წარმოიქმნება შეფერხება. შეფერხების დამმუშავებელი ამოწმებს პაკეტის მონაცემების სისწორეს და ადგენს, რომელ ნაკერზე უნდა გაიგზავნოს იგი. თუ არცერთი სტატია არ ელოდება ამ პაკეტს, დამმუშავებელმა ან უნდა დააფიქსიროს იგი ან საერთოდ გაუქმდეს. თუ არის ლოდინის პუნქტი, შეტყობინება კოპირდება მასში. დაბოლოს, შესრულებულია კონტექსტური გადართვა, რის შედეგადაც აღდგება რეგისტრები და მეხსიერების რუკა, იღებენ იმ მნიშვნელობებს, რაც მათ ჰქონდათ იმ მომენტში, როდესაც სტუბმა დარეკა მიიღო.

ახლა სერვერის ნაკერი იწყებს მუშაობას. ის ხსნის პარამეტრებს და სათანადოდ უბიძგებს მათ დასტაზე. როდესაც ყველაფერი მზად არის, კეთდება ზარი სერვერზე. პროცედურის განხორციელების შემდეგ, სერვერი გადასცემს შედეგებს კლიენტს. ამისათვის შეასრულეთ ზემოთ აღწერილი ყველა ნაბიჯი, მხოლოდ საპირისპირო თანმიმდევრობით.

სურათი 3 გვიჩვენებს ბრძანებების თანმიმდევრობას, რომელიც უნდა შესრულდეს თითოეული RPC გამოძახებისთვის.

სურათი 3. RPC პროცედურის საფეხურები

) დისტანციური პროცედურის ზარის კონცეფცია

დისტანციური პროცედურის ზარის (RPC) იდეა არის კონტროლისა და მონაცემების გადაცემის ცნობილი და გასაგები მექანიზმის გაფართოება ერთ მანქანაზე გაშვებული პროგრამის ფარგლებში კონტროლისა და მონაცემების ქსელში გადასაცემად. დისტანციური პროცედურის გამოძახების ხელსაწყოები შექმნილია განაწილებული გამოთვლის ორგანიზების გასაადვილებლად. RPC გამოყენების ყველაზე დიდი ეფექტურობა მიიღწევა იმ აპლიკაციებში, რომლებშიც არის ინტერაქტიული კომუნიკაცია დისტანციურ კომპონენტებს შორის სწრაფი რეაგირების დროით და შედარებით მცირე რაოდენობით გადაცემული მონაცემებით. ასეთ აპლიკაციებს უწოდებენ RPC-ზე ორიენტირებულს.

ადგილობრივი პროცედურების გამოძახების დამახასიათებელი ნიშნებია:

ასიმეტრია, ანუ ერთ-ერთი ურთიერთდამოკიდებული მხარე არის ინიციატორი; სინქრონულობა, ანუ გამოძახების პროცედურის შესრულება ჩერდება მოთხოვნის გაცემის მომენტიდან და განახლდება მხოლოდ გამოძახებული პროცედურის დაბრუნების შემდეგ.

ძირითადი RPC ოპერაციები

რაოდენობა=წაკითხული(fd,buf,nbytes);

სადაც fd არის მთელი რიცხვი,
buf - სიმბოლოების მასივი,
nbytes არის მთელი რიცხვი.

ზარის განსახორციელებლად, გამოძახების პროცედურა უბიძგებს პარამეტრებს დასტაზე საპირისპირო თანმიმდევრობით (სურათი 3.1). წაკითხული ზარის შესრულების შემდეგ, ის ათავსებს დაბრუნების მნიშვნელობას რეესტრში, გადააქვს დაბრუნების მისამართი და აბრუნებს კონტროლს გამოძახების პროცედურას, რომელიც აბრუნებს პარამეტრებს სტეკიდან და აბრუნებს მას თავდაპირველ მდგომარეობაში. გაითვალისწინეთ, რომ C ენაში პარამეტრების გამოძახება შესაძლებელია მითითებით (სახელით) ან მნიშვნელობით (მნიშვნელობით). გამოძახებულ პროცედურასთან დაკავშირებით, მნიშვნელობის პარამეტრები არის ინიციალიზებული ლოკალური ცვლადები. გამოძახებულ პროცედურას შეუძლია შეცვალოს ისინი გამოძახების პროცედურაში ამ ცვლადების თავდაპირველ მნიშვნელობებზე გავლენის გარეშე.

ასევე არსებობს პარამეტრების გადაცემის კიდევ ერთი მექანიზმი, რომელიც არ გამოიყენება C-ში. მას ეწოდება call-by-copy/restore, რომელიც მოითხოვს აბონენტს დააკოპიროს ცვლადები დასტაზე როგორც მნიშვნელობები და შემდეგ დააკოპიროს ისინი ზარის განხორციელების შემდეგ. გამოძახების პროცედურის ორიგინალური მნიშვნელობები.

ბრინჯი. 3.1. ა) დასტის წაკითხვის ზარის შესრულებამდე;
ბ) სტეკი პროცედურის შესრულებისას;
გ) დაწყობა დარეკვის პროგრამაში დაბრუნების შემდეგ

RPC აღწევს გამჭვირვალობას შემდეგი გზით. როდესაც გამოძახებული პროცედურა რეალურად არის დისტანციური, პროცედურის სხვა ვერსია, რომელსაც ეწოდება კლიენტის ნაკერი, განთავსებულია ბიბლიოთეკაში ლოკალური პროცედურის ნაცვლად. ორიგინალური პროცედურის მსგავსად, stub იწოდება გამოძახების თანმიმდევრობის გამოყენებით (როგორც სურათზე 3.1), და ხდება შეფერხება ბირთვზე წვდომისას. მხოლოდ, ორიგინალური პროცედურისგან განსხვავებით, ის არ ათავსებს პარამეტრებს რეგისტრებში და არ ითხოვს მონაცემებს ბირთვიდან; ამის ნაცვლად, ის ქმნის შეტყობინებას, რომელიც უნდა გაიგზავნოს დისტანციური აპარატის ბირთვში.

RPC შესრულების ეტაპები

პროგრამული უზრუნველყოფის კომპონენტების ურთიერთქმედება დისტანციური პროცედურის ზარის შესრულებისას ილუსტრირებულია ნახაზზე 3.2. მას შემდეგ, რაც კლიენტის სათაური გამოიძახება კლიენტის პროგრამის მიერ, მისი პირველი ამოცანაა ბუფერის შევსება გაგზავნილი გზავნილით. ზოგიერთ სისტემაში, კლიენტის შტაბს აქვს ერთი ფიქსირებული სიგრძის ბუფერი, რომელიც თავიდანვე ივსება ყოველი ახალი მოთხოვნით. სხვა სისტემებში შეტყობინებების ბუფერი არის ბუფერების აუზი ინდივიდუალური შეტყობინების ველებისთვის, რომელთაგან ზოგიერთი უკვე სავსეა. ეს მეთოდი განსაკუთრებით შესაფერისია იმ შემთხვევებისთვის, როდესაც პაკეტს აქვს ფორმატი, რომელიც შედგება ველების დიდი რაოდენობით, მაგრამ ამ ველის მნიშვნელობები არ იცვლება ზარიდან ზარამდე.

ბრინჯი. 3.2. დისტანციური პროცედურის ზარი

ნახაზი 3.3 გვიჩვენებს ბრძანებების თანმიმდევრობას, რომელიც უნდა შესრულდეს თითოეული RPC გამოძახებისთვის, ხოლო ნახაზი 3.4 გვიჩვენებს, თუ რა პროპორცია იხარჯება RPC-ის შესრულების მთლიანი დროის რა წილი იხარჯება აღწერილ 14 საფეხურზე. ტესტები ჩატარდა DEC Firefly მრავალპროცესორულ სამუშაო სადგურზე და მაშინ, როცა ხუთი პროცესორის არსებობა აუცილებლად იმოქმედებდა გაზომვების შედეგებზე, ფიგურაში ნაჩვენები ჰისტოგრამა იძლევა ზოგად წარმოდგენას RPC-ის შესრულების პროცესზე.

ბრინჯი. 3.3. ნაბიჯები RPC პროცედურის შესასრულებლად

ბრინჯი. 3.4. დროის განაწილება RPC-ის შესრულების 14 ეტაპს შორის

1. ნაკერის დარეკვა

2. მოამზადეთ ბუფერი

3. შეფუთვის პარამეტრები

4. შეავსეთ სათაურის ველი

5. გამოთვალეთ საკონტროლო ჯამი შეტყობინებაში

6. შეწყვიტოს ბირთვი

7. პაკეტის რიგი შესასრულებლად

8. მესიჯის გადაცემა კონტროლერზე QBUS ავტობუსის მეშვეობით

9. Ethernet გადაცემის დრო

10. მიიღეთ პაკეტი კონტროლერისგან

11. შეწყვეტის დამუშავების პროცედურა

12. საკონტროლო ჯამის გაანგარიშება

13. კონტექსტის გადართვა მომხმარებლის სივრცეში

14. სერვერის ნაკერის შესრულება

დინამიური კავშირი

მოდით განვიხილოთ, თუ როგორ განსაზღვრავს კლიენტი სერვერის ადგილმდებარეობას. ამ პრობლემის გადაჭრის ერთ-ერთი მეთოდია კლიენტის პროგრამაში სერვერის ქსელის მისამართის პირდაპირ გამოყენება. ამ მიდგომის მინუსი არის მისი უკიდურესი მოუქნელობა: სერვერის გადაადგილებისას, ან სერვერების რაოდენობის გაზრდისას, ან ინტერფეისის შეცვლისას ყველა ამ და ბევრ სხვა შემთხვევაში, აუცილებელია ყველა პროგრამის ხელახალი შედგენა, რომელიც იყენებდა მყარი კოდირებული სერვერის მისამართს. ყველა ამ პრობლემის თავიდან ასაცილებლად, ზოგიერთი განაწილებული სისტემა იყენებს იმას, რასაც დინამიური კავშირი ეწოდება.

დინამიური დაკავშირების საწყისი წერტილი არის სერვერის ფორმალური განმარტება (სპეციფიკაცია). სპეციფიკაცია შეიცავს ფაილის სერვერის სახელს, ვერსიის ნომერს და ამ სერვერის მიერ კლიენტებისთვის მოწოდებული სერვისის პროცედურების ჩამონათვალს (სურათი 3.5). თითოეული პროცედურისთვის მოცემულია მისი პარამეტრების აღწერა, სადაც მითითებულია, არის თუ არა ეს პარამეტრი შემავალი ან გამომავალი სერვერთან შედარებით. ზოგიერთი პარამეტრი შეიძლება იყოს როგორც შემავალი, ასევე გამომავალი - მაგალითად, ზოგიერთი მასივი, რომელიც კლიენტის მიერ სერვერზე იგზავნება, იქ შეცვლილია და შემდეგ უბრუნდება კლიენტს (კოპირება/აღდგენის ოპერაცია).

ბრინჯი. 3.5. RPC სერვერის სპეციფიკაცია

სერვერის ფორმალური სპეციფიკაცია გამოიყენება როგორც შემავალი ნაკერების გენერატორის პროგრამაში, რომელიც ქმნის როგორც კლიენტის, ასევე სერვერის ნაკერებს. შემდეგ ისინი მოთავსებულია შესაბამის ბიბლიოთეკებში. როდესაც მომხმარებელი (კლიენტი) პროგრამა იძახებს სერვერის სპეციფიკაციაში განსაზღვრულ ნებისმიერ პროცედურას, შესაბამისი სტუბის პროცედურა ასოცირდება პროგრამის ორობით კოდთან. ანალოგიურად, სერვერის შედგენისას, მას უკავშირდება სერვერის ნაკერები.

სერვერის გაშვებისას, პირველი, რასაც ის აკეთებს, არის სერვერის ინტერფეისის გადაცემა სპეციალურ პროგრამაზე, რომელსაც ეწოდება Binder. ეს პროცესი, რომელიც ცნობილია როგორც სერვერის რეგისტრაციის პროცესი, გულისხმობს სერვერის გადაცემას მისი სახელის, ვერსიის ნომრის, უნიკალური იდენტიფიკატორისა და სახელურის. სერვერის მდებარეობაზე. სახელური არის სისტემური დამოუკიდებელი და შეიძლება იყოს IP, Ethernet, X.500 ან სხვა მისამართი და ასევე შეიძლება შეიცავდეს სხვა ინფორმაციას, როგორიცაა ავთენტიფიკაციასთან დაკავშირებულ ინფორმაციას.

როდესაც კლიენტი პირველად იძახებს ერთ-ერთ დისტანციურ პროცედურას, მაგალითად, წაკითხვას, კლიენტის სტუბი ხედავს, რომ ის ჯერ არ არის დაკავშირებული სერვერთან და აგზავნის შეტყობინებას ბაინდერის პროგრამაში სასურველი ინტერფეისის იმპორტის მოთხოვნით. სასურველი სერვერის ვერსია. თუ ასეთი სერვერი არსებობს, მაშინ Binder გადასცემს აღწერს და უნიკალურ იდენტიფიკატორს კლიენტის ნაკვთს.

ინტერფეისების იმპორტის/ექსპორტის ეს მეთოდი ძალიან მოქნილია. მაგალითად, შეიძლება არსებობდეს რამდენიმე სერვერი, რომლებიც მხარს უჭერენ ერთსა და იმავე ინტერფეისს და კლიენტები შემთხვევით ნაწილდებიან სერვერებზე. ამ მეთოდის ფარგლებში შესაძლებელი ხდება სერვერების პერიოდული გამოკითხვა, მათი მუშაობის ანალიზი და წარუმატებლობის შემთხვევაში ავტომატურად გამორთვა, რაც ზრდის სისტემის საერთო ხარვეზების ტოლერანტობას. ამ მეთოდს ასევე შეუძლია კლიენტის ავთენტიფიკაციის მხარდაჭერა. მაგალითად, სერვერმა შეიძლება განსაზღვროს, რომ მისი გამოყენება მხოლოდ კლიენტებს შეუძლიათ კონკრეტული სიიდან.

თუმცა, დინამიურ დაკავშირებას აქვს უარყოფითი მხარეები, როგორიცაა დამატებითი ზედნადები (დრო) ინტერფეისების ექსპორტისა და იმპორტისთვის. ამ ხარჯების სიდიდე შეიძლება იყოს მნიშვნელოვანი, რადგან კლიენტის მრავალი პროცესი არსებობს მოკლე დროში და ყოველ ჯერზე, როდესაც პროცესი იწყება, ინტერფეისის იმპორტის პროცედურა ხელახლა უნდა განხორციელდეს. გარდა ამისა, დიდ განაწილებულ სისტემებში, ბაინდერის პროგრამა შეიძლება გახდეს ბოსტნეული და რამდენიმე პროგრამის მსგავსი მიზნის შექმნა ასევე ზრდის პროცესების შექმნისა და სინქრონიზაციის ხარჯებს.

RPC სემანტიკა წარუმატებლობის შემთხვევაში

იდეალურ შემთხვევაში, RPC სწორად უნდა ფუნქციონირებდეს წარუმატებლობის შემთხვევაშიც კი. განვიხილოთ წარუმატებლობის შემდეგი კლასები:

კლიენტი ვერ იპოვის სერვერს, მაგალითად, თუ სასურველი სერვერი ვერ ხერხდება, ან იმის გამო, რომ კლიენტის პროგრამა დიდი ხნის წინ იყო შედგენილი და გამოიყენებოდა სერვერის ინტერფეისის ძველი ვერსია. ამ შემთხვევაში კლიენტის მოთხოვნის პასუხად მიიღება შეცდომის კოდის შემცველი შეტყობინება. კლიენტის მოთხოვნა სერვერზე დაიკარგა. უმარტივესი გამოსავალი არის მოთხოვნის გამეორება გარკვეული დროის შემდეგ. საპასუხო შეტყობინება სერვერიდან კლიენტისთვის დაიკარგა. ეს ვარიანტი უფრო რთულია, ვიდრე წინა, რადგან ზოგიერთი პროცედურა არ არის უიმედო. იდემპოტენტური პროცედურა არის პროცედურა, რომლის შესრულების მოთხოვნა შეიძლება რამდენჯერმე განმეორდეს შედეგის შეცვლის გარეშე. ასეთი პროცედურის მაგალითი იქნება ფაილის წაკითხვა. მაგრამ საბანკო ანგარიშიდან გარკვეული თანხის ამოღების პროცედურა არ არის იდემპოტენტური და თუ პასუხი დაიკარგება, განმეორებით მოთხოვნამ შეიძლება მნიშვნელოვნად შეცვალოს კლიენტის ანგარიშის მდგომარეობა. ერთ-ერთი შესაძლო გამოსავალია ყველა პროცედურების უკმარისობა. თუმცა, პრაქტიკაში ეს ყოველთვის არ არის შესაძლებელი, ამიტომ შეიძლება სხვა მეთოდის გამოყენება - კლიენტის ბირთვის მიერ ყველა მოთხოვნის თანმიმდევრული ნუმერაცია. სერვერის ბირთვი ახსოვს თითოეული კლიენტის უახლესი მოთხოვნის რაოდენობას და ყოველი მოთხოვნის მიღებისთანავე აანალიზებს, არის ეს მოთხოვნა პირველადი თუ განმეორებითი. სერვერი გაფუჭდა მოთხოვნის მიღების შემდეგ. აქ ასევე მნიშვნელოვანია იდემპოტენციის თვისება, მაგრამ, სამწუხაროდ, შეკითხვის ნუმერაციის მიდგომის გამოყენება შეუძლებელია. ამ შემთხვევაში მნიშვნელობა აქვს

Java RMI, როგორც დისტანციური პროცედურის ზარის ტიპი, დამოუკიდებელი ქსელისგან, მასთან მუშაობის ძირითადი საფეხურებისგან და მისი მიზნისგან. განაწილებული და არაგანაწილებული Java პროგრამების შედარება. Java RMI-ის არქიტექტურა, ჩონჩხი და ჩონჩხი, დისტანციური საცნობარო და სატრანსპორტო ფენები.

SQL მოთხოვნების წინასწარ შედგენა აღსრულების ადგილზე. მომზადება განაცხადის გამოყენება. გამოიყენეთ ზარის განსაზღვრის სინტაქსი პროცედურის ან ფუნქციის დაბრუნების მნიშვნელობის მისაღებად. მოთხოვნის შემთხვევაში ნიმუშის აღების ინსტრუქციების შექმნა.

სამუშაოს მიზანი და სქემა. შემადგენლობა და მონტაჟი. http პაკეტის პროცედურის სპეციფიკაცია.

პროცედურები და ფუნქციები შეიძლება განისაზღვროს, როგორც დახურული პროგრამის ერთეულები, რომლებიც ახორციელებენ გარკვეულ ალგორითმს. სინამდვილეში, პროცედურა ან ფუნქცია თითქმის პროგრამაა.

ავტომატური TCP/IP კონფიგურაცია, დინამიური კონფიგურაცია BOOTP-ის გამოყენებით. მოთხოვნა/პასუხის IP მისამართები, შეტყობინების დაკარგვა და ფორმატი, BOOTP ფაზები. DHCP პროტოკოლი არის BOOTP პროტოკოლის გაფართოება. IP მისამართების განაწილება და მინიჭება.

ჩვენ უკვე შეგვხვდა რეკურსიის ცნება: რეციდივის მიმართებები საკმაოდ ხშირად გვხვდება მათემატიკურ გამონათქვამებში. დეფინიციაში რეკურსია მდგომარეობს იმაში, რომ განსაზღვრული ცნება განისაზღვრება თავად ამ კონცეფციის მეშვეობით.

1. შესავალი 2 2. COM ტექნოლოგიის მიმოხილვა 2 2.1. COM ობიექტის შემადგენლობა 3 2.2. ინტერფეისები 4 2.3. COM ობიექტების თვისებები 6 2.4. COM სერვერები 6 2.5. მარშალინგის მექანიზმი 7

დისტანციური მონაცემთა ბაზების არსის, მოქმედების პრინციპისა და ძირითადი დანიშნულების შესწავლა. დისტანციური მონაცემთა მართვის მოდელი (ფაილის სერვერის მოდელი). პარალელიზმის სახეები. ტრიგერი არის სპეციალური მოვლენების თვალთვალის მექანიზმი, რომლებიც დაკავშირებულია მონაცემთა ბაზის მდგომარეობასთან.

მეტამოდელი, ფაქტი და უსაფრთხოების პაკეტები. კლიენტის კონცეპტუალური მოდელი. განაწილებული არქიტექტურის ფუნქციონირების მაგალითი. განხორციელების სირთულე.

Dll კონცეფცია. გავიხსენოთ პროგრამირების პროცესი DOS-ში. საწყისი ტექსტის მანქანურ კოდად გადაქცევა მოიცავდა ორ პროცესს: კომპილაციას და დაკავშირებას. დაკავშირების დროს პროგრამის კოდში განთავსდა არა მხოლოდ ფუნქციების და პროცედურების დეკლარაციები, არამედ მათი სრული კოდი.

TCP/IP პროტოკოლთან მუშაობის ფუნქციები, Socket, Bind, მოსმენა და მიღება. ფაილის აღმწერი. საკომუნიკაციო პროცესები. მონაცემების მიღება. კითხვა სოკეტიდან. ჩაწერეთ სოკეტში. სოკეტის დახურვა. პროგრამის ტექსტი, რომელიც ქმნის ვებ სერვერს QNX ოპერაციულ სისტემაში.

ქსელის მომხმარებლების წვდომა სერვერზე შენახულ ელექტრონულ შეტყობინებებზე. პროგრამის აღწერა, მარტივი ავთენტიფიკაცია, APOP და AUTH ავტორიზაცია. ფუნქციების განხორციელება, მომხმარებლის სახელმძღვანელო, პროგრამის მუშაობის ალგორითმები, გრაფიკული ინტერფეისი.

Turbo-Paskal პროგრამირების ენის ძირითადი ოპერატორების მუშაობის პრინციპი: დავალების ოპერატორი, ქეისის შერჩევა, უპირობო ნახტომი, მარყუჟი, დაჭერა, კომპოზიცია. ფუნქციისა და პროცედურის ფორმალური აღწერა და გამოძახება. მოთხოვნები ფაქტობრივი პარამეტრების ჩამონათვალისთვის.

Java სერვერების მუშაობის პრინციპი და დანიშნულება, მათი მნიშვნელობა ვებ სერვერების ფუნქციონირების გაზრდისა და მათი პროგრამირების გაუმჯობესებაში, გამოყენების უპირატესობები და უარყოფითი მხარეები. სერლეტების გამოძახების გზები ბრაუზერიდან და გვერდიდან. ჩაწერეთ და წაიკითხეთ სესიის ატრიბუტები.

Windows NT OS-ის არქიტექტურა. OS სტრუქტურა მიკროკერნელზე დაფუძნებული. Windows NT-ის დაცული ქვესისტემები.

ძირითადი შეტყობინებები განაწილებულ სისტემებში პრიმიტივების გადაცემისას. მიმართვის მეთოდები. ბლოკირებადი და არადაბლოკვის პრიმიტივები. ბუფერული და არაბუფერული პრიმიტივები.

აპლიკაციების სერვერი. კლიენტის ნაწილი.

ორი წლის წინ, AJAX იყო სიახლე (და თავად სიტყვა AJAX ჯერ არ იყო გამოგონილი). ახლა ვებ აპლიკაციები, რომელთა გვერდებიც განახლდება ფრენის დროს, დღის წესრიგშია. პირიქით: ძნელი წარმოსადგენია ზოგიერთი სერვისი AJAX-ის გარეშე.

სინტაქსი პროცედურის აღწერისა და გამოძახებისთვის. Პარამეტრები. პროცედურის აღწერისა და ზარის მაგალითი. პარამეტრების ტიპები. პროგრამა.

კლიენტ-სერვერის აპლიკაციებისთვის ძალიან მნიშვნელოვანი მექანიზმი უზრუნველყოფილია RPC ( დისტანციური პროცედურის ზარი). RPC შეიქმნა Sun Micrysystems-ის მიერ და არის ინსტრუმენტებისა და ბიბლიოთეკის ფუნქციების კოლექცია. კერძოდ, RPC-ზე მუშაობს NIS (Network Information System) და NFS (Network File System).

RPC სერვერი შედგება ისეთი პროცედურების სისტემისგან, რომელზედაც კლიენტს შეუძლია წვდომა სერვერზე RPC მოთხოვნის პროცედურების პარამეტრებთან ერთად გაგზავნით. სერვერი გამოიძახებს დანიშნულ პროცედურას და დააბრუნებს პროცედურის დაბრუნების მნიშვნელობას, ასეთის არსებობის შემთხვევაში. იმისათვის, რომ იყოს მანქანიდან დამოუკიდებელი, კლიენტსა და სერვერს შორის გაცვლილი ყველა მონაცემი გარდაიქმნება ეგრეთ წოდებულ გარე მონაცემთა წარმომადგენლობაში ( გარე მონაცემების წარმომადგენლობა, XDR). RPC ურთიერთობს UDP და TCP სოკეტებთან მონაცემთა XDR ფორმატში გადასატანად. Sun-მა RPC საჯარო დომენად გამოაცხადა და მისი აღწერა ხელმისაწვდომია RFC დოკუმენტების სერიაში.

ზოგჯერ RPC აპლიკაციებში ცვლილებები იწვევს ინტერფეისის ზარის პროცედურაში შეუთავსებლობას. რა თქმა უნდა, უბრალო ცვლილება გამოიწვევს სერვერის ავარიას ყველა აპლიკაციას, რომელიც ჯერ კიდევ ელოდება იმავე ზარებს. ამიტომ, RPC პროგრამებს აქვთ მინიჭებული ვერსიის ნომრები, რომლებიც ჩვეულებრივ იწყება 1-ით. RPC-ის ყოველი ახალი ვერსია აკონტროლებს ვერსიის ნომერს. ხშირად სერვერს შეუძლია ერთდროულად რამდენიმე ვერსია შესთავაზოს. კლიენტები ამ შემთხვევაში მიუთითებენ ვერსიის ნომერზე, რომლის გამოყენებაც სურთ.

RPC სერვერებსა და კლიენტებს შორის ქსელური კომუნიკაცია ცოტა განსაკუთრებულია. RPC სერვერი გთავაზობთ ერთ ან მეტ სისტემურ პროცედურას, ასეთი პროცედურების თითოეულ კომპლექტს ეწოდება პროგრამა ( პროგრამა) და ცალსახად იდენტიფიცირებულია პროგრამის ნომრით ( პროგრამის ნომერი). სერვისების სახელების სია ჩვეულებრივ ინახება /etc/rpc-ში, რომლის მაგალითი მოცემულია ქვემოთ.

მაგალითი 12-4. ნიმუში /etc/rpc ფაილი

# # /etc/rpc - სხვადასხვა RPC-ზე დაფუძნებული სერვისები # portmapper 100000 portmap sunrpc rstatd 100001 rstat rstat_svc rup perfmeter rusersd 100002 rusers nfs 100003 nfsprog 10punt0 yp show დაამონტაჟე ypbind 100007 walld 100008 rwall გამორთვა yppasswdd 100009 yppasswd bootparam 100026 ypupdated 100028 ypupdate

TCP/IP ქსელებში, RPC-ის ავტორებს წინაშე დგანან პროგრამის ნომრების საერთო ქსელის სერვისებზე გადატანის ამოცანა. თითოეული სერვერი უზრუნველყოფს TCP და UDP პორტს თითოეული პროგრამისა და თითოეული ვერსიისთვის. ზოგადად, RPC აპლიკაციები იყენებენ UDP-ს მონაცემების გადასაცემად და უბრუნდებიან TCP-ს, როდესაც გადასაცემი მონაცემები არ ჯდება ერთ UDP დატაგრამაში.

რა თქმა უნდა, კლიენტის პროგრამებს უნდა ჰქონდეთ გზა იმის გასარკვევად, თუ რომელი პორტი შეესაბამება პროგრამის ნომერს. ამისთვის კონფიგურაციის ფაილის გამოყენება ძალიან მოუქნელი იქნება; ვინაიდან RPC აპლიკაციები არ იყენებენ რეზერვებულ პორტებს, არ არსებობს გარანტია იმისა, რომ პორტი არ არის დაკავებული რომელიმე აპლიკაციის მიერ და ხელმისაწვდომია ჩვენთვის. აქედან გამომდინარე, RPC აპლიკაციები ირჩევენ ნებისმიერ პორტს, რომლის მიღებაც შეუძლიათ და დაარეგისტრირონ პორტმაპერ დემონი. კლიენტი, რომელსაც სურს დაუკავშირდეს სერვისს მოცემული პროგრამის ნომრით, პირველ რიგში მიმართავს პორტმაპერს, რათა გაარკვიოს სასურველი სერვისის პორტის ნომერი.

ამ მეთოდს აქვს მინუსი, რომ შემოაქვს ერთი მარცხის წერტილი, ისევე როგორც inetdდემონი თუმცა, ეს საქმე ცოტათი უარესია, რადგან პორტმაპერი მარცხის შემთხვევაში, პორტების შესახებ ყველა RPC ინფორმაცია იკარგება. ეს ჩვეულებრივ ნიშნავს, რომ თქვენ უნდა გადატვირთოთ ყველა RPC სერვერი ხელით ან გადატვირთოთ მანქანა.

Linux-ზე პორტმაპერს ეწოდება /sbin/portmap ან /usr/sbin/rpc.portmap. გარდა იმისა, რომ ის უნდა იყოს გაშვებული ქსელის გაშვების სკრიპტიდან, პორტმაპერს არ სჭირდება რაიმე კონფიგურაციის სამუშაო.

დისტანციური პროცედურების გამოძახება RPC დისტანციური პროცედურის ზარის კონცეფცია დისტანციური პროცედურული ზარის (RPC) იდეა არის კონტროლისა და მონაცემების გადაცემის ცნობილი და გასაგები მექანიზმის გაფართოება ერთ მანქანაზე გაშვებულ პროგრამაში კონტროლისა და მონაცემების ქსელში გადასაცემად. დისტანციური პროცედურების გამოძახების ხელსაწყოები შექმნილია განაწილებული გამოთვლის ორგანიზების გასაადვილებლად.RPC გამოყენების ყველაზე დიდი ეფექტურობა მიიღწევა იმ აპლიკაციებში, რომლებშიც არის ინტერაქტიული კომუნიკაცია დისტანციურ კომპონენტებს შორის მოკლე რეაგირების დროით და შედარებით მცირე რაოდენობით გადაცემული მონაცემებით.

ასეთ აპლიკაციებს უწოდებენ RPC-ზე ორიენტირებულს. ლოკალური პროცედურების გამოძახების დამახასიათებელი ნიშნებია ასიმეტრია, ანუ ერთ-ერთი ურთიერთქმედება არის ინიციატორი სინქრონიულობა, ანუ გამოძახების პროცედურის შესრულება ჩერდება მოთხოვნის გაცემის მომენტიდან და განახლდება მხოლოდ გამოძახებული პროცედურისგან დაბრუნების შემდეგ. დისტანციური ზარების განხორციელება ბევრად უფრო რთულია, ვიდრე ადგილობრივ პროცედურებზე ზარების განხორციელება.

დასაწყისისთვის, რადგან დარეკვის და გამოძახების პროცედურები შესრულებულია სხვადასხვა მანქანებზე, მათ აქვთ მისამართის სხვადასხვა სივრცე და ეს ქმნის პრობლემებს პარამეტრებისა და შედეგების გადაცემისას, განსაკუთრებით იმ შემთხვევაში, თუ მანქანები არ არის იდენტური. ვინაიდან RPC არ შეიძლება დაეყრდნოს საერთო მეხსიერებას, ეს ნიშნავს. რომ RPC პარამეტრები არ უნდა შეიცავდეს მითითებებს მეხსიერების არადაწყობის ადგილებზე და რომ პარამეტრის მნიშვნელობები უნდა დაკოპირდეს ერთი კომპიუტერიდან მეორეზე.

შემდეგი განსხვავება RPC-სა და ლოკალურ ზარს შორის არის ის, რომ ის აუცილებლად იყენებს საკომუნიკაციო სისტემას, მაგრამ ეს არ უნდა იყოს აშკარად ხილული არც პროცედურების განსაზღვრაში და არც თავად პროცედურებში. დისტანციურობა დამატებით პრობლემებს იწვევს. გამოძახების პროგრამის და გამოძახებული ლოკალური პროცედურის შესრულება ერთსა და იმავე მანქანაზე ხორციელდება ერთი პროცესის ფარგლებში, მაგრამ RPC-ის დანერგვა მოიცავს მინიმუმ ორ პროცესს - თითო თითოეულ მანქანაში.

ერთ-ერთი მათგანის ავარიის შემთხვევაში შეიძლება წარმოიშვას შემდეგი სიტუაციები: თუ გამოძახების პროცედურა ავარიულია, დისტანციურად გამოძახებული პროცედურები დარჩება ობოლი, ხოლო თუ დისტანციური პროცედურები ჩამოიშლება, გამოძახების პროცედურები ობოლი მშობლები გახდებიან, რომლებიც ამაოდ დაელოდებიან პასუხს. დისტანციური პროცედურებიდან. გარდა ამისა, არსებობს მთელი რიგი პრობლემები, რომლებიც დაკავშირებულია პროგრამირების ენების და ოპერაციული გარემოს არაერთგვაროვნებასთან, მონაცემთა სტრუქტურები და პროცედურების გამოძახების სტრუქტურები, რომლებიც მხარდაჭერილია რომელიმე პროგრამირების ენაზე, არ არის მხარდაჭერილი ერთნაირად ყველა სხვა ენაზე. ენები.

ეს და ზოგიერთი სხვა პრობლემა მოგვარებულია ფართოდ გავრცელებული RPC ტექნოლოგიით, რომელიც საფუძვლად უდევს ბევრ განაწილებულ ოპერაციულ სისტემას. ძირითადი RPC ოპერაციები იმისათვის, რომ გავიგოთ, როგორ მუშაობს RPC, ჯერ განვიხილოთ ლოკალური პროცედურის გამოძახება ჩვეულებრივ მანქანაზე, რომელიც მუშაობს ავტონომიურად. მოდით, იყოს, მაგალითად, სისტემური ზარების რაოდენობა წაკითხული fd, buf, nbytes სადაც fd არის მთელი რიცხვი, buf არის მასივი. სიმბოლოებიდან, nbytes არის მთელი რიცხვი.

ზარის განსახორციელებლად, გამოძახების პროცედურა უბიძგებს პარამეტრებს დასტაზე ნახაზი 3.1-ის საპირისპირო თანმიმდევრობით. წაკითხული ზარის შესრულების შემდეგ, ის ათავსებს დაბრუნების მნიშვნელობას რეესტრში, აბრუნებს დაბრუნების მისამართს და აბრუნებს კონტროლს გამოძახების პროცედურაში, რომელიც აბრუნებს პარამეტრებს დასტადან და აბრუნებს მას თავდაპირველ მდგომარეობაში. გაითვალისწინეთ, რომ C-ში, პარამეტრები შეიძლება ეწოდოს მითითებით ან სახელით, ან მნიშვნელობით. გამოძახებულ პროცედურასთან დაკავშირებით, მნიშვნელობის პარამეტრები არის ინიციალიზებული ლოკალური ცვლადები.

გამოძახებულ პროცედურას შეუძლია შეცვალოს ისინი გამოძახების პროცედურაში ამ ცვლადების თავდაპირველ მნიშვნელობებზე გავლენის გარეშე. თუ ცვლადის მაჩვენებელი გადაეცემა გამოძახებულ პროცედურას, მაშინ ამ ცვლადის მნიშვნელობის შეცვლა გამოძახებული პროცედურებით იწვევს ამ ცვლადის მნიშვნელობის შეცვლას გამოძახების პროცედურისთვის.ეს ფაქტი ძალიან მნიშვნელოვანია RPC-სთვის. ასევე არსებობს პარამეტრების გადაცემის სხვა მექანიზმი, რომელიც არ გამოიყენება C-ში. მას ეწოდება call-by-copy restore და გულისხმობს გამოძახებული პროგრამის კოპირებას ცვლადების დასტაზე მნიშვნელობების სახით და შემდეგ მათ უკან კოპირებას ზარის განხორციელების შემდეგ ორიგინალზე. გამოძახების პროცედურის მნიშვნელობები.

ბრინჯი. 3.1. a სტეკი წაკითხვის ზარის შესრულებამდე b სტეკი პროცედურის შესრულებისას c სტეკი გამოძახების პროგრამაში დაბრუნების შემდეგ იდეა RPC არის, რომ დისტანციურ პროცედურაზე ზარი გამოიყურებოდეს რაც შეიძლება მსგავსი ზარისთვის. ადგილობრივი პროცედურა. სხვა სიტყვებით რომ ვთქვათ, RPC გამჭვირვალობისთვის, გამოძახების პროცედურამ არ უნდა იცოდეს, რომ გამოძახებული პროცედურა სხვა მანქანაზეა და პირიქით, RPC აღწევს გამჭვირვალობას შემდეგი გზით.

როდესაც გამოძახებული პროცედურა რეალურად დისტანციურია, ლოკალური პროცედურის ნაცვლად, ბიბლიოთეკაში მოთავსებულია პროცედურის სხვა ვერსია, რომელსაც ეწოდება კლიენტის ნაკერი. ორიგინალური პროცედურის მსგავსად, სტუბი გამოიძახება გამოძახების თანმიმდევრობის გამოყენებით, როგორც სურათზე 3.1, და ხდება შეფერხება ბირთვზე წვდომისას. მხოლოდ, ორიგინალური პროცედურისგან განსხვავებით, ის არ ათავსებს პარამეტრებს რეგისტრებში და არ ითხოვს მონაცემებს ბირთვიდან; ამის ნაცვლად, ის ქმნის შეტყობინებას, რომელიც უნდა გაიგზავნოს დისტანციური აპარატის ბირთვში. RPC-ის შესრულების ეტაპები პროგრამული კომპონენტების ურთიერთქმედება დისტანციური პროცედურის გამოძახების შესრულებისას ილუსტრირებულია სურათზე 3.2. მას შემდეგ, რაც კლიენტის სათაური გამოიძახება კლიენტის პროგრამის მიერ, მისი პირველი ამოცანაა ბუფერის შევსება გაგზავნილი გზავნილით.

ზოგიერთ სისტემაში, კლიენტის შტაბს აქვს ერთი ფიქსირებული სიგრძის ბუფერი, რომელიც თავიდანვე ივსება ყოველი ახალი მოთხოვნით. სხვა სისტემებში შეტყობინებების ბუფერი არის ბუფერების აუზი ინდივიდუალური შეტყობინების ველებისთვის, რომელთაგან ზოგიერთი უკვე სავსეა.

ეს მეთოდი განსაკუთრებით შესაფერისია იმ შემთხვევებისთვის, როდესაც პაკეტს აქვს ფორმატი, რომელიც შედგება ველების დიდი რაოდენობით, მაგრამ ამ ველის მნიშვნელობები არ იცვლება ზარიდან ზარამდე. შემდეგ პარამეტრები უნდა გადაიზარდოს შესაბამის ფორმატში და ჩასვათ შეტყობინებების ბუფერში.ამ დროს შეტყობინება მზად არის გასაგზავნად, ამიტომ შესრულდება ბირთვის გამოძახების შეწყვეტა. ბრინჯი. 3.2. დისტანციური პროცედურის გამოძახება როდესაც ბირთვი აკონტროლებს, ის ცვლის კონტექსტს, ინახავს პროცესორის რეგისტრებს და მეხსიერების რუქის გვერდების სახელურებს და აყენებს მეხსიერების ახალ რუკას, რომელიც გამოყენებული იქნება ბირთვის რეჟიმში გასაშვებად. იმის გამო, რომ ბირთვი და მომხმარებლის კონტექსტი განსხვავებულია, ბირთვმა უნდა დააკოპიროს შეტყობინება ზუსტად მის მისამართთა სივრცეში, რათა შეძლოს მასზე წვდომა, დაიმახსოვროს დანიშნულების მისამართი და შესაძლოა სხვა სათაურის ველები და მან უნდა გადასცეს ის ქსელის ინტერფეისს.

ეს ასრულებს სამუშაოს კლიენტის მხარეს.

გადაცემის ტაიმერი ჩართულია და ბირთვს შეუძლია ან ციკლურად გამოკითხოს პასუხი ან გადასცეს კონტროლი განრიგს, რომელიც შეარჩევს სხვა პროცესს გასაშვებად. პირველ შემთხვევაში, შეკითხვის შესრულება დაჩქარებულია, მაგრამ მულტიპროგრამირება არ არის. სერვერის მხარეს შემომავალი ბიტები მოთავსებულია მიმღები აპარატურის მიერ ან ჩაშენებულ ბუფერში ან RAM-ში. როდესაც ყველა ინფორმაცია მიიღება, წარმოიქმნება შეფერხება.

შეფერხების დამმუშავებელი ამოწმებს პაკეტის მონაცემებს ვალიდობაზე და ადგენს, რომელ ნაკვთს უნდა გადასცეს იგი. თუ არცერთი ნაკვთი არ ელოდება პაკეტს, შეფერხების დამმუშავებელმა ან უნდა მოახდინოს ის ბუფერული ან საერთოდ გაუქმდეს. თუ არის ლოდინის პუნქტი, შეტყობინება კოპირდება მასში. დაბოლოს, შესრულებულია კონტექსტური გადართვა, რის შედეგადაც აღდგება რეგისტრები და მეხსიერების რუკა, იღებენ იმ მნიშვნელობებს, რაც მათ ჰქონდათ იმ მომენტში, როდესაც სტუბმა დარეკა მიიღო.

ახლა სერვერის ნაკერი იწყებს მუშაობას. ის ხსნის პარამეტრებს და სათანადოდ უბიძგებს მათ დასტაზე. როდესაც ყველაფერი მზად არის, კეთდება ზარი სერვერზე. პროცედურის დასრულების შემდეგ სერვერი გადასცემს შედეგებს კლიენტს, ამისათვის შესრულებულია ყველა ზემოთ აღწერილი ნაბიჯი, მხოლოდ საპირისპირო თანმიმდევრობით. ნახაზი 3.3 გვიჩვენებს ბრძანებების თანმიმდევრობას, რომელიც უნდა შესრულდეს თითოეული RPC გამოძახებისთვის, ხოლო ნახაზი 3.4 გვიჩვენებს, თუ რა პროპორცია იხარჯება RPC-ის შესრულების მთლიანი დროის რა წილი იხარჯება აღწერილ 14 საფეხურზე.

ტესტები ჩატარდა DEC Firefly მრავალპროცესორულ სამუშაო სადგურზე და მაშინ, როცა ხუთი პროცესორის არსებობა აუცილებლად იმოქმედებდა გაზომვების შედეგებზე, ფიგურაში ნაჩვენები ჰისტოგრამა იძლევა ზოგად წარმოდგენას RPC-ის შესრულების პროცესზე. ბრინჯი. 3.3. RPC პროცედურის ეტაპები ნახ. 3.4. დროის განაწილება RPC-ის შესრულების 14 ეტაპს შორის 1. გამოძახება სტუბი 2. მოამზადეთ ბუფერი 3. შეფუთეთ პარამეტრები 4. შეავსეთ სათაურის ველი 5. გამოთვალეთ საკონტროლო ჯამი შეტყობინებაში 6. შეწყვიტე ბირთვში 7. პაკეტის რიგი შესასრულებლად 8. შეტყობინების გადაცემა კონტროლერზე QBUS ავტობუსით 9. დროის გადაცემა Ethernet ქსელის მეშვეობით 10. პაკეტის მიღება კონტროლერიდან 11. შეფერხების დამუშავების პროცედურა 12. საკონტროლო ჯამის გაანგარიშება 13. კონტექსტის გადართვა მომხმარებლის სივრცეში 14. სერვერის ნაკერის შესრულება Dynamic Binding მოდით განვიხილოთ კითხვა, თუ როგორ განსაზღვრავს კლიენტი სერვერის ადგილმდებარეობას.

ამ პრობლემის გადაჭრის ერთ-ერთი მეთოდია კლიენტის პროგრამაში სერვერის ქსელის მისამართის პირდაპირ გამოყენება.

ამ მიდგომის მინუსი ის არის, რომ ის უკიდურესად მოუქნელია სერვერის გადაადგილებისას, სერვერების რაოდენობის გაზრდის ან ინტერფეისის შეცვლისას; ყველა ამ და სხვა მრავალ შემთხვევაში, აუცილებელია ყველა პროგრამის ხელახალი კომპილირება, რომლებიც იყენებდნენ სერვერის მყარ პარამეტრებს. ყველა ამ პრობლემის თავიდან აცილების მიზნით, ზოგიერთ განაწილებულ სისტემაში იყენებენ იმას, რასაც დინამიური კავშირი ეწოდება.

დინამიური დაკავშირების საწყისი წერტილი არის სერვერის სპეციფიკაციის ოფიციალურად განსაზღვრა. სპეციფიკაცია შეიცავს ფაილის სერვერის სახელს, ვერსიის ნომერს და ამ სერვერის მიერ კლიენტებისთვის მოწოდებული სერვისის პროცედურების ჩამონათვალს (სურათი 3.5). თითოეული პროცედურისთვის მოცემულია მისი პარამეტრების აღწერა, სადაც მითითებულია, არის თუ არა ეს პარამეტრი შემავალი ან გამომავალი სერვერთან შედარებით. ზოგიერთი პარამეტრი შეიძლება იყოს როგორც შემავალი, ასევე გამომავალი - მაგალითად, გარკვეული მასივი, რომელიც კლიენტის მიერ სერვერზე გაგზავნილია, შეცვლილია. იქ და შემდეგ დაბრუნდა კლიენტის ოპერაციის ასლის აღდგენაში. ბრინჯი. 3.5. RPC სერვერის სპეციფიკაცია სერვერის ფორმალური სპეციფიკაცია გამოიყენება, როგორც შეყვანის საშუალება ნაკერების გენერატორის პროგრამაში, რომელიც ქმნის როგორც კლიენტის, ასევე სერვერის ნაკერებს.

შემდეგ ისინი მოთავსებულია შესაბამის ბიბლიოთეკებში. როდესაც მომხმარებლის კლიენტის პროგრამა იძახებს სერვერის სპეციფიკაციაში განსაზღვრულ ნებისმიერ პროცედურას, შესაბამისი ნაკერი პროცედურა ასოცირდება პროგრამის ორობით კოდთან.

ანალოგიურად, სერვერის შედგენისას, მას უკავშირდება სერვერის ნაკერები. როდესაც სერვერი იწყება, მისი პირველივე მოქმედებაა მისი სერვერის ინტერფეისის გადატანა სპეციალურ პროგრამაზე, რომელსაც ეწოდება ბაინდერი. ეს პროცესი, რომელიც ცნობილია როგორც სერვერის რეგისტრაციის პროცესი, გულისხმობს სერვერის გადაცემას მისი სახელის, ვერსიის ნომრის, უნიკალური იდენტიფიკატორის და სერვერის მდებარეობის აღწერის შესახებ. აღმწერი სისტემა დამოუკიდებელია და შეიძლება იყოს IP, Ethernet, X.500 ან ზოგიერთი. სხვა მისამართი.

გარდა ამისა, ის შეიძლება შეიცავდეს სხვა ინფორმაციას, მაგალითად, ავთენტიფიკაციას. როდესაც კლიენტი პირველად იძახებს ერთ-ერთ დისტანციურ პროცედურას, მაგალითად, წაკითხვას, კლიენტის სტუბი ხედავს, რომ ის ჯერ არ არის დაკავშირებული სერვერთან და აგზავნის შეტყობინებას ბაინდერის პროგრამაში ინტერფეისის იმპორტის მოთხოვნით. სასურველი სერვერის სასურველი ვერსია. თუ ასეთი სერვერი არსებობს, მაშინ Binder აგზავნის აღწერს და უნიკალურ იდენტიფიკატორს კლიენტის ნაკვთისთვის.

მოთხოვნით შეტყობინების გაგზავნისას, კლიენტის ნაკერი იყენებს აღწერს მისამართად. შეტყობინება შეიცავს პარამეტრებს და უნიკალურ იდენტიფიკატორს, რომელსაც სერვერის ბირთვი იყენებს შემომავალი შეტყობინების სასურველ სერვერზე გადასატანად, თუ ამ მანქანაზე რამდენიმე მათგანია. ინტერფეისების იმპორტისა და ექსპორტის ეს მეთოდი ძალიან მოქნილია, მაგალითად, შეიძლება იყოს რამდენიმე სერვერი, რომელიც მხარს უჭერს ერთსა და იმავე ინტერფეისს და კლიენტები შემთხვევით ნაწილდება სერვერებს შორის.

ამ მეთოდის ფარგლებში შესაძლებელი ხდება სერვერების პერიოდული გამოკითხვა, მათი მუშაობის ანალიზი და წარუმატებლობის შემთხვევაში ავტომატურად გამორთვა, რაც ზრდის სისტემის საერთო ხარვეზების ტოლერანტობას. ამ მეთოდს ასევე შეუძლია კლიენტის ავთენტიფიკაციის მხარდაჭერა. მაგალითად, სერვერმა შეიძლება განსაზღვროს, რომ მისი გამოყენება მხოლოდ კლიენტებს შეუძლიათ კონკრეტული სიიდან. თუმცა, დინამიურ დაკავშირებას აქვს უარყოფითი მხარეები, როგორიცაა დამატებითი ზედნადები და ინტერფეისების ექსპორტზე და იმპორტზე დახარჯული დრო.

ამ ხარჯების სიდიდე შეიძლება იყოს მნიშვნელოვანი, რადგან კლიენტის მრავალი პროცესი არსებობს მოკლე დროში და ყოველ ჯერზე, როდესაც პროცესი იწყება, ინტერფეისის იმპორტის პროცედურა ხელახლა უნდა განხორციელდეს. გარდა ამისა, დიდ განაწილებულ სისტემებში, ბაინდერის პროგრამა შეიძლება გახდეს ბოსტნეული და მრავალი პროგრამის შექმნა ერთი და იგივე მიზნით, ასევე ზრდის პროცესების შექმნისა და სინქრონიზაციის ხარჯებს. RPC სემანტიკა წარუმატებლობის შემთხვევაში. იდეალურ შემთხვევაში, RPC სწორად უნდა ფუნქციონირებდეს იმ შემთხვევაში. წარუმატებლობის.

განვიხილოთ წარუმატებლობის შემდეგი კლასები: 1. კლიენტს არ შეუძლია სერვერის პოვნა, მაგალითად, თუ სასურველი სერვერი ვერ ხერხდება, ან იმის გამო, რომ კლიენტის პროგრამა შედგენილია დიდი ხნის წინ და იყენებდა სერვერის ინტერფეისის ძველ ვერსიას. ამ შემთხვევაში კლიენტის მოთხოვნის პასუხად მიიღება შეცდომის კოდის შემცველი შეტყობინება. 2. კლიენტისგან სერვერის მოთხოვნა დაიკარგა.უმარტივესი გამოსავალია მოთხოვნის გამეორება გარკვეული დროის შემდეგ. 3. სერვერიდან კლიენტისთვის გაგზავნილი პასუხი დაკარგულია.

ეს ვარიანტი უფრო რთულია, ვიდრე წინა, რადგან ზოგიერთი პროცედურა არ არის უიმედო. იდემპოტენტური პროცედურა არის პროცედურა, რომლის შესრულების მოთხოვნა შეიძლება რამდენჯერმე განმეორდეს შედეგის შეცვლის გარეშე. ასეთი პროცედურის მაგალითია ფაილის წაკითხვა, მაგრამ საბანკო ანგარიშიდან გარკვეული თანხის ამოღების პროცედურა არ არის უიმედო და პასუხის დაკარგვის შემთხვევაში, განმეორებით მოთხოვნამ შეიძლება მნიშვნელოვნად შეცვალოს კლიენტის ანგარიშის მდგომარეობა.

ერთ-ერთი შესაძლო გამოსავალია ყველა პროცედურების უკმარისობა. თუმცა, პრაქტიკაში ეს ყოველთვის არ არის შესაძლებელი, ამიტომ შეიძლება სხვა მეთოდის გამოყენება - კლიენტის ბირთვის მიერ ყველა მოთხოვნის თანმიმდევრული ნუმერაცია. სერვერის ბირთვი ახსოვს თითოეული კლიენტის უახლესი მოთხოვნის რაოდენობას და ყოველი მოთხოვნის მიღებისთანავე აანალიზებს, არის ეს მოთხოვნა პირველადი თუ განმეორებითი. 4. მოთხოვნის მიღების შემდეგ სერვერი გაფუჭდა, აქ ასევე მნიშვნელოვანია იდემპოტენციის თვისება, მაგრამ სამწუხაროდ მოთხოვნის ნუმერაციის მიდგომის გამოყენება შეუძლებელია.

ამ შემთხვევაში, მნიშვნელობა აქვს როდის მოხდა მარცხი - ოპერაციამდე თუ მის შემდეგ. მაგრამ კლიენტის ბირთვი ვერ ცნობს ამ სიტუაციებს; მან მხოლოდ იცის, რომ პასუხის დრო ამოიწურა. ამ პრობლემის სამი მიდგომა არსებობს: დაელოდეთ სერვერის გადატვირთვას და ხელახლა სცადეთ ოპერაცია. ეს მიდგომა უზრუნველყოფს RPC დასრულებას ერთხელ მაინც და შესაძლოა მეტიც. შეცდომის შესახებ დაუყოვნებლივ შეატყობინეთ აპლიკაციას.

ეს მიდგომა უზრუნველყოფს, რომ RPC შესრულდება მაქსიმუმ ერთხელ. მესამე მიდგომა არაფრის გარანტიას არ იძლევა. როდესაც სერვერი ვერ ხერხდება, კლიენტს მხარდაჭერა არ ეძლევა. RPC შეიძლება ან საერთოდ არ იყოს შესრულებული, ან შეიძლება მრავალჯერ შესრულდეს. ნებისმიერ შემთხვევაში, ამ მეთოდის განხორციელება ძალიან მარტივია. არცერთი ეს მიდგომა არ არის ძალიან მიმზიდველი და იდეალური ვარიანტი, რომელიც გარანტირებული იქნება ზუსტად ერთი RPC-ის შესრულების გარანტიით, ზოგად შემთხვევაში პრინციპული მიზეზების გამო ვერ განხორციელდება.

მაგალითად, დისტანციური ოპერაცია იყოს ტექსტის ბეჭდვა, რომელიც მოიცავს პრინტერის ბუფერის ჩატვირთვას და პრინტერის მართვის ზოგიერთ რეესტრში ერთი ბიტის დაყენებას, რის შედეგადაც პრინტერი იწყება. სერვერის ავარია შეიძლება მოხდეს როგორც მიკროწამში ადრე, ასევე მიკროწამში. საკონტროლო ბიტის დაყენების შემდეგ. წარუმატებლობის მომენტი მთლიანად განსაზღვრავს აღდგენის პროცედურას, მაგრამ კლიენტს არ შეუძლია გაარკვიოს წარუმატებლობის მომენტი.

მოკლედ, სერვერის ავარიის შესაძლებლობა რადიკალურად ცვლის RPC-ს ბუნებას და ნათლად ასახავს განსხვავებას ცენტრალიზებულ და განაწილებულ სისტემას შორის. პირველ შემთხვევაში, სერვერის ავარია იწვევს კლიენტის ავარიას და აღდგენა შეუძლებელია. მეორე შემთხვევაში, შესაძლებელია და აუცილებელია სისტემის აღდგენის მოქმედებების შესრულება. 1. კლიენტი მოთხოვნის გაგზავნის შემდეგ ჩამოვარდა. ამ შემთხვევაში გამოთვლები კეთდება იმ შედეგებზე, რომლებსაც არავინ ელოდება, ასეთ გამოთვლებს ობოლი გამოთვლები ეწოდება. ობლების არსებობამ შეიძლება გამოიწვიოს სხვადასხვა პრობლემები: CPU დროის ზედმეტად, რესურსების დაბლოკვა, მიმდინარე მოთხოვნაზე პასუხის ჩანაცვლება იმ მოთხოვნაზე პასუხით, რომელიც გაცემული იყო კლიენტის აპარატის მიერ სისტემის გადატვირთვამდე.

როგორ მოვიქცეთ ობლებს? მოდით შევხედოთ 4 შესაძლო გამოსავალს. განადგურება. სანამ კლიენტის სტუბი გაგზავნის RPC შეტყობინებას, ის აკეთებს ჩანაწერს ჟურნალში, სადაც მიუთითებს, თუ რას გააკეთებს შემდეგ. ჟურნალი ინახება დისკზე ან სხვა შეცდომის შემწყნარებ მეხსიერებაზე.

ავარიის შემდეგ სისტემა გადაიტვირთება, ჟურნალი გაანალიზებულია და ობლები აღმოიფხვრება. ამ მიდგომის ნაკლოვანებები მოიცავს, პირველ რიგში, გაზრდილ ხარჯებს, რომლებიც დაკავშირებულია თითოეული RPC დისკზე ჩაწერასთან და, მეორე, შესაძლო არაეფექტურობასთან დაკავშირებით, მეორე თაობის ობლების გამოჩენის გამო, რომლებიც წარმოიქმნება პირველი თაობის ობლების მიერ გამოშვებული RPC ზარებით. რეინკარნაცია.ამ შემთხვევაში ყველა პრობლემა წყდება დისკის ჩაწერის გამოყენების გარეშე. მეთოდი მოიცავს დროის დაყოფას თანმიმდევრულად დანომრილ პერიოდებად. როდესაც კლიენტი გადაიტვირთება, ის აგზავნის შეტყობინებას ყველა მანქანაზე, რომ გამოაცხადოს ახალი პერიოდის დაწყება.

ამ შეტყობინების მიღების შემდეგ, ყველა დისტანციური გამოთვლა აღმოიფხვრება. რა თქმა უნდა, თუ ქსელი სეგმენტირებულია, მაშინ ზოგიერთი ობოლი შეიძლება გადარჩეს. რბილი ხელახალი ინკარნაცია წინა შემთხვევის მსგავსია, გარდა იმისა, რომ ყველა წაშლილი გამოთვლა არ არის ნაპოვნი და განადგურებული, არამედ მხოლოდ გადატვირთვის კლიენტის გამოთვლები. ვადის გასვლა. თითოეულ მოთხოვნას ეძლევა დროის სტანდარტული პერიოდი T, რომლის განმავლობაშიც ის უნდა დასრულდეს.

თუ მოთხოვნა არ დასრულებულა დანიშნულ დროში, მაშინ გამოიყოფა დამატებითი კვანტი. მიუხედავად იმისა, რომ ეს მოითხოვს დამატებით მუშაობას, თუ კლიენტის ავარიის შემდეგ სერვერი კლიენტის გადატვირთვამდე ელოდება T ინტერვალს, მაშინ ყველა ობოლი აუცილებლად ნადგურდება. პრაქტიკაში არც ეს მიდგომაა სასურველი; სინამდვილეში, ობლების განადგურებამ შეიძლება გააუარესოს სიტუაცია. . მაგალითად, დავუშვათ, ობოლი დაბლოკილია მონაცემთა ბაზის ერთი ან მეტი ფაილი.

თუ ობოლი მოულოდნელად განადგურდა, მაშინ ეს საკეტები დარჩება, გარდა ამისა, განადგურებული ობლები შეიძლება დარჩნენ სხვადასხვა სისტემის რიგებში, მომავალში მათ შეიძლება გამოიწვიოს ახალი პროცესების შესრულება და ა.შ.

რას ვიზამთ მიღებულ მასალასთან:

თუ ეს მასალა თქვენთვის სასარგებლო იყო, შეგიძლიათ შეინახოთ იგი თქვენს გვერდზე სოციალურ ქსელებში:

RPC გამოყენების ყველაზე დიდი ეფექტურობა მიიღწევა იმ აპლიკაციებში, რომლებშიც არსებობს ინტერაქტიული კომუნიკაცია დისტანციურ კომპონენტებს შორისთან მოკლე რეაგირების დროდა გადაცემული მონაცემების შედარებით მცირე რაოდენობა.ასეთ აპლიკაციებს უწოდებენ RPC-ზე ორიენტირებულს.

ადგილობრივი პროცედურების გამოძახების დამახასიათებელი ნიშნებია:

ასიმეტრია,ანუ ერთ-ერთი ურთიერთდამოკიდებული მხარე არის ინიციატორი;

სინქრონულობა,ანუ გამოძახების პროცედურის შესრულება ჩერდება მოთხოვნის გაცემის მომენტიდან და განახლდება მხოლოდ გამოძახებული პროცედურის დაბრუნების შემდეგ.

დისტანციური ზარების განხორციელება ბევრად უფრო რთულია, ვიდრე ადგილობრივი პროცედურების ზარების განხორციელება.

1. დავიწყოთ იმით, რომ ვინაიდან გამოძახების და გამოძახების პროცედურები შესრულებულია სხვადასხვა აპარატებზე, ისინი აქვს სხვადასხვა მისამართების სივრცედა ეს ქმნის პრობლემები პარამეტრების და შედეგების გადაცემისას, განსაკუთრებით იმ შემთხვევაში, თუ მანქანები არ არის იდენტური.

ვინაიდან RPC არ შეიძლება დაეყრდნოს საერთო მეხსიერებას, ეს ნიშნავს RPC პარამეტრები არ უნდა შეიცავდეს მითითებებს მეხსიერების არადაწყობის ადგილებზეᲛერე რა პარამეტრის მნიშვნელობები უნდა დაკოპირდეს ერთი კომპიუტერიდან მეორეზე.

2. შემდეგი განსხვავება RPC-სა და ლოკალურ ზარს შორის არის ის აუცილებლად იყენებს საკომუნიკაციო სისტემას, თუმცა ეს არ უნდა იყოს ნათლად ხილული არც პროცედურების განსაზღვრაში და არც თავად პროცედურებში .

დისტანციურობა დამატებით პრობლემებს იწვევს. გამოძახების პროგრამის და გამოძახებული ლოკალური პროცედურის შესრულება იმავე მანქანაზე ფარგლებში განხორციელდამარტოხელა პროცესი. მაგრამ ჩართულია RPC-ის განხორციელებაშიმინიმუმ ორი პროცესი - თითო მანქანაში. თუ რომელიმე მათგანი ვერ ხერხდება, შეიძლება მოხდეს შემდეგი სიტუაციები:

თუ გამოძახების პროცედურა ავარიულია, დისტანციურად გამოძახებული პროცედურები „ობოლი“ გახდება და

თუ დისტანციური პროცედურები არანორმალურად შეწყდება, გამოძახების პროცედურები გახდებიან „გაჭირვებული მშობლები“ და დაელოდებიან დისტანციური პროცედურების პასუხს უშედეგოდ.

გარდა ამისა, არსებობს რიგი პრობლემები, რომლებიც დაკავშირებულია პროგრამირების ენების და ოპერაციული გარემოს არაერთგვაროვნებასთან : მონაცემთა სტრუქტურები და პროცედურების გამოძახების სტრუქტურები, რომლებიც მხარდაჭერილია რომელიმე პროგრამირების ენაზე, არ არის მხარდაჭერილი ერთნაირად ყველა სხვა ენაზე.

RPC აღწევს გამჭვირვალობას შემდეგი გზით. როდესაც გამოძახებული პროცედურა რეალურად არის დისტანციური, პროცედურის სხვა ვერსია, რომელსაც ეწოდება კლიენტის ნაკერი, განთავსებულია ბიბლიოთეკაში ლოკალური პროცედურის ნაცვლად. ორიგინალური პროცედურის მსგავსად, stub იწოდება გამოძახების თანმიმდევრობის გამოყენებით (როგორც სურათზე 3.1), და ხდება შეფერხება ბირთვზე წვდომისას. მხოლოდ, ორიგინალური პროცედურისგან განსხვავებით, ის არ ათავსებს პარამეტრებს რეგისტრებში და არ ითხოვს მონაცემებს ბირთვიდან; ამის ნაცვლად, ის ქმნის შეტყობინებას, რომელიც უნდა გაიგზავნოს დისტანციური აპარატის ბირთვში..

ბრინჯი. 3.2. დისტანციური პროცედურის ზარი

მოსწავლის ელექტრონული დღიური სამთავრობო სერვისების მეშვეობით როგორ შეხვიდეთ ელექტრონულ დღიურში

რა არის ელექტრონული დღიური როგორ შევიტანოთ ელექტრონული დღიური: ვიდეო

როგორ დარეგისტრირდეთ და შეხვიდეთ მოსწავლის ელექტრონულ დღიურში სახელმწიფო სერვისების მეშვეობით რამდენად სანდო და დროულია ინფორმაცია ელექტრონულ ჟურნალში?

ყველაზე საინტერესო რუსული ტექნიკური ინოვაციები