3.6. Komunikace procesu

• V kapitole 3.4 bylo ukazano, jak procesy mohou komunikovat prostrednictvim sdilene pameti. Tento postup vyzaduje existenci spolecneho bufferu, ktery je explicitne vytvoren uzivatelskym programem. Jina cesta k dosazeni tehoz je v podpore komunikace procesu primo OS pres tzv interprocess-communication (IPC) facility.

• IPC umoznuje procesum komunikovat a synchronizovat sve akce. IPC vytvari system zprav. Jak sdilena pamet tak i system zprav mohou byt uzity soucasne.

• System zprav musi umoznovat minimalne 2 operace: send(zprava) a receive(zprava).

• Zpravy dorucovane systemem mohou byt promenne nebo pevne delky. Implementace prenosu pouze zprav pevne delky je narocnejsi pro programatora, na druhe strane vsak implementace prenosu zprav promenne delky vyzaduje vetsi fyzickou podporu.

• Pokud chteji procesy P a Q komunikovat, museji byt navzajem schopni prijimat a vysilat sve zpravy. Musi mezi nimi existovat komunikacni spojeni (communication link). Tot spojeni je implementovano ruzne. Hardwarovou implementaci (sdilena pamet, sbernice, sit) ponechme zatim stranou a venujme se softwareove implementaci.

• Spojeni muze byt navazano i mezi vice nez dvema procesy. Spojeni je nesmerove (undirectional), jestlize kazdy proces do nej zapojeny muze bud jen vysilat nebo jen prijimat, ale ne oboji a kazde spojeni obsahuje minimalne jednoho vysilajiciho a jednoho prijemce.

• Nasleduji ruzne logicke implementace spojeni:

1. Prima nebo neprima komunikace

2. Symetricka nebo nesymetricka komunikace

3. Automaticke nebo explicitni bufferovani

4. Posilani kopie nebo posilani odkazu

5. Zpravy pevne nebo promenne delky

• V tomto typu komunikace musi kazdy proces, ktery chce komunikovat znat jmeno prijemce. V tomto schematu je definice funkci send a receive nasledujici:

• send(P, zprava) - Posli zpravu procesu P.

• receive(Q, zprava) - Prijmi zpravu od procesu Q.

• Komunikacni spojeni v tomto schematu ma nasledujici vlastnosti:

• Spojeni je vytvoreno mezi prave dvema procesy

• Spojeni je automaticky povoleno mezi kazdymi dvema procesy, ktere chteji komunikovat. Pro komunikaci musi procesy pouze navzajem vedet svou identifikaci.

• .Mezi kazdymi dvema procesy muze existovat maximalne jedno spojeni.

• Spojeni muze byt nesmerove, ale vetsinou je dvousmerove.

• Problem producenta a prijemce realizovany primou komunikaci by vypadal nasledovne. Oba procesy jsou spusteny soucasne a konzument zpracovava polozku zatimco producent jiz vytvari jinou. V okamziku kdy ji vytvori posle ji pomoci fce send prijemci. Ten ji prijme prostrednictvim fce receive. Neni- li Vyprodukovana zadna zprava, je producent ve stavu cekajici.

• Kostra algoritmu procesu producenta:

	repeat
		{vytvor dalsi polozku do promenne nova_hodnota}
		send(prijemce, nova_hodnota)
	until false

• Kostra algoritmu prijemce:

	repeat
		receive (producent, prijata_hodnota)
		{zpracuj polozku v promenne prijata_hodnota}
	until false

• Vyse uvedene algoritmy poukazuji na symetrii prijemce a producenta - oba museji znat navzajem sve identifikace, aby mohli komunikovat. Druhiu variantou je asymetricke adresovani tak, ze pouze producent zna adresu prijemce, prijemce vsak adresu producenta znat nemusi. V tomto pripade jsou zahlavi funkci send a receive nasledujici:

• send(P, zprava) - Posli zpravu procesu P.

• receive(id, zprava) - Prijmi zpravu od procesu. Do promenne id je vlozenaidentifikace procesu, od ktereho bylazprava prijata.

• Nevyhodou obou techto schemat komunikace (symetricke i asymetricke) je limitovana modularita konence definice procesu. Zmena jmena procesu si vynuti prohlidku definic vsech ostatnich procesu. Vsechny odkazy na stare jmeno musi byy nalezeny a zamemeny. Tato situace je nezadouci .

• V teto forme komunikace i producent a prijemce vymenuji zpravy pomoci schranky (mailbox) take nazyvane port. Schranka muze byt chapana jako objekt, do ktereho procesy vkladaji zpravy a odkud mouhou byt tyto zpravy procesy vyzvedavany.

• Kazda schranka ma jedinecnou identifikaci. V tomto pripade muze proces komiunikovat s jinymi prostrednictvim mnozstvi ruznych schranek. Dva procesy mohou komunikovat pouze sdili-li spolecny mailbox. funkce send a receive maji nasledujici hlavicku:

• send(A, zprava) - Posli zpravu do schranky A.

• receive(A, zprava) - Prijmi zpravu ze schranky A.

• V tomto pripade ma komunikacni spojeni nasledujici charakteristiky:

• Spojeni je navazano mezi dvema procesy pouze maji-li sdilenou schranku.

• Spojeni muze byt navazano mezi vice nez dvema procesy.

• Mezi kazdym parem komunikujicich procesu muze byt navazano vice spojeni; kazde spojeni vyzaduje jednu schranku.

• Spojeni muze byt nesmerove nebo dvousmerove.

• Uvazujme, ze procesy P1, P2 a P3 sdili spolecnou schranku A. P1 posle zpravu do schranky A, zatimco procesy P2 a P3 maji spustenou funkci receive ze schranky A. Ktery proces prijme zpravu od P1? Otazka muze byt resena vice zpusoby:

• Povolit spojeni mezi vice nez dvema procesy.

• Povolit nejvyse jedno spusteni operace receive v case.

• Povolit systemu, aby vybiral, ktery proces zpravu obdrzi.

• Vlastnikem schranky muze byt bud OS nebo proces. Je-li schranka ve vlastnictvi procesu (je jim definovana), rozlisuje se mezi vlastnikem - tim, kdo do schranky muze zapisovat a uzivatelem schranky - tim, kdo z ni muze jenom cist.

• Kazda schranka ma jedinecneho vlastnika. Je-li proces, ktery vlastni schranku ukoncen je schranka zrusena. Pokud by jine procesy chteli nadale komunikovat s touto schrankou, jsou upozorneny, ze schranka jiz neexistuje (prostrednictvim vymeny namitek viz. dale).

• Je vice cest, jak stanovit vlastnika a uzivatele schranky. Jedna moznost je zavest typ promenne schranka. Proces, ktery ma deklarovanou promennou typu schranka je jejim vlastnikem. Ostatni procesy, ktere znaji jmeno teto schranky ji mohou uzivat.

• Druhym typem jsou schranky ve vlastnictvi operacniho systemu. OS provadi mechanismy vedouci k:

1. Vytvoreni nove schranky;

2. Poslani a prijeti zpravy prostrednictvim schranky;

3. zruseni schranky.

• Proces, ktery schranku vytvoril je implicitne jejim vlastnikem a jedine on muze do schranky zasilat zpravy. Vlastnictvi, stejne jako pravu zapisu do schranky muze byt udeleno jinemu procesu prostrednictvim preruseni.

• Procesy mohou sdilet schranku prostrednictvim techniky tvorby procesu. Pokud proces P vytvori schranku A a posleze vytvori novy proces Q, potom oba procesy P a Q sdili schranku A.

• Kapacita spojeni je dana mnozstvim zprav, ktere mohou cekat v zaloze, nez si je prijemce odebere. V tomto smeru je mozno chapat spojeni jako frontu zprav. Pro implementaci fronty jsou mozne 3 zakladni zpusoby:

1. Fronta s nulovou kapacitou: Maximalni delka fronty je 0; ve spojeni nemohou tedy byt zadne cekajici zpravy v zaloze. V tomto pripade musi odesilatel cekat, dokud prijemce zpravu neprevezme. Oba procesy musi byt synchronizovany pro prenos zprav. Tato synchronizace se nazyva randevous.

2. Fronta s omezenou kapacitou: Fronta ma konecnou delku n; maximalne n zprav muze byt do ni vlozeno. Jestlize fronta v okamziku zaslani nove zpravy neni plna, zprava je do ni zarazena (je do fronty nakopirovana, nebo je do fronty zarazen ukazatel na zpravu) a odesilatel muze pokracovat v praci bez cekani. Fronta ma ovsem konecnou delku a je-li plna, musi odesilatel cekat s dalsi zpravou nez se ve fronte uvolni misto.

3. Fronta s neomezenou kapacitou: Fronta ma teoreticky neomezenou delku a muze v ni cekat teoreticky neomezeny pocet zprav. Odesilatel teoreticky nikdy neceka.

• Pripad (1) je nekdy oznacovan jako system zprav bez bufferu, (2) a (3) potom jako system s automatickym bufferovanim.

• Poznamenejme, ze u systemu s automatickym bufferovanim odesilatel explicitne nevi, kdo jeho zpravu po ulozeni do bufferu prijme. Jestlize je tato informace pro dalsi vypocet potrebna musi odesilatel s prijemcem primo komunikovat. Uvazujme proces P, ktery zasila zpravu procesu Q a muze pokracovat ve vypoctu pouze v pripade, ze proces Q zpravu prijal.

• Algoritmus procesu P potom obsahuje sekvenci prikazu:

	send(Q,zprava);

	receive(Q,zprava);

• Algoritmus procesu Q obsahuje sekvenci prikazu:

	receive(P,zprava);

	send(P,"potvrzeni");

• Vyse uvedene procesy komunikuji asynchronne.

• Existuji dalsi vyjmecne formy komunikace procesu:

1. Proces, ktery produkuje zpravy nikdy neceka. Tzn. pokud prijemce neprijima, fronta je plna a producent vyslal dalsi zpravu, je prvni zprava ve fronte znicena. (problematicke naprogramovani, nutna presna synchronizace)

2. Proces, ktery vyslal zpravu ceka dokud nedostane odpoved. Nektere operacni systemy (napr. Thoth) maji tento system zprav a maji implmentovanu funkci reply(P,zprava), kterou provadi potvrzeni o prijeti. Rozdil mezi funkcemi send a reply je ten, ze po funkci send je proces blokovan dokud nedostane reply, zatimco po provedeni funkce reply pokracuje ve vypoctu.

• Synchronni komunikace muze byt velmi jednoduse rozsirena na system volani vzdalene procedury (remote procedure call - RPC). System RPC je konstruovan tak, ze volani podprogramu nebo procedur v jednoprocesorovem systemu je na bazi systemu zprav, kdy odesilatel je blokovan dokud nedostane reply. Zprava je volani procedury a reply vraci vypoctenou hodnotu. Dalsim krokem v rozsirovani RPC je umoznit soubezne bezicim procesum, aby se mohli navzajem volat a vrcholem pyramidy je potom spousteni procesu na ruznych procesorech ruznych pocitacu. Na principu RPC pracuje napr. Network File System (NFS) v umoznujici sdilet pevne disky v siti a dalsi aplikace.

• System zprav je uzitecny pro budovani distribuovaneho prostredi, kde jednotlive procesy mohou byt rozlozeny na ruznych mistech (ruznych vypocetnich systemech). Je vsak zrejme, ze problemy vznikle v souvislosti s komunikaci procesu budou mnohem vetsi nez na jednom jednoprocesorovem stroji.

• U jednoho stroje je system zprav implementovan ponejvice ve sdilene pameti. V tom pripade chyba ve spojeni znamena chybu v systemu. V distribuovanem prostredi je tomu jinak - zpravy jsou prenaseny po pocitacove siti a chyba behem prenosu v zadnem pripade nemusi nutne znamenat chybu OS.

• Pokud dojde k chybe at v centralizovanem nebo distribuovanem systemu, musi byt spusteny opravne prostredky (prostredky osetreni vyjimecne situace), ktere nejakym zpusobem chybu odstrani. Nasleduji nektere vyjimecne situace, ktere musi system umet osetrit v pripade uziti RPC apod.

Proces byl ukoncen

• Odesilatel nebo prijemce muze byt ukoncen drive, nez byla zpracovana zprava. Diky takove udalosti by mohli vzniknout zpravy, ktere nikdy nebudou prijaty, nebo zablokovane procesy cekajici na zpravu, ktera nikdy nebude odeslana. Dve mozne situace:

1. Proces P ceka na zpravu od procesu Q, ktery byl zrusen. Pokud by nebyly uplatneny prostredky osetreni vyjimecne situace, proces P by byl blokovan naveky. OS musi v tomto pripade proces P ukoncit, nebo mu sdelit, ze na zpravu od procesu Q uz cekat nemusi.

2. Proces P odeslal zpravu procesu Q, ktery byl zrusen. V systemu s automatickym bufferovanim se nic nedeje a proces P klidne pokracuje dal. Pokud ovsem proces P potrebuje vedet, ze Q zpravu prijal, ceka na potvrzeni prijeti. V systemu bez bufferovani je proces Q blokovan vzdy. Opravne mechanismy jsou totozne s bodem (1).

Ztracena zprava

• Zprava odeslana procesem P procesu Q se ztratila kdesi v siti - chybou hardwaru nebo komunikacniho spojeni. Zakladni metody osetreni teto udalosti:

1. OS je schopen detekovat tuto udalost a znovu poslat zpravu.

2. Odesilajici proces je schopen detekovat tuto udalost a znovu odeslat zpravu, je-li to zapotrebi.

3. OS je schopen detekovat tuto udalost a upozorni odesilajici proces, ze zprava byla ztracena. Odesilajici proces potom muze udelat co uzna za vhodne.

• Pri pouziti nekterych sitovych protokolu neni nutne detekovat ztracene zpravy OSem, sitovy protokol to dela sam a uzivatelsky program ziskava informace primo od protokolu.

• Pro detekci ztracene zpravy je nejpouzivanejsi metodou metoda detekce pomoci timeoutu. Po prijeti kazde zpravy je vzdy odeslano potvrzeni o prijeti. OS nebo uzivatelsky program mohou specifikovat dobu behem ktere ocekavaji potvrzeni o prijeti odeslane zpravy. Pokud tato doba uplyne aniz by potvrzeni dorazilo, zprava je povazovana za ztracenou a je opetovne odeslana. Samozrejme se muze stat, ze ani v tomto pripade nedoslo ke ztraceni zpravy, ta pouze prochazela siti "dele nez obvykle". Za teto situace je v siti vice kopii teze zpravy a musi existovat mechanismy i pro osetreni tohoto stavu.

Porusena zprava

• Zprava byla dorucena prijemci, ale cestou doslo k jejimu poskozeni (napr. v dusledku ruchu v siti). Dusledky teto udalosti jsou totozne se ztracenim zpravy a vetsinou OS znovu posila original porusene zpravy.

• Mechanismus detekce poskozeni spociva v kontrolnim souctu zpravy (parita nebo CRC).

• OS Mach vyvinuty na Carnegie Mellon University je postaveny na systemu zprav. Jadro OS Mach obsahuje podporu pro tvorbu a ruseni uloh s multivlaknovou architekturou. Vsechny meziulohove informace jsou prenaseny formou zprav. Zpravy jsou odesilany a prijimany pomoci schranek (v OS Mach nazyvanych porty).

• Kazde systemove volani je provedeno formou zpravy. S kazdou ulohou jsou vytvoreny 2 schranky - schranka jadra a schranka hlaseni. Schranku jadra pouziva jadro pro komunikaci s ulohou. Hlaseni o nastalych udalostech posila jadro do schranky hlaseni.

• Prenos zprav zabezpecuji pouze 3 systemova volani. Volani msg_send posle zpravu do schranky, volani msg_receive zajisti prijeti zpravy. Mechanismus RPC je provaden pomoci volani msg_rpc, ktere zpravu odesle a ceka na odpoved.

• Volani port_allocate slouzi k vytvoreni nove schranky a k alokovani prostoru pro buffer. Buffer je omezeny s implicitni velikosti 8 zprav. Uloha, ktera schranku vytvori se stava jeji vlastnikem a muze do ni zapisovat. V jednom okamziku muze schranku vlastnit a do ni zapisovat pouze jedna uloha; tato prava vsak mohou byt pridelena jine.

• Tak jak jsou zpravy odesilany do schranky, jsou do ni kopirovany. Vsechny zpravy maji stejnou prioritu. Zpravy jsou do schranky ukladany mechanismem FIFO.

• Kazda zprava sestava z hlavicky pevne delky a z tela libovolne delky. Hlavicka obsahuje delku zpravy a jmena dvou schranek. Jedno je jmeno schranky, kam byla zprava odeslana, druhe je jmeno schranky odesilatele. Obvykle vlakno zajistujici prenos zpravy ocekava odpoved a jako navratova adresa je uzito jmeno schranky odesilatele.

• Promenliva cast zpravy je seznam datovych polozek. Kazdy prvek seznamu ma typ, velikost a hodnotu. Specifikace typu hodnoty je vhodna, protoze potom mohou byt pomoci zprav zasilany ruzne definice jako napr. vlastnictvi nebo pristupova prava, stav ulohy apod.

• Akceptuje-li schranka adresata zpravu, muze vlakno odesilatele pokracovat ve vypoctu. Je-li schranka plna, vlakno odesilatele ma 4 moznosti:

1. Cekat do te doby, nez se ve schrance uvolni misto;

2. Cekat maximalne n ms;

3. Necekat vubec a okamzite se vratit;

4. Docasne uchovat zpravu; Zprava muze byt docasne uchovana operacnim systemem, dokud se ve fronte adresata neuvolni misto. Kdyz muze byt zprava umistena do patricne schranky, system zasle zpravu odesilateli. Jen jedna zprava muze cekat na uvolneni mailboxu.

• Posledni moznost je urcena pro serverove ulohy, jako napr. pro driver tiskarny apod. Temto uloham je potom zaslano reply o tom, ze pozadovaly sluzbu, ale schranka klienta je plna.

• Pri prijeti zpravy musi byt specifikovano ze ktere schranky nebo mnoziny schranek byla odeslana. Mnozina schranek jsou schranky deklarovane urcitou ulohou a mohou byt zpracovavany jako jedna schranka ulohy. Vlakno ulohy muze prijmout zpravu pouze od schranky nebo mnoziny schranek od ktere ma k tomu pravo.

• Volani port_status vraci pocet zprav ve schrance. Operace prijeti zpravy (receive) muze prijimat zpravy od

1. libovolne schranky z mnoziny schranek

2. specificke (pojmenovane) schranky.

• Jestlize neni ve schrance zadna cekajici zprava, prijimaci vlakno muze byt ve stavu cekajici.

• OS Mach je koncipovan pro distribuovane prostredi, ale pouze pro jednoprocesorove vypocetni systemy. Hlavni problem systemu zprav spociva ve slozitosti predavani zprav, kdy nejprve odesilatel zkopiruje zpravu do schranky a program pro posilani zprav ji potom kopiruje ze schranky prijemci. Pro schranky pouziva OS Mach virtualni pamet. Pro zjednoduseni Mach mapuje adresovy prostor obsahujici odesilatelovu zpravu jako prostor patrici jejimu prijemci, takze zprava neni ve skutecnosti nikdy kopirovana. Tato technika zvysuje vykonnost systemu zprav, ale funguje pouze pro spravy v ramci jednoho vypocetniho systemu.

Sockety

• Nejvyznamnejsi IPC mechanismus v OS UNIX je pipe. Pipe provadi spolehlivy jednosmerny bytovy proud dat (stream). Vetsinou je implementovan jako bezny soubor s malymi odlisnostmi. Nema jmeno v systemu souboru a je vytvoren behem volani jadra pipe. Ma pevnou delku a pokud ho producent zaplni, je pozastaven dokud prijemce vsechna data ze souboru nezpracuje.

• Vyhoda maleho rozsahu (vetsinou 4kB) "pipe" souboru je, ze je zridka ukladan na disk a vetsinou je v cache pameti.

• Ve 4.3BSD UNIXU je pipe implementovan jako specialni socket. Sockety provadi hlavni interface nejen pro mechanismy jako je napr. pipe, ale i pro sitove prostredky.

• Socket je konecny bod komunikace. Pouzivany socket ma pridelenou adresu. Povahu adresy podminuje komunikacni domena socketu. Procesy komunikujici v te same komunikacni domene uzivaji stejny format adresy.

• Ve 4.3 BSD UNIXU jsou implementovany 3 komunikacni domeny:

1. domena UNIX (AF_UNIX)

2. domena Internet (AF_INET)

3. domena Xerox Network services (AF_NS)

• Adresa v domene UNIX je plna cesta k souboru /alfa/beta/gama. Procesy komunikujici v domene INTERNET uzivaji protokoly TCP/IP a Internetovskou adresu tj. 32-bitove cislo coby adresa stroje a 32-bitove cislo portu (bod spojeni na hostu).

• Existuji ruzne typy socketu, ktere definuji tridy sluzeb. Kazdy typ muze nebo nemusi byt implementovan v komunikacni domene. Pokud dany typ implementovan je, muze byt implementovan mnozstvim komunikacnich protokolu:

• Stream socket: Provadi spolehlivy duplexni postupny tok dat. Zadna data behem tohoto spojeni nejsou nikdy ztracena nebo duplikovana. Tento typ komunikace je podporovan v domene Internet protokolem TCP, v domene UNIX jako pipe.

• Sequenced packet socket: Obdoba stream socketu v domene XEROX.

• Datagram socket: Tento socket zajistuje prenos zprav libovolne delky v libovolnem smeru. Neni zaruceno, ze zprava bude vzdy dorucena ve stejnem poradku, jako byla odeslana nebo ze nebude duplikovana ci dorucena cela. Velikost puvodni zpravy je dorucena prijemci v jednom datagramu. Tento socket je podporovan v domene Internet protokolem UDP.

• Reliable delivered message socket (Socket pro spolehlive dorucovane zpravy): Tento socket Tento socket by zajistoval doruceni zpravy pri vsech ostatnich charakteristikach, jake ma datagram socket. Dosud neni nikde podporovan.

• Raw socket: Tento socket umoznuje procesu primy pristup k jinemu typu socketu. Primy pristup neni jen k protokolum vyse uvedenym, ale je podporovan primy pristup ke vsem protokolum nizke urovne. Napr. v domene Internet dovoluje protokolu TCP pristup k IP protokolu apod. Uzitecne pro vyvoj noveho protokolu.

• Sockety jsou podporovany mnozinou volani jadra. Volani socket vytvori novy socket. Pri specifikaci volani je treba uvest komunikacni domenu, typ socketu a protokol, ktery bude tento socket vyuzivat. Navratova hodnota volani je cele cislo socket descriptor, shodne s prislusnym descriptorem souboru. Socket descriptor je index v poli otevrenych "souboru" na prislusnou polozku.

• Pro adresovani socketu jinym procesem musi mit socket jmeno. To mu prideli volani jadra bind. Obsah a delka jmena socketu zavisi na jeho typu. Inicializace spojeni se provadi volnim jadra connect.

• Mnoho procesu komunikuje pomoci IPC modelem klient - server. V tomto modelu provadi server sluzby pro klienta. Je-li sluzba k dispozici, server nasloucha na jeji verejne adrese a klient uziva k navazani spojeni volani connect, jak jiz bylo uvedeno.

• Proces server pak uzije volani socket pro vytvoreni noveho socketu a bind k napojeni adresy k novemu socketu. Volani listen rika jadru, ze server proces je schopen akceptovat pripojeni klienta a definuje pocet nevyrizenych volani, ktere ma jadro uchovavat, nez bude server schopen je vyridit. Nakonec dojde k volani accept, kterym server dava vedet, ze je schopen akceptovat prime spojeni s klientem.

• Jak volani listen, tak i accept maji za argument descriptor socketu. Accept vraci novy descriptor socketu, ktery provadi nove spojeni. Puvodni socket je stale otevren pro mozna budouci dalsi spojeni. Vetsinou po akceptovani pozadavku klienta volanim accept server provede fork a vytvori novym proces, ktery bude klienta obsluhovat a sam dale nasloucha dalsim pozadavkum.

• Kdyz je spojeni na prislusnem typu socketu ustanoveno, jsou znamy adresy obou komunikujicich procesu, ktere jsou treba pro vymenu dat mezi nimi. K tomu slouzi volani read a write.

• Nejjednodussi cesta ke zruseni spojeni a asociovaneho socketu je v uziti volani close na patricny descriptor socketu. Je-li treba uzavrit pouze jeden smer v obousmerne komunikaci procesu, je mozno uzit volani shutdown.

• Nektere typy socketu, jako napr. datagram socket nepodporuji prime spojeni. V tom pripade musi byt jednotlive datagramy adresovany individualne a k tomu souzi volani sendto a recvfrom. Obe pozaduji jako argument descriptor socketu, odkaz na buffer, delku zpravy a ukazatel do bufferu adres, ktery obsahuje adresy pro zaslani datagramu prostrednictvim sendto. Buffer je naplnovan navratovymi adresami z prijatych datagramu prostrednictvim volani recvfrom.

• Volani jadra select je uzito pri multiplexovani prenasenych zprav na ruzne descriptory souboru nebo socketu. Uziva se, pokud jeden server proces nasloucha vice klientum a je volanim fork vytvoren zvlastni proces pro kazdeho klienta po navazani spojeni. Pri kazdem navazani spojeni vola server socket, bind a listen a pote select pro multiplexovani zprav na vsechny jeho sockety. Jestlize select zaznamena aktivitu na nejakem descriptoru, provede server accept a pomoci fork vytvori proces pro vyrizeni pozadavku na descriptoru, ktery vraci accept. Rodicovsky server proces pak opet provede listen.

Zpet Obsah Vpred