kcii. Esli struktura obnaruzhena, yadro vychitaet znachenie proizvedennoj nad semaforom operacii iz ustanovochnogo znacheniya. Takim obrazom, v strukture vosstanovle- niya hranitsya rezul'tat vychitaniya summy znachenij vseh operacij, proizvedennyh nad semaforom, dlya kotorogo ustanovlen flag SEM_UNDO. Esli sootvetstvuyushchej struktury net, yadro sozdaet ee, sortiruya pri etom spisok struktur po identi- fikatoram i nomeram semaforov. Esli ustanovochnoe znachenie stanovitsya ravnym 0, yadro udalyaet strukturu iz spiska. Kogda process zavershaetsya, yadro vyzyva- +---------------++-------+ +---------------++-------+-------+ | identifikator || | | identifikator || | | | semafora || semid | | semafora || semid | semid | +---------------++-------+ +---------------++-------+-------+ | nomer semafora|| 0 | | nomer semafora|| 0 | 1 | +---------------++-------+ +---------------++-------+-------+ | ustanovochnoe || | | ustanovochnoe || | | | znachenie || 1 | | znachenie || 1 | 1 | +---------------++-------+ +---------------++-------+-------+ (a) Posle pervoj operacii (b) Posle vtoroj operacii +---------------++-------+ | identifikator || | | semafora || semid | +---------------++-------+ | nomer semafora|| 0 | pusto +---------------++-------+ | ustanovochnoe || | | znachenie || 1 | +---------------++-------+ (v) Posle tret'ej operacii (g) Posle chetvertoj operacii Risunok 11.17. Posledovatel'nost' sostoyanij spiska struktur vosstanovleniya 352 et special'nuyu proceduru, kotoraya prosmatrivaet vse svyazannye s processom struktury vosstanovleniya i vypolnyaet nad ukazannym semaforom vse obuslovlen- nye dejstviya. YAdro sozdaet strukturu vosstanovleniya vsyakij raz, kogda process umen'sha- et znachenie semafora, a udalyaet ee, kogda process uvelichivaet znachenie sema- fora, poskol'ku ustanovochnoe znachenie struktury ravno 0. Na Risunke 11.17 pokazana posledovatel'nost' sostoyanij spiska struktur pri vypolnenii programmy s parametrom 'a'. Posle pervoj ope- racii process imeet odnu strukturu, sostoyashchuyu iz identifikatora semid, nome- ra semafora, ravnogo 0, i ustanovochnogo znacheniya, ravnogo 1, a posle vtoroj operacii poyavlyaetsya vtoraya struktura s nomerom semafora, ravnym 1, i ustano- vochnym znacheniem, ravnym 1. Esli process neozhidanno zavershaetsya, yadro proho- dit po vsem strukturam i pribavlyaet k kazhdomu semaforu po edinice, vossta- navlivaya ih znacheniya v 0. V chastnom sluchae yadro umen'shaet ustanovochnoe zna- chenie dlya semafora 1 na tret'ej operacii, v sootvetstvii s uvelicheniem zna- cheniya samogo semafora, i udalyaet vsyu strukturu celikom, poskol'ku ustanovoch- noe znachenie stanovitsya nulevym. Posle chetvertoj operacii u processa bol'she net struktur vosstanovleniya, poskol'ku vse ustanovochnye znacheniya stali nule- vymi. Vektornye operacii nad semaforami pozvolyayut izbezhat' vzaimnyh blokiro- vok, kak bylo pokazano vyshe, odnako oni predstavlyayut izvestnuyu trudnost' dlya ponimaniya i realizacii, i v bol'shinstve prilozhenij polnyj nabor ih vozmozh- nostej ne yavlyaetsya obyazatel'nym. Programmy, ispytyvayushchie potrebnost' v is- pol'zovanii nabora semaforov, stalkivayutsya s vozniknoveniem vzaimnyh bloki- rovok na pol'zovatel'skom urovne, i yadru uzhe net neobhodimosti podderzhivat' takie slozhnye formy sistemnyh funkcij. Sintaksis vyzova sistemnoj funkcii semctl: semctl(id,number,cmd,arg); Parametr arg ob®yavlen kak ob®edinenie tipov dannyh: union semunion { int val; struct semid_ds *semstat; /* opisanie tipov sm. v Pri- * lozhenii */ unsigned short *array; } arg; YAdro interpretiruet parametr arg v zavisimosti ot znacheniya parametra cmd, podobno tomu, kak interpretiruet komandy ioctl (glava 10). Tipy dejst- vij, kotorye mogut ispol'zovat'sya v parametre cmd: poluchit' ili ustanovit' znacheniya upravlyayushchih parametrov (prava dostupa i dr.), ustanovit' znacheniya odnogo ili vseh semaforov v nabore, prochitat' znacheniya semaforov. Podrobnos- ti po kazhdomu dejstviyu soderzhatsya v Prilozhenii. Esli ukazana komanda udale- niya, IPC_RMID, yadro vedet poisk vseh processov, soderzhashchih struktury vossta- novleniya dlya dannogo semafora, i udalyaet sootvetstvuyushchie struktury iz siste- my. Zatem yadro inicializiruet ispol'zuemye semaforom struktury dannyh i vy- vodit iz sostoyaniya priostanova vse processy, ozhidayushchie nastupleniya nekotoro- go svyazannogo s semaforom sobytiya: kogda processy vozobnovlyayut svoe vypolne- nie, oni obnaruzhivayut, chto identifikator semafora bol'she ne yavlyaetsya korrek- tnym, i vozvrashchayut vyzyvayushchej programme oshibku. 11.2.4 Obshchie zamechaniya Mehanizm funkcionirovaniya fajlovoj sistemy i mehanizmy vzaimodejstviya 353 processov imeyut ryad obshchih chert. Sistemnye funkcii tipa "get" pohozhi na funk- cii creat i open, funkcii tipa "control" predostavlyayut vozmozhnost' udalyat' deskriptory iz sistemy, chem pohozhi na funkciyu unlink. Tem ne menee, v meha- nizmah vzaimodejstviya processov otsutstvuyut operacii, analogichnye operaciyam, vypolnyaemym sistemnoj funkciej close. Sledovatel'no, yadro ne raspolagaet svedeniyami o tom, kakie processy mogut ispol'zovat' mehanizm IPC, i, dejst- vitel'no, processy mogut pribegat' k uslugam etogo mehanizma, esli pravil'no ugadyvayut sootvetstvuyushchij identifikator i esli u nih imeyutsya neobhodimye prava dostupa, dazhe esli oni ne vypolnili predvaritel'no funkciyu tipa "get". YAdro ne mozhet avtomaticheski ochishchat' neispol'zuemye struktury mehanizma vzai- modejstviya processov, poskol'ku yadru neizvestno, kakie iz etih struktur bol'she ne nuzhny. Takim obrazom, zavershivshiesya vsledstvie vozniknoveniya oshib- ki processy mogut ostavit' posle sebya nenuzhnye i neispol'zuemye struktury, peregruzhayushchie i zasoryayushchie sistemu. Nesmotrya na to, chto v strukturah meha- nizma vzaimodejstviya posle zaversheniya sushchestvovaniya processa yadro mozhet soh- ranit' informaciyu o sostoyanii i dannye, luchshe vse-taki dlya etih celej is- pol'zovat' fajly. Vmesto tradicionnyh, poluchivshih shirokoe rasprostranenie fajlov mehanizmy vzaimodejstviya processov ispol'zuyut novoe prostranstvo imen, sostoyashchee iz klyuchej (keys). Rasshirit' semantiku klyuchej na vsyu set' dovol'no trudno, pos- kol'ku na raznyh mashinah klyuchi mogut opisyvat' razlichnye ob®ekty. Koroche go- vorya, klyuchi v osnovnom prednaznacheny dlya ispol'zovaniya v odnomashinnyh siste- mah. Imena fajlov v bol'shej stepeni podhodyat dlya raspredelennyh sistem (sm. glavu 13). Ispol'zovanie klyuchej vmesto imen fajlov takzhe svidetel'stvuet o tom, chto sredstva vzaimodejstviya processov yavlyayutsya "veshch'yu v sebe", poleznoj v special'nyh prilozheniyah, no ne imeyushchej teh vozmozhnostej, kotorymi oblada- yut, naprimer, kanaly i fajly. Bol'shaya chast' funkcional'nyh vozmozhnostej, predostavlyaemyh dannymi sredstvami, mozhet byt' realizovana s pomoshch'yu drugih sistemnyh sredstv, poetomu vklyuchat' ih v sostav yadra vryad li sledovalo by. Tem ne menee, ih ispol'zovanie v sostave paketov prikladnyh programm tesnogo vzaimodejstviya daet luchshie rezul'taty po sravneniyu so standartnymi fajlovymi sredstvami (sm. Uprazhneniya). 11.3 VZAIMODEJSTVIE V SETI Programmy, podderzhivayushchie mezhmashinnuyu svyaz', takie, kak elektronnaya poch- ta, programmy distancionnoj peresylki fajlov i udalennoj registracii, izdav- na ispol'zuyutsya v kachestve special'nyh sredstv organizacii podklyuchenij i in- formacionnogo obmena. Tak, naprimer, standartnye programmy, rabotayushchie v sostave elektronnoj pochty, sohranyayut tekst pochtovyh soobshchenij pol'zovatelya v otdel'nom fajle (dlya pol'zovatelya "mjb" etot fajl imeet imya "/usr/mail/mjb"). Kogda odin pol'zovatel' posylaet drugomu pochtovoe soobshche- nie na tu zhe mashinu, programma mail (pochta) dobavlyaet soobshchenie v konec faj- la adresata, ispol'zuya v celyah sohraneniya celostnosti razlichnye blokiruyushchie i vremennye fajly. Kogda adresat poluchaet pochtu, programma mail otkryvaet prinadlezhashchij emu pochtovyj fajl i chitaet soobshcheniya. Dlya togo, chtoby poslat' soobshchenie na druguyu mashinu, programma mail dolzhna v konechnom itoge otyskat' na nej sootvetstvuyushchij pochtovyj fajl. Poskol'ku programma ne mozhet rabotat' s udalennymi fajlami neposredstvenno, process, protekayushchij na drugoj mashine, dolzhen dejstvovat' v kachestve agenta lokal'nogo pochtovogo processa; sledova- tel'no, lokal'nomu processu neobhodim sposob svyazi so svoim udalennym agen- tom cherez mezhmashinnye granicy. Lokal'nyj process yavlyaetsya klientom udalenno- go obsluzhivayushchego (servernogo) processa. Poskol'ku v sisteme UNIX novye processy sozdayutsya s pomoshch'yu sistemnoj funkcii fork, k tomu momentu, kogda klient popytaetsya vypolnit' podklyuchenie, obsluzhivayushchij process uzhe dolzhen sushchestvovat'. Esli by v moment sozdaniya no- vogo processa udalennoe yadro poluchalo zapros na podklyuchenie (po kanalam mezh- mashinnoj svyazi), voznikla by nesoglasovannost' s arhitekturoj sistemy. CHtoby 354 izbezhat' etogo, nekij process, obychno init, porozhdaet obsluzhivayushchij process, kotoryj vedet chtenie iz kanala svyazi, poka ne poluchaet zapros na obsluzhiva- nie, posle chego v sootvetstvii s nekotorym protokolom vypolnyaet ustanovku soedineniya. Vybor setevyh sredstv i protokolov obychno vypolnyayut programmy klienta i servera, osnovyvayas' na informacii, hranyashchejsya v prikladnyh bazah dannyh; s drugoj storony, vybrannye pol'zovatelem sredstva mogut byt' zako- dirovany v samih programmah. V kachestve primera rassmotrim programmu uucp, kotoraya obsluzhivaet pere- sylku fajlov v seti i ispolnenie komand na udalenii (sm. [Nowitz 80]). Pro- cess-klient zaprashivaet v baze dannyh adres i druguyu marshrutnuyu informaciyu (naprimer, nomer telefona), otkryvaet avtokommutator, zapisyvaet ili prove- ryaet informaciyu v deskriptore otkryvaemogo fajla i vyzyvaet udalennuyu mashi- nu. Udalennaya mashina mozhet imet' special'nye linii, vydelennye dlya ispol'zo- vaniya programmoj uucp; vypolnyayushchijsya na etoj mashine process init porozhdaet getty-processy - servery, kotorye upravlyayut liniyami i poluchayut izveshcheniya o podklyucheniyah. Posle vypolneniya apparatnogo podklyucheniya process-klient regis- triruetsya v sisteme v sootvetstvii s obychnym protokolom registracii: getty-process zapuskaet special'nyj interpretator komand, uucico, ukazannyj v fajle "/etc/passwd", a process-klient peredaet na udalennuyu mashinu posle- dovatel'nost' komand, tem samym zastavlyaya ee ispolnyat' processy ot imeni lo- kal'noj mashiny. Setevoe vzaimodejstvie v sisteme UNIX predstavlyaet ser'eznuyu problemu, poskol'ku soobshcheniya dolzhny vklyuchat' v sebya kak informacionnuyu, tak i uprav- lyayushchuyu chasti. V upravlyayushchej chasti soobshcheniya mozhet raspolagat'sya adres nazna- cheniya soobshcheniya. V svoyu ochered', struktura adresnyh dannyh zavisit ot tipa seti i ispol'zuemogo protokola. Sledovatel'no, processam nuzhno znat' tip se- ti, a eto idet vrazrez s tem principom, po kotoromu pol'zovateli ne dolzhny obrashchat' vnimaniya na tip fajla, ibo vse ustrojstva dlya pol'zovatelej vyglya- dyat kak fajly. Tradicionnye metody realizacii setevogo vzaimodejstviya pri ustanovke upravlyayushchih parametrov v sil'noj stepeni polagayutsya na pomoshch' sis- temnoj funkcii ioctl, odnako v raznyh tipah setej etot moment voploshchaetsya po-raznomu. Otsyuda voznikaet nezhelatel'nyj pobochnyj effekt, svyazannyj s tem, chto programmy, razrabotannye dlya odnoj seti, v drugih setyah mogut ne zarabo- tat'. CHtoby razrabotat' setevye interfejsy dlya sistemy UNIX, byli predprinyaty znachitel'nye usiliya. Realizaciya potokov v poslednih redakciyah versii V ras- polagaet elegantnym mehanizmom podderzhki setevogo vzaimodejstviya, obespechi- vayushchim gibkoe sochetanie otdel'nyh modulej protokolov i ih soglasovannoe is- pol'zovanie na urovne zadach. Sleduyushchij razdel posvyashchen kratkomu opisaniyu me- toda resheniya dannyh problem v sisteme BSD, osnovannogo na ispol'zovanii gnezd. 11.4 GNEZDA V predydushchem razdele bylo pokazano, kakim obrazom vzaimodejstvuyut mezhdu soboj processy, protekayushchie na raznyh mashinah, pri etom obrashchalos' vnimanie na to, chto sposoby realizacii vzaimodejstviya mogut byt' razlichat'sya v zavi- simosti ot ispol'zuemyh protokolov i setevyh sredstv. Bolee togo, eti sposo- by ne vsegda primenimy dlya obsluzhivaniya vzaimodejstviya processov, vypolnyayu- shchihsya na odnoj i toj zhe mashine, poskol'ku v nih predpolagaetsya sushchestvovanie obsluzhivayushchego (servernogo) processa, kotoryj pri vypolnenii sistemnyh funk- cij open ili read budet priostanavlivat'sya drajverom. V celyah sozdaniya bolee universal'nyh metodov vzaimodejstviya processov na osnove ispol'zovaniya mno- gourovnevyh setevyh protokolov dlya sistemy BSD byl razrabotan mehanizm, po- luchivshij nazvanie "sockets" (gnezda) (sm. [Berkeley 83]). V dannom razdele my rassmotrim nekotorye aspekty primeneniya gnezd (na pol'zovatel'skom urovne predstavleniya). 355 Process-klient Process-server | | +--+ +--+ +-------------------------+--+ +--+--------------------------+ | Uroven' gnezd | | Uroven' gnezd | +-------------------------+--+ +--+--------------------------+ | TCP | | TCP | | Uroven' protokolov | | | | Uroven' protokolov | | IP | | IP | +-------------------------+--+ +--+--------------------------+ | Drajver| | Drajver | | Uroven' ustrojstv Ethernet| |Ethernet Uroven' ustrojstv | +-------------------------+--+ +--+--------------------------+ +---+ +---+ | | S e t ' Risunok 11.18. Model' s ispol'zovaniem gnezd Struktura yadra imeet tri urovnya: gnezd, protokolov i ustrojstv (Risunok 11.18). Uroven' gnezd vypolnyaet funkcii interfejsa mezhdu obrashcheniyami k ope- racionnoj sisteme (sistemnym funkciyam) i sredstvami nizkih urovnej, uroven' protokolov soderzhit moduli, obespechivayushchie vzaimodejstvie processov (na ri- sunke upomyanuty protokoly TCP i IP), a uroven' ustrojstv soderzhit drajvery, upravlyayushchie setevymi ustrojstvami. Dopustimye sochetaniya protokolov i drajve- rov ukazyvayutsya pri postroenii sistemy (v sekcii konfiguracii); etot sposob ustupaet po gibkosti vysheupomyanutomu potokovomu mehanizmu. Processy vzaimo- dejstvuyut mezhdu soboj po sheme klient-server: server zhdet signala ot gnezda, nahodyas' na odnom konce dupleksnoj linii svyazi, a processy-klienty vzaimo- dejstvuyut s serverom cherez gnezdo, nahodyashcheesya na drugom konce, kotoryj mo- zhet raspolagat'sya na drugoj mashine. YAdro obespechivaet vnutrennyuyu svyaz' i pe- redaet dannye ot klienta k serveru. Gnezda, obladayushchie odinakovymi svojstvami, naprimer, opirayushchiesya na ob- shchie soglasheniya po identifikacii i formaty adresov (v protokolah), gruppiru- yutsya v domeny (upravlyaemye odnim uzlom). V sisteme BSD 4.2 podderzhivayutsya domeny: "UNIX system" - dlya vzaimodejstviya processov vnutri odnoj mashiny i "Internet" (mezhsetevoj) - dlya vzaimodejstviya cherez set' s pomoshch'yu protokola DARPA (Upravlenie perspektivnyh issledovanij i razrabotok Ministerstva obo- rony SSHA) (sm. [Postel 80] i [Postel 81]). Gnezda byvayut dvuh tipov: virtu- al'nyj kanal (potokovoe gnezdo, esli pol'zovat'sya terminologiej Berkli) i dejtagramma. Virtual'nyj kanal obespechivaet nadezhnuyu dostavku dannyh s soh- raneniem ishodnoj posledovatel'nosti. Dejtagrammy ne garantiruyut nadezhnuyu dostavku s sohraneniem unikal'nosti i posledovatel'nosti, no oni bolee eko- nomny v smysle ispol'zovaniya resursov, poskol'ku dlya nih ne trebuyutsya slozh- nye ustanovochnye operacii; takim obrazom, dejtagrammy polezny v otdel'nyh sluchayah vzaimodejstviya. Dlya kazhdoj dopustimoj kombinacii tipa domen-gnezdo v sisteme podderzhivaetsya umolchanie na ispol'zuemyj protokol. Tak, naprimer, dlya domena "Internet" uslugi virtual'nogo kanala vypolnyaet protokol trans- portnoj svyazi (TCP), a funkcii dejtagrammy - pol'zovatel'skij dejtagrammnyj protokol (UDP). Sushchestvuet neskol'ko sistemnyh funkcij raboty s gnezdami. Funkciya socket ustanavlivaet okonechnuyu tochku linii svyazi. sd = socket(format,type,protocol); Format oboznachaet domen ("UNIX system" ili "Internet"), type - tip svyazi che- rez gnezdo (virtual'nyj kanal ili dejtagramma), a protocol - tip protokola, upravlyayushchego vzaimodejstviem. Deskriptor gnezda sd, vozvrashchaemyj funkciej socket, ispol'zuetsya drugimi sistemnymi funkciyami. Zakrytie gnezd vypolnyaet 356 funkciya close. Funkciya bind svyazyvaet deskriptor gnezda s imenem: bind(sd,address,length); gde sd - deskriptor gnezda, address - adres struktury, opredelyayushchej identi- fikator, harakternyj dlya dannoj kombinacii domena i protokola (v funkcii socket). Length - dlina struktury address; bez etogo parametra yadro ne znalo by, kakova dlina struktury, poskol'ku dlya raznyh domenov i protokolov ona mozhet byt' razlichnoj. Naprimer, dlya domena "UNIX system" struktura soderzhit imya fajla. Processy-servery svyazyvayut gnezda s imenami i ob®yavlyayut o sosto- yavshemsya prisvoenii imen processam-klientam. S pomoshch'yu sistemnoj funkcii connect delaetsya zapros na podklyuchenie k su- shchestvuyushchemu gnezdu: connect(sd,address,length); Semanticheskij smysl parametrov funkcii ostaetsya prezhnim (sm. funkciyu bind), no address ukazyvaet uzhe na vyhodnoe gnezdo, obrazuyushchee protivopolozhnyj ko- nec linii svyazi. Oba gnezda dolzhny ispol'zovat' odni i te zhe domen i proto- kol svyazi, i togda yadro udostoverit pravil'nost' ustanovki linii svyazi. Esli tip gnezda - dejtagramma, soobshchaemyj funkciej connect yadru adres budet is- pol'zovat'sya v posleduyushchih obrashcheniyah k funkcii send cherez dannoe gnezdo; v moment vyzova nikakih soedinenij ne proizvoditsya. Poka process-server gotovitsya k priemu svyazi po virtual'nomu kanalu, yad- ru sleduet vystroit' postupayushchie zaprosy v ochered' na obsluzhivanie. Maksi- mal'naya dlina ocheredi zadaetsya s pomoshch'yu sistemnoj funkcii listen: listen(sd,qlength) gde sd - deskriptor gnezda, a qlength - maksimal'no-dopustimoe chislo zapro- sov, ozhidayushchih obrabotki. +--------------------+ +-------------------------+ | Process-klient | | Process-server | | | | | | - | | | | | +----+ ------ | | | | | | - | | | | |listen addr accept addr| +---------+----------+ +-----+-------------------+ | | - +--------------------------+------------- Risunok 11.19. Priem vyzova serverom Sistemnaya funkciya accept prinimaet zaprosy na podklyuchenie, postupayushchie na vhod processa-servera: nsd = accept(sd,address,addrlen); gde sd - deskriptor gnezda, address - ukazatel' na pol'zovatel'skij massiv, v kotorom yadro vozvrashchaet adres podklyuchaemogo klienta, addrlen - razmer pol'zovatel'skogo massiva. Po zavershenii vypolneniya funkcii yadro zapisyvaet v peremennuyu addrlen razmer prostranstva, fakticheski zanyatogo massivom. Fun- kciya vozvrashchaet novyj deskriptor gnezda (nsd), otlichnyj ot deskriptora sd. Process-server mozhet prodolzhat' slezhenie za sostoyaniem ob®yavlennogo gnezda, podderzhivaya svyaz' s klientom po otdel'nomu kanalu (Risunok 11.19). 357 Funkcii send i recv vypolnyayut peredachu dannyh cherez podklyuchennoe gnezdo. Sintaksis vyzova funkcii send: count = send(sd,msg,length,flags); gde sd - deskriptor gnezda, msg - ukazatel' na posylaemye dannye, length - razmer dannyh, count - kolichestvo fakticheski peredannyh bajt. Parametr flags mozhet soderzhat' znachenie SOF_OOB (poslat' dannye out-of-band - "cherez tamozh- nyu"), esli posylaemye dannye ne uchityvayutsya v obshchem informacionnom obmene mezhdu vzaimodejstvuyushchimi processami. Programma udalennoj registracii, napri- mer, mozhet poslat' out-of-band soobshchenie, imitiruyushchee nazhatie na klaviature terminala klavishi "delete". Sintaksis vyzova sistemnoj funkcii recv: count = recv(sd,buf,length,flags); gde buf - massiv dlya priema dannyh, length - ozhidaemyj ob®em dannyh, count - kolichestvo bajt, fakticheski peredannyh pol'zovatel'skoj programme. Flagi (flags) mogut byt' ustanovleny takim obrazom, chto postupivshee soobshchenie pos- le chteniya i analiza ego soderzhimogo ne budet udaleno iz ocheredi, ili nastro- eny na poluchenie dannyh out-of-band. V dejtagrammnyh versiyah ukazannyh funk- cij, sendto i recvfrom, v kachestve dopolnitel'nyh parametrov ukazyvayutsya ad- resa. Posle vypolneniya podklyucheniya k gnezdam potokovogo tipa processy mogut vmesto funkcij send i recv ispol'zovat' funkcii read i write. Takim obrazom, soglasovav tip protokola, servery mogli by porozhdat' processy, rabotayushchie tol'ko s funkciyami read i write, slovno imeyut delo s obychnymi fajlami. Funkciya shutdown zakryvaet gnezdovuyu svyaz': shutdown(sd,mode) gde mode ukazyvaet, kakoj iz storon (posylayushchej, prinimayushchej ili obeim vmes- te) otnyne zapreshcheno uchastie v processe peredachi dannyh. Funkciya soobshchaet ispol'zuemomu protokolu o zavershenii seansa setevogo vzaimodejstviya, ostav- lyaya, tem ne menee, deskriptory gnezd v neprikosnovennosti. Osvobozhdaetsya deskriptor gnezda tol'ko v rezul'tate vypolneniya funkcii close. Sistemnaya funkciya getsockname poluchaet imya gnezdovoj svyazi, ustanovlen- noj ranee s pomoshch'yu funkcii bind: getsockname(sd,name,length); Funkcii getsockopt i setsockopt poluchayut i ustanavlivayut znacheniya raz- lichnyh svyazannyh s gnezdom parametrov v sootvetstvii s tipom domena i proto- kola. Rassmotrim obsluzhivayushchuyu programmu, predstavlennuyu na Risunke 11.20. Process sozdaet v domene "UNIX system" gnezdo potokovogo tipa i prisvaivaet emu imya sockname. Zatem s pomoshch'yu funkcii listen ustanavlivaetsya dlina oche- redi postupayushchih soobshchenij i nachinaetsya cikl ozhidaniya postupleniya zaprosov. Funkciya accept priostanavlivaet svoe vypolnenie do teh por, poka protokolom ne budet zaregistrirovan zapros na podklyuchenie k gnezdu s oznachennym imenem; posle etogo funkciya zavershaetsya, vozvrashchaya postupivshemu zaprosu novyj desk- riptor gnezda. Process-server porozhdaet potomka, cherez kotorogo budet pod- derzhivat'sya svyaz' s processom-klientom; roditel' i potomok pri etom zakryva- yut svoi deskriptory, chtoby oni ne stanovilis' pomehoj dlya kommunikacionnogo traffika drugogo processa. Process-potomok vedet razgovor s klientom i za- vershaetsya posle vyhoda iz funkcii read. Process-server vozvrashcha- etsya k nachalu cikla i zhdet postupleniya sleduyushchego zaprosa na podklyuchenie. Na Risunke 11.21 pokazan primer processa-klienta, vedushchego obshchenie s serverom. Klient sozdaet gnezdo v tom zhe domene, chto i server, i posylaet zapros na podklyuchenie k gnezdu s imenem sockname. V rezul'tate podklyucheniya 358 +------------------------------------------------------------+ | #include | | #include | | | | main() | | { | | int sd,ns; | | char buf[256]; | | struct sockaddr sockaddr; | | int fromlen; | | | | sd = socket(AF_UNIX,SOCK_STREAM,0); | | | | /* imya gnezda - ne mozhet vklyuchat' pustoj simvol */ | | bind(sd,"sockname",sizeof("sockname") - 1); | | listen(sd,1); | | | | for (;;) | | { | | | | ns = accept(sd,&sockaddr,&fromlen); | | if (fork() == 0) | | { | | /* potomok */ | | close(sd); | | read(ns,buf,sizeof(buf)); | | printf("server chitaet '%s'\n",buf); | | exit(); | | } | | close(ns); | | } | | } | +------------------------------------------------------------+ Risunok 11.20. Process-server v domene "UNIX system" +------------------------------------------------------------+ | #include | | #include | | | | main() | | { | | int sd,ns; | | char buf[256]; | | struct sockaddr sockaddr; | | int fromlen; | | | | sd = socket(AF_UNIX,SOCK_STREAM,0); | | | | /* imya v zaprose na podklyuchenie ne mozhet vklyuchat' | | /* pustoj simvol */ | | if (connect(sd,"sockname",sizeof("sockname") - 1) == -1)| | exit(); | | | | write(sd,"hi guy",6); | | } | +------------------------------------------------------------+ Risunok 11.21. Process-klient v domene "UNIX system" 359 process-klient poluchaet virtual'nyj kanal svyazi s serverom. V rassmatrivae- mom primere klient peredaet odno soobshchenie i zavershaetsya. Esli server obsluzhivaet processy v seti, ukazanie o tom, chto gnezdo pri- nadlezhit domenu "Internet", mozhno sdelat' sleduyushchim obrazom: socket(AF_INET,SOCK_STREAM,0); i svyazat'sya s setevym adresom, poluchennym ot servera. V sisteme BSD imeyutsya bibliotechnye funkcii, vypolnyayushchie eti dejstviya. Vtoroj parametr vyzyvaemoj klientom funkcii connect soderzhit adresnuyu informaciyu, neobhodimuyu dlya iden- tifikacii mashiny v seti (ili adresa marshrutov posylki soobshchenij cherez prome- zhutochnye mashiny), a takzhe dopolnitel'nuyu informaciyu, identificiruyushchuyu priem- noe gnezdo mashiny-adresata. Esli serveru nuzhno odnovremenno sledit' za sos- toyaniem seti i vypolneniem lokal'nyh processov, on ispol'zuet dva gnezda i s pomoshch'yu funkcii select opredelyaet, s kakim klientom ustanavlivaetsya svyaz' v dannyj moment. 11.5 VYVODY My rassmotreli neskol'ko form vzaimodejstviya processov. Pervoj formoj, polozhivshej nachalo obsuzhdeniyu, yavilas' trassirovka processov - vzaimodejstvie dvuh processov, vystupayushchee v kachestve poleznogo sredstva otladki programm. Pri vseh svoih preimushchestvah trassirovka processov s pomoshch'yu funkcii ptrace vse zhe dostatochno dorogostoyashchee i primitivnoe meropriyatie, poskol'ku za odin seans funkciya sposobna peredat' strogo ogranichennyj ob®em dannyh, trebuetsya bol'shoe kolichestvo pereklyuchenij konteksta, vzaimodejstvie ogranichivaetsya tol'ko formoj otnoshenij roditel'-potomok, i nakonec, sama trassirovka proiz- voditsya tol'ko po oboyudnomu soglasiyu uchastvuyushchih v nej processov. V versii V sistemy UNIX imeetsya paket vzaimodejstviya processov (IPC), vklyuchayushchij v sebya mehanizmy obmena soobshcheniyami, raboty s semaforami i razdeleniya pamyati. K so- zhaleniyu, vse eti mehanizmy imeyut uzkospecial'noe naznachenie, ne imeyut horo- shej stykovki s drugimi elementami operacionnoj sistemy i ne dejstvuyut v se- ti. Tem ne menee, oni ispol'zuyutsya vo mnogih prilozheniyah i po sravneniyu s drugimi shemami otlichayutsya bolee vysokoj effektivnost'yu. Sistema UNIX podderzhivaet shirokij spektr vychislitel'nyh setej. Tradici- onnye metody soglasovaniya protokolov v sil'noj stepeni polagayutsya na pomoshch' sistemnoj funkcii ioctl, odnako v raznyh tipah setej oni realizuyutsya po-raz- nomu. V sisteme BSD imeyutsya sistemnye funkcii dlya raboty s gnezdami, podder- zhivayushchie bolee universal'nuyu strukturu setevogo vzaimodejstviya. V budushchem v versiyu V predpolagaetsya vklyuchit' opisannyj v glave 10 potokovyj mehanizm, povyshayushchij soglasovannost' raboty v seti. 11.6 UPRAZHNENIYA 1. CHto proizojdet v tom sluchae, esli v programme debug budet otsutstvovat' vyzov funkcii wait (Risunok 11.3) ? (Namek: vozmozhny dva ishoda.) 2. S pomoshch'yu funkcii ptrace otladchik schityvaet dannye iz prostranstva trassiruemogo processa po odnomu slovu za odnu operaciyu. Kakie izmene- niya sleduet proizvesti v yadre operacionnoj sistemy dlya togo, chtoby uve- lichit' kolichestvo schityvaemyh slov ? Kakie izmeneniya pri etom neobhodi- mo sdelat' v samoj funkcii ptrace ? 3. Rasshir'te oblast' dejstviya funkcii ptrace tak, chtoby v kachestve para- metra pid mozhno bylo ukazyvat' identifikator processa, ne yavlyayushchegosya potomkom tekushchego processa. Podumajte nad voprosami, svyazannymi s zashchi- toj informacii: Pri kakih obstoyatel'stvah processu mozhet byt' pozvoleno 360 chitat' dannye iz adresnogo prostranstva drugogo, proizvol'nogo processa ? Pri kakih obstoyatel'stvah razreshaetsya vesti zapis' v adresnoe prost- ranstvo drugogo processa ? 4. Organizujte iz funkcij raboty s soobshcheniyami biblioteku pol'zovatel'sko- go urovnya s ispol'zovaniem obychnyh fajlov, poimenovannyh kanalov i ele- mentov blokirovki. Sozdavaya ochered' soobshchenij, otkrojte upravlyayushchij fajl dlya zapisi v nego informacii o sostoyanii ocheredi; zashchitite fajl s pomoshch'yu sredstv zahvata fajlov i drugih udobnyh dlya vas mehanizmov. Po- sylaya soobshchenie dannogo tipa, sozdavajte poimenovannyj kanal dlya vseh soobshchenij etogo tipa, esli takogo kanala eshche ne bylo, i peredavajte so- obshchenie cherez nego (s podschetom peredannyh bajt). Upravlyayushchij fajl dol- zhen sootnosit' tip soobshcheniya s imenem poimenovannogo kanala. Pri chtenii soobshchenij upravlyayushchij fajl napravlyaet process k sootvetstvuyushchemu poime- novannomu kanalu. Sravnite etu shemu s mehanizmom, opisannym v nastoya- shchej glave, po effektivnosti, slozhnosti realizacii i funkcional'nym voz- mozhnostyam. 5. Kakie dejstviya pytaetsya vypolnit' programma, predstavlennaya na Risunke 11.22 ? *6. Napishite programmu, kotoraya podklyuchala by oblast' razdelyaemoj pamyati slishkom blizko k vershine steka zadachi i pozvolyala by steku pri uveliche- nii peresekat' granicu razdelyaemoj oblasti. V kakoj moment proizojdet fatal'naya oshibka pamyati ? 7. Ispol'zujte v programme, predstavlennoj na Risunke 11.14, flag IPC_NOWAIT, realizuya uslovnyj tip semafora. Prodemonstrirujte, kak za schet etogo mozhno izbezhat' vozniknoveniya vzaimnyh blokirovok. 8. Pokazhite, kak operacii nad semaforami tipa P i V realizuyutsya pri rabote s poimenovannymi kanalami. Kak by vy realizovali operaciyu P uslovnogo tipa ? 9. Sostav'te programmy zahvata resursov, ispol'zuyushchie (a) poimenovannye kanaly, (b) sistemnye funkcii creat i unlink, (v) funkcii obmena soob- shcheniyami. Provedite sravnitel'nyj analiz ih effektivnosti. 10. Na prakticheskih primerah raboty s poimenovannymi kanalami sravnite ef- fektivnost' ispol'zovaniya funkcij obmena soobshcheniyami, s odnoj storony, s funkciyami read i write, s drugoj. 11. Sravnite na konkretnyh programmah skorost' peredachi dannyh pri rabote s razdelyaemoj pamyat'yu i pri ispol'zovanii mehanizma obmena soobshcheniyami. Programmy, ispol'zuyushchie razdelyaemuyu pamyat', dlya sinhronizacii zavershe- niya operacij chteniya-zapisi dolzhny opirat'sya na semafory. +------------------------------------------------------------+ | #include | | #include | | #include | | #define ALLTYPES 0 | | | | main() | | { | | struct msgform | | { | | long mtype; | | char mtext[1024]; | | } msg; | | register unsigned int id; | | | | for (id = 0; ; id++) | | while (msgrcv(id,&msg,1024,ALLTYPES,IPC_NOWAIT) > 0)| | ; | | } | +------------------------------------------------------------+ 361