<div dir="ltr">Buna,<div>Eu tot am niste nelamuriri legate de citirea asincrona / trimiterea cu send (inline):<br><div class="gmail_extra"><br><div class="gmail_quote">2015-05-25 20:53 GMT+03:00 Adrian Stanciu via so <span dir="ltr"><<a href="mailto:so@cursuri.cs.pub.ro" target="_blank">so@cursuri.cs.pub.ro</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">2015-05-25 20:49 GMT+03:00 Madalina Hristache via so <<a href="mailto:so@cursuri.cs.pub.ro">so@cursuri.cs.pub.ro</a>>:<br>
> Salut,<br>
<br>
Bună, Mădălina!<br>
<span class=""><br>
><br>
> Am câteva nelămuriri și am nevoie de clarificarea lor ca să pot continua<br>
> tema.<br>
><br>
> 1. Când transmitem un fișier din directorul static, trimitem header-ul HTTP<br>
> cu send (non-blocant, asincron), apoi fișierul cu sendfile. Fără nicio<br>
> legătură cu libaio.h, da?<br>
<br>
</span>Da, așa este.<br>
<span class=""><br>
><br>
> 2. Când transmitem un fișier din directorul dynamic, îl citim de pe disc cu<br>
> apeluri legate de libaio.h, apoi îl punem pe socket. Și cum îl trimitem? Cu<br>
> send? Sendfile? La partea asta sunt în ceață.<br>
><br>
<br>
</span>Cu send().<br></blockquote><div><br></div><div>In exemplul din laborator [1], precum si in exemplul sugerat in tema [2] (xmailserver), am observat ca se face read pe un file descriptor, pentru a notifica serverul atunci cand operatia asincrona de citire s-a terminat.</div><div><br></div><div>1) Este acest read blocant, sau nu ?</div><div>2) Care ar trebui sa fie workflow-ul server-ului in cazul trimiterii unui fisier dinamic ? Ma gandeam ca unul posibil este acesta, dar inca nu imi dau seama daca este corect:</div><div><ul><li>initializare io_context (in main, inainte de logica serverului);</li><li>in server, primirea unui request de citire fisier dinamic;</li><li>trimiterea catre client a unui raspuns: 200/404, in functie de caz, prin send-uri repetate (metoda comuna, atat pentru fisier static, cat si pentru dinamic);</li><li>dupa trimiterea header-ului, in cazul unui fisier dinamic, serverul seteaza un eventfd si submite un request de read pentru contextul aio -- actiune neblocanta;</li><li>serverul face read pe eventfd-ul anterior -- <b>actiune blocanta</b> ?;</li><li>in urma notificarii de terminare a citirii din fisier a unui buffer <b>in general mai mic decat dimensiunea fisierului</b>, serverul face apeluri send repetate, pentru a trimite buffer-ul proaspat citit; -- <b>in timpul acesta, se presupune ca serverul initiaza o noua cerere de citire asincrona, sau asteapta trimiterea buffer-ului curent ? </b>;</li><li>serverul continua sa citeasca bucati de fisier si sa le trimita catre client.</li></ul></div><div>3) Este corect ca in functia de trimitere fisier, pentru cazul unui fisier dinamic, si care se tot apeleaza in bucla principala a server-ului (pentru ca epoll este setat pe out, cat timp trimit un fisier), sa verific si sa schimb starea conexiunilor (de ex, cat timp trimit fisierul, starea sa fie SENDING_DATA, apoi, cand citirea asincrona se termina, pur si simplu sa schimb starea in DATA_SENT si sa inchid conexiunea) ? </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
Adrian<br>
_______________________________________________<br>
<a href="http://ocw.cs.pub.ro/courses/so/info/lista-discutii" target="_blank">http://ocw.cs.pub.ro/courses/so/info/lista-discutii</a></blockquote></div><br><br>[1] <a href="http://ocw.cs.pub.ro/courses/so/laboratoare/laborator-11#integrarea_linux_aio_cu_eventfd">http://ocw.cs.pub.ro/courses/so/laboratoare/laborator-11#integrarea_linux_aio_cu_eventfd</a></div><div class="gmail_extra">[2] <a href="http://www.xmailserver.org/eventfd-aio-test.c">http://www.xmailserver.org/eventfd-aio-test.c</a><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><font color="#0000ff"><b>Georgiana Diana Ciocirdel</b></font><div>Polytechnic University of Bucharest,</div><div>Computer Science</div></div></div>
</div></div></div>