Ca o continuare la mailul lui Max, as vrea sa adaug cateva cuvinte despre greselile frecvente la tema 4, mai precis despre partea de retea.<br><br>De departe cea mai des intalnita greseala este presupunerea ca recv/read pe socketi citeste exact ce s-a trimis in partea cealalta. Daca pe localhost chestia asta e adevarata 99% din cazuri, in retea pachetele se pot fragmenta. Solutia este cod care pastreaza ce s-a citit intr-un buffer pana este receptionat un mesaj complet.
<br><br>De asemenea, vad ca multi au folosit socketi blocanti in server. Asta nu e o problema in sine, mai ales cand se foloseste epoll pentru notificari. Problema apare cand pentru o notificare primita se apeleaza de mai multe ori consecutiv recv/read pentru conexiunea in cauza. Primul recv e garantat ca nu blocheaza(doar a fost primita notificarea), dar urmatoarele pot bloca pentru ca s-ar putea sa nu mai fie nimic de citit o anumita perioada. In server nu trebuie sa se blocheze _decat_ in epoll_wait.
<br><br>In cateva teme am gasit o forma deghizata de busy waiting. Cand adaugati un socket nou creat in setul epoll NU dati flag-ul EPOLLOUT. Daca EPOLLOUT e pus, o sa se genereze incontinuu notificari ca "e loc de scris in socket" si daca nu aveti nimic de scris, e echivalentul unui busy waiting. EPOLLOUT este facut ca sa rezolve problema descrisa in continuare.
<br><br>Urmatoarea problema: write pe socketi blocanti s-ar putea sa blocheze pana se face loc in bufferele socket-ului pentru a putea pune datele pe care le vreti trimise. write pe socketi neblocanti s-ar putea sa nu trimita tot ce ii dati daca nu poate face asta fara sa blocheze. Am vazut in prea putine teme tratata situatia asta. Multi fac send si nu verifica daca s-a trimis tot sau nu. Saracul client o sa primeasca in partea cealalta un pachet trunchiat. Solutia: activati EPOLLOUT si pastrati ce mai e de trimis. Cand se termina de trimis scoateti EPOLLOUT. Simplu si logic.
<br><br>Next: designul protocolului. Cand creati un protocol trebuie sa aveti in vedere ce am zis mai sus(grija la fragmentare in principiu) si in plus inca cateva aspecte care fac diferenta intre programatorii buni si cei care introduc gauri de securitate. Regula de aur este SA NU AI INCREDERE IN CE VINE DE PE RETEA. Asta inseamna verificarea chestiilor primite, MARE GRIJA la stringuri. Extrem de multe gauri de securitate sunt cauzate de protocoale care primesc stringuri terminate cu 0, numai ca stringul primit...nu contine 0 la sfarsit. De aici rezulta diverse probleme.
<br><br>Sper ca mail-ul acesta va avea un efect oricat de mic...<br> <div><span class="gmail_quote"><br><br>On 2/8/07, <b class="gmail_sendername">Maximilian Machedon</b> <<a href="mailto:maximilian.machedon@gmail.com">
maximilian.machedon@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">
<div><font face="Arial" size="2"> Scriu acest mail pentru
că m-am apucat să corectez temele 1 (și sper să le și termin la timp :-D, ținând
cont că sunt și eu în sesiune) și am găsit unele greșeli extrem de frecvente... <br></font></div><div>[...bucata taiata...] </div>
<div><font face="Arial" size="2">...PS: Știu că este "doar o temă", dar vă asigur că
există o diferență între a scrie cod bun și a scrie cod care să meargă. Adică
dacă ați scris codul doar că să meargă asta nu v-a ajutat cu nimic pentru a
învăța să scrieți cod bun.</font></div>
<div><font face="Arial" size="2"></font> </div></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></blockquote><div> </div><br></div><br>