Dezvoltarea aplicațiilor ce comunică pe net

Plecand de la design-ul actual (ceea ce nu stiu daca e o idee buna), as putea face o clasa Server, ce se va ocupa de conexiune (eventual si ceva parsare), un StaticHandler si un DynamicHandler. Pentru ca ultimile 2 imprumuta destul de multe concepte comune, m-as gandi sa fac o clasa Handler, si StaticHandler si DynamicHandler sa fie "mostenitori".

Gady_paul, on 05 octombrie 2013 - 22:21, said:

Am şi zis:

OriginalCopy, on 05 octombrie 2013 - 15:55, said:

Poate că numele claselor sunt bune, dar nu poţi pleca de la "designul actual" deoarece:
- nu întotdeauna vei avea un "design actual", de cele mai multe ori vei începe un proiect de la zero direct în OOP
- tu vrei să înveţi OOP, e o nouă paradigmă de programare, nu poţi sta cu vechea paradigmă în minte şi să te aştepţi să iasă ceva bun

Să zicem că clasele sunt bune, dar nu sunt toate.

În descrierea aplicaţiei se află ascunse mai toate clasele:

Aplicaţia mea este un daemon http care deserveşte conţinut clienţilor care se conectează şi trimit cereri.

Aproape fiecare al doilea cuvânt e câte un concept din aplicaţie.

OriginalCopy, on 06 octombrie 2013 - 06:11, said:

Am pictat cu rosu keywords care mi se par relevante. Deci, ar trebui (ca mai devreme), o clasa Server (care e si un soi de controller), Request, care se ocupa de primire cerere/parsare, ResolveStaticRequest/ResolveDynamicRequest pentru deservirea celor 2 tipuri de cereri, Client, care se ocupa de interactiunea cu clientul.

P.S. nelegandu-ma de aplicatie, daca vreau sa fac treaba X, si pentru asta am deja ceva functii existente intr-o biblioteca procedurala, se practica/se pot crea clase-wrapper care au ca scop interfatarea intre procedural si aplicatia mea oop?

Gady_paul, on 06 octombrie 2013 - 19:39, said:

Dacă ai Request, ar trebui să ai şi Response. Acum, vezi cum le îmbini.

Gady_paul, on 06 octombrie 2013 - 19:39, said:

Depinde de priorităţile proiectului.

Dacă faci un rewrite şi nu vrei să mai expui nimic procedural, nu se practică.

Dacă biblioteca respectivă e mentenată separat, intern sau extern, şi rezolvă probleme pe care nu vrei să le mai rezolvi încă o dată, se practică.

Totul depinde de proiectul concret pe care-l ai în faţă, nu există reţete magice.

Şi în general, nu te lua după sfaturi măreţe, "reţete magice". Majoritatea deciziilor interesante sunt relative la proiectul concret.

Pentru ca cererea e in principiu de un fel, as putea face asa:
Server, Request, Client, Response (si StaticResponse/DynamicResponse ca mostenitori), caci rezolvarea cererii e practic generarea raspunsului.
Eventual se pot crea si clase gen GetRequest/PostRequest dar nu cred ca e cazul.

Deci, sunt pe drumul cel bun sau departe de el?

Am hotarat sa extind varianta procedurala cu signals/multithreading/servire dinamica a paginilor (nu era terminata).

Pe scurt, fiecare cerere sta intr-un nou thread. Cat despre cererile dinamice, folosesc execve. Problema in cazul acestora (am incercat si o abordare cu pipes, tot fara rezultat), este ca nu pot determina lungimea raspunsului. Din fericire, standardul HTTP spune pe undeva ca daca lungimea raspunsului nu este specificata, raspunsul se incheie odata cu incheierea conexiunii (scrie in primele randuri de aici: http://www.w3.org/Pr...html#BodyLength).

Nu pot determina response length fara a rula de 2 ori sau a stoca in memorie raspunsul (chestie nepractica), asa ca am zis sa il inchei prin terminarea conexiunii. Dupa umila mea parere (si dupa cum spune si telnet), conexiunea se inchide si continutul este transmis. Numai ca browserul nu se prinde de chestia asta.

Asta zice telnet cand vorbeste cu serverul:

GET /x.php HTTP/1.0
HTTP/1.0 200 OK
Location: localhost
Content-type: text/html; charset=UTF-8
array(0) {
}
NO AConnection closed by foreign host.

Si asta zice telnet cand vorbeste cu apache:

GET /x.php HTTP/1.1
Host: localhost
HTTP/1.1 200 OK
Date: Mon, 11 Nov 2013 19:16:09 GMT
Server: Apache/2.2.25 (Unix) mod_ssl/2.2.25 OpenSSL/1.0.1e DAV/2 PHP/5.5.3
X-Powered-By: PHP/5.5.3
Content-Length: 17
Content-Type: text/html
array(0) {
}
NO AConnection closed by foreign host.

Si nu in cele din urma, acesta este x.php:

<?php
var_dump($_GET);
if(isset($_GET['a'])){
	echo $_GET['a']*5;
}else{
	echo "NO A";
}

Aici sunt rezolvate cererile dinamice: https://github.com/P...r/src/dynamic.c
Aici se intampla fork, se rezolva cererea, se inchide conexiunea si se omoara copilu' (adica child reaping, sa nu va ganditi la prostii ): https://github.com/P...ver.c#L101-L118
(ingorati printf-urile, au scopuri de debugging).

PHP poate genera si el headere. Tii cont de ele?
Pentru site-uri dinamice nici nu prea are rost sa transmiti dimensiunea, ele oricum fiind relativ mici. Daca, prin php, trimiti defapt continutul unui fisier, setezi din php headerul cu dimensiunea corespunzatoare.

Apoi, in HTTP/1.0 conexiunea se inchide dupa fiecare cerere, doar HTTP/1.1 permite mai multe cereri succesive pe acceasi conexiune.
Ce intelegi prin "browserul nu se prinde"?

dani.user, on 11 noiembrie 2013 - 21:58, said:

Nu, voi implementa si chestia asta.

dani.user, on 11 noiembrie 2013 - 21:58, said:

Conexiunea e inchisa (nu asteapta/transfera date), dar pagina e goala sau nu arata nici o pagina.

Fa un debug de la View Source, la o analiza cu Wireshark (sub linux poti capta usor si loopback-ul).
Vezi sa nu fie si ceva din cauza cache-ului din browser.

Am curatat cache-ul si se comporta la fel.

Cat despre analiza cu wireshark, intrucat cunostintele mele nu sunt foarte vaste, am hotarat sa atasez aici niste screenshot-uri.
Primul screenshot reprezinta toate pachetele din timpul recording-ului, cu exceptia discutiilor cu routerul care nu cred ca sunt relevante in cazul de fata.
Inregistrarea a fost facuta pe 192.168.1.3, iar serverul rula pe 192.168.1.2. Se observa cererea http (pachetul 8). Pachetele 10 si 12 reprezinta headerele, respectiv body-ul response-ului, asa cum se vede in screenshot-ul 2. Datele sunt ele la locul lor, numai ca e interesat ca nu sunt recunoscute ca protocol HTTP de catre wireshark.

Edited by Gady_paul, 12 November 2013 - 22:24.

Right click si da-i sa-ti arate strict conversatia HTTP.

Cam asta e intreaga conversatie

Edited by Gady_paul, 12 November 2013 - 22:46.

Dupa ultimul header mai trebuie un rand liber lasat, inainte de continut.

Pfff, asta era. Multumesc mult.

Totusi, de ce daca ii spuneam content-length se descurca?