socket tcp pour de l'http et retour incomplet

Jean Hoffmann wrote in message
<slrnd9bbil.oie.moomoo@www.playeradvance.org>:

J'ai ecrit un bout de code en C me permettant d'aller chercher une page sur un
site internet (c'est un fait un script en php generant du texte que j'ai
ecrit) j'ai ecrit une socket tcp tout ce qu'il y a de plus de simple qui
va se connecter sur le site en question et qui reprend la reponse. la ou
ca m'ennuye bcp, c'est que la reponse du serveur web est tronquée a 1448
octets, ce qui m'ennuye encore plus, c'est que des fois, ce n'est pas
limité a 1448, mais sa taille totale passe (a savoir 1742 octets).
la frequence a laquelle j'ai la reponse complete est environ 1 sur 10.

Est-ce qu'on peut voir le code du client ?

On 2005-05-26, Nicolas George <nicolas$george@salle-s.org> wrote:

Jean Hoffmann wrote in message
<slrnd9bbil.oie.moomoo@www.playeradvance.org>:

J'ai ecrit un bout de code en C me permettant d'aller chercher une page sur un
site internet (c'est un fait un script en php generant du texte que j'ai
ecrit) j'ai ecrit une socket tcp tout ce qu'il y a de plus de simple qui
va se connecter sur le site en question et qui reprend la reponse. la ou
ca m'ennuye bcp, c'est que la reponse du serveur web est tronquée a 1448
octets, ce qui m'ennuye encore plus, c'est que des fois, ce n'est pas
limité a 1448, mais sa taille totale passe (a savoir 1742 octets).
la frequence a laquelle j'ai la reponse complete est environ 1 sur 10.

Est-ce qu'on peut voir le code du client ?

bien sur :

int get_http_file(char *buf, char *address, int port)
{

struct sockaddr_in addr;
struct in_addr dest_ip;
socklen_t len;
int sockfd=-1;
long ip;

dest_ip.s_addr = net_strtol (address);

len = sizeof (struct sockaddr);

ip = net_strtol (address);

addr.sin_family = AF_INET;
addr.sin_port = htons (port);
addr.sin_addr = dest_ip;
memset (&(addr.sin_zero), '', 8);

if ( (sockfd = socket(AF_INET,SOCK_STREAM,0)) < 0)
{
strcpy(buf, strerror(errno));
return(-1);
}
if(connect( sockfd,(struct sockaddr *)&addr,sizeof(addr)) < 0 )
{
strcpy(buf, strerror(errno));
return(-1);
}
strcpy (buf,"GET /html/choupette/liste_peach.php HTTP/1.0rn");
sendstr(sockfd,buf);
strcpy (buf,"Host: elwoodz.free.fr:80rn");
sendstr(sockfd,buf);
strcpy (buf,"rn");
sendstr(sockfd,buf);

len=recv(sockfd,buf,4096,0);
buf[len]=0;

close(sockfd);
return(len);

}


--
je suis si magnifique =( / je suis si mysterieuse =(
le mystere est-il magnifique ? =(

Jean Hoffmann a écrit le Jeudi 26 Mai 2005 13:14 :

On 2005-05-26, Nicolas George <nicolas$george@salle-s.org> wrote:

Jean Hoffmann wrote in message
<slrnd9bbil.oie.moomoo@www.playeradvance.org>:

J'ai ecrit un bout de code en C me permettant d'aller chercher une page
sur un site internet (c'est un fait un script en php generant du texte
que j'ai ecrit) j'ai ecrit une socket tcp tout ce qu'il y a de plus de
simple qui va se connecter sur le site en question et qui reprend la
reponse. la ou ca m'ennuye bcp, c'est que la reponse du serveur web est
tronquée a 1448 octets, ce qui m'ennuye encore plus, c'est que des fois,
ce n'est pas limité a 1448, mais sa taille totale passe (a savoir 1742
octets). la frequence a laquelle j'ai la reponse complete est environ 1
sur 10.

len=recv(sockfd,buf,4096,0);
buf[len]=0;

soit tu passes MSG_WAITALL comme dernier argument à recv,
soit tu boucles sur recv (en cumulant les données reçus) jusqu'à ce qu'il
n'y ait plus rien à lire,
soit tu utilises select ou poll pour savoir s'il y a encore des données à
lire.

@+
--
Ella, Sally SEKKOUSH (signature aléatoire)
BANQUIER : Personne qui serait d'accord pour vous consentir un prêt a
la condition que vous lui apportiez la preuve que vous n'en avez pas
besoin.

On 2005-05-26, Patrick Lamaizière <adresse@est.invalid> wrote:

Jean Hoffmann écrivait

strcpy (buf,"GET /html/choupette/liste_peach.php HTTP/1.0rn");
sendstr(sockfd,buf);
strcpy (buf,"Host: elwoodz.free.fr:80rn");
sendstr(sockfd,buf);
strcpy (buf,"rn");
sendstr(sockfd,buf);

len=recv(sockfd,buf,4096,0);
buf[len]=0;

close(sockfd);
return(len);

Vous pouvez très bien recevoir les octets au compte goutte. Rien ne dit que
recv va lire *toute* la réponse. Il faut boucler et se baser sur le
protocole pour savoir quand la réponse est terminée.

je crois qu'il va falloir que je m'en prenne a mon ex prof de C.
merci pour cette reponse.

--
je suis si magnifique =( / je suis si mysterieuse =(
le mystere est-il magnifique ? =(

On 2005-05-26, Thomas Labourdette <thomas.labourdette@9online.fr> wrote:

Jean Hoffmann a écrit le Jeudi 26 Mai 2005 13:14 :

On 2005-05-26, Nicolas George <nicolas$george@salle-s.org> wrote:

Jean Hoffmann wrote in message
<slrnd9bbil.oie.moomoo@www.playeradvance.org>:

J'ai ecrit un bout de code en C me permettant d'aller chercher une page
sur un site internet (c'est un fait un script en php generant du texte
que j'ai ecrit) j'ai ecrit une socket tcp tout ce qu'il y a de plus de
simple qui va se connecter sur le site en question et qui reprend la
reponse. la ou ca m'ennuye bcp, c'est que la reponse du serveur web est
tronquée a 1448 octets, ce qui m'ennuye encore plus, c'est que des fois,
ce n'est pas limité a 1448, mais sa taille totale passe (a savoir 1742
octets). la frequence a laquelle j'ai la reponse complete est environ 1
sur 10.

len=recv(sockfd,buf,4096,0);
buf[len]=0;

soit tu passes MSG_WAITALL comme dernier argument à recv,
soit tu boucles sur recv (en cumulant les données reçus) jusqu'à ce qu'il
n'y ait plus rien à lire,
soit tu utilises select ou poll pour savoir s'il y a encore des données à
lire.

@+

Merci, j'ai appliqué la methode avec MSG_WAITALL, mais j'ai lu la man
select et poll, la methode la plus propre me semble etre la 3eme en ce
qui concerne un gros transfert, mais bon, je transporterai jamais plus
de 3/4 ko, donc, ca ne devrait pas trop bloquer.

--
je suis si magnifique =( / je suis si mysterieuse =(
le mystere est-il magnifique ? =(

Patrick Lamaizière <adresse@est.invalid> écrit:

Vous pouvez très bien recevoir les octets au compte goutte. Rien ne dit que
recv va lire *toute* la réponse. Il faut boucler et se baser sur le
protocole pour savoir quand la réponse est terminée.

Et ça peut être plus simple avec fdopen(3) et fread(3).