<br><br><div><span class="gmail_quote">On 12/15/06, <b class="gmail_sendername">Catalin Iacob</b> <<a href="mailto:iacobcatalin@gmail.com">iacobcatalin@gmail.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Salut<br><br>2. in apelul recv putem si daca da e indicat sa folosim flagul<br>MSG_WAITALL? Pe de o parte simplifica tema prin faptul ca stim sigur ca<br>a venit toata bucata / fisierul ( in functie de raspunsul la intrebarea
<br>1 ) dar introduce aceeasi ineficienta datorata asteptarii mai mult timp<br>pe socket</blockquote><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
3. epoll se deblocheaza si cand un client incearca sa stabileasca o<br>conexiune fara sa vrea neaparat sa trimita date, deci nu e nevoie de un<br>al doilea thread in care serverul sa stea blocat in accept(), poate sa<br>stea mereu in epoll. Corect?
<br><br>Imi inchipui ca testele se pot trece si fara multe intrebari filosofice<br>in stilul primelor 2 de mai sus (se fac pe localhost si cu maxim 1MB<br>daca am vazut bine). Dar tema a plecat de la ideea ca folosim IO<br>
asincron pentru a suporta un numar mare de clienti si a fi ultra<br>eficienti. Daca nu conta puteam sa facem thread diferit pentru fiecare<br>client si gata - era mai simplu API-ul.<br><br>Multumesc... iar a iesit un post lung :-(
<br>_______________________________________________<br>so mailing list<br><a href="mailto:so@cursuri.cs.pub.ro">so@cursuri.cs.pub.ro</a><br><a href="http://cursuri.cs.pub.ro/cgi-bin/mailman/listinfo/so">http://cursuri.cs.pub.ro/cgi-bin/mailman/listinfo/so
</a><br></blockquote></div><br>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.<br>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.
<br><br>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).
<br><br>