Curs 6

Gestiunea proceselor
Cooperarea si comunicarea intre
procese

Sisteme de operare
Lect. Dr. Ozten CHELAI

Facultatea de Matematica si Informatica

Universitatea Ovidius Constanta

Curs5 SO - lect. dr. Ozten Chelai, 2009-2010 1

Crearea proceselor in Windows

Crearea unui proces se poate face prin utilizarea funcŃiei
BOOL CreateProcess(
LPCTSTR lpApplicationName,
LPTSTR lpCommandLine,
LPSECURITY_ATTRIBUTES lpProcessAttributes,
LPSECURITY_ATTRIBUTES lpThreadAttributes,
BOOL bInheritHandles,
DWORD dwCreationFlags,
LPVOID lpEnvironment,
LPCTSTR lpCurrentDirectory,
LPSTARTUPINFO lpStartupInfo,
LPPROCESS_INFORMATION lpProcessInformation);
cu următoarele semnificaŃii pentru parametri:
LPCTSTR lpApplicationName – calea şi numele fişierului executabil care conŃine programul ce trebuie
executat;
LPTSTR lpCommandLine - linia de comandă asociată lansării în execuŃie a programului;
LPSECURITY_ATTRIBUTES lpProcessAttributes - un pointer spre o structură
SECURITY_ATTRIBUTES care arată dacă identificatorul instanŃei procesului poate fi moştenit de un
proces copil. O valoare NULL nu permite moştenirea;
LPSECURITY_ATTRIBUTES lpThreadAttributes - idem parametrul precedent;
BOOL bInheritHandles - o valoare TRUE arată că noul proces moşteneşte identificatori de la procesul
apelant;
DWORD dwCreationFlags - specifică fanioane adiŃionale cu privire la crearea şi prioritatea noului proces;
LPVOID lpEnvironment – pointer spre mediul de execuŃie al noului proces. O valoare NULL permite
execuŃia în acelaşi mediu ca şi procesul apelant;
LPCTSTR lpCurrentDirectory - pointer spre directorul în care este creatprocesul copil (pentru procese
copil). NULL indică acelaşi director ca şi procesul părinte;
LPSTARTUPINFO lpStartupInfo - pointer spre o structură STARTUPINFO care modelează fereastra
asociată procesului;
LPPROCESS_INFORMATION lpProcessInformation - pointer spre o structură care reŃine parametri ai
noului proces;
Terminarea proceselor - Windows

Terminarea unui proces este comandată de funcŃia
BOOL TerminateProcess(HANDLE hProcess, UINT uExitCode)
unde
HANDLE hProcess - identificatorul procesului ce va fi terminat;
UINT uExitCode – un code de retur la terminarea procesului;

Un exemplu de program (Win32 Console Application) care lansează în execuŃie aplicaŃia
regedit.exe şi o termină forŃat este prezentat mai jos:
#include <Windows.h>
#include <conio.h>
#include <stdio.h>
void main()
{
// informaŃii despre starea iniŃială a procesului
STARTUPINFO si;
// informaŃii returnate despre proces
PROCESS_INFORMATION pi;
// iniŃializare structură
memset(&si, 0, sizeof(si));
si.cb = sizeof(STARTUPINFO);
// creare proces
if(!CreateProcess("C:\\Winnt\\Regedit.exe", NULL, NULL, NULL, FALSE, 0L, NULL, NULL, &si, &pi))
DWORD err = GetLastError();
printf("Proces creat. Apasati o tasta pentru oprire!\n");
getch();
// terminare proces
TerminateProcess(pi.hProcess, 0L);
}
Procese cooperante

Procesele concurente ce se execută sub controlul unui SO cu multiprogrmare
pot fi independente sau cooperante.

Un proces independent nu afectează şi nu este afectat de nici un alt proces
din sistem. Procesele independente nu partajează date (permanente sau
temporare).

Un proces cooperant afectează sau poate fi afectat de alte procese ce se
execută în sistem. Procesele care partajează date sunt procese cooperante.

AplicaŃiile formate din procese cooperante au următoarele avantaje:

partajează informaŃii,

se execută mai rapid, deoarece conŃin subactivităŃi ce se execută în paralel,

sunt modulare, fiind construite prin divizarea funcŃiilor sistemului în procese sau fire de
execuŃie separate,

convenabilitate la nivel de utilizator, care poate desfăşura simultan câteva activităŃi
interactive.

ExecuŃia concurentă a proceselor cooperante necesită mecanisme de
comunicare informaŃii între acestea şi de sincronizare a acŃiunilor lor asupra
informaŃiilor şi resurselor partajate.
Cooperarea si comunicarea
intre procese

Problema producător-consumator

Problema producător-consumator este o paradigmă pentru procese
cooperante. În esenŃă există procesul producător de informaŃii şi procesul
consumator de informaŃii. Ele se execută în paralel şi utilizează o zonă
comună (buffer) prin care transferă date. Procesul producător pune date în
buffer, iar procesul consumator extrage date din buffer. Producătorul poate
plasa o informaŃie în buffer în timp ce consumatorul extrage o altă informaŃie
existentă deja în buffer, astfel încât cele două procese pot lucra în paralel.

AcŃiunile celor două procese trebuie sincronizate, astfel încât
consumatorul să nu încerce extragerea unor date ce nu au fost încă puse în
buffer de producător, ci să aştepte încheierea acŃiunilor corespunzătoare ale
acestuia.

Varianta cea mai simplă de soluŃionare a problemei oferă un buffer de
dimensiune nelimitată. În această variantă producătorul poate pune oricând
date, iar consumatorul va trebui eventual să aştepte apariŃia de noi date în
buffer.

Varianta în care dimensiunea buffer-ului este limitată la o valoare fixă
introduce cerinŃa ca şi producătorul să aştepte consumarea de date dacă
buffer-ul s-a umplut. Astfel, consumatorul intră în aşteptare dacă buffer-ul s-
a golit, iar producătorul trebuie să aştepte dacă bufferul este plin.

Buffer-ul poate fi oferit de SO prin utilizarea unei facilităŃi de comunicare
între procese (IPC – interprocess communication) sau codificat în mod
explicit de către programator prin utilizarea memoriei partajate.

Prezentăm în continuare codul pentru problema producător-consumator în varianta cu buffer limitat şi
utilizarea memoriei partajate.

Datele partajate de procesele producator si consumator
#define BUFFER_SIZE 10
typedef struct {
// definiŃia unei anumite structuri ...
} item;
item buffer[BUFFER_SIZE];
int in = 0;
int out = 0;

Buffer-ul partajat este implementat ca un array circular cu 2 pointeri: in şi out. Variabila in indică
prima poziŃie liberă în buffer, iar out prima poziŃie ocupată.

Buffer vid dacă in == out

Buffer plin dacă ((in+1)%BUFFER_SIZE)==out.

Procesul producător are următorul cod, în care variabila locală nextProduced conŃine elementul ce
trebuie plasat în buffer
while(1)
// se produce un element în nextProduced
while((in+1)%BUFFER_SIZE)==out)
; //nu se execută nimic; aşteptare activă
buffer[in] = nextProduced;
in = (in+1)%BUFFER_SIZE;
}

Similar, procesul consumator are următorul cod, în care variabila locală nextConsumed conŃine
elementul ce trebuie extras din buffer
while(1)
while(in == out)
; //nu se execută nimic; aşteptare activă
nextConsumed = buffer[in];
out = (out+1)%BUFFER_SIZE;
// se consumă un element în nextConsumed
}
1. Această schemă permite existenŃa a maximum BUFFER_SIZE-1 elemente în buffer.
Comunicarea intre procese

Pe lângă utilizarea unei zone de memorie partajată de procese şi gestionată de
programator, comunicarea între procese se poate realiza utilizând un suport
oferit de SO prin intermediul facilităŃii IPC. Acest mecanism permite
comunicarea şi sincronizarea acŃiunilor proceselor aflate în spaŃii de adresare
diferite. Acest mecanism este util în medii distribuite pentru comunicarea
proceselor aflate pe calulatoare diferite.

Sisteme cu transfer de mesaje.

Transferul de mesaje permite comunicarea între procese fără ca acestea să necesite
memorie comună.

Mecanismul IPC are la bază două operaŃii:

send – emitere mesaj

receive – recepŃie mesaj.

Mesajele pot avea dimensiuni fixe sau variabile. În primul caz implementarea
sistemului este directă dar programarea este mai dificilă. Al doilea caz plăteşte o
flexibilitate în programare printr-o complexitate la nivelul implementării sistemului.

Două procese P1 şi P2 care comunică emit şi recepŃionează mesaje prin intermediul
unei căi de comunicare. Această cale poate avea diverse implementări (retea,
magistrală hardware, chiar memorie partajată) fizice. Din punct de vedere logic
implementarea căii de comunicare pentru operaŃii send şi receive este însoŃită de
următoarele decizii:

comunicare directă sau indirectă,

comunicare simetrică sau asimetrică,

zone intermediare (buffer) automate sau implicite,

transfer prin valoare (copie) sau prin referinŃă,

mesaje cu lungime fixă sau variabilă.
Sisteme cu transfer de mesaje

Identificarea. Procesele care comunică, direct sau indirect, sunt
identificate prin nume.

Comunicare directă

În cazul comunicării directe procesul care iniŃiază comunicarea trebuie să
specifice numele celui cu care va comunica. Acest nume este parametru de
apel al primitivei de comunicare utilizată (send sau receive). Forma generică a
acestor apeluri sistem este următoarea:
 send (P1, mesaj) – trimite mesaj la procesul P1
 receive (P2, mesaj) – recepŃionează mesaj de la procesul P2

Semanticile căii de comunicare în comunicarea directă şi simetrică:
 stabilită automat între două procese care îşi cunosc identitatea reciproc,
 asociată exact la două procese,
 între fiecare pereche de procese există o singură cale de comunicare.

Adresarea este simetrică, în sensul că atât procesul emiŃător cât şi cel
receptor trebuie să precizeze identitatea interlocutorului.

Varianta asimetrică a căii de comunicare directă necesită doar cunoasterea
de către procesul emiŃător a identităŃii receptorului, nu şi reciproc.

Forma generică a apelurilor sistem în acest caz este:
 send (P1, mesaj) – trimite mesaj la procesul P1,
 receive (id, mesaj) – recepŃionează mesaj de la procesul al cărui identificator va fi
plasat în variabila id în momentul stabilirii căii de comunicare.

Comunicarea directă are dezavantajul lipsei decuplării operaŃiei de
identificatorii proceselor. Dacă numele unuia dintre procese se modifică,
atunci toate referirile la acest nume trebuie actualizate.
Sisteme cu transfer de mesaje

Comunicarea indirectă - În cazul comunicării indirecte mesajele sunt trimise şi
recepŃionate prin intermediari de tip mailbox sau port.

Un mailbox este un obiect abstract în/din care procesele pot plasa/extrage mesaje. El are un
identificator unic. Două procese pot comunica în cazul în care partajează un mailbox. Această
schemă permite ca două procese să comunice simultan prin intermediul mai multor obiecte de tip
mailbox.

Forma generică a primitivelor send şi receive este următoarea:

send (M, mesaj) – trimite mesaj la mailbox M

receive (M, mesaj) – recepŃionează mesaj din mailbox M

Semanticile căii de comunicare în comunicarea indirectă:

stabilită între două procese care partajează un mailbox,

asociată la două sau mai multe procese,

între fiecare pereche de procese pot exista mai multe căi de comunicare, fiecare corespunzând la un
obiect de tip mailbox.

Fie procesele P1, P2 şi P3 care partajează acelaşi mailbox M. P1 trimite un mesaj la M iar P2 şi P3
realizează o operaŃie de receive pe M. Procesul care va primi mesajul transmis de P1 depinde de
schema aleasă dintre următoarele varinte:

cale de comunicare să fie asociată cu cel mult două procese,

doar un singur proces execută receive la un moment dat,

sistemul alege în mod arbitrar procesul care va primi mesajul, comunicându-i şi emiŃătorului
identificatorul acestuia.

Un obiect de tip mailbox poate aparŃine fie unui proces fie sistemului de operare.

Un mailbox deŃinut de un proces este parte a spaŃiului de adresare al acestuia. Procesul
proprietar primeşte mesaje în acest obiect, iar orice proces utilizator al mailbox-ului îi trimite mesaje.
Obiectul de tip mailbox dispare din sistem odată cu proprietarul său, iar orice proces care încearcă
trimitere de mesaje la un mailbox care nu mai există trebuie să fie notificat asupra acestui lucru.

Un mailbox deŃinut de SO este independent, nefiind ataşat unui anume proces.

SO oferă un mecanism care permite proceselor crearea unui mailbox de acest tip, comunicarea de
mesaje prin intermediul său şi eliminarea din sistem a unui mailbox. Procesul care crează un
mailbox devine automat proprietarul acestuia, dar dreptul de proprietate poate fi transferat ulterior,
prin intermediul unui aplel sistem specializat, altui proces din sistem. În acest caz trebuie tratată
posibilitatea apariŃiei de receptori multipli pentru acelaşi mailbox.
Sisteme cu transfer prin mesaje

Sincronizarea

Transferul de mesaje se poate realiza cu sau fără blocarea proceselor.

Transferul cu blocare este transfer sincron. La emiterea cu blocare a unui mesaj procesul
emiŃător se blochează până mesajul emis este recepŃionat de procesul destinatar sau de
mailbox. La recepŃia cu blocare procesul receptor se blochează în aşteptarea unui mesaj.

Transferul fără blocare este transfer asincron. La emiterea fără blocare procesul emiŃător
trimite un mesaj după care continuă operaŃiile începute anterior. Un receptor fără blocare
recepŃionează fie un mesaj valid, fie un NULL, funcŃie de starea căii de comunicare în
momentul executării primitivei receive.

În proiectarea unei scheme de comunicare între procese se poate alege orice combinaŃie. În
cazul în care atât emisia cât şi recepŃia se fac cu blocare avem de a face cu o schemă de tip
rendezvous.

Utilizarea zonelor intermediare(buffer)

Mesajele transferate între procese sunt păstrate temporar structuri de date de tip coadă de
aşteptare. O astfel de structură de date poate fi implementată în trei variante.

Cazul extrem în care coada de aşteptare are lungimea 0, astfel încât calea de date nu păstrază
mesajele. În această variantă emiŃătorul este nevoit să se blocheze până la recepŃia mesajului.

Coada de aşteptare cu capacitate limitată are o lungime finită n, şi poate păstra maximum n mesaje în
vederea până la recepŃionarea lor de către procesul(ele) destinatar. În structura de date se poate copia
mesajul integral sau un pointer la acesta. EmiŃătorul poate funcŃiona fără blocare până la atingerea
capacităŃii maxime a cozii de aşteptare, când va trebui să se blocheze până este recepŃionat cel puŃin
încă un mesaj.

În cazul ideal coada de aşteptare poate avea capacitate nelimitată, caz în care poate păstra oricâte
mesaje iar emiŃătorul nu se va bloca niciodată.

Sistemele în care coada de aşteptare are capacitate 0 sunt considerate sisteme fără zone de
transfer intermediare (Sisteme fara “buffer-are”). Celelalte sunt sisteme ce utilizează zone
intermediare (Sisteme cu “buffer-are”).
Sisteme cu transfer prin mesaje - Exemplificare cu
SO Windows 2000

Windows 2000 este un SO modular care oferă suport pentru medii de operare
multiple numite subsisteme, medii cu care aplicaŃiile comunică prin transfer de
mesaje. Astfel fiecare aplicaŃie poate fi considerată un client al unui subsistem
Windows 2000.

Facilitatea oferită de acest SO pentru transfer mesaje se numeşte LPC (local
procedure-call) şi asigură comunicare între 2 procese aflate pe aceeaşi maşină.

SO utilizează un obiect de tip port pentru stabilirea şi utilizarea unei conexiuni între
două procese. Fiecare client al unui subsistem utilizează un canal de comunicare
individual oferit de un obiect de tip port. La Windows 2000 există două tipuri de
porturi: port de comunicare şi port de conectare. Un port de conectare este un
obiect identificat prin nume şi vizibil tuturor proceselor şi permite setarea unui canal
de comunicare. Procedura de comunicare are loc astfel:

clientul ia legătura cu obiectul port de conectare al subsistemului ale cărui servicii le solicită (funcŃie
de tipul aplicaŃiei client),

clientul trimite o cerere de conectare,

serverul crează două obiecte de tip port de comunicare private şi întoarce clientului o referinŃa la
unul dintre ele,

clientul şi serverul utilizează referinŃele corespunzătoare la obiectul port pentru a trimite mesaje sau
apeluri de la server la client (callback) şi pentru a aştepta răspunsuri.

Se utilizează două tipuri de tehnici pentru transferul de mesaje:

pentru mesaje scurte (până la 256 oct.) se utilizează coada de aşteptare a portului ca memorie
intermediară şi se copiază mesajele

pentru mesaje mai lungi mesajul este transferat printr-un obiect de tip section (memorie partajată),
fără a se executa copierea mesajului deoarece se transmite un pointer la acesta.

Clientul trebuie să decidă, în momentul în care stabileşte canalul, dacă va comunica
sau nu mesaje lungi. FuncŃie de aceasta se va alege tehnica de transfer. Dacă vor fi
mesaje lungi atunci se solicită un obiect de tip section prin intermediul unui mesaj
scurt prin care se comunică un pointer şi dimensiunea obiectului section.
Comunicarea în sistemele client-server

În sistemele client-server cele două procese evoluează în spaŃii de adresare diferite.
Clientul trimite la server un mesaj ce conŃine o cerere de executare a unei operaŃii.
Serverul execută operaŃia respectivă şi returnează clientului rezultatul sub forma unui
mesaj.

Socket

Un socket este un punct terminal într-o cale de comunicare. O pereche de procese care comunică
în reŃea necesită câte un socket pentru fiecare proces.

Un socket este caracterizat de o adresă IP şi de un număr de port.

Procesul server ascultă pe un port[1] pentru a recepŃiona mesajele trimise de clienŃi. La
recepŃionarea unei cereri serverul acceptă o conexiune cu socketul clientului.

Unui client care solicită o conexiune i se asignează un port pe calculatorul gazdă identificat printr-un
număr mai mare decât 1024. Conexiunea va consta din perechea de socket-uri (IP-client :
nr_port_client) şi (IP-server : nr_port_server). Pachetele cu mesaje primite de un anumit calculator
conectat în reŃea sunt transmise procesului corespunzător pe baza numărului de port al
destinatarului.

Fiecare client comunică cu un server printr-o conexiune unică, chiar dacă se află pe aceeaşi maşină
cu un alt client ce comunică cu acelaşi server.


[1] Porturile cu mai mici de 1024 sunt utilizate pentru implementarea de servicii standard

(ex. 21–ftp, 23-telnet, 80-http).

Socket coresp. Server =M2

serv. s1
connect
listen()

Client =M1 s1
Comunicarea în sistemele client-server - Socket

Etape le realizării unui transfer prin socket:

creare SOCKET la server

specificare protocol

identificator al maşinii gazdă (IP)

specificare id al SOCKET-ului: nr port

ascultare - lansare operaŃie listen() (în Java – accept()) în care procesul server se
pune în regim de aşteptare a cererilor pentru servicii prin acest port

creare SOCKET client

legare la un SOCKET server (bind()) – se va indica IP şi port

conectarea propriu-zisă (connect()) – deschiderea căii de comunicare între procesele
client şi server

transferul de mesaje

close(): închiderea căii de comunicare

Ilustrăm utilizarea obiectelor de tip socket în implementarea unei aplicaŃii simple
client-server în Java.

Java oferă 3 tipuri de socket:

orientate conexiune (TCP) implementate cu clasa Socket,

neorientate conexiune (UDP) implementate cu clasa DatagramSocket,

multicast implementate cu clasa MulticastSocket, subclasa a DatagramSocket, şi care
permit trimiterea de date către receptori multipli.

Serverul răspunde cu ora curentă şi ascultă pe portul 5155.
Comunicarea în sistemele client-server – Socket –
Cod Server
import java.net.*;
import java.io.*;
public class Server {
public static void main(String[] args) throws IOException {
Socket client = null;
PrintWriter pout = null;
ServerSocket sock = null;
try {
sock = new ServerSocket(5155);
// bucla de a;teptare a unei cereri client
while(true) {
client = sock.accept();
// a aparut o cerere
pout = new PrintWriter(client.getOutputStream(), true);
pout.println(new java.util.Date().toString());
pout.close();
client.close();
}
}
catch (IOException ioe) {
System.err.println(ioe);
}
finally {
if(client!=null)
client.close();
else
sock.close();
}
}
}
Comunicarea în sistemele client-server –
Socket – Cod Client
import java.net.*;
import java.io.*;
public class Client {
public static void main(String[] args) throws IOException {
InputStream in = null;
BufferedReader bin = null;
Socket sock = null;
try {
// realizare conexiune la socket
sock = new Socket(“127.0.0.1”,5155);
in = sock.getInputStream();
bin = new BufferedReader(new InputStreamReader(in));
String line;
while((line = bin.readLine())!=null)
System.out.println(line);
}
catch (IOException ioe) {
System.err.println(ioe);
}
finally {
if(sock!=null)
sock.close();
}
}
}
RPC

Comunicarea prin socket este o comunicare client-server la nivel inferior. Prin socket se transmit fluxuri
de octeŃi nestructurate. Structura datelor este gestionată la nivelul aplicaŃiei[1].

În continuare vom prezenta două metode de comunicare de nivel superior, RPC şi RMI.


Paradigma RPC(Remote Procedure Call) abstractizează mecanismul de apel procedură. Permite astfel
utilizarea acestuia în sistemele conectate în reŃea.

Se utilizează o schemă cu transfer de mesaje (IPC) şi se adaugă la acesta o structurare specifică a
mesajelor. Mesajul de apel este structurat conform semnaturii funcŃiei solicitată la server şi conŃine
numele acestuia şi parametrii de apel.

Procesul client apelează o procedură la un server aflat la distanŃă la fel ca şi cum ar apela o procedură
locală. Suportul RPC apelează un proces specializat(stub) corespunzător acestei proceduri care
împachetează informaŃiile de apel într-un mesaj structurat corespunzător. Apoi realizează o conexiune cu
serverul prin care trimite mesajul. Mesajul este preluat la server de un proces daemon specializat
(skeleton) care ascultă pe un port şi care realizează despachetarea informaŃiilor şi utilizarea acestora
pentru a apela funcŃia respectivă la procesul server. Dacă procedura apelată produce un rezultat ce
trebuie returnat apelantului, atunci acesta este preluat de skeleton, împachetat corespunzător şi trimis în
reŃea către stub-ul procesului client. Acesta la rândul lui va despacheta rezultatul şi îl va prezenta
clientului.

Întregul mecanism de formare mesaje şi extragere informaŃii din mesaje este transparent pentru
procesele client şi server, acestea comunicând la nivel logic pe principiul apelului clasic de procedură.

[1] Formată din codul clientului şi codul server-ului.
RPC
Client Server

Apel procedură Apel procedură

InterfaŃă server

InterfaŃă server

Stub Skeleton

Împachetare parametri Despachetare parametri

mesaj
mesaj
mesaj

ReŃea
RMI

RMI (Remote Method Invocation) este un mecanism oferit de limbajul Java, similar paradigmei
RPC. Obiectele se consideră a fi la distanŃă dacă se află pe o altă maşină virtuală Java (JVM).

Există două deosebiri fundamentale între RPC şi RMI.

RPC este orientat pe apel de procedură pe când RMI este destinat aplicaŃiilor orientate obiect
şi asigură invocarea de metode ale obiectelor.

Pe de altă parte, parametrii unui apel RPC sunt structuri de date obişnuite pe când la RMI se
pot transfera obiecte ca parametri. Dacă parametri sunt obiecte locale atunci ei se transferă
prin copiere utilizând tehnica de serializare a obiectelor. Pentru aceasta tipurile parametrilor
lor trebuie să implementeze interfaŃa java.io.Serializable ceea ce permite transformarea
obiectului într-un flux de octeŃi. Dacă parametri sunt obiecte aflate la distanŃă atunci ei sunt
transferaŃi prin referinŃă.

Nivelul de abstractizare oferit de RMI permite dezvoltatorilor de aplicaŃii Java să invoce metodele
la distanŃă la fel ca şi pe cele locale (aflate pe aceeaşi JVM).

RMI oferă o funcŃionalitate sporită faŃă de RPC.[1] Astfel, poate transfera obiecte ca argumente.
Aceasta are ca rezultat transfer de comportament prin download a implementării unei interfeŃe la
client atunci când e solicitată, deci se va obŃine o variantă actualizată (dacă între timp au apărut
modificări).

Alte caracteristici RMI:

mecanisme de securitate built_in (la descărcare cod la clienŃi)

portabil;

garbage collection distribuit;

multi – threaded = > calcul paralel


[1] Paradigma RPC este independentă de limbaj, deci defineşte o funcŃionalitate mai generală.
RMI
Deschide un serverSoket pentru obj (serviciu)
(portul este indicat de client)
(evidenŃă servere)

Naming. bind (Nume_server, obj)

Registry Remote Object

Server Socket (1099) Server Soket (alt port pt. obj)

1: Naming. lookup („nume_server”) => se

realizează o conexiune la ServerSoket

3: invocare metodă
2: returnează stub

Client

Fig.x.x Mecanismul RMI