[so] [SO][Tema 5][Linux] netcat opreste conexiunea prea devreme

George Diaconu pgn.george at gmail.com
Fri May 17 18:01:50 EEST 2019


Revin cu o completare.
La testul 16, server-ul afiseaza ca a trimis raspunsul "200 OK", apoi
fisierul si ca a inchis conexiunea, chair daca wget spune ca a fost
inchisa conexiunea inainte sa primeasca macar "200 OK".
Am rulat testul si am obitnut 2 fisiere .pcap, unul pentru o executie
cu succes a testului si altul cand esueaza testul. Las arhiva cu cele
doua fisiere la [1].
La [2] este link-ul catre repo-ul meu.

Numai bine,
George Diaconu

[1] https://drive.google.com/open?id=1JG98HjEDUO7kZM0UmOiHid62gF0OWqNY
[2] https://gitlab.cs.pub.ro/george.diaconu2208/l3-so-assignments

În vin., 17 mai 2019 la 16:48, George Diaconu <pgn.george at gmail.com> a scris:
>
> Salut,
>
> Am reusit sa rezolv problema asta intre timp. Las la [1] link-ul unde
> am inteles care a fost problema. Pe scurt, din ce am inteles, netcat
> anunta ca este gata sa opreasca conexiunea, dar server-ul considera ca
> s-a si deconectat si dadea drop conexiunii. Acum in momentul in care
> recv intoarce 0, nu inchid imediat conexiunea, verific in ce stadiu
> este conexiunea (am o masina de stari cum este recomandat in enuntul
> temei), si inchid conexiunea dupa ce a fost trimis tot fisierul.
>
> Acum am probleme cu testul 16. Uneori merge, alteori nu merge. Acest
> test foloseste wget. Cand nu merge, mesajul intors de wget este "Read
> error (Connection reset by peer) in headers." Interesant este ca daca
> adaug flag-ul '-d' comenzii wget, testul trece mereu (am testat cu 100
> de rulari succesive, fara '-d' merge foarte rar). Flag-ul acesta ar
> trebui doar sa produca mai mult output, dar cumva face mai mult.
>
> Numai bine,
> George
>
> [1] https://stackoverflow.com/questions/41776718/what-exactly-does-the-q-option-of-netcat-do
>
> În vin., 17 mai 2019 la 15:12, Razvan Crainea
> <razvan.crainea at gmail.com> a scris:
> >
> > Salut, George!
> >
> > Poți face un trace pcap (folosind wireshark sau tcpdump) pe portul
> > 8888, să vedem exact comunicația TCP între client și server?
> >
> > Numai bine,
> > Răzvan
> >
> > On Fri, May 17, 2019 at 1:28 AM George Diaconu via so
> > <so at cursuri.cs.pub.ro> wrote:
> > >
> > > Salut,
> > >
> > > Am o problema la testul 13. Checker-ul executa urmatoarea comanda:
> > > echo -ne "GET /static/small00.dat HTTP/1.0\r\n\r\n" | nc -q 1
> > > 192.168.169.128 8888
> > >
> > > Inteleg de aici ca cere fisierul /static/small00.dat.
> > > Problema mea este ca dupa ce clientul trimite toata cererea (unesc
> > > bucatile trimise de client), server-ul apuca sa parseze cererea, dar
> > > apoi client-ul inchide conexiunea fara sa mai astepte raspunsul.
> > > Am reusit sa reduc problema la parametrul '-q 1' al comenzii 'nc'. In
> > > manual scrie ca acest parametru face ca 'nc' sa mai astepte o secunda
> > > dupa ce a primit EOF de la stdin, si apoi se inchide.
> > > Am incercat cu '-q 5' si am observat ca server-ul scrie mesajul de la
> > > deconectarea cleintului inainte ca 'nc' sa isi termine executia. Asta
> > > ma face sa trag concluzia ca nc inchide conexiunea mult prea devreme.
> > > Restul testelor de la static merg fara probleme.
> > >
> > > De asemenea, in momentul in care trimit raspunsul, intai raspund cu
> > > HTTP/1.1 200 OK si apoi incep sa trimit fisierul. De asemenea, verific
> > > ca raspunsul sa fie trimis in intregime, si trimit pe bucati daca nu
> > > poate fi trimis tot o data.
> > >
> > > Nu inteleg unde gresesc, mai ales ca restul testellor trec fara probleme.
> > >
> > > Multumesc anticipat.
> > > _______________________________________________
> > > http://ocw.cs.pub.ro/courses/so/info/lista-discutii
> >
> >
> >
> > --
> > Răzvan Crainea


More information about the so mailing list