Nu o sa primesti niciodata 100 de MB intr-un foc la un recv, in primul rand pentru ca nu ai tu buffer de 100 de MB (sper :) ), si in al doilea rand pentru ca prin natura tcp-ului nu o sa iti tina el atatea date in bufferele lui, o sa se umple la un moment dat si nu o sa mai accepte date de la transmitator pana nu mai citesti din date tu, user-ul.
<br><br>Cat despre partea cu operatiile aio si socketi, s-ar putea sa gresesc. Oricum, informatiile pe internet sunt contradictorii. Ceea ce este sigur este ca nu se folosesc operatiile aio pentru partea de retea, ci se foloseste epoll. Oricum, acuma e prea tarziu pentru a schimba enuntul/reface testele/etc. Deci folositi epoll pt retea si aio_read/aio_write+semnale pe partea de disk si totul intr-un singur thread.
<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;">
<div bgcolor="#ffffff" text="#000000">
Cosmin Ratiu mi-a raspuns acum cateva zile:<br>
"Salut.<br>
<br>
Da, banuiesti bine, nu merg operatiile asincrone pe
socketi...deocamdata[...] in momentul de fata, aio_read si
aio_write merg doar pe fisiere. In concluzie, pe partea de server o sa
ai un thread care foloseste epoll ca sa iti dai seama cand poti
citi/scrie fara sa blochezi.
"<br>
<br>
Deci daca folosim recv pe socket (ca aio_read nu merge) si primim multe
date (gen 100MB) in server, eu ziceam doar ca o sa dureze multicel -
vreo cateva minute - si ca deci sunt probleme de eficienta si
scalabilitate, nu ca recv se blocheaza nedefinit pana vine ceva pe
socket.<br>
<br>
Cercetand putin am gasit la adresa
<a href="http://www-128.ibm.com/developerworks/linux/library/l-async/index.html" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://www-128.ibm.com/developerworks/linux/library/l-async/index.html
</a>
fraza "The <code>aio_read</code> function requests an asynchronous
read operation for a valid file descriptor. The file descriptor can
represent
a file, a socket, or even a pipe.". Asa ca acum sunt total confuz: se
poate sau nu folosi aio_read direct pe socket-ul serverului?<span class="q"><br>
<br>
Octavian Purdila wrote:
<blockquote cite="http://mid200612151856.12795.tavi@cs.pub.ro" type="cite">
<pre>On Friday 15 December 2006 18:17, Catalin Iacob wrote:<br> </pre>
<blockquote type="cite">
<pre>Salut<br><br>Eu tot am cateva nelamuriri legate de tema pe linux(sper sa fie ultimele<br>si sa ma apuc apoi de treaba):<br><br>1. fisierele trebuie impartite in bucati sau nu? - ma gandesc ca nu prea<br>e normal sa trimiti un fisier de 100MB tot odata din moment ce serverul
<br>va sta blocat (din moment ce se fac read/write blocante) un timp de<br>ordinul minutelor daca se comunica prin Internet; in timpul asta<br>clientii se vor aduna la coada si daca se va depasi parametrul 2 backlog<br>al functiei listen conexiunea le va fi refuzata
<br><br> </pre>
</blockquote>
<pre>Serverul nu trebuie sa se blocheze la operatiile de read/write. Din cauza asta <br>folositi epoll si aio_*. <br><br>Doar clientul se poate bloca.<br><br>tavi<br><br> </pre>
</blockquote>
<br>
</span></div>
<br>_______________________________________________<br>so mailing list<br><a onclick="return top.js.OpenExtLink(window,event,this)" href="mailto:so@cursuri.cs.pub.ro">so@cursuri.cs.pub.ro</a><br><a onclick="return top.js.OpenExtLink(window,event,this)" href="http://cursuri.cs.pub.ro/cgi-bin/mailman/listinfo/so" target="_blank">
http://cursuri.cs.pub.ro/cgi-bin/mailman/listinfo/so</a><br><br><br></blockquote></div><br>