[so] Tema 4 linux

[cosminratiu at gmail.com]

On 12/15/06, Catalin Iacob <iacobcatalin at gmail.com> wrote:
>
> Salut
>
> 2. in apelul recv putem si daca da e indicat sa folosim flagul
> MSG_WAITALL? Pe de o parte simplifica tema prin faptul ca stim sigur ca
> a venit toata bucata / fisierul ( in functie de raspunsul la intrebarea
> 1 ) dar introduce aceeasi ineficienta datorata asteptarii mai mult timp
> pe socket

3. epoll se deblocheaza si cand un client incearca sa stabileasca o
> conexiune fara sa vrea neaparat sa trimita date, deci nu e nevoie de un
> al doilea thread in care serverul sa stea blocat in accept(), poate sa
> stea mereu in epoll. Corect?
>
> Imi inchipui ca testele se pot trece si fara multe intrebari filosofice
> in stilul primelor 2 de mai sus (se fac pe localhost si cu maxim 1MB
> daca am vazut bine). Dar tema a plecat de la ideea ca folosim IO
> asincron pentru a suporta un numar mare de clienti si a fi ultra
> eficienti. Daca nu conta puteam sa facem thread diferit pentru fiecare
> client si gata - era mai simplu API-ul.
>
> Multumesc... iar a iesit un post lung :-(
> _______________________________________________
> so mailing list
> so at cursuri.cs.pub.ro
> http://cursuri.cs.pub.ro/cgi-bin/mailman/listinfo/so
>

Nu trebuie presupus ca mesajele vin toate deodata. Protocolul implementat de
voi trebuie sa faca fata la situatii in care datele vin cate un byte pe
rand(e un exemplu extrem). Si pe localhost am vazut ca se poate fragmenta ce
se trimite in bucati mici.
Cat despre cealalta intrebare, da, epoll genereaza un eveniment EPOLLIN cand
pe un socket de ascultare soseste o cerere de conectare. Deci nu e nevoie de
un thread in plus.

Filosofia temei e sa stii cand e ceva de citit => citesti cat ai primit, sa
stii cand ai loc sa mai scrii fara sa blochezi => scrii cat poti si sa faci
operatiile read/write pe fisiere asincron. Scopul e sa stiti sa faceti un
program event-driven in care se manevreaza eficient totul dintr-un singur
thread(sau ma rog, un thread/procesor in tema de windows).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://cursuri.cs.pub.ro/pipermail/so/attachments/20061215/18b0fcd3/attachment.htm