[so] [Tema5] Bug exasperant

[Andrei Mardale]

Salut!

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) .
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) .

Multumesc,
Andrei

Pe 13 mai 2017, 15:03, Costin Lupu <costin.lup at gmail.com> a scris:

> On Sat, 2017-05-13 at 13:52 +0300, Ioana Ciornei via so wrote:
> > Redirectez mesajul către lista de so.
> >
> >
> >
> > On May 13, 2017 12:11, "Andrei Mardale" <andrei.mardale at gmail.com>
> > wrote:
> >         Salut,
> >
> >
> >         Am inceput sa lucrez tema 5, AWS. Aproape am terminat, insa
> >         imi pica ultimele 4 teste uneori (de la 31 .. 35). Testul 31
> >         pica constant.. Am facut debugging si am observat ca nu se
> >         incepe transferul al doilea. Asta pentru ca, desi folosesc
> >         connection_remove(conn); si rc = w_epoll_remove_ptr(epollfd,
> >         conn->efd, conn); dupa ce termin de transferat pentru primul
> >         client, cumva, conexiunea nu este eliminata... astfel ca la
> >         urmatoarea notificare de la epoll, tot pentru acea conexiune
> >         sunt datele.. astfel ca programul se blocheaza in functia
> >         wait_aio(conn); ...
>
> Următorul event de input este cel pentru network (data available for
> receive). Însă îl tratezi eronat ca fiind event de input pentru citirile
> de pe disk. ATENȚIE: un file descriptor invalid are o valoare mai mică
> decât 0 (0 e valoare validă, vezi STDIN_FILENO). Inițializează-ți
> *toate* câmpurile structurii când creezi o conexiune nouă.
>
> >         Chiar nu imi dau seama de ce se intampla asta... de asemenea,
> >         voiam sa intreb daca acel eventfd pentru fiecare conexiune, ar
> >         trebui adaugat cu w_epoll_add_fd sau w_epoll_add_ptr_in si sa
> >         fie legat la conexiunea curenta?
>
> Semantica e aceeași pentru ambele apeluri. Doar în cazul lui
> 'w_epoll_add_ptr_in' mai adaugi niște informație în plus pentru a
> identifica ulterior mai punctual evenimentul primit. Asta înseamnă că e
> de folosit când același file descriptor este asociat cu mai multe
> entități (a se citi conexiuni în cazul temei 5).
>
> Costin
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cursuri.cs.pub.ro/pipermail/so/attachments/20170513/bc2d395b/attachment.html>