10 Тақырып. Процедуралардың қашықтықтан шақыртулары
Мақсаты: Процедуралардың қашықтықтан шақыртуларын талдау
Кілттік сөздер: түрлендіру, аутентификация, режим, қосымшалар, интерфейс, сервер, клиенттік қосымшалар, тапсырма, үдеріс, сегмент, код
Дәріс жоспары (2 сағат)
Бағдарламалаудың төменгі деңгейлі және жоғары деңгейлі интерфейсі.
XDR–түрлендірулер, аутентификация, кеңжолақты режим.
Үлестірілген қосымшаларды құру үшін DCOM және COBRA технологияларын қолдану. IDL интерфейсін сипаттау тілі.
SMB хаттамасы, оның тағайындалуы, Samba серверін және қолдану және клиенттік қосымшаларды пайдалану.
Желідегі жұмыста қауіпсіздікті қамтамасыз ету. Жергілікті компьютердегі жұмыста қауіпсіздікті қамтамасыз ету.
Жергілікті компьютерде және желіде қауіпсіздікті қамтамасыз ету құралдары.
Процедуралар мен тапсырмаларды шақыру құралдары
Операциялық жүйе тапсырмаларға операциялық жүйе үдерістерінің шақыру құралдарын қамтамасыз етеді. Ол сонымен бірге тапсырмаларды қосу үшін құралдары болу керек. Ал көп тапсырмалы жұмыста – тапсырмадан тапсырмаға жылдам қосылу құралдары болу қажет. Үдерісті шақыру тапсырманың қосылу айырмашылығында бірінші кезекте виртуалды адрес аралығының тапсырмасы сол күйінде қалады. Ал шақыру тапсырмасында бұл аралық өзгереді.
Процедураларды шақыру
Pentium процессорының қорғалған режимінде үдерістің шақырылуы код сегментіне ауыспай JMP және CALL командасы арқылы жүзеге асырылады.
Бағынбайтын сегменттен үдерісті тік шақыру. Бұл тәсіл жаңа код сегменті дескрипторына нұсқайтын селектордағы JMP және CALL командасы жолындағы нұсқаулардан тұрады. Бұл сегмент шақырылыатын үдеріс кодынан тұрады.
Бұл шақырылу Сурет 1-те көрсетілген. Осында және ары қарай виртуалды аралықтан тік адрес алу кезеңі көрсетілгген.
С=0 болғандағы шақырылатын сегмент бағынышты емес болып табылады. Ал шақыру рұқсат етіледі, егер шақырылатын кодтың артықшылық деңгейі шақырылатын сегмент артықшылық деңгейімен сәйкес келгенде ғана шақыруға рұқсат етіледі.
Сурет 1. Үдерістің тікелей шақырылуы.
Тыйым бiрiншi жағдайда қолданбалы бағдарламалардан кез келген ерекше құқықты процедуралардың шақыруынан ОЖ табиғи қорғау құралы болып табылады. ОЖ-ның қорғауының жүйесi абсолюттi болуы керек болатыны анық қосымша, өйткенi ОЖ жүйелiк шақыру iске асыратын нақтылы процедураларға айналу мүмкiндiгiн алуы керек. Бағынбайтын кодтық сегменттер көмегiмен оны жасау мүмкiн емес, онда бұл мәселенiң шешiмi үшiн басқа әдiстер бар болады - шақыруларды қол астындағы сегменттер және төменде қаралатын шлюздар.
Тыйым екiншi жағдайда осылай сезiледi: егер соңғы артықшылық төменде болса код басқа кодты шақыра алмайды. Бұл сырттай қарағанда оғаштанады. Артықшылықтардың деңгейi бiр жағынан қосымшаның кодқа қарағандағы жоғарынан басқару жүйесi бұл ережемен сәйкес бағынбайтын сегменттен қосымшасының кодын шақыра алмайды. Мәндер бойынша алайда, бұл тыйым Pentium процессорларының қорғау жүйесiнiң құрастыруын иерархиялық қағидасының жалпы көрiнiсi болып табылады - ерекше құқықты код, артықшылықтардың деңгейi, және бұл қағида аласалаулармен процедуралармен сенiмсiз жағдайларда пайдалана алмайды, процедураны шақырудың барлық әдiстерi үшiн сақталғанында емес, мәлiмет үшiн ғана емес.
Бағынышты сегменттен процедураны тік шақыру. Мысалы, процессор ОЖ қызметтерге қолданбалы бағдарламалары тиiстi жүйелiк шақырулар көмегiмен енгiзу-шығаруды орындауға рұқсат ала алу үшiн ОЖ-нiң модулдардың қауiпсiз шақыруына әдiс қолдануы керек. Бiрнеше әдiстердiң бар болу мүмкiндiгiнiң iске асырылуы үшiн, және солардың бiрi ОЖ-ның процедураларының (С=1 ) бағынышты сегментiнде орналастыру болып табылады. Қол астындағы сегмент (DPL CPL) артықшылықтардың деңгейiмен тең немесе аласалаулармен бағдарламалардың кодынан CALL немесе JMPнiң командаларындағы оның селекторын жөн-жоба арқылы шақыруға болады.
Шлюз арқылы жанама процедураны шақыру. Процедураны шақырудың екі әдісі қарастырылған жоғары жүйелiк шақыруларды iске асыру үшiн жақындамайтыны анық. Бiрiншi әдiсте бағынбайтын сегментте артықшылықтар жоғары деңгейлi болатын басқару жүйелерiнің процедурасының артықшылықтардың үшiншi деңгейi бар қолданбалы бағдарламасынан шақыруға негiзiнен мүмкiндiк бермейдi. Екiншi әдiс көмегiмен ОЖ-ның процедурасын шақыруға, қол астындағы сегментте бола алатын, дегенмен олар артықшылықтардың қолданбалы деңгейiмен орындалады және жүйелiк шақыруларды көпшiлiк үшiн керек жүйелiк мәлiметтерін ұсына алмайды. Pentium процессоры сондықтан iшкi программаны шақыруда тағы бiр әдiстi қолданады - қолданбалы кодтарға артықшылықтардың өз биiк деңгейiмен жұмыс iстейтiн ерекше құқықты процедуралар шақырылуға мүмкiндiк беретiн (шұра ) шлюз арқылы. Шақырудың шлюздары тағы бiр артықшылықтарға ие болады - шақырылатын процедураларда кiру нүктелерiнiң бақылауының мүмкiндiгi көрiнiп қалады. Демек, шамданған процедураның CALL командасында жылжуды дұрыс емес мәннiң тапсырмасының мүмкiндiгi бар болуға тап қалған жылжумен шақырылатын процедураға кiру нүктесiнiң адресіне екі әдіс қарастырылған, жоғары басқару тапсыруы керек командаға емес немесе тiптi команданың ортасында нәтижеде не бола алатыны анықталады. Шақырудың шлюздары осы кемшiлiктен еркiн.
Кiру нүктелерiнiң ерекше құқықты кодтық сегменттерi жиынмен алдын ала анықталады, және бұл кiру нүктелерi арнайы дескрипторлар көмегiмен суреттеледi - процедураны шақырудың шлюздарының дескрипторлары.
Процедураны шақыруды схема Сурет 2-да шлюз арқылы көрсетiлген.
Сурет 2. Шлюз арқылы программаны шақыру.
Шамданған және шақырылатын процедуралардың аралығында параметрлердi тапсыру мәселесі артықшылықтардың әр түрлi деңгейге ие болатын кодтардың шақыруында пайда болады. Процессорда оны шешiм үшiн артықшылықтардың әрбiр деңгейге, стекке әртүрлi деңгейлер, бiр-бiрленген стектерiнiң болуы ескерiлген. Демек, стек қолданылатын кодтық сегментпен CPL мәнiне кодтың сегменттiң артықшылықтарының ағымдағы деңгейiне әрдайым сәйкес келедi.
Тапсырмаларды шақыру.
Есептердiң арасындағы шақыруды тетiк ауыстырып қосуда процедураны шақырудың тетiктен айырмашылығы болады. CALL командасының селекторы осы жағдайда TSS жүйелiк сегментi дескрипторға көрсетуi керек. Демек, TSS сегмент үзiлген кез келген уақыт есептерінде орындауын қалпына келтiруi үшiн керек мәлiметтi есептiң контекстi сақталады. Есептiң контекстi ашық файлдарға процессордың регистрлерiнiң мәнi, нұсқағыштар қосады және басқару жүйесі тәуелдi болатын кейбiр басқа айнымалы.
Қашықтатылған процедураны (RPC) шақыру
Қашықтатылған процедураны шақырудың тұжырымдамасы
Қашықтатылған процедураларды шақыру идеясы (Remote Procedure Call - RPC) бір машинада орындалатын, басқаруды және деректерді желі арқылы беретін жақсы танымал және түсінікті механизмнің кеңейтілуінен тұрады. Қашықтатылған процедуралар құралы өндірісте есептеуді бөліп беруді жеңілдетуге парналған. RPC қолданудың тиімділігі аз жауабымен қашықтатылған компоненттер мен аз мөлшерде берілетін деректер арасында интерактивті байланысы бар қосымшаларда болады. мұндай қосымшалар RPC- бағытталған деп аталады.
Локальді процедуралардың шақыруының ерекше белгiлерi:
Асимметриялылық, яғни өзара тараптардың бiрi бастаушы болса.
Синхрондылық, яғни сұрауды беру кезіндегі тоқтату мен шақыртылған процедураны жаңарту кезінде қайтарылғаннан кейін шақыртылатын процедураның орындалуы.
Қашықтатылған шақыртуларды орындау локальді шақыртуларды орындауға қарағанда әлдеқайда қиынырақ. Шақыратын және шақыртылатын процедуралар әртүрлі машинада орындалатынын ескеретін болсақ, онда олар адрестік кеңістіктен тұрады және бұл, әсіресе машиналар сәйкес келмесе параметр мен нәтижені беру кезінде қиындықтар тудырады. RPC бөлінген жадты есептей алмаса, бұл RPC параметрлері стекті емес жадтар ұяшықтарына сілтемеден тұруы керек және параметрлер мағынасы бір компьтерден екіншісіне көшірілуі керек екендігін білдіреді. RPC-тің локальді шақыртудан келесі айырмашылығы төмен орналасатын байланыс жүйесінде міндетті түрде қолдануы, бірақ бұл процедураны анықтау кезінде де, процедураның өзінде де анық көрінбеуі керек. Алшақтық қосымша кедергілер енгізеді. Бағдарламаны шақыруды және локальді процедураны шақыртуды бір машинада орындау бірыңғай процесс айналасында орындалады. Бірақ RPC-ді іске асыру кезінде екі процесс қатысады- бір-бірден әр машинада. Екеуінің біреуі авариялы тоқтатылған жағдайда келесі жағдайлар пайда болу мүмкін: шақыратын процедураның авариялық жағдайында қашықтатылған шақыртылған процедуралар «жетімсіреп» қалады, ал қашықтатылған процедуралдың авариялық аяқталу кезінде шақыратын процедуралар «ата-анасынан қаріп» болып қалады.
Одан басқа бағдарламалау тілінің біркелкі болмауіы мен операциялық ортасымен байланысты кез-келген бағдарламалау тілін қолдайтын деректер құрылымы және процедуралар шақыру құрылымы басқа тілдерде сияқты қолдамайтын кедергілер реті бар.
Осы және басқа кедергілер көптеген операциялық жүйелерді бөлу негізінде жататын RPC технологиясын кең көлемде таратуды шешеді.
RPC-дің базалық операциялары
RPC жұмысын түсіну үшін, ең алдымен, кәдімгі машинада орындалатын автономды жұмыс істейтін локальді процедураны шақыруды қарстырайық. Мысалы бұл жүйелік шақырту болсын
count=read (fd,buf,nbytes);
мұндағы fd –бүтін сан,
buf – символдар массиві,
nbytes –бүтін сан.
Шақыртуды жүзеге асыру үшін шақыратын процедура стектегі параметрді кері ретпен қозғайды. Read шақыруы орындалғаннан кейін ол бастапқы жағдайына келтіре отырып парметрден стек таңдайтын қайтарылатын мәнді регистрге орналастырады, қайтару адресін ауыстырады және шақыратын процедураның басқаруын қайтарады. С тілінде парметрлер шақыртылуы мүмкін немесе сілтеме (by name), мәні (by value) бойынша да шақыртылады. Шақырылатын процедураға қарағанда параметр-мәндер локальді айнымалыларға сәйкестендірілген болады. Шақыртылатын процедуралар оларды өзгерте алады және осы айнамалылар түпнұсқасының мәніне әсер етпейді.
Егер шақырылатын процедураға айнымалыға сілтеуіш берілсе, онда осы айнымалының мәнінің процедурамен өзгертілуі шақыратын процедура мен айнымалының мәнінің өзгертілуіне алып келеді. RPC үшiн бұл айғақ тiптi мағыналы. С тілінде қолданылмайтын параметрлерді берудің таға да басқа механизмдері бар. Ол call-by-copy/restore деп аталады және айнымалыларды мән түрінде стекке шақыратын бағдарламамен көшірудің қажеттілігінен тұрады.
Параметрлерді берудің қандай механизмін қолдану керектігін тілді құрастырушылармен шешіледі. Кейде бұл берілетін деректер типіне байланысты болып келеді. С тілінде, мысалы, бүтін және скалярлы деректер мән бойынша беріледі, ал массивтер сілтеме бойынша.
RPC негізіне жататын идея қашықтатылған процедураны шақырудың локальді процедураға ұқсас болып көрінуінде. Басқаша айтқанда – RPC-ді мөлдір етіп көрсетуінде.
RPC мөлдірлікке келесі жолдармен жетеді. Шақырылатын процедура шынымен де қашықтатылған болса кітапханаға локальді процедура орнына клиенттік стаб (stub - заглушка) деп аталатын процедураның басқа түрі орналасады. Түпнұсқа процедураға ұқсас стаб реттелген шақырумен орындалады және де ядроға қарау үзілісі пайда болады. Бірақ түпнұсқа процедураға қарағанда ол параметрлерді регистрге орналастырмайды және ядродан деректер сұрастырмайды, оның орнына ол қашықтатылған машина ядросына жіберетін хабарлама құрастырады.
RPC орындау этаптары
Клиенттік стаб бағдарлама-клиентпен шақырылғаннан кейін оның бірінші мақсаты буферді жіберілген хабарламалармен толтыру болып табылады. Кейбір жүйелерде клиенттік стаб әр кез басынан жаңа сұраныс кеген сайын толтырылатын бекітілген ұзындықты жалғыз буферден тұрады. Басқа жүйелерде хабарлама буфері бөлек хабарламалар үшін өздерінің буферінің пулы болады, және де кейбір буферлер толтырылған болады. Бұл әдіс әсіресе үлкен сандар жолынан тұратын форматтан тұратын пакетке арналған, бірақ бұл жолдар мәні шақыртудан шақыртуға өзгермейді. Содан кейін параметрлер сәйкес келген форматқа ауысу керек және хабарлама буферына қойылуы керек. Осы мезетте хабарлама жіберілуге дайын, сол үшін ядроның шақырылуы тоқтатылады.
Ядро басқару алғанда ол контексті қайта қосады, процессордың регистрлерін және карталық жадты сақтайды.(беттердің дескрипторы), ядроның режимінде жұмыс жасайтын жаңа карта жадын орналастырады. Ядроның және қолданушлық контекстісі ерекшелінеді, оған рұқсаты бар ядро өзінің адрестік кеңістігіне хабарламаны көшіру керек,тағайындалған адресті сақтау және желілік интерфейске жіберу керек. Осымен клиенттің жағында жұмыс істеу бітеді. Жіберу таймері қосылады және ядро циклдік сұраудың жауабы болуы немесе жоспарлау басқаруына,яғни қандай да бір басқа үрдістің орындалуын таңдайды. Бірінші жағдайда сұраныстың жіберілуі тездетіледі, бірақ мультипрограммирование болмайды.Сервердің жағында түсуші биттер қабылдайтын құрылғыларға орналастырылған буферге немесе оперативті жадқа орналастырылады. Барлық ақпарат келген кезде үзулер генерацияланады. Өңдеуші үзулердің деректер пакетінің дұрыстығын тексереді және қандай стабқа жіберілетінің анықтайды. Егерде стабтардың ешқайсысы осы пакетті күтпесе,онда өңдеуші буферге орналастыру керек немесе одан бас тарту керек. Егер күтуші стаб болса, онда хабарлама соған көшіріледі. Әйтеуір контекстердің ауысуы орындалады,нәтижесінде регистрлер және жад картасы қалпына келгенде, стаб receive шақыру жасайды.
Енді серверлік стаб жұмысты бастайды. Ол параметрлерді ашады және оларды керекті түрде стекқа орналастырады. Барлығы дайын болған соң, сервердің шақырылуы орындалады. Процедура орындалғаннан кейін нәтижесін сервер клиентке жібереді. Ол үшін барлық көрсетілген деңгейлер кері тәртіпте орындалады.
RPC орындалуынның арасында 14 деңгейінің бөліну уақыты.
1. Стабтың шақырылуы
2. Буферді дайындау
3. Параметрлерді қаптау
4. Тақырып жолын толтыру
5.Хабарлманың бақылау сомасын есептеу
6. Ядролық үзулер
7.Пакеттердің орындалу кезектері
8. QBUS шинасының контроллерге хабарлама жіберу
9. Ethernet желісі бойынша жәберу уақыты
10. Контроллерден пакет алу
11.Үзулердің өңдеу процедурасы.
12.Бақылау соммасын анықтау
13. Контесктің қолданушының кеңістігіне ауысуы
14. Серверлік стабтың орындалуы
Динамикалық байланыстыру
Клиент сервердің орналасуын қалай береді екені туралы сұрақты қарастырамыз. Осы мәселенің шешу тәсілдерінің бірі клиенттік бағдарламада сервердің желілік адресінің тікелей қолдануы. Осы қатынастың кемшілігі оның төтенше иілмеушілігі:сервердің орын ауыстыруы немесе серверлердің сандардың өсуі,интерфейстің өзгеруі осы және басқа жағдайларда барлық бағдарламаны қайтадан компилирлеу,серверлік адрестің қатаң тапсырмасын орындау.Осы мәселерді болдырмау үшін кейбір таратылған жүйелерде динамикалық байланыстыру қолданылады.
Динамикалық байланыстыру үшін бастапқы мезеті сервердің формальді анықтамасы (спецификациясы) болып табылады. Спецификация файл-сервердің аты,версияның нөмері және қызмет-процедурасының тізімі құрамында бар берілген сервердің клиентке берілуі.
Серверге берілген кіріс немесе шығыс параметрлерге қатысты әрбір процедура үшін оның парамерлерінің суреттелуі беріледі. Кейбір параметрлер бір уақытта кіріс және шығыс болуы мүмкін,мысалы кейбір массивті клиент серверге жібереді,сол жерде модифицирленеді содан кейін клиентке қайтарылады.
Сервердің формальді спецификациясы стабтың бағдарлама-генераторы үшін шығыс деректері сияқты орындалады,клиенттік және серверлік стаб құрады.
Содан кейін олар сәйкес кітапханаларға орналастырады. Қолданушылық бағдарлама әртүрлі процедураларды шақырады,спецификацияның сервері сәйкес келген стаб-процедурасы екілік кодпен байланысады. Сервер компиляцияланған кезде серверлік стабтармен байланысады.
Серверді жүктегенде ең бірінші – өзінің серверлік интерфейсін арнайы, яғни binder'ом бағдарламасында іс әрекетін бастайды. Бұл процесс - серверді тіркеу:сервер өз атын беруді,версия нөмірінлерін,мінсіз идентификаорды және сервер орналасқан жерді сипаттаушыны қосатын үрдісі ретінде танымал.
Сипаттаушы жүйеге тәуелсіз және IP, Ethernet, X.500 немесе тағы қандай да бір адрес болуы мүмкін. Сондай-ақ ол басқа да информация сақтай алады, мысалға, аутентификацияға жататын.
Клиент өшірілген процедураны бірінші рет шақырғанда, мысалға read, клиенттік стаб серверге қосылмағаннын көреді де binder-бағдарламасына қажет сервердің қажет нұсқасыен интерфейстің импортталуын сұрап хабарлама жібереді. Егер ондай сервер жоқ болса, binder- бағдарламасы клиенттік стабқа анықтауышты және ерекше идентификаторды жібереді.
Клиенттік стаб сұраныспен хабарламаны жибергенде анықтаушыны адрес ретінде қолданады. Хабарлама қажет серверге келіп түскен хабарламаларды қайта жіберу үшін қолданатын ядро серверінің параметрлері мен ерекше идентификаторынан турады.
Интерфестердің импорты мен экспортына негізделген бұл әдіс жоғары иілгіштікке ие. Мысалы, бір ғана интерфейсті қолдайтын бірнеше серверлер болуы мүмкін. Бұл әдісте серверлерге мерзімді сұраныс жүргізуге және жұмыс қабілетін талдауға мүмкіндік береді, егер сервер қарсы болса, автоматты сөнуін және жүйенің төзімділікке қарсылығын арттырадды. Бұл әдіс соымен қатар клиентті аутентификацияны қолдайды. Мысалы, сервер тізімнен таңдалған бір клиентпен қолданатынын анықтауына болады.
Бірақ динамикалық байланыстың айтарлықтай кемшіліктері бар, мысалы, интерфейстердің экспорты мен импортыа арналған қосымша және уақытша шығындардың болуы.
Осы шығындардың біршама өсуі маңызды болуы мүмкін, себебі клиенттік үрдістер уақытша болғандықтан, интерфейс импортының процедура процессі іске қосылғанда қайта орындалуы қажет. Соынмен қатар, көптеген лестірілген жүйелерде binder бағдарламасы тар орында болуы мүмкін, ал бірнеше бағдарламалардың құрылуы үрдістердің құрылуына және синхрондалуына арналған қосымша шығындардың артуына алып келуі мүмкін.
Қарсылық жағдайындағы RPC семантикасы
Идеалды RPC қарсылық жағдайында дұрыс қызмет атқару керек.
Келесі қарсылық класстарын қарастырып көрейік:
Клиент сервердің тұрақты орнын анықтай алмайды, мысалы, қажет сервердің қарсылық жағдайында немесе клиенттің бағдарламасы бұрын жинақталған болса және сервердің ескі нұсқасын қолданған болса. Осы жағдайда қателік коды бар хабарлама сұраныс жіберге клиентке жауап ретінде келеді.
Сұраныс клиенттен серверге жоғалған.Ең қарапайым шешімі – уақыт өткеннен кейін сұранысты қайталау.
Серверден клиентке жауап хабарлама жоғалаған. Бұл нұсқасы алдыңғыдан қиынырақ, өйткені кейбір процедуралар идемпотентті болмайды. Идомпентеті процедура деп бірнеше рет қайталана алатын сұраныс және нәтижесі өзгермейді. Осыған мысал ретінде файлдардың оқылуы жатады. Бірақ банктік шоттан кейбір соммалардың алынуы идемпотентті процедура болып табылмайды, ал егер суранысқа жауап қайтарылмаса немесе жоғалса онда клиенттің счетінің жағдайы өзгеруі әбден мүмкін. Бәрінен дұрыс шешім ол барлық процедураларды идемпотенттік түрге келтіру. Бірақ тәжірибе жүзінде бұл әдіс аса көп қолданылмайды, сондықтан көбінесе клиенттік ядролардың тізбектелген номірлеу әдісі қолданылады. Сервердің ядросы барлық сұраныстардағы клиенттердің ең соңғы нөмірлерін есте сақтайды және барлық сұраныстарды алған кезде мынадай анализ жасалынады: бұл сураныс бірінше ме ,әлде қайталанып келді ма? Сұраныстарды алғаннан кейін сервер аварияға ұшырады. Тіпті бұл жерде идемпотенттін құрамы да маңызды, бірақ сұраныстарды нөмірлеу әдісі қолданыла алмайды. Бұл жағдайда бас тарту қашан болғаны яғни операциядан кейін немесе операцияға дейін екенің көрсету маңызды болып табылады. Осы жағдайды клиенттік ядро қарастыра алмайды, өйткені оған жауаптың уақыты өтіп кеткені ғана белгілі. Осы ахуалға байланысты 3 әдіс бар:
Операцияның орындалуын қайта орындауын жүзеге асыру немесе сервердің қайта қосылуын күту. Бұл әдіс RPCтың бір немесе бірнеше рет орындалуын қамтамасыз етеді.
Қате туралы қосымшаға жедел хабарлама беру. Бұл әдіс RPCтың бір реттен кем орындалуын қамтамасыз етеді.
Үшінші әдіс ештене қамтамасыз етпейді. Егер сервер бас тартатын болса,онда клиенттке ешқандай көмек көрсетілмейді. Бұл жағдайда RPCтың орындалмауы мүмкін немесе бірнеше рет орындалуы мүмкін.
Қандай жағдай болмасын бұл әдісті іске асыру оңай. Бұл әдістердің ешқайсысы қолайлы болып табылмайды. Ал мінсіз нұсқасы RPC-тың бір рет орындалуын қамтамасыз етеді.
Осы жағдайларды бірде-біреуі қолданушыға ыңғайлы емес. RPC-тің біреуін орындауға кепілдік берген идеалды нұсқа принципті түрде жүзеге аспайды. егер, мысалы, қашықталған операция ретінде баспа жіберілген мәтінді алайық, ол принтер буферін іске қосып, басқарушы принтер регистірінің бір битін орнатады, нәтижесінде принтер сіке қосылады. Сервердіңапаттық жағдайы басқарушы бит орнатылған сәттен бастап болуы мүмкін. Өшу сәті жалпы процедураның қалпына келуін анықтайды, бірақ бұл жайлы клиент білмеуі мүмкін. Серверде авариялық жағдайдың болуы RPC табиғатын өзгертеді және орталықтандырылған жүйе мен үлестірілген жүйе арасындағы айырмашылықты көрсетеді. Бірінші жағдайда сервердің күйреуі клиенттің күйреуіне алып келеді және мүмкін еместі қалпына келтіреді. Екінші жағдайда жүйені қалпына келтіру іс-әрекеттірн орындау қажет.
Сұранысты жібергеннен кейін клиент аварияға ұшырады. бұл жағдайда ешкім күтпеген шешімнің есептелуі жүргізіледі. Бұл есептеулерді жетімдер деп атайды. Жетімдердің болуы көптеген ахуалдарға әкеп соғуы мүмкін: процессорлық уақыттын кемуі, қорлардың бұғатталуы, жауапты өзгерту және тағы да басқа ахуалдар.
Жетімдермен не істей аламыз:
Бұл сұраққа 4 шешім бар:
Жою. Клиентті стаб RPC –хабарламасын жібергенге дейін, ол қазір не істейтіні туралы журналға белгі қояды. Журнал орнықты дисктерде немесе басқа жадта сақтаады. Жүйе авариядан кейін қайта жүктеледі, журнал талданады және жетімдер жойылады. Осы жағдайдың кемшілігіне біріншіден әрбір RPC-нің дискке жазылуына байлансыты шығындардың көп болуы, екіншіден екінші ұрпақтың пайда болуынан тиімсіздіктің болу мүмкіндігі, олар бірінші ұрпақтың жетімдерімен берілген RPC-шақыртулар арқылы туады.
Түрлену. Бұл жағдайда барлық мәселелер жазбалардың дискке жазуын қолданбай-ақ шешіледі. Әдiс нөмерлелген мерзiмдерге уақыттың бөлуiнен тұрады. Клиент қайта жүктелген кезде барлық машиналарға жаңа мерзімнің басталғаны туралы хабарлайды. Осы хабарламаны алғаннан кейін барлық қашықталған есептер жойылады. Әрине, егер желі сегменттелген болса, онда бірнеше жетімдер қайта тууы мүмкін.
Жай түрлену алдыңғы әдіске ұқсайды, бірақ барлық жойылған есептер ізделініп жойылмайды, тек қана клиенттен қайта жүктелген есептер жойылады.
Мерзімнің аяқталуы. Әрбір сұранысқа Т уақытының стандартты кесіндісі беріледі, ол осы уақытта орындалып аяқталуы қажет. Егер сұраныс берілген уақытта орындалмаса, оған қосымша квант беріледі. Бұл қосымша жұмысты талап етеді, бірақ клиент авариясынан кейін сервер Т интервалында клиенттің қайта жүктелуіне дейін күтсе барлық жетімдер міндетті түрде жойылады.
Тәжірибеде осы әдістердің бірде біреуі қажет емес, сонымен қатар жетімдердің жойылуы жағдайды қиындатып жіберуі мүмкін. Мысалы жетімдер деректер базасының бір немесе бірнеше файлын блоктасын, содан кейін жетімдерді жойсақ, онда осы блоктар қалып қояды және жетімдер жүйенің әртүрлі кезегінде тұрады, келешекте осы жетімдер жаңа үрдістің орындалуын шақыруы мүмкін .
DCOM технологиясы
COM (Component Object Model – көп компонентті объектілер моделі)
- Windows технологияларының ішіндегі негізгілердің бірі.COM – бұл компоненттердің объектілі моделі.COM – технологиясы API – ді суреттеу кезінде және әртүрлі бағдарламалау ортасы мен әртүрлі тілдер объектілерін үйлестіру үшін қолданылатын екілік стандартты суреттеу үшін қолданылады.СОМ компоненттер мен приложениялар арасындағы қарым – қатынас моделін ұсынады.СОМ – технологиясы СОМ – объектілермен жұмыс жасайды.Объект СОМ серверінің бөлігі болып табылады.СОМ – объекттер Delphi визуалды кітапханасының объектілеріне ұқсас.VCL Delphi объектілеріне қарағанда СОМ-объектілерінің құрамында әдістер,қасиеттер және интерфейстер болады.Жай ғана СОМ-объектінің құрамында бір немесе бірнеше интерфейс болады.Егер интерфейстер бірнеше болса, онда олардың ішінде ұқсас функцияларды орындайтын көптеген әдістер болады. Интерфейсті жариялаудың құрамына оның әдістерін және қасиеттерін суреттеу кіреді бірақ оны жүзеге асыру кірмейді.Сонымен қатар интерфейсті жариялаған кезде оналты байттық сан көрсетілуі мүмкін, ол интерфейстің идентификаторы.Әр интерфейстің өзіндік көрсеткіші болады. СОМ – технологиясының екі ерекшелігі бар:
- СОМ – объектілерді құру бағдарламалау тіліне тәуелді емес.Осындай жолмен СОМ-объектілері кез – келген тілде жазылуы мүмкін.
- СОМ-объектілері Windows – қа арналған кез – келген бағдарламалау ортасында қолданылуы мүмкін.Осы орталардың құрамына келесілер кіреді: Delphi, Visual C++, C++Builder, Visual Basic және тағы басқалар.Microsoft фирмасы Windows операциялық жүйесін құрастырған кезде алдына қойған ең басты мақсаттарының бірі,Windows – та жұмыс істейтін әртүрлі бағдарламалардың бір – бірімен үйлесімділікте болуы.Бұл оңай емес мәселені шешудің алғашқылары алмастырулар буфері,бөлетін файлдар және мәліметтерді динамикалық алмастырулар технологиясы (Dynamic Data Exchange, DDE) болды.Осыдан кейін объектілерді енгізу және біріктіру технологиясы (Object Linking and Embedding, OLE) құрылды.Алғашқы нұсқасы OLE 1, құрамды құжаттарды құру үшін арналған.Бұл нұсқа жетілдірілмеген болып танылды.Оның орнына OLE 2 нұсқасы шығарылды.Жаңа нұсқасы әртүрлі бағдарламалардың бір – біріне өздерінің функцияларын ұсыну туралы сұрақтарды шешуге мүмкіндік берді.Бұл технология 1996 жылға дейін қолданылған.Одан кейін оның орнына ActiveX технологиясы келді. Оның құрамына автоматтандыру (OLE-автоматтандыру), контейнерлер, басқарушы элементтер, Web-технологиялар және т.б. кіреді.
Желідегі жұмыста қауіпсіздікті қамтамасыз ету
ДК ақпаратына рұқсатсыз кіру-онымен жасырын танысуды, өңдеуді, көшіруді, әр түрлі вирустарды,оның ішінде, бүлдіруші бағдарламалық өнімдерді, сондай-ақ ақпаратқа шығудың белгіленген ережелеріне қайшы келетін ақпарат өзгертуді немесе оны жоюды айтамыз.
ДК қорғау үшін сақталған ақпарат қауіпсіздігін қамтамасыз ету мүмкіндігін кеңітетін әр түрлі бағдарламалық әдістер қолданылады. Стандартты дербес компьютерді қорғау құралдарының ішінде кең таралғандары:
Парольдік ұқсастыруды (идентификацияны) пайдаланып, мүмкіндік ресурстарын қорғау құралдары.
Әр түрлі ақпаратты шифрлау әдістерін қолдану.
Компьютерлік вирустардан қорғау және архив құру.