Dotaz: C sitova aplikace, ztrata tal odpovedi

[Karel Dlouhy]

Dobry den, delam jednoduchou sitovou aplikaci v C, ktera vysle HTTP pozadavek a prijde odpoved. Odpoved prijimam nadvakrat, nejdrive hlavicku odpovedi, pote telo:

    int BUFSIZE = 1;    

    // read HTTP response header
    while ((size = recv(s, buf, BUFSIZE, MSG_WAITALL)))
    {
        cout << "1";
        response_header += buf[BUFSIZE-1];
        i = response_header.find("\r\n\r\n");
        if (i != std::string::npos)
            break;
    }

    cout << "Response header:\n" << response_header << endl;

    // read HTTP response body
    while ((size = recv(s, buf, BUFSIZE, MSG_WAITALL)))
    {
        cout << "2";
        response_body += buf[BUFSIZE-1];
        i = response_body.find("\r\n\r\n");
        if (i != std::string::npos)
            break;
    }
    cout << "Response body:\n" << response_body << endl;

Mam vsak problem, ze hlavicka se nacte a zobrazi v poradku a pote program zamrzne takto:

111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111Response1:
HTTP/1.1 200 OK
Content-Type: text/plain
Cache-control: no-cache, no-store
Pragma: no-cache
Expires: Mon, 01-Jan-1990 00:00:00 GMT
Date: Tue, 06 Oct 2009 16:54:13 GMT
X-Content-Type-Options: nosniff
X-XSS-Protection: 0
Content-Length: 584
Server: GFE/2.0


                   

Navic se nevypisuji ani dvojky, ktere jsou v druhem cyklu, to znamena, ze program necykli, proste jen stoji za prikazem vypsani hlavicky odpovedi

Kdyz takto necham program viset v konzoli nekolik minut, telo se nakonec nacte. Proc je tam ale vzdy ten dlouhy zasek?

Odpovědi

[Karel Dlouhy]

Tak jsem zjistil, ze toho tela odpovedi se nekdy nedockam vubec, program se proste zasekne. Divne...

[petr_p]

Nevím, jak se chová string::find(), ale rozhodně byste si měl hlídat návratovou hodnotu z recv(), protože může být i -1.

Pokud potřebujete zjistit, jak si program povídá s jádrem, zkuste nástroj strace(1).

A pro skutečné nasazení otravovat jádro po jednom bajtu je neefektivní. Zkuste větší buffer.

[wintermute]

No pre vacsi buffer ako 1 mu to fungovat nebude lebo ked si ho da napr. 1K tak sa mu moze stat, ze prvym recv si nacita aj cast tela, teoreticky aj celu poziadavku a ten druhu recv pre telo uz nebude mat co nacitat. Je to ukazka toho ako sa programovat nema. Problem toho programu je, ze je to kus bordelu. Autor by si mal sadnut a navrhnut poriadne to co chce robit. A az potom sa pustit do pisania programu. Respektive predtym by si mal este nastudovat programovacie techniky.

[Messa]

Zajímavé, mě to funguje (http://gist.github.com/acfbf88598c50c00325a).

Chybu ve tvém případě odhaduji v:

1. cout << "2"; se bufferuje, text se odešle až po flushnutí nebo zapsání \n. Zkus tam dát třeba cout << "2" << flush;
2. zde uvedený příklad není to, co ve skutečnosti spouštíš; ve skutečnosti třeba může HTTP spojení zůstat otevřené a čekat na další požadavek, pokud je v režimu connection: keep-alive (uvedeno i v hlavičkách odpovědi)
3. něco ošklivého se stane a recv() vrátí -1, čímž neskončí cyklus, i když by měl
4. všeobecně hrozná kvalita kódu, možná včetně toho, který tu ani nevidíme :)

BTW. HTTP odpověď není ukončena sekvencí \r\n\r\n (takto jsou jen odděleny hlavičky od těla). find je v druhém cyklu nesmyslný a může způsobovat useknutí odpovědi.

Pevně doufám, že až to rozchodíš, vezmeš si k srdci i rady od petr_p.

[NeoV]

Ja by som este dodal, ze toto NIE JE (!!!) jazyk C, ale C++.

Btw. pred tym nez zacnes pisat program je dobre si zvolit spravny jazyk. Pre pracu s textami (hlavne bez GUI) su vhodne skriptovacie jazyky - napr. perl, python, bash. C/C++ sa vyuziva pri rieseni zlozitych algoritmickych/matematickych uloh. Ak chces GUI aplikaciu tak volis Java/C#/C++.

Samozrejme, ze vsetko sa da spravit v kazdom jazyku, ale niektory jazyk ti ulohu skomplikuje viac ako iny...

[pht]

Bože, to je prasárna.

[wintermute]

Dufam, ze to si pisete tu aplikaciu len tak lebo vas to bavi. Dufam, ze to nieje nejaka komercna zakazka a ze Vy nepracujete ako programator. Ak pracujete ako programator tak to lutujem vaseho klienta. Osobne by som Vam potom odporucil zmenu zamestnania. Na to sa neda ani pozerat.

Odhliadnuc od toho, ze miesate dohromady C a C++. Pre pripad kedy BUFSIZE bude ine ako 1 vam to aj tak, nebude fungovat. Prepinat kontext z userspace do jadra pri kazdom prijimanom znaku je asi nejaka technika ako zabezpecit procesoru aby sa nenudil. A keby sa nahodou nudil tak po kazdom prijatom znaku mu date pekne prehladat stale vsetko co ste zatial prijali. Ved dnesne procaky su rychle tak naco spravit s kazdym znakom 4 operacie ked ich mozete spravit 4000 vsakze.

Hovorim Vam nieco pojem: Programovacie techniky? Zvykne sa to ucit na niektorych skolach.

Bohuzial takto programuje 95% "programatorov".

[rastos]

Prepinat kontext z userspace do jadra pri kazdom prijimanom znaku je asi nejaka technika ako zabezpecit procesoru aby sa nenudil

O to sa snáď stará runtime, nie? Prečo by read() musel prepínať do jadra, keď môže jednoducho vrátiť ďalší znak z bufferu, ktorý bol jadrom prijatý naraz v jednom kroku a odovzdaný runtime knižnici? (Len sa pýtam. Pripadá mi logické, aby to tak bolo.)

[oroborus]

>>O to sa snáď stará runtime, nie?

IMHO funkcia read je iba wrapper pre systemove volanie read a pri kazdom systemovom volani dojde k prepinaniu kontextu z userspace do jadra.

[Messa]

Ne, read() je interface jádra. Tím, čemu říkáš runtime, je třeba libc a její funkce fread(), nebo std::fstream; to je to, co si vede buffer a v případě potřeby volá read().

Je to vidět třeba na tom, že read() se volá s file deskriptorem typu int jako parametrem, což je vlastně offset do nějaké tabulky vedené jádrem, kdežto fread() s parametrem typu FILE*, což je struktura obsahující právě ten buffer, informace o pozici apod. A také je to napsané v manuálových stránkách všech těchto funkcí (a ty manuálové stránky jsou podle toho v příslušných sekcích, tj. 2 nebo 3).

[rastos]

S tým sa dá súhlasiť, ale išlo mi o to, že to *môže* byť inak. Napr. ak daný kód pobeží na Windowsoch, tak zodpovedajúce funkcie jadra budú CreateFile/ReadFile/... a práve open/read/.. je tým wrapperom. Na inom OS to zasa môže byť inak. Čiste teoreticky by sa preto programátor nemusel zaujímať o to, či dôjde k prepnutiu do jadra. Zaujímavé je to len v prípade, keď vie na akej platforme pobeží a chce z nej vyžmýkať všetko čo sa dá. To už ale spadá pod tému "predčasná optimalizácia je ...". Je pravdepodobné, že čítať viac bajtov naraz je optimálnejšie, ale za tak hrubú chybu by som to nepovažoval.

[Karel Dlouhy]

Stezovali jste si, ze micham C a C++, jak tedy ale nactu ze socketu C++ string? Jedine co me napadlo je to do nej kopirovat takto pismenko po pismenku. Vsichni jste to zdrbali, ale tak nekdo napiste jak to tedy poradne programatorsky udelat, rad se poucim...

[Messa]

Jak programovat komunikaci síť? Můžeš použít standardní knihovnu C, která implementaci bufferu/streamu samozřejmě obsahuje; sice především pro soubory, ale obsahuje i „kouzelnou“ funkci fdopen() (stream pro čtení a stream pro zápis se musí otevřít zvlášť, nelze mít jeden na obojí).

Můžeš použít nějakou implementaci pro C++. Standardní knihovna (STL) C++ sice streamy taky umí, ale pokud vím, nelze přímo pracovat s nějakým už předem otevřeným file deskriptorem (lze to ale celkem snadno doprogramovat). Nebo použít Boost.

Takový buffer si i můžeš udělat sám. Jde o to mít nějaký buffer (pole char), třeba cyklický, do něj zapisovat data přečtená pomocí read(). Musíš si hlídat, kde ti data začínají, kde končí apod.. Z tohoto bufferu můžeš vytvářet C++ řetězce (std::string), buď dané délky, nebo mít tam nějakou logiku na detekci řádků. A to logiku pokud možno efektivnější než pokaždé volat find("\n") na všechna přečtená data. Zkoušel jsem najít nějaký příklad, ale žádný pěkný a v C++ jsem nenašel, což bude asi tím, že každý rozumný programátor na to použije nějakou knihovnu.

K míchání C a C++ – samozřejmě, že pokud to budeš dělat celé sám, tak se Céčkovým věcem úplně nevyhneš, protože systémová volání se takto prostě volají. Mě se ale nezdá, že bys v nějak extrémně míchal C a C++, to spíš ten jednobytový buffer a ignorování chybových návratových hodnot je větší pecka než míchání nízkoúrovňových volání s řekněme aplikační logikou.

[Michal Kubeček]

Standardní knihovna (STL) C++ sice streamy taky umí, ale pokud vím, nelze přímo pracovat s nějakým už předem otevřeným file deskriptorem (lze to ale celkem snadno doprogramovat).

Problém je v tom, že C++ jako abstraktní jazyk (a tedy ani standardní C++ knihovna) pojem file descriptor vůbec nezná, takže může být v principu implementován(a) i na platformě, kde nic takového neexistuje. Proto ani součástí standardní C++ knihovny nemůže být funkce, která by umožnila C++ stream svázat s deskriptorem. Možné přístupy jsou asi tak tři:

• použít nekompatibilní rozšíření konkrétní implementace (GNU takové mívala, ale IIRC už nemá)
• pomocí fdopen() to nejdřív navázat na céčkový stream
• napsat si vlastní třídu rozšiřující basic_streambuf a pomocí ní pak už snadno i třídu rozšiřující basic_stream

Postupně jsem od první možnosti přes druhou došel až ke třetí.

[AraxoN]

Pokiaľ ide o HTTP requesty v C/C++, tak namiesto takýchto pokusov by som do toho zapojil knižnicu libcurl. Tá rieši aj plno vecí, na ktoré si ani nepomyslel - napríklad redirect, partial response, kompresiu, keep-alive, a tak podobne. Ver mi - bol som tam kde ty si teraz a rozhodol som sa programovať si takéto somariny sám. Bolo to zlé rozhodnutie.

Pokiaľ ide o samotné Tvoje C/C++, tak majú kolegovia zväčša pravdu. Ak je to možné, tak by som sa sústredil na jednoduchšie príklady.

A pokiaľ ide o Tvoju schopnosť položiť správne otázku - ak chceš aby Ti ľudia pomohli to opraviť, mal si zverejniť (najlepšie v prílohe) taký kus kódu, ktorý je možné skompilovať a otestovať. Nikomu sa nechce okolo toho ešte domýšľať a dopisovať hlavičky, includy a ďalšie veci aby to aspoň prešlo GCCčkom. Tvoj fragment kódu ale už od pohľadu nekorešponduje s tým debugovým výpisom, čo si dal ("Response header" vs. "Response1") takže ja osobne som v tom momente stratil chuť sa tým ďalej zaoberať.

A pokiaľ ide o môj názor čo by si naozaj mal urobiť - ak to nie je kód, ktorý sa bude spúšťať milión-krát za sekundu, alebo kód spúšťaný na zariadení s 16 MB RAM, tak podľa mňa je ďaleko najefektívnejšie prepísať ho do nejakého skriptovacieho jazyka, ktorý lepšie odpúšťa chyby. Lebo C/C++ chyby neodpúšťa a môžeš byť aký chceš profík, aj tak sa Ti občas podarí v 10-riadkovej funkcii urobiť 7 syntaktických chýb, jeden memory leak a 2 logické chyby čo budú po pamäti zapisovať krížom krážom až do segmentation fault.

[pht]

+1

[Karel Dlouhy]

Dekuji moc za reakce, poucim se. O libcurl vim, ale na komunikaci chci pouzit pouze BSD sockety (mam sve duvody tak me prosim nekamenujte:)). Jde mi o to, ze nevim jak tedy po odeslani HTTP pozadavku na server korektne prijmout odpoved, tak abych data nemusel nacitat po jednom znaku a zaroven nehrozilo, ze se mi while cyklus zacykli. Jak uz tu nekdo psal, tato (podle me) elementarni operace nejde v C/C++ na urovni socketu skoro nikde vygooglit.

Muze mi tu tedy prosim nekdo placnout jednoduchy kod, jak korektne na to?

[benn]

Zdravím,

zde je pěkný přehled příkladů na sítování:

www.cs.utah.edu/~swalton/listings/sockets/programs/

Hledejte http-client.c

[AraxoN]

Keď potrebuješ naraz celú hlavičku a celé telo v pamäti, tak jedinou možnosťou je mať alokovaný tak veľký kus pamäte. Ak chceš byť slušný a nechceš rovno alokovať jedno mega, tak je možnosťou pred každým recv() cez realloc() predĺžiť buffer o toľko, koľko recv() následne chceš povoliť načítať. Recv() to musí zapísať od miesta kde predtým skončil a toto samozrejme nerobí automaticky. Správnu adresu kde má recv() pokračovať musíš evidovať ty a ty mu ju musíš poskytnúť. Keď už máš celú odpoveď v pamäti, operácia nájdenia "\r\n\r\n" je triviálna. Ak potrebuješ hlavičku spracovať skôr ako načítaš telo, tak budeš hľadať "\r\n\r\n" priebežne. Rozhodne by som na to nerobil 2 cykly.

[Karel Dlouhy]

Co se tyce alokace, to uz chapu, ale nevim jak korektne ukoncit tu while podminku po nacteni tela odpovedi.

[AraxoN]

Nespôsobuje Tvoj problém keep-alive? MSG_WAITALL čaká až do ukončenia spojenia a je kľudne možné, že server spojenie nezatvára, lebo čaká či ešte niečo nebudeš od neho chcieť.

[Michal Kubeček]

Po určité době ho ale stejně zavře, typicky to bývá 5-20 sekund. V každém případě by ale klient měl konec odpovědi detekovat korektně, tj. podle Content-Length, a samozřejmě také implementovat dekódování chunked encoding.

[Messa]

Server spojení ukončí sám po odeslání odpovědi, takže cyklus má skončit poté, co read() nebo recv() vrátí 0.

HTTP umožňuje ještě režim keep-alive, kdy server čeká na další požadavek, ale AFAIK tento režim se zapíná hlavičkou v požadavku, kterou doufám neposíláš... Pro jistotu můžeš přidat do požadavku hlavičku Connection: close.

Jinak samozřejmě nejlepší chování by bylo umět navíc používat Content-Length a chunked odpovědi, ale na to už opravdu jsou hotové knihovny.

[Michal Kubeček]

HTTP umožňuje ještě režim keep-alive, kdy server čeká na další požadavek, ale AFAIK tento režim se zapíná hlavičkou v požadavku, kterou doufám neposíláš... Pro jistotu můžeš přidat do požadavku hlavičku Connection: close.

Naopak, v HTTP/1.1 je keep-alive default.

[Ivan]

Jestli se muze zeptat - jake duvody to jsou? Takhle ten vas dotaz vypada jako "Potrebuju poradit jak se strelit do nohy a nereknu vam proc".

Ivan PS: proc size write-only promenna?

[Bedňa]

Dúfam že nezanevrieš na poradňu po týchto odpovediach čo tu odzneli Neviem či netrafím vedľa, ale asi chceš s/na server prenášať dáta, skús sa pozrieť na toto Grafické programy v Qt 4 – 8 (TCP klient) Celý tento seriál o QT je kvalitka a naučíš sa pri tom dosť o C++ a ...