Распределенные вычисления: технология Microsoft RPC. Часть1: Учебное пособие

Ф Е Д Е РАЛ Ь Н О Е АГ Е Н С Т В О П О О БРАЗО В АН И Ю РФ В О РО Н Е Ж С К И Й Г О С У Д АРС Т В Е Н Н Ы Й У Н И В Е РС И Т Е Т

Распред ел енныевычисл ения: технол огия Microsoft RPC У чебноепособиепо специал ьности 230201 (071900) «И нф орм ационныесистем ы и технологии» Д С .09

Ч асть1

В О РО Н Е Ж 2005

2

У тверж д ено Н ау чно-м етод ическим советом В оронеж ского у ниверситета П ротокол № 12 от18.02.2005 г.

С оставител ьФ ертиковВ .В .

П особие под готовл ено накаф ед ре инф орм ационных систем ф аку л ьтетаком пью терных нау к В оронеж ского госу д арственного у ниверситета. Реком енд у ется д л я использования сту д ентам и 4 ку рсад невного отд ел ения вкачестве у чебных м атериаловнапрактических занятиях по ку рсу «Распред ел енныесистем ы вычисл ений » .

3

К о нцеп ци я у д а л енно го вы зо ва п ро цед у р Распред ел енные вычисл ения им ею т д ел о с понятиям и бол ее высокого у ровня, чем ф изические носител и, каналы связи и м етод ы перед ачи по ним сообщ ений . Распред ел енная сред а д ол ж на д ать пол ьзовател ям и прил ож ениям прозрачный д осту п к д анным , вычисл ениям и д ру гим ресу рсам вгетерогенных систем ах, пред ставл яю щ их собой набор сред ств разл ичных производ ител ей . С тратегические архитекту ры каж д ого кру пного систем ного производ ител я базиру ю тся сей час натой ил и иной ф орм е распред ел енной вычисл ител ьной сред ы (Distributed Computing Environment – DCE). К лю чом к поним анию выгод ы такой архитекту ры является прозрачность. П ол ьзовател и не д ол ж ны тратить свое врем я напопытки выяснить, гд е наход ится тот ил и иной ресу рс, аразработчики не д ол ж ны писать код ы д л я своих прилож ений , использу ю щ ие м естопол ож ениевсети. Х орош о известный м еханизм д л я реал изации распред ел енных вычисл ений , в ы зов уд а лен н ы х процед ур (Remote Procedure Call – RPC), расш иряеттрад иционну ю м од ел ь програм м ирования – вызовпроцед у ры – д л я использования всети. RPC м ож ет составл ять основу распред ел енных вычисл ений . В каж д ом вызовеу д ал енной процед у ры у частву ю тд вестороны: активный клиен т , который отправл яет запрос вызовапроцед у ры насервер, и с ерв ер, который отправл яет кл иенту ответ. С л ед у ет им еть ввид у , что терм ины «кл иент» и «сервер» вд анном сл у чае относятся к опред ел енной транзакции. К онкретное програм м ное обеспечение (процесс ил и програм м а) м огу тработатькак врол и кл иента, так и врол и сервера. Н аибол ьш ая э ф ф ективность использования RPC д остигается в тех прил ож ениях, вкоторых су щ еству етинтерактивная связь м еж д у у д ал енным и ком понентам и с небол ьш им врем енем ответови относител ьно м ал ым кол ичеством перед аваем ых д анных. Т акие прилож ения называю тся RPCориентированным и. Х арактерным и чертам и вызовалокальных процед у р явл яю тся а с им мет ричн ос т ь (то есть од наиз взаим од ей ству ю щ их сторон явл яется инициатором ) и с ин х рон н ос т ь (то естьвыпол нениевызываю щ ей процед у ры приостанавл ивается с м ом ентавыд ачи запросаи возобновл яется тол ько посл е возвратаиз вызываем ой процед у ры). П од обным и свой ствам и обл адает и у д ал енный вызов: процесс кл иентаотправляет серверу сообщ ение, вкоторое вклю чены парам етры вызываем ой процед у ры и ож ид ает ответного сообщ ения с резу л ьтатам и ее работы. П ри пол у чении ответарезу л ьтат считывается, и процесс прод ол ж ает работу . С о стороны серверапроцесс-обработчик вызововнаход ится всостоянии ож ид ания и при посту пл ении сообщ ения считываетпарам етры процед у ры, выпол няет ее, отправл яет ответ и становится всостояние ож ид ания сл ед у ю щ его вызова. Н еобход им о зам етить, од нако, что протокол RPC ненакл ад ываеткаких-л ибо требований над опол нител ьныесвязи м еж д у процессам и и нетребу ет синхронности выпол няем ых ф у нкций , т. е. вызовы м огу тбытьасинхронным и и взаим но независим ым и, так что кл иент во врем я ож ид ания ответам ож ет выпол нять д ру гие процед у ры. С ервер RPC м ож ет выд ел ять д л я каж д ой ф у нкции

4

отд ел ьный процесс ил и вирту альну ю м аш ину , поэ том у , не д ож ид аясь окончания работы пред ыд у щ их запросов, сразу ж ем ож етприним атьсл ед у ю щ ие. П ротокол RPC м ож ет испол ьзовать нескол ько разл ичных транспортных протоколов. В обязанности RPC-протокол авход ит тол ько обеспечение станд артови интерпретация перед ачи сообщ ений . Д остоверность и над еж ность перед ачи сообщ ений цел иком обеспечивается транспортным у ровнем . О д нако RPC м ож етконтрол ировать выбор и некоторые ф у нкции транспортного протокол а. RPC никогд ане д у бл иру ет ф у нкции транспортных протоколов. Е сл и, наприм ер, RPC работает поверх TCP, все заботы о над еж ности и д остоверности соед инения RPC возл агаетнаTCP. Е сл и протокол RPC у становл ен поверх UDP, он м ож етобеспечивать д опол нител ьные собственные ф у нкции обеспечения гарантированной д оставки сообщ ений . И д ея, пол ож енная воснову RPC, состоит втом , чтобы сд ел ать вызову д ал енной процед у ры выгл яд ящ им по возм ож ности так ж е, как и вызовл окальной процед у ры. Д ру гим и словам и – сд ел ать RPC прозра чн ы м : вызываю щ ей процед у ренетребу ется знать, что вызываем ая процед у ранаход ится над ру гой м аш ине, и наоборот. Реал изация у д ал енных вызововсу щ ественно слож нее реал изации вызововлокал ьных процед у р. Н ачнем с того, что поскол ьку вызываю щ ая и вызываем ая процед у ры выпол няю тся наразных м аш инах, то они им ею тразные ад ресные пространства, и э то созд ает пробл ем ы при перед ачепарам етрови резу л ьтатов, особенно есл и м аш ины неид ентичны. Так как RPC нем ож етрассчитывать наразд ел яем у ю пам ять, то э то означает, что парам етры RPC не д ол ж ны сод ерж ать у казател ей наячей ки нестековой пам яти и что значения парам етров д ол ж ны копироваться с од ного ком пью теранад ру гой . С л ед у ю щ им отл ичием RPC от л окал ьного вызоваявл яется то, что он обязател ьно использу ет ниж ел еж ащ у ю систем у связи, од нако э то нед олж но бытьявно вид но ни вопред ел ении процед у р, ни всам их процед у рах. У д аленность вносит д опол нител ьные пробл ем ы. В ыпол нение вызываю щ ей програм м ы и вызываем ой л окал ьной процед у ры вод ной м аш инереал изу ется врам ках ед иного процесса. Н о вреализации RPC у частву ю т как м иним у м д вапроцесса– по од ном у вкаж д ой м аш ине. В сл у чае аварий ного заверш ения какого-л ибо из них м огу т возникну ть сл ед у ю щ ие ситу ации: при аварии вызываю щ ей процед у ры, у д аленно вызванные процед у ры стану т «осиротевш им и» , апри аварий ном заверш ении у д ал енных процед у р стану т «обезд ол енным и род ител ям и» вызываю щ ие процед у ры, которые бу д у т безрезу л ьтатно ож ид ать ответаот у д ал енных процед у р. Кром е того, су щ еству ет ряд пробл ем , связанных с неод нород ностью языковпрограм м ирования и операционных сред : стру кту ры д анных и стру кту ры вызовапроцед у р, под д ерж иваем ые вкаком -л ибо од ном языке програм м ирования, не под д ерж иваю тся точно так ж ево всех д ру гих языках. Т ехнология RPC реш ает э ти и некоторые д ру гие пробл ем ы, д остигая прозрачности пу тем вкл ю чения впроцесс взаим од ей ствия кл иентаи сервераспециальных програм м ных ком понентов, ст а бов (stub - загл у ш ка). В заим од ей ствие програм м ных ком понентовпри выпол нении у д ал енного вызовапроцед у ры ил л ю стриру ется рис. 1. К огд авызываем ая процед у рад ей ствител ьно явл яется у д ал енной , вбибл иотеку пом ещ ается вм есто л окал ьной процед у ры д ру гая вер-

5

сия процед у ры, называем ая кл иентским стабом . Зад ачазагл у ш ки – принять аргу м енты, пред назначаем ые у д ал енной процед у ре, преобразовать их в некий станд артный ф орм ат и сф орм ировать сетевой запрос. У паковкааргу м ентови созд аниесетевого запросаназывается сборкой (marshalling). П осл етого, как сообщ ениеготово к перед аче, выпол няется прерываниепо вызову яд раоперационной систем ы. К огд аяд ро пол у чает у правл ение, оно перекл ю чаетконтексты, сохраняетрегистры процессораи карту пам яти (д ескрипторы страниц), у станавл ивает нову ю карту пам яти, которая бу д ет испол ьзоваться д л я работы вреж им е яд ра. П оскол ьку контексты яд раи пол ьзовател я разл ичаю тся, яд ро д ол ж но точно скопировать сообщ ение всвое собственное ад ресное пространство, так, чтобы им еть к нем у д осту п, запом нить ад рес назначения (а, возм ож но, и д ру гие пол я заголовка), атакж е оно д ол ж но перед ать его сетевом у интерф ей су . Н аэ том заверш ается работанакл иентской стороне. В кл ю чается тай м ер перед ачи, и яд ро м ож етл ибо выпол нятьцикл ический опрос нал ичия ответа, л ибо перед атьу правл ениепл анировщ ику , который выбереткакой -л ибо д ру гой процесс навыпол нение. В первом сл у чаеу скоряется выпол нениезапроса, но отсу тству етм у л ьтипрограм м ирование.

К л иент-м аш ина

С ервер-м аш ина

вызов

П роцесскл иент

С таб кл иента

вызов

С таб сервера

П роцед у ра резу л ьтат

резу л ьтат

Я д ро кл иента

Я д ро сервера сообщ ение-вызов сообщ ение-резу л ьтат

Рис. 1. В заим од ей ствиепрограм м ных ком понентов Н астороне серверапосту паю щ ие биты пом ещ аю тся приним аю щ ей аппарату рой л ибо во встроенный бу ф ер, л ибо воперативну ю пам ять. Когд ався инф орм ация бу д ет пол у чена, генериру ется прерывание. О бработчик прерывания проверяет правил ьность д анных пакетаи опред ел яет, каком у стабу сл ед у ет их перед ать. Е сл и ни од ин из стабовне ож ид ает э тот пакет, обработчик д ол ж ен л ибо пом естить его в бу ф ер, л ибо вообщ е отказаться от него. Е сл и им еется ож ид аю щ ий стаб, то сообщ ение копиру ется ем у . Н аконец, выпол няется перекл ю чение контекстов, врезу л ьтате чего восстанавл иваю тся регистры и карта пам яти, приним ая тезначения, которыеони им ел и вм ом ент, когд астабсд ел ал систем ный вызовreceive д л я переход авреж им ож ид ания прием асообщ ения.

6

Т еперь начинает работу серверный стаб. О н распаковывает парам етры и пом ещ ает их соответству ю щ им образом встек. И звл ечение (unmarshalling) м ож ет вкл ю чать необход им ые преобразования (наприм ер, изм енения поряд ка распол ож ения бай тов). К огд авсе готово, выпол няется вызовнастоящ ей процед у ры-сервера, которой ад ресован запрос кл иента, с перед ачей ей пол у ченных по сети аргу м ентов. П осл е выпол нения процед у ры сервер перед ает резу л ьтаты кл иенту . Д л я э того выпол няю тся всеописанныевыш еэ тапы, тол ько вобратном поряд ке: стабсерверапреобразу етвозвращ енныепроцед у рой значения, ф орм иру я сетевоесообщ ение-откл ик, который перед ается по сети систем е, откоторой приш ел запрос. О перационная систем аперед ает пол у ченное сообщ ение стабу кл иента, который , посл е необход им ого преобразования, перед ает значения (явл яю щ иеся значениям и, возвращ енным и у д ал енной процед у рой ) кл иенту , восприним аю щ ем у э то как норм ал ьный возврат из процед у ры. Рис. 2 д ем онстриру етописанныеэ тапы выпол нения RPC-вызова.

Рис. 2. Э тапы выпол нения процед у ры RPC И так, с точки зрения кл иента, он производ ит вызову д ал енной процед у ры, как он э то сд ел ал бы д л я локальной . Т о ж е сам ое м ож но сказать и о сервере: вызовпроцед у ры происход ит станд артным образом , некий объ ект (стабсервера) производ ит вызовл окал ьной процед у ры и пол у чает возвращ енные ею значения. К л иент восприним ает стабкак вызываем у ю процед у ру -сервер, асервер приним аетсобственну ю загл у ш ку закл иента. Т аким образом , стабы составл яю тяд ро систем ы RPC, отвечая завсеаспекты ф орм ирования и перед ачи сообщ ений м еж д у кл иентом и у д ал енным сервером (процед у рой ), хотя и кл иент и сервер считаю т, что вызовы происход ят локально. В э том -то и состоит основная концепция RPC – пол ностью спрятать распред ел енный (сетевой ) характер взаим од ей ствия вкод е стабов. П реим у щ е-

7

стватакого под ход аочевид ны: и кл иент и сервер явл яю тся независим ым и от сетевой реал изации, обаони работаю т врам ках некой распред ел енной вирту ал ьной м аш ины, и вызовы процед у р им ею т станд артный интерф ей с. В то ж е врем я, при разработкераспред ел енных прил ож ений неприд ется вникатьвпод робности протокол аRPC ил и програм м ировать обработку сообщ ений . С истем а пред пол агает су щ ествование соответству ю щ ей сред ы разработки, которая значител ьно обл егчает ж изнь созд ател ям прикл ад ного програм м ного обеспечения. О д ним из кл ю чевых м ом ентоввRPC явл яется то, что разработкараспред ел енного прилож ения начинается с опред еления интерф ей са– ф орм ального описания ф у нкций сервера, сд ел анного наспециальном языке. Н аосновании э того интерф ей сазатем автом атически созд аю тся стабы кл иентаи сервера. Е д инственное, что необход им о сд ел ать посл е э того, – написать ф актический код процед у ры.

Реа л и за ци я RPC ф и рм ы Microsoft Microsoft Remote Procedure Call (MS RPC) д л я языковпрограм м ирования C и C++ пред ставл яет совоку пность трех м од ел ей програм м ирования распред ел енных вычисл ений : обычная м од ел ьразработки прил ож ений наC пу тем написания процед у р и библ иотек; м од ел ь, которая испол ьзу етм ощ ные ком пью теры вкачестве сетевых серверов, выпол няю щ их специф ические зад ачи д л я своих кл иентов; и м од ел ь кл иент-сервер, вкоторой кл иент обычно у правл яет интерф ей сом пол ьзовател я, вто врем я как сервер заним ается выборкой , м анипу л ированием и хранением д анных. В ыд ел им основныеих особенности. П р огр ам м н ая м оде л ь . Я зык C под д ерж ивает процед у рно-ориентированное програм м ирование. В се процед у рно-ориентированные языки обеспечиваю т простые м еханизм ы опред ел ения и описания процед у р. Н априм ер, ANSI станд арт прототипаф у нкции C – констру кция, испол ьзу ем ая д л я опред ел ения им ени процед у ры, типа возвращ аем ого резу л ьтата(есл и есть), атакж е числ а, посл ед овател ьности, и типовпарам етров. И спол ьзование ф у нкционал ьного прототипа– ф орм ал ьный способопред ел ить интерф ей с м еж д у процед у рам и. Д алее терм ин «процед у ра» испол ьзу ется как синоним терм ина«под програм м а» д л я обозначения л ю бой посл ед овател ьности ком пью терных ком анд , выпол няю щ их ф у нкциональну ю цел ь. Т ерм ин «ф у нкция» обозначаетпроцед у ру , которая возвращ аетзначение. С вязанныепроцед у ры часто гру ппиру ю тся вбибл иотеках. Т ак, библ иотека м ож ет вкл ю чать набор процед у р, которые выпол няю т зад ачи вкакой -л ибо общ ей обл асти, наприм ер, м атем атические операции с пл аваю щ ей запятой , ф орм атиру ем ый ввод / вывод , сетевые ф у нкции. Библ иотекапроцед у р – сл ед у ю щ ий у ровень у паковки, обл егчаю щ ий разработку прикл ад ных програм м . Библ иотеки м огу т разд ел яться м ногим и прикл ад ным и програм м ам и. Библ иотеки, разработанные на C, обычно сопровож д аю тся ф ай л ам и загол овков. К аж д ая програм м а, испол ьзу ю щ ая библ иотеку , ком пил иру ется с ф ай л ам и загол овков, которыеф орм ал ьно опред ел яю тинтерф ей с к процед у рам библ иотеки.

8

И нстру м ентал ьные сред стваMicrosoft RPC пред ставл яю т общ ий под ход , который позвол яет библ иотекам процед у р, написанным наC, выпол няться на д ру гих ком пью терах. Ф актически, прикл ад ная програм м ам ож етком поноваться с библ иотекам и, реал изованным и с испол ьзованием RPC, без у вед ом л ения пол ьзовател я обиспол ьзовании RPC. М оде л ь кл ие н т -се р ве р . Архитекту ракл иент-сервер – э ф ф ективный и попу л ярный проект распред ел енных прилож ений . В м од ел и прилож ение разд ел яется над ве части: ф ронтальный кл иент, который пред ставл яет инф орм ацию пол ьзовател ю , и оконечный сервер, сохраняю щ ий и м анипу л иру ю щ ий д анным и и вообщ е– производ ящ ий бол ьш у ю часть вычисл ител ьных зад ач д л я пол ьзовател я. В э той м од ел и сервер – обычно бол еем ощ ный ком пью тер, чем кл иент, и сл у ж итцентрал ьным хранил ищ ем д анных д л я м ногих ком пью теровкл иентов, д ел ая систем у простой в у правл ении. Т ипичным и прим ерам и прил ож ений кл иент-сервер явл яю тся разд ел яем ые базы д анных, у д ал енные ф ай л овые серверы и у д аленные серверы печати. С етевые систем ы под д ерж иваю т разработку прил ож ений кл иент-сервер с испол ьзованием сред ств м еж процессных взаим од ей ствий (interprocess communication – IPC), которые позвол яю т кл иенту и серверу связываться и коорд инировать их работу . Н априм ер, кл иент м ож ет использовать м еханизм IPC, чтобы посл ать код операции и д анныенасервер, запраш ивая вызовспециф ической процед у ры. С ервер пол у чает и д екод иру ет запрос, затем вызывает соответству ю щ у ю процед у ру , выпол няетвсевычисл ения, необход им ыед ля у д овл етворения запроса, затем возвращ ает резу л ьтат пользовател ю . П рил ож ения кл иент-сервер обычно разрабатываю тся с цел ью м иним изации кол ичества перед аваем ых по сети д анных. В д опол нение ко всем возм ож ным ош ибкам , которые м огу т происход ить наод иночном ком пью тере, сеть им еет и собственные у сл овия возникновения ош ибок. Н априм ер, соед инение м ож ет быть потеряно, сервер м ож ет исчезну ть из сети, сетевая сл у ж бабезопасности м ож ет отвергну ть д осту п к ресу рсам систем ы, пол ьзовател и м огу т конку рировать при испол ьзовании ресу рсов. И так, при написании прил ож ения кл иент-сервер необход им о обеспечить у ровень код а, который у правл ял бы сетевой связью с обработкой все возм ож ные у сл овий возникновения ош ибок. П реим у щ ество испол ьзования Microsoft RPC втом , что инстру м ентальные сред стваRPC сам и обеспечиваю т э тот у ровень: RPC почти у страняет потребность писать специф ический д л я сети код . И нстру м ентальные сред стваRPC у правл яет м ногим и д етал ям и вотнош ении сетевых протоколови связи, позвол яя разработчику сосред оточиться на д етал ях прил ож ения. М оде л ь се р ве р а-вы ч исл ит е л я . RPC пред ставл яет ш агразвития м од ел и кл иент-сервер, вкоторой под серверам и под разу м еваю тся ф ай ловые серверы, серверы печати, ил и серверы связи, в зависим ости от того, обеспечиваю т л и они совм естное использование ф ай л овил и соед инены с принтерам и или м од ем ам и. В д опол нение к э тим тра-

9

д иционным рол ям , сервер, испол ьзу ю щ ий RPC, м ож ет играть рол ь вычисл ител ьной станции. В э той рол и, сервер пред оставл яет собственну ю вычисл ител ьну ю м ощ ность д ру гим ком пью терам сети, акл иент испол ьзу ет не тол ько ф ай л ы и принтеры, но такж еи централ ьные м од у л и обработки д ру гих ком пью теров. Ком пон е н т ы Microsoft RPC Реализация Microsoft RPC совм естим асо станд артом DCE консорциу м а OSF (Open Software Foundation) с небольш им и отл ичиям и. К л иентскиеил и серверные прилож ения, написанные с испол ьзованием Microsoft RPC, м огу т э кспл у атироваться совм естно с л ю бым и DCE RPC серверам и ил и кл иентам и, чьи библ иотеки врем ени выпол нения работаю т над под д ерж иваем ым протоколом (список под д ерж анных протоколовсм . ниж е). П род у ктMicrosoft RPC вкл ю чаетсл ед у ю щ иегл авныеком поненты: • ком пил ятор MIDL; • библ иотеки врем ени выпол нения и заголовочныеф ай л ы; • м од у л и транспортного интерф ей са; • провай д ер сервисаим ен; • сервис под клю чения (Endpoint supply service). К ак сказано выш е, вм од ел и RPC пред у см атривается ф орм альное опред ел ение интерф ей сак у д ал енным процед у рам с испол ьзованием специального языка. Э то так называем ый язы к опред елен ияин т ерфейсов , ил и IDL (Interface Definition Language). Реал изация Microsoft э того языканазывается MIDL. П осл е того, как интерф ей с описан, необход им о обработать его ком пил ятором MIDL. К ом пил ятор генериру ет стабы (stub), которые трансл иру ю т локал ьные вызовы процед у ры в у д ал енные. С табы являю тся зам естител ям и ф у нкций и в свою очеред ь производ ят вызовы ф у нкций библ иотеки врем ени выпол нения, выпол няю щ их у д ал енный вызовпроцед у р. П реим у щ ество такого под ход автом , что сеть становится почти пол ностью прозрачной д л я распред ел енного прил ож ения. К л иентская програм м акак бу д то бы вызывает локальные процед у ры; работапо превращ ению их ву д ал енныевызовы выпол няется автом атически. В есь код , который трансл иру етд анные, обращ ается к сети и возвращ аетрезу л ьтаты, генериру ется ком пил ятором MIDL и невид им д л я прикл адной програм м ы. О собе н н ост и р абот ы MS RPC К ак выяснено раньш е, инстру м ентал ьные сред стваRPC позвол яю т вызывать процед у ру , разм ещ енну ю ву д ал енной серверной програм м е, как есл и бы онаразм ещ ал ась локально. К л иенти сервер им ею т свои собственные ад ресные пространства; то есть каж д ый им еет собственный ресу рс пам яти, выд ел енный д л я разм ещ ения д анных, испол ьзу ем ых процед у рой . К л иентское прил ож ение вызываетл окал ьну ю процед у ру стабавм есто ф актического код а, реал изу ю щ его процед у ру . С табы ком пил иру ю тся и ком пону ю тся с кл иентской програм м ой . В м есто ф актического код а, реал изу ю щ его у д ал енну ю процед у ру , код стаба пол ьзовател я: • выбираеттребу ем ыепарам етры из адресного пространствакл иента;

10

• трансл иру ет парам етры встанд артный с ет ев ой форм а т пред ст а в лен ияд а н н ы х (NDR – network data representation), что необход им о д л я их перед ачи по сети; • вызывает ф у нкции кл иентской RPC-библ иотеки врем ени выпол нения, чтобы посл атьзапрос и парам етры серверу . С ервер выпол няетсл ед у ю щ иеш аги, чтобы вызватьу д аленну ю процед у ру : • ф у нкции серверной RPC-библ иотеки врем ени выпол нения приним аю т запрос и вызываю тпроцед у ру серверного стаба; • стабсерверавыбирает парам етры из сетевого бу ф ераи преобразу ет их из сетевого ф орм атаперед ачи вф орм ат, необход им ый серверу ; • стабсерверавызываетф актическу ю серверну ю процед у ру . У д ал енная процед у равыпол няется, возм ож но, генериру я выход ные парам етры и возвращ аем ое значение. К огд ау д ал енная процед у разаверш ается, под обная выш еописанной посл ед овател ьностьш аговвозвращ аетд анныекл иенту : • у д ал енная процед у равозвращ аетд анныесерверном у стабу ; • стаб серверапреобразу ет выход ные парам етры в ф орм ат, требу ем ый д л я перед ачи по сети, и возвращ ает их ф у нкциям RPC-библ иотеки врем ени выпол нения; • ф у нкции серверной RPC-библ иотеки перед аю т д анные по сети наком пью тер кл иента. К л иент заверш ает процесс, приним ая д анные из сети и возвращ ая их вызвавш ей ф у нкции: • кл иентская RPC-библ иотека пол у чает возвращ аем ые у д ал енной процед у рой значения и возвращ аетих кл иентском у стабу ; • кл иентский стабпреобразу ет д анные из сетевого пред ставл ения вф орм ат, испол ьзу ем ый ком пью тером кл иента, записывает д анные впам ять кл иентаи возвращ аетрезу л ьтатвызвавш ей кл иентской програм м е; • вызвавш ая процед у рапрод ол ж ается, как посл ел окал ьного вызова. Д л я Microsoft Windows и Microsoft Windows NT, библ иотеки врем ени выпол нения состоят из д ву х частей : им портиру ем ой библ иотеки, ком пону ем ой с прикл ад ной програм м ой , и RPC-библ иотеки врем ени выпол нения, которая реал изованакак д инам ическая (DLL). С ерверное прил ож ение сод ерж ит вызовы ф у нкций серверной библ иотеки врем ени выпол нения, которые регистриру ю т интерф ей с сервераи позвол яю тсерверу приним ать у д ал енные вызовы. С ерверное прилож ение такж е сод ерж ит и сам и специф ические у д ал енные процед у ры, пред назначенныед л я вызовакл иентским и прил ож ениям и.

У ч ебны й п ри м ер ра сп ред ел енно го п ри л о жени я Э то введ ение вRPC пред ставл ено очень простой прикл ад ной програм м ой , концентриру ю щ ей вним ание наразл ичиях м еж д у автоном ным и програм м ам и наC и распред ел енным и прил ож ениям и, испол ьзу ю щ им и RPC. Э тот прим ер, конечно, не явл яется исчерпываю щ им показом возм ож ностей RPC, богатых сред ствязыкаопред ел ения интерф ей совMicrosoft (MIDL). П рилож ение печатает сл ова «П ривет, м ир» . К л иентский ком пью тер д ел ает у д ал енный вызов

11

процед у ры насервере, асервер печатает сл ованау строй стве станд артного вывод а. Э то распред ел енное прил ож ение вклю чает д ве разл ичные испол няем ые програм м ы: од ну д л я кл иентаи од ну д ля сервера. П од обно обычным програм м ам , они бу д у тпол у чены из исход ных ф ай л овнаязыкеC, восновном написанных разработчиком . О д нако некоторые из исход ных ф ай л овбу д у т автом атически сгенерированы RPC инстру м ентом – ком пил ятором MIDL. П рим ерный пл ан работы по реализации э того прил ож ения таков. Ч тобы сд ел ать его распред ел енным , В ы созд адите ф ай л , вкл ю чаю щ ий ф у нкционал ьный прототип у д аленной процед у ры. П рототип связан с а т рибут а м и, которые описываю т, каким образом д анные д л я у д аленной процед у ры д ол ж ны быть перед аны через сеть. Атрибу ты, типы д анных и ф у нкционал ьные прототипы совм естно описываю т ин т ерфейс м еж д у кл иентом и сервером . И нтерф ей с ассоцииру ется с ун ика льн ы м ид ен т ифика т ором , позвол яю щ им отл ичать э тот интерф ей с от всех д ру гих. В ы такж е созд ад ите ф ай л , который объ явл яет особу ю перем енну ю – д ес крипт ор с в язы в а н ия, испол ьзу ем у ю кл иентом и сервером д л я пред ставл ения их логического соед инения через э тот интерф ей с. В ы бу д ете, наконец, писать гл авные програм м ы кл иентаи сервера, которые вызываю т RPC фун кции в рем ен и в ы полн ен ияд л я у становки интерф ей са. П р огр ам м а кл ие н т а Н ачнем с сам ого простого. Автоном ная програм м а, которая м ож ет быть выпол ненанаод ном ком пью тере, состоит из вызоваод ной ф у нкции, называем ой HelloProc : /* файл: helloc.c (автономная программа) */ void HelloProc(unsigned char * pszString); void main(void) { unsigned char * pszString = "Hello, world"; HelloProc(pszString); }

Ф у нкция HelloProc вызывает библ иотечну ю C ф у нкцию printf, чтобы отобразитьтекст"Привет, мир": /* файл: hellop.c */ #include <stdio.h> void HelloProc(unsigned char * pszString) { printf("%s\n", pszString); }

12 HelloProc м ы с са м ого началаопред елил и всобственном исход ном ф ай -

л еHELLOP.C, так что онам ож етком пил ироваться и ком поноваться как с автоном ной прикл ад ной програм м ой , так и с распред ел енным прилож ением , к реал изации которого м ы присту паем . Ф а йл н а я з ы ке о пре де ле н ия ин т е рф е йсо в П ервый ш аг при созд ании распред ел енного прилож ения д ол ж ен обеспечить возм ож ность кл иенту и серверу най ти д ру г д ру гаи связаться через сеть. Д л я э того ф орм ально опред ел яется интерф ей с с испол ьзованием языкаопред ел ения интерф ей сов Microsoft (MIDL). И нтерф ей с состоит из типов д анных, ф у нкционал ьных прототипов, атрибу тови инф орм ации интерф ей са. О пред ел ение интерф ей са сохраняется в собственном ф ай л е с расш ирением IDL. Д л я у д обстваэ тот прим ер испол ьзу ет то ж е сам ое им я, HELLO, как д л я IDL ф ай л а, так и д л я ф ай л аязыкаC. В ы м ож ете испол ьзовать и разл ичные им енад л я э тих д ву х ф ай лов: /* файл: hello.idl */ [ uuid (6B29FC40-CA47-1067-B31D-00DD010662DA), version(1.0) ] interface hello { void HelloProc([in, string] unsigned char * pszString); }

К онстру кции IDL ф ай л аотл ичаю тся от констру кций висход ных ф ай л ах языкаC, но они д остаточно очевид ны. IDL ф ай л состоит из д ву х частей : загол овкаинтерф ей саи тел аинтерф ей са. Заголовок интерф ей савкл ю чает инф орм ацию относител ьно интерф ей савцел ом , таку ю как его ид ентиф икатор и ном ер версии. О н состоит из специф икации, заклю ченной вквад ратные скобки и заканчиваю щ ей ся кл ю чевым сл овом interface и им енем интерф ей са. Заголовок интерф ей сав э том прим ере вкл ю чает кл ю чевые сл оваuuid, version и interface . Т ел о интерф ей сазаклю чено вф игу рные скобки и сод ерж ит типы д анных и ф у нкциональныепрототипы. UUID – ун ив ерс а льн о ун ика льн ы й ид ен т ифика т ор (universally unique identifier), строкаиз пяти гру пп ш естнад цатеричных циф р, разд ел яем ых д еф исам и. Э ти пятьгру пп соответственно сод ерж атвосем ьциф р, четырециф ры, четыре циф ры, четыре циф ры и 12 циф р. Н априм ер, "6B29FC40-CA47-1067B31D-00DD010662DA " – явл яется д опу стим ым UUID. В сред е Microsoft Windows NT UUID такж е известен как GUID, ил и гл обально у никал ьный ид ентиф икатор (globally unique identifier). UUID интерф ей сам ож но пол у чить при пом ощ и специал ьной у тил иты uuidgen, которая генериру ет у никал ьные ид ентиф икаторы втребу ем ом ф орм ате. Т ел о интерф ей са сод ерж ит С -под обные опред ел ения типов д анных и ф у нкционал ьных прототипов, к которым д обавл ены атрибу ты. Ат рибут ы при-

13

вод ятся вквад ратных скобках и описываю тспособперед ачи д анных по сети. В д анном прим ере тел о интерф ей са сод ерж ит ф у нкционал ьный прототип HelloProc. Е д инственный па рам етр pszString, обозначен как парам етр in, что означаетнеобход им ость его перед ачи откл иентак серверу . П арам етры м огу т такж е быть обозначены как out, есл и они перед аю тся от серверакл иенту , ил и in,out , есл и перед аю тся вобоих направл ениях. Э ти атрибу ты – инф орм ация д л я библ иотек врем ени выпол нения, организу ю щ их перед ачу д анных м еж д у кл иентом и сервером . Атрибу т string у казывает, что парам етр – сим вольный м ассив. В резу л ьтате обработки IDL ф ай л аком пил ятором MIDL бу д у т сгенерированы ф ай л ы наязыкеC д л я кл иентского и серверного стабови ф ай л заголовка. Ф ай л загол овка, произвед енный из ф ай л аопред ел ения интерф ей саHELLO.IDL, по у м олчанию им ену ется HELLO.H и сод ерж ит вкл ю чение (#include ) заголовочного ф ай л а RPC.H , а такж е ф у нкционал ьные прототипы из IDL ф ай л а. Ф ай л заголовкаRPC.H опред ел яет д анные и ф у нкции, использу ем ые сгенерированным ф ай лом заголовка: /* файл: hello.h (фрагмент) */ #include <rpc.h> void HelloProc(unsigned char * pszString);

В м есто того чтобы д у бл ировать э ти ф у нкциональные прототипы, исход ный текст кл иентад ол ж ен вкл ю чить ф ай л заголовка, который сгенерирован из IDL ф ай л а: /* файл: helloc.c (распределенная версия) */ #include <stdio.h> #include "hello.h" // заголовок, сгенерированный // компилятором MIDL void main(void) { char * pszString = "Hello, world"; ... HelloProc(pszString); ... }

IDL ф ай л опред ел яет«д оговор» м еж д у кл иентом и сервером – тверд ое согл аш ение относительно посл ед овател ьности, типов и разм еров д анных, которыед ол ж ны бытьперед аны через сеть. Ф а йл ко н ф иг ура ции прило ж е н ия С танд артраспред ел енной вычисл ител ьной сред ы (DCE) требу ет такж е опред ел ить фа йл кон фигура ции прилож ен ия ил и ACF (application configuration

14

file), который обрабатывается ком пил ятором MIDL вм есте с IDL ф ай л ом . ACF сод ерж ит д анные и атрибу ты RPC, не им ею щ ие отнош ения к перед аваем ым д анным . Н априм ер, объ ект д анных, называем ый д ес крипт ором с в язы в а н ия, пред ставл яет соед инение м еж д у прил ож ениям и кл иентаи сервера. К л иент вызывает ф у нкции врем ени выпол нения, чтобы у становить им ею щ ий сил у д ескриптор связывания, который м ож ет затем использоваться ф у нкциям и врем ени выпол нения всякий раз, когд акл иент вызывает у д ал енну ю процед у ру . Д ескриптор связывания не явл яется частью ф у нкционал ьного прототипаи не перед ается через сеть, поэ том у он опред ел яется вACF. ACF д л я програм м ы "Hello,world " им еетсл ед у ю щ ий вид : /* файл: hello.acf */ [ implicit_handle(handle_t hello_IfHandle) ]interface hello { }

Ф орм ат ACF под обен ф орм ату IDL ф ай л а. Атрибу ты привод ятся вквад ратных скобках со сл ед у ю щ им заним и кл ю чевым сл овом interface и им енем интерф ей са. И м я интерф ей са, опред ел енное в ACF, д ол ж но соответствовать им ени, опред ел енном у в IDL ф ай л е. ACF сод ерж ит атрибу т implicit_handle , у казыва ю щ ий , что д ескриптор – глобальная перем енная, т.е. д осту пная ф у нкциям библ иотеки врем ени выпол нения. К л ю чевое слово implicit_handle связа но с типом д ескриптораи им енем д ескриптора; вэ том прим ере д ескриптор им еет MIDL тип д анных handle_t. И м я hello_IfHandle д ескриптора , специф ицированное вACF, опред ел ено всгенерированном ф ай л е заголовкаHELLO.H. Э тот д ескриптор бу д ет испол ьзоваться при вызовах ф у нкций кл иентской библ иотеки врем ени выпол нения. Ф ун кции, в ы з ы в а е мы е из RPC Библ иотеки врем ени выпол нения RPC часто вызываю т ф у нкции, реал изованные пол ьзовател ем . Э тот под ход позвол яет ком пил ятору MIDL генерироватьC код автом атически, вто ж е врем я сохраняя возм ож ность непосред ственного у правл ения выпол нением операции вприлож ении. Такие реал изованные пол ьзовател ем ф у нкции м огу т им еть л ибо ф иксированные им ена, л ибо им ена, основанные наатрибу тах ил и типах д анных IDL-ф ай л а. Н априм ер, всякий раз, когд абибл иотеки врем ени выпол нения распред ел яю тил и освобож д аю тпам ять, они вызываю треализованныепол ьзовател ем ф у нкции midl_user_allocate и midl_user_free . В прим ере"П ривет, м ир" прил ож ениене ну ж д ается всл ож ном у правл ении пам ятью , так что э ти ф у нкции просто реал изованы втерм инах библ иотечных C-ф у нкций malloc и free: void __RPC_FAR * __RPC_USER midl_user_allocate(size_t len) { return(malloc(len)); }

15 void __RPC_USER midl_user_free(void __RPC_FAR * ptr) { free(ptr); }

Вы з о в ф ун кций клие н т ско г о API RPC под д ерж иваетд ватипасвязывания: а в т ома т ичес кое и програ м м н оупра в ляемое. П ри испол ьзовании автом атического связывания, В ы не д ол ж ны опред ел ять д ескриптор связывания, атакж е д ел ать какие-л ибо вызовы кл иентских ф у нкций врем ени выпол нения д л я объ явл ения (регистрации) д ескриптора. Е сл и ж е у правл яет д ескриптором прилож ение, оно сам о д ол ж но д ел ать э ти опред ел ения и вызовы. В д анном прим ере соед инением с сервером у правл яет кл иент. Ч тобы связаться с сервером , клиент д ол ж ен вызвать ф у нкции врем ени выпол нения перед вызовом у д ал енной процед у ры и д ол ж ен отсоед иниться по заверш ении всех у д аленных вызовов. С тру кту рапрограм м ы кл иента, которая у правл яет собственным соед инением с сервером , описанавсл ед у ю щ ем ф рагм енте код а. У д ал енные вызовы процед у ры пом ещ аю тся м еж д у вызовам и э тих ф у нкций кл иентской библ иотеки врем ени выпол нения: /* файл: helloc.c (фрагмент) */ #include "hello.h" // заголовок, сгенерированный // компилятором MIDL void main(void) { RpcStringBindingCompose(...); RpcBindingFromStringBinding(...); HelloProc(pszString);

// удаленный вызов

RpcStringFree(...); RpcBindingFree(...); }

П ервые д вавызоваAPI врем ени выпол нения у станавл иваю т им ею щ ий сил у д ескриптор д л я сервера. Э тотд ескриптор затем использу ется, чтобы сд ел ать у д ал енный вызовпроцед у ры. Закл ю чител ьные д вавызоваAPI врем ени выпол нения освобож д аю тего. Ф у нкции Microsoft RPC использу ю тстру кту ры д анных, которыепред ставл яю т св язы в а н ие, ин т ерфейс , пос лед ов а т ельн ос т ь прот околов и пун кт н а зн а чен ия(endpoint). С вязывание– э то соед инением еж д у кл иентом и сервером ; интерф ей с– совоку пность типовд анных и процед у р, реал изованных сервером ; посл ед овател ьность протоколов– специф икация базового сетевого транспорта, который ну ж но испол ьзоватьд л я перед ачи д анных по сети; пу нктназначения – сетевое им я, которое явл яется специф ическим д л я посл ед овател ьности протокол ов. Д анный прим ер испол ьзу етим енованныеканал ы (named pipe) вкачестве

16

посл ед овател ьности протоколов, и пу нкт назначения \pipe\hello. В привод им ом д алее прим ере код а ф у нкция RpcStringBindingCompose ком биниру ет посл ед овательность протокол ов, сетевой ад рес (им я сервера), пу нкт назначения (им я канала) и д ру гие строковые э л ем енты в ф орм у , требу ю щ у ю ся д л я сл ед у ю щ ей ф у нкции, RpcBindingFromStringBinding , а такж е распред ел яет пам ять д л я разм ещ ения сим вол ьной строки. В свою очеред ь, RpcBindingFromStringBinding испол ьзу ет э ту строку д л я генера ции д ескриптора, который пред ставл яетсвязыванием еж д у сервером и кл иентом . П осл етого, как у д ал енные вызовы процед у р выпол нены, RpcStringFree освобож д ает пам ять, которая был араспред ел енаRpcStringBindingCompose д л я стру кту ры д анных строки связывания. RpcBindingFree освобож д аетд ескриптор. Ст рока св язы в а н ия (string binding), таким образом , явл яется клю чевым понятием при реализации соед инения програм м но-у правл яем ого типа, поскол ьку сод ерж ит всю необход им у ю д л я э того инф орм ацию . С трокасвязывания состоит из нескольких под строк, пред ставл яю щ их UUID интерф ей са, посл ед овательность протокол ов, сетевой ад рес, пу нкт назначения и его опции. П осл ед овател ьность протокол ов, в свою очеред ь, пред ставл яет сетевой RPC протокол, атакж еопред еляетсогл аш ения о соответству ю щ ем ф орм атесетевых ад ресови обим еновании пу нктовназначения. Н априм ер, посл ед овател ьность протоколовncacn_ip_tcp опред ел яет протокол с у становл ением соед инения, втерм инах NCA (Network Computing Architecture), над TCP/IP. П ри э том требу ется соответству ю щ ий ф орм атпред ставл ения сетевого адресаил и им ени сервера, апу нктназначения обозначаетсерверный ком м у никационный порт. В общ ем сл у чае посл ед овател ьность протокол овсод ерж ит набор из трех опций , которые д ол ж ны быть опред елены д л я RPC-библ иотеки врем ени выпол нения: • RPC протокол, д осту пные опции – ncacn (NCA Connection-oriented) и ncadg (Datagram-oriented); • ф орм атсетевого ад реса, д осту пныеопции – ip, dnet и osi; • транспортный протокол, д осту пные опции – tcp, udp, nsp, dna, np (named pipes) и nb (NetBIOS). Зам етим , что наибол ее сл ож ные распред ел енные прил ож ения д л я пол у чения д ескрипторасвязывания д ол ж ны испол ьзовать ф у нкции сервисаим ен вм есто строк связывания. Ф у нкции сервисаим ен позвол яю т серверу регистрировать интерф ей с, UUID, сетевой ад рес и пу нкт назначения под од ним логическим им енем . Э ти ф у нкции обеспечиваю т независим ость располож ения ком понентовприл ож ения и л егкостьад м инистрирования. П ол ный текст програм м ы кл иентавкл ю чает код д л я обработки ввод аком анд ной строки и выгл яд итсл ед у ю щ им образом : #include #include #include #include

<stdlib.h> <stdio.h> "hello.h" // заголовок, сгенерированный // компилятором MIDL

17 void Usage(char * pszProgramName) { fprintf(stderr, "Usage: %s\n", pszProgramName); fprintf(stderr, " -p protocol_sequence\n"); fprintf(stderr, " -n network_address\n"); fprintf(stderr, " -e endpoint\n"); fprintf(stderr, " -o options\n"); fprintf(stderr, " -s string\n"); exit(1); } void main(int argc, char **argv) { RPC_STATUS status; unsigned char * pszUuid unsigned char * pszProtocolSequence unsigned char * pszNetworkAddress unsigned char * pszEndpoint unsigned char * pszOptions unsigned char * pszStringBinding unsigned char * pszString unsigned long ulCode; int i;

= = = = = = =

NULL; "ncacn_np"; NULL; "\\pipe\\hello"; NULL; NULL; "Hello, world";

/* Обработка ключей командной строки, позволяющих изменять определенные выше установки параметров */ for (i = 1; i < argc; i++) { if ((*argv[i] == '-') || (*argv[i] == '/')) { switch (tolower(*(argv[i]+1))) { case 'p': // protocol sequence pszProtocolSequence = argv[++i]; break; case 'n': // network address pszNetworkAddress = argv[++i]; break; case 'e': // endpoint pszEndpoint = argv[++i]; break; case 'o': // options pszOptions = argv[++i]; break; case 's': // string pszString = argv[++i]; break; case 'h': case '?': default: Usage(argv[0]); } } else Usage(argv[0]); }

18 /* Формирование строки связывания в требуемом формате */ status = RpcStringBindingCompose( pszUuid, pszProtocolSequence, pszNetworkAddress, pszEndpoint, pszOptions, &pszStringBinding); printf("RpcStringBindingCompose returned 0x%x\n",status); printf("pszStringBinding = %s\n", pszStringBinding); if (status) exit(status); /* Установка дескриптора связывания */ status = RpcBindingFromStringBinding( pszStringBinding, &hello_IfHandle); printf("RpcBindingFromStringBinding returned 0x%x\n", status); if (status) exit(status); printf("Calling the remote procedure 'HelloProc'\n"); printf("Print the string '%s' on the server\n", pszString); RpcTryExcept { HelloProc(pszString); // удаленный вызов printf("Calling the remote procedure 'Shutdown'\n"); Shutdown(); // остановка сервера (используется далее) } RpcExcept(1) { ulCode = RpcExceptionCode(); printf("Runtime reported exception 0x%lx \n",ulCode); } RpcEndExcept /* /*

Удаленные вызовы сделаны. */ Освобождение строки и дескриптора связывания */ status = RpcStringFree(&pszStringBinding); printf("RpcStringFree returned 0x%x\n", status); if (status) exit(status); status = RpcBindingFree(&hello_IfHandle); printf("RpcBindingFree returned 0x%x\n", status); if (status) exit(status); exit(0);

}

19 void __RPC_FAR * __RPC_USER midl_user_allocate(size_t len) { return(malloc(len)); } void __RPC_USER midl_user_free(void __RPC_FAR * ptr) { free(ptr); }

Сбор ка пр ил оже н ия кл ие н т а Распред ел енное прил ож ение требу ет, чтобы перед ком пил яцией и ком поновкой исход ного текстанаC был сд ел ан д опол нител ьный под готовител ьный ш аг: ком пил яция IDL и ACF ф ай л овс испол ьзованием ком пил ятораMIDL. П ри э том необход им о с сам ого началаобратитьвним аниенато, что резу л ьтаты э той ком пил яции зависят: • отверсий операционной систем ы, которая бу д етстроитьприлож ение; • от операционной систем ы (систем ), вкоторой бу д у т выпол няться програм м ы кл иентаи сервера; • от сетевой посл ед овател ьности протоколов, которая бу д ет испол ьзоваться вреализации распред ел енного прил ож ения. В се э ти у словия опред ел ят версии испол ьзу ем ых MIDL и C ком пил яторов, версии заголовочных ф ай лов, вкл ю чаем ых в прил ож ения, и версии RPCбибл иотек врем ени выпол нения, ком пону ем ых с прилож ениям и. Д л я простоты м ы прим ем , что э тот первый прим ер испол ьзу ет од ну и ту ж е операционну ю систем у – Microsoft Windows NT – как д л я построения, так и вкачестве пл атф орм ы кл иентаи сервера, и что прим ер испол ьзу ет им енованные канал ы вкачествепосл ед овател ьности протокол ов. MIDL ко мпиля ция IDL ф ай л HELLO.IDL и ф ай л конф игу рации прил ож ения HELLO.ACF ком пил иру ется с испол ьзованием ком пил ятораMIDL: # makefile, фрагмент midl hello.idl

К ом пил ятор MIDL генериру ет ф ай л заголовкаHELLO.H и ф ай л кл иентского стаба наязыке C HELLO_C.C. (К ом пил ятор MIDL такж е производ ит ф ай л серверного стабаHELLO_S.C, но м ы покаего игнориру ем .) Ко мпиля ция C О стальная часть процессаразработки знаком а: ком пил яция исход ных ф ай л овнаязыкеC и ком поновкаих с RPC-библ иотекам и врем ени выпол нения д л я цел евой пл атф орм ы и всем и остальным и библ иотекам и, требу ю щ им ися д л я прил ож ения. С л ед у ю щ ие ком анд ы ком пил иру ю т прим ер кл иентской програм м ы:

20 # makefile, Фрагмент # CC обращается к компилятору C # CFLAGS задает ключи компилятора C # CVARS управляет директивой #ifdef # $(CC) $(CFLAGS) $(CVARS) helloc.c $(CC) $(CFLAGS) $(CVARS) hello_c.c

О братитевним ание: привед енные ком анд ы пред пол агаю т наличиеопред ел енной конф игу рации програм м ного обеспечения, которая состоит из у тил иты nmake, ком пил ятораMicrosoft C и операционной систем ы Microsoft Windows NT. Ко мпо н о в ка И сход ные ф ай л ы кл иентазатем ком пону ю тся с кл иентской библ иотекой врем ени выпол нения, библ иотекой сетевого пред ставл ения д анных и станд артной библ иотекой C врем ени выпол нения д л я д анной пл атф орм ы. # makefile, фрагмент # LINK обращается к компоновщику # CONFLAGS задает флаги консольных приложений # CONLIBS задает библиотеки консольных приложений # client.exe : helloc.obj hello_c.obj $(LINK) $(CONFLAGS) -out:client.exe helloc.obj hello_c.obj \ $(CONLIBS) rpcrt4.lib

Зам етьте, что ком анд ы ком поновщ икаи парам етры м огу т изм ениться взависим ости отконкретной ком пью терной конф игу рации. Сбо рка клие н т а , ре з юме С л ед у ю щ ий ф рагм ент ф ай л аMAKEFILE д л я у тил иты nmake показывает зависим ости м еж д у ф ай л ам и, испол ьзу ем ым и д л я построения прилож ения кл иента. # makefile, фрагмент client.exe : helloc.obj hello_c.obj ... hello.h hello_c.c : hello.idl hello.acf ... helloc.obj : helloc.c hello.h ... hello_c.obj : hello_c.c hello.h ...

П рим ер испол ьзовал зад анные по у м ол чанию им енаф ай л ов, которые произвед ены ком пил ятором MIDL. Зад анноепо у м ол чанию им я д л я ф ай л акл иент-

21

ского стабасф орм ировано из им ени IDL ф ай л а(без расш ирения) и сим волов _C.C . Е сл и им я (без расш ирения) им еет д л ину бол ее ш ести сим вол ов, некоторые ф ай л овые систем ы м огу т не приним ать пол у ченное им я ф ай л астаба. В э том сл у чае ф ай л ы стаба не д ол ж ны испол ьзовать зад анные по у м ол чанию им ена. И м я кл иентского стаба м ож но изм енить, воспользовавш ись клю чом /cstub ком пил ятораMIDL: midl hello.idl -cstub mystub.c

Е сл и вком анд ной строке ком пил ятораMIDL опред ел ены ваш и собственные им енаф ай л ов, необход им о испол ьзовать э ти им енаи впосл ед у ю щ их ком анд ах ком пил яции и ком поновки. П р огр ам м а се р ве р а С ерверная сторонараспред ел енного прил ож ения сообщ ает систем е, что сервисы явл яю тся д осту пным и, посл ечего переход итвсостояниеож ид ания запросовкл иента. В зависим ости от разм ераприлож ения и привычек код ирования, м ож но выбирать, реал изовывать ли у д аленные процед у ры вод ном ил и в бол ьш ем кол ичестве отд ел ьных ф ай л ов. В д анном прим ере основная под програм м апом ещ енависход ный ф ай л HELLOS.C, ау д ал енная процед у рареал изу ется вотд ел ьном ф ай л е, им енованном HELLOP.C. П ол ьзаот такой организации у д ал енных процед у р вотд ельных ф ай л ах закл ю чается втом , что процед у ры м огу т быть ском понованы с автоном ной програм м ой д л я отл ад ки код а, преж д е чем онабу д ет преобразованавраспред ел енное прил ож ение. П осл е того, как програм м азаработает автоном но, те ж е сам ые исход ные ф ай л ы м огу т ком пил ироваться и ком поноваться с серверным прил ож ением . П од обно исход ном у ф ай л у кл иентской прикл ад ной програм м ы, исход ный ф ай л програм м ы серверад ол ж ен вкл ю чить заголовочный ф ай л HELLO.H, чтобы пол у читьопред ел ения д анных и ф у нкций RPC, атакж е специф ических д л я интерф ей сад анных и ф у нкций . Вы з о в ф ун кций се рв е рн о г о API В сл ед у ю щ ем прим ере сервер вызывает ф у нкции RpcServerUseProtseqEp и RpcServerRegisterIf , чтобы сд ел а ть инф орм ацию связывания д осту пной кл иенту . Затем сервер сообщ аето своей готовности приним атьзапросы кл иента, вызвавф у нкцию RpcServerListen : /* файл: hellos.c (фрагмент) */ #include "hello.h" // заголовок, сгенерированный // компилятором MIDL

22 void main(void) { RpcServerUseProtseqEp(...); RpcServerRegisterIf(...); RpcServerListen(...); } RpcServerUseProtseqEp ид ентиф ициру ет пу нкт назна чения (endpoint) сервераи посл ед овател ьностьсетевых протокол ов. RpcServerRegisterIf регистриру ет интерф ей с, аRpcServerListen инстру ктиру ет сервер начать про-

сл у ш иваниезапросовкл иента. П рограм м а сервера д ол ж на такж е вкл ю чить д ве ф у нкции, вызываем ые серверным и стабам и, midl_user_allocate и midl_user_free . Э ти ф у нкции распред ел яю ти освобож д аю тпам ятьнасерверепри необход им ости, когд ау д ал енная процед у ра д ол ж на перед ать парам етры. В сл ед у ю щ ем прим ере, midl_user_allocate и midl_user_free реа л изованы с испол ьзованием библ иотечных C-ф у нкций malloc и free: void __RPC_FAR * __RPC_API midl_user_allocate(size_t len) { return(malloc(len)); } void __RPC_API midl_user_free(void __RPC_FAR * ptr) { free(ptr); }

П ол ный код д л я HELLOS.C выгл яд итсл ед у ю щ им образом : #include #include #include #include

<stdlib.h> <stdio.h> "hello.h" // заголовок, сгенерированный // компилятором MIDL void Usage(char * pszProgramName) { fprintf(stderr, "%s", PURPOSE); fprintf(stderr, "Usage: %s\n", pszProgramName); fprintf(stderr, " -p protocol_sequence\n"); fprintf(stderr, " -e endpoint\n"); fprintf(stderr, " -m maxcalls\n"); fprintf(stderr, " -n mincalls\n"); fprintf(stderr, " -f flag_wait_op\n"); exit(1); }

23 void main(int argc, char * argv[]) { RPC_STATUS status; unsigned char * pszProtocolSequence unsigned char * pszSecurity unsigned char * pszEndpoint unsigned int cMinCalls unsigned int cMaxCalls unsigned int fDontWait int i;

= = = = = =

"ncacn_np"; NULL; "\\pipe\\hello"; 1; 20; FALSE;

/* Обработка ключей командной строки, позволяющих изменять определенные выше установки параметров */ for (i = 1; i < argc; i++) { if ((*argv[i] == '-') || (*argv[i] == '/')) { switch (tolower(*(argv[i]+1))) { case 'p': // protocol sequence pszProtocolSequence = argv[++i]; break; case 'e': // endpoint pszEndpoint = argv[++i]; break; case 'm': // max concurrent calls cMaxCalls = (unsigned int) atoi(argv[++i]); break; case 'n': // min concurrent calls cMinCalls = (unsigned int) atoi(argv[++i]); break; case 'f': // flag fDontWait = (unsigned int) atoi(argv[++i]); break; case 'h': case '?': default: Usage(argv[0]); } } else Usage(argv[0]); } status = RpcServerUseProtseqEp( pszProtocolSequence, cMaxCalls, pszEndpoint, pszSecurity); // Security- дескриптор printf("RpcServerUseProtseqEp returned 0x%x\n", status); if (status) exit(status);

24 status = RpcServerRegisterIf( hello_ServerIfHandle, NULL, // MgrTypeUuid NULL); // MgrEpv; null по умолчанию printf("RpcServerRegisterIf returned 0x%x\n", status); if (status) exit(status); printf("Calling RpcServerListen\n"); status = RpcServerListen( cMinCalls, cMaxCalls, fDontWait); printf("RpcServerListen returned: 0x%x\n", status); if (status) exit(status); if (fDontWait) { printf("Calling RpcMgmtWaitServerListen\n"); status = RpcMgmtWaitServerListen(); // ожидание printf("RpcMgmtWaitServerListen returned: 0x%x\n", status); if (status) exit(status); } } /* распределение памяти */ void __RPC_FAR * __RPC_API midl_user_allocate(size_t len) { return(malloc(len)); } void __RPC_API midl_user_free(void __RPC_FAR * ptr) { free(ptr); }

Сбор ка се р ве р н ого пр ил оже н ия С боркасерверного прил ож ения соверш енно анал огичнасборке прил ож ения кл иента. MIDL ко мпиля ция П од разу м евается, что исход ный ф ай л серверного стабабыл сгенерирован вм есте с ф ай лом кл иентского стабаи ф ай л ом заголовка. К ом пил ятор MIDL созд аетвсеэ ти три ф ай л аод новрем енно. В наш ем прим ере нет необход им ости вызыватьком пил ятор MIDL д важ д ы. К ом анд ная строкаком пил ятораMIDL выгл яд итсл ед у ю щ им образом : # makefile, фрагмент midl hello.idl

25

Ко мпиля ция C И сход ные ф ай л ы наC, сод ерж ащ ие вызовы серверных RPC-ф у нкций и у д ал енные процед у ры, ком пил иру ю тся с исход ным ф ай л ом стаба, сгенерированным ком пил ятором MIDL: $(CC) $(CFLAGS) $(CVARS) hellos.c $(CC) $(CFLAGS) $(CVARS) hellop.c $(CC) $(CFLAGS) $(CVARS) hello_s.c

О братитевним ание: привед енные ком анд ы пред пол агаю т наличиеопред ел енной конф игу рации програм м ного обеспечения, которая состоит из у тил иты nmake, ком пил ятораMicrosoft C и операционной систем ы Microsoft Windows NT. Ко мпо н о в ка К ак только исход ные ф ай л ы наC отком пил ированы, они ком пону ю тся с серверной библ иотекой врем ени выполнения и станд артным и библ иотекам и C врем ени выпол нения д л я д анной пл атф орм ы, посл ед овател ьности протоколов (у нас – им енованным и канал ам и) и м од ел и пам яти: # makefile, фрагмент # LINK обращается к компоновщику # CONFLAGS задает флаги консольных приложений # CONLIBS задает библиотеки консольных приложений # server.exe : hellos.obj hellop.obj hello_s.obj $(LINK) $(CONFLAGS) -out:server.exe hellos.obj hellop.obj \ hello_s.obj $(CONLIBS) rpcrt4.lib

Зам етьте, что ком анд ы ком поновщ икаи парам етры м огу т изм ениться взависим ости отконкретной ком пью терной конф игу рации. Сбо рка се рв е ра , ре з юме С л ед у ю щ ий ф рагм ент ф ай л аMAKEFILE д л я у тил иты nmake показывает зависим ости м еж д у ф ай л ам и, испол ьзу ем ым и д л я построения прил ож ения сервера. И спол няем ая програм м асобирается из исход ных ф ай л овсервераи ф ай л а серверного стаба. В се исход ные ф ай л ы серверассыл аю тся наф ай л загол овка HELLO.H:

26 # makefile, фрагмент server.exe : hellos.obj hellop.obj hello_s.obj ... hello.h hello_s.c : hello.idl hello.acf ... hellos.obj : hellos.c hello.h ... hellop.obj : hellop.c hello.h ... hello_s.obj : hello_s.c hello.h ...

О ст ан овка се р ве р н ого пр ил оже н ия Робастная серверная програм м апри заверш ении работы д ол ж наостановить просл у ш ивание кл иентов и анну л ировать регистрацию интерф ей са. Д л я реал изации такой возм ож ности использу ю тся д ве специальные серверные ф у нкции – RpcMgmtStopServerListening и RpcServerUnregisterIf . С ерверная ф у нкция RpcServerListen не возвращ ает вызвавш ей програм м е у правл ениед о тех пор, поканепроизой д ет исклю чение ил и покасервер невызовет RpcMgmtStopServerListening . В Microsoft RPC кл иент не м ож ет непосред ственно вызывать э ту ф у нкцию , останавл иваю щ у ю просл у ш ивание. М ож но, од нако, разработать програм м у сервератак, чтобы пользовател ь м ог у правл ятьею как сервисом и таким способом заставл ял д ру гой поток серверного прил ож ения вызвать RpcMgmtStopServerListening . Д ру гой пу ть реш ения зад ачи – позвол ить кл иентском у прил ож ению останавл ивать серверное, д ел ая у д аленный вызовпроцед у ры насервере, которая всвою очеред ь вызывает RpcMgmtStopServerListening . С л ед у ю щ ий прим ер испол ьзу ет посл ед ний из под ход ов, д л я чего к HELLOP.C д обавл енановая у д ал енная ф у нкция Shutdown : /* файл: hellop.c (фрагмент) */ #include "hello.h" // заголовок, сгенерированный // компилятором MIDL void Shutdown(void) { RPC_STATUS status; status = RpcMgmtStopServerListening(NULL); ... status = RpcServerUnregisterIf(NULL, NULL, FALSE); ... }

27

Е д инственный

парам етр

со значением NULL у казывает RpcMgmtStopServerListening , что л окал ьное прил ож ение д ол ж но остановить просл у ш ивание у д ал енных вызовов процед у р. Д ваNULL-парам етрад л я RpcServerUnregisterIf у казыва ю т, что никакие интерф ей сы не остану тся зарегистрированным и. П арам етр FALSE требу ет, чтобы регистрация интерф ей сабыл аанну л ировананем ед л енно. П роцед у раShutdown, поскол ьку онаявл яется у д ал енной , д ол ж натакж е бытьд обавл енавсекцию тел аинтерф ей саIDL ф ай л а: /* файл: hello.idl */ [ uuid (6B29FC40-CA47-1067-B31D-00DD010662DA), version(1.0) ] interface hello { void HelloProc([in, string] char * pszString); void Shutdown(void); }

Н аконец, програм м акл иентад ол ж над обавитьвызовф у нкции Shutdown : /* файл helloc.c (фрагмент) */ #include "hello.h" // заголовок, сгенерированный // компилятором MIDL void main(void) { char * pszString = "Hello, world"; RpcStringBindingCompose(...); RpcBindingFromStringBinding(...); HelloProc(pszString); Shutdown(); RpcStringFree(...); RpcBindingFree(...); }

Осо бенно сти сбо рки RPC п ри л о жени й в сред еви зу а л ьно го п ро гра м м и ро ва ни я Рассм отренная выш е посл ед овательность операций ил л ю стриру ет процесс сборки распред ел енного прил ож ения с испол ьзованием простых програм м ных сред ств, сопровож д аю щ их поставку ком пил ятора Microsoft C: ком пил ятора MIDL, у тил иты nmake, ком поновщ ика, библ иотекаря и т.д . Т е ж е ш аги м ож но

28

прод ел ать с испол ьзованием ш ироко распространенных сред визу ал ьного програм м ирования наC++: Microsoft Visual C++ ил и Borland C++ Builder, всостав поставки которых вход итком пил ятор MIDL. Е сл и не ставить цел и интегрировать процесс ком пил яции IDL-ф ай л ов в сред у разработки, ком пил ятор MIDL м ож но запу скать просто из ком анд ной строки, как показано впред ыд у щ их разд ел ах. П ри э том необход им о пом нить, что ком пил ятор MIDL реал изован как д инам ическое прил ож ение и м ож ет потребовать у становки опред ел енных библ иотек DLL. П ол у ченные исход ные ф ай л ы д л я стабови заголовочный ф ай л затем необход им о д обавить всоответству ю щ иепрограм м ные проекты д л я прод ол ж ения работы всред евизу ального програм м ирования. Т ак рассм атриваем ый в д анном ру ковод стве прим ер реал изу ется в вид е д ву х консольных прилож ений : кл иентского и серверного. К ом пил яция прим ера м ож ет потерпеть неу д ачу из-засм ены версий ком пил ятораMIDL, врезу л ьтате чего изм еняю тся согл аш ения относител ьно генериру ем ых им ид ентиф икаторов. Н априм ер, MIDL из поставки Visual C++ 6.0 изм еняет им я стру кту ры д анных регистриру ем ого насервере интерф ей сапо сравнению с испол ьзованным внаш ем прим ере ид ентиф икатором hello_ServerIfHandle . Затру д нения при ком поновке проектовм огу т возникать из-заотсу тствия у казаний относител ьно библ иотечных ф ай л овRPC-библ иотек врем ени выпол нения. Н априм ер, д л я поставки Visual C++ 6.0, необход им о д обавитьву становки проекта(окно «Project Settings» , вкл ад ка«Link» ) им я библ иотечного м од у л я rpcrt4.lib. Д л я C++ Builder, возм ож но, потребу ется у казать пу ть к библ иотечным м од у л ям RPC (окно «Project Options» , вкл адка «Directories/Conditionals» ). Н априм ер, при станд артной у становке C++ Builder 5.0 э ти м од у л и пом ещ аю тся в каталог \Lib\PSDK .

За кл юч ени е: о сно вны е ш а ги п ри ра зра бо тке RPC п ри л о жени й Распред ел енноеприл ож ениесостоитиз испол няем ых програм м настороне кл иентаи насторонесервера. П роцесс разработки с испол ьзованием RPC вкл ю чает, в д опол нение к станд артном у процессу разработки, д ваш ага. В ы д ол ж ны опред ел ить интерф ей с д л я у д ал енного вызовапроцед у ры вIDL и ACF ф ай л ах, которые ком пил иру ю тся MIDL. К ом пил ятор MIDL производ итисход ныеф ай л ы наC и ф ай л ы стабов. Д алее сл ед у ет обычный д л я л ю бого прил ож ения процесс разработки: ком пил иру ю тся ф ай л ы языкаC и ком пону ю тся объ ектные м од у л и с библ иотекам и д л я созд ания испол няем ых програм м . Д л я распред ел енного прил ож ения «П ривет, м ир» , разработчик созд ает сл ед у ю щ иеисход ныеф ай л ы: • • • •

HELLOC.C HELLOS.C HELLOP.C HELLO.IDL

29

• HELLO.ACF К ом пил ятор MIDL испол ьзу етф ай л ы HELLO.IDL и HELLO.ACF д л я генерации исход ного ф ай л акл иентского стабаHELLO_C.C, исход ного ф ай л асерверного стабаHELLO_S.C и ф ай л загол овкаHELLO.H, который всвою очеред ь вкл ю чаетзаголовочный ф ай л RPC.H. И спол няем ая програм м акл иентастроится из кл иентской библ иотеки врем ени выпол нения и сл ед у ю щ их ф ай л овнаязыкеC, загол овочного и исход ных: • HELLO.H • HELLOC.C • HELLO_C.C (кл иентский стаб) И спол няем ая програм м асерверастроится из серверной библ иотеки врем ени выпол нения и сл ед у ю щ их ф ай ловнаязыкеC, заголовочного и исход ных: • • • •

HELLO.H HELLOS.C HELLOP.C HELLO_S.C (серверный стаб)

Н иж е перечисл ены задачи, выпол няем ые впроцессе разработки с испол ьзованием Microsoft RPC: 1. С озд ание ф ай л а на языке опред ел ения интерф ей сов, который опред ел яет ид ентиф икацию интерф ей са, типы д анных и ф у нкциональные прототипы д л я у д ал енных процед у р. 2. С озд аниеф ай л аконф игу рации прил ож ения. 3. К ом пил яция опред ел ения интерф ей сас испол ьзованием MIDL. К ом пил ятор MIDL генериру ет ф ай л ы наязыке C д л я стабови заголовочные ф ай л ад л я кл иентаи сервера. 4. В кл ю чение (include) заголовочных ф ай лов, сгенерированных ком пил ятором MIDL впрограм м ы сервераи кл иента. 5. Н аписаниеисход ного текстапрограм м ы сервера, которая вызываетф у нкции RPC, чтобы сд ел ать инф орм ацию связывания д осту пной кл иенту , затем вызывает RpcServerListen д л я начал апросл у ш ивания кл иентских запросов. О беспечением етод аостановки сервера. 6. К ом поновка кл иента с ф ай лом кл иентского стаба и кл иентской RPCбибл иотекой врем ени выпол нения. 7. К ом поновкасерверас ф ай лом серверного стаба, у д ал енным и процед у рам и и серверной RPC-библ иотекой врем ени выпол нения.

30

П ра кти ч ески еза д а ни я 1. С ред ствам и MS RPC реал изу й тераспред ел енноеприлож ение, вкотором сервер сл у ж ит д л я вед ения ж у рналасобытий , происход ящ их настороне кл иентов, с под д ерж кой процед у ры их регистрации. 2. С ред ствам и MS RPC реал изу й тераспред ел енноеприлож ение, вкотором сервер сл у ж ит централ изованным хранил ищ ем ф ай л овкл иентови под д ерж ивает ф у нкции каталогаф ай л ов, атакж е процед у ру регистрации кл иентови авторизации сохраняем ой инф орм ации. 3. С ред ствам и MS RPC реал изу й те распред ел енное прил ож ение с сервером –вычисл ител ем , хранящ им библ иотеку м атем атических ф у нкций . С ервер д ол ж ен вести ж у рнал своей загру зки, изм еряя врем я посту пл ения запросовкл иентови прод ол ж ител ьностьработы по их у д овл етворению . 4. С ред ствам и MS RPC реал изу й тераспред ел енноеприлож ение, вкотором сервер испол няет рол ь архиватора, под д ерж ивая ф у нкции сж атия кл иентских потоковд анных без потери инф орм ации. Ал горитм ы ком прессии/д еком прессии выберитесам и. 5. С ред ствам и MS RPC реал изу й тераспред ел енноеприлож ение, вкотором сервер выпол няет ф у нкции ш иф рования кл иентских потоковд анных од ним (а возм ож но – нескол ьким и, по запросу кл иента) из известных вам ал горитм ов. Запросы нарасш иф ровку д анных д ол ж ны сопровож д аться процед у рой регистрации кл иентов. 6. С ред ствам и MS RPC реализу й тераспред ел енное прил ож ение с безопасным обм еном инф орм ацией по сети: перед аваем ые потоки д анных д ол ж ны ш иф роваться каким -л ибо из известных вам способов. 7. С ред ствам и MS RPC реал изу й те распред ел енное прил ож ение с интенсивным обм еном д анным и, вкотором вцел ях сниж ения сетевого траф ика, перед аваем ые потоки д анных сж им аю тся без потери инф орм ации. Ал горитм ы ком прессии/д еком прессии выберитесам и. 8. С ред ствам и MS RPC реал изу й те асинхронный парал л ел ьный вычисл ител ьный процесс враспред ел енном прил ож ении: кл иентпод готавл иваетм ассив д анных и перед ает его серверу , запу ская процед у ру обработки (наваш е у см отрение). Д алее кл иент генериру ет сл ед у ю щ ий м ассив, атакж е производ ит период ический опрос сервера на пред м ет заверш ения обработки и готовности д анных к возвращ ению кл иенту . 9. С ред ствам и MS RPC реализу й те распред ел енное прил ож ение – м од ел ь сл у ж бы врем ени: кл иенты период ически синхронизиру ю т свои тай м еры с врем енем насервере; сервер у станавл иваетсвой тай м ер, у сред няя врем я, сообщ аем ое кл иентам и. К аким образом ваш асистем ау читывает зад ерж ки нареал изацию у д аленных вызовов? 10. С ред ствам и MS RPC реализу й те м од ел ь «проф ай л ера» распред ел енного прил ож ения – сред ства, позволяю щ его изм ерять врем я испол нения у д ал енных вызововс разл ичным и типам и парам етрови при разл ичных способах разм ещ ения кл иентаи сервера, атакж е– взависим ости отвыборатранспорта.

31

С оставител ьФ ертиковВ ад им В алериевич Ред актор Бу нинаТ .Д .