<div dir="ltr"><div><div>Salut!<br></div><br>Multumesc mult pentru sfaturi! Am rezolvat in mare parte. Acum am o alta problema: uneori, la ultimul test (cel cu ambele tipuri de fisiere) se intampla urmatorul lucru: primesc o cerere pentru un fisier, trimit fisierul corect, insa dupa un timp, primesc din nou o cerere pentru acelasi fisier. A doua oara, parserul gaseste o cale gresita, ex ./static/large07.datt . Astfel ca cel mai probabil se trimite un 404 Not Found si se suprascrie fisierul initial trimis cu un fisier gol ( 0 K) .<br></div><div>Ma gandesc ca ar putea fi din cauza modului in care inchid conexiunea in cazul fisierelor statice? Eu apelez functia 'connection_remove()', in care se inchide socket-ul, se schimba starea in STATE_CONNECTION_CLOSED si se face free(con) . <br><br></div><div>Multumesc,<br></div><div>Andrei<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">Pe 13 mai 2017, 15:03, Costin Lupu <span dir="ltr"><<a href="mailto:costin.lup@gmail.com" target="_blank">costin.lup@gmail.com</a>></span> a scris:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Sat, 2017-05-13 at 13:52 +0300, Ioana Ciornei via so wrote:<br>
> Redirectez mesajul către lista de so.<br>
><br>
><br>
><br>
> On May 13, 2017 12:11, "Andrei Mardale" <<a href="mailto:andrei.mardale@gmail.com">andrei.mardale@gmail.com</a>><br>
> wrote:<br>
>         Salut,<br>
><br>
><br>
>         Am inceput sa lucrez tema 5, AWS. Aproape am terminat, insa<br>
>         imi pica ultimele 4 teste uneori (de la 31 .. 35). Testul 31<br>
>         pica constant.. Am facut debugging si am observat ca nu se<br>
>         incepe transferul al doilea. Asta pentru ca, desi folosesc<br>
>         connection_remove(conn); si rc = w_epoll_remove_ptr(epollfd,<br>
>         conn->efd, conn); dupa ce termin de transferat pentru primul<br>
>         client, cumva, conexiunea nu este eliminata... astfel ca la<br>
>         urmatoarea notificare de la epoll, tot pentru acea conexiune<br>
>         sunt datele.. astfel ca programul se blocheaza in functia<br>
>         wait_aio(conn); ...<br>
<br>
</span>Următorul event de input este cel pentru network (data available for<br>
receive). Însă îl tratezi eronat ca fiind event de input pentru citirile<br>
de pe disk. ATENȚIE: un file descriptor invalid are o valoare mai mică<br>
decât 0 (0 e valoare validă, vezi STDIN_FILENO). Inițializează-ți<br>
*toate* câmpurile structurii când creezi o conexiune nouă.<br>
<span class=""><br>
>         Chiar nu imi dau seama de ce se intampla asta... de asemenea,<br>
>         voiam sa intreb daca acel eventfd pentru fiecare conexiune, ar<br>
>         trebui adaugat cu w_epoll_add_fd sau w_epoll_add_ptr_in si sa<br>
>         fie legat la conexiunea curenta?<br>
<br>
</span>Semantica e aceeași pentru ambele apeluri. Doar în cazul lui<br>
'w_epoll_add_ptr_in' mai adaugi niște informație în plus pentru a<br>
identifica ulterior mai punctual evenimentul primit. Asta înseamnă că e<br>
de folosit când același file descriptor este asociat cu mai multe<br>
entități (a se citi conexiuni în cazul temei 5).<br>
<span class="HOEnZb"><font color="#888888"><br>
Costin<br>
<br>
<br>
</font></span></blockquote></div><br></div>