[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [linux] [OT] Programmation: petites questions...
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
C'est en effet une solution. J'ai cependant un problème avec l'option
Connection : keep-alive du protocole http. Dans ce cas, le protocole
voudrait que la connection reste ouverte pour d'autres requetes. Donc,
il faudrait attendre un time-out et donc le thread resterait en attente
pour rien un temps indéterminé lui aussi. Ce qui n'est pas propre non
plus... Je ne vois pourtant pas d'autres solutions. Soit je boucle sur
le recv() jusqu'a avoir -1. soit je mets le usleep(). Le problème,
c'est que le temps à mettre est cpu dépendant puisque c'est directement
lié à la rapidité du système...
Sinon, je pensais à jouer avec un select. Cela me permettrait de
recevoir les données temps qu'il y en a et de sortir rapidement grâce à
un time_out raisonnable style 30-40s...
Est-ce raisonnable?
Encore merci pour ces réponses
Ben
Le Mardi 27 Novembre 2001 14:15, vous avez écrit :
> OK, je comprends mieux.
> Donc, chaque thread a une socket différente vers un serveur web
> (tiens, au passage, ce sont bien des threads ou ce sont des process
> ?).
>
> Si j'ai bien compris, ce que tu fais se résume à
>
> do {
>
> lire_socket();
> } while socketNotEmpty && bufferNotFull
>
> TraiteBuffer(); /* Sauve sur disque, transmet aux clients, que
> sais-je... ? */
>
> Si tu ne mets pas de usleep après lire_socket(), parfois ta page est
> incomplète.
> A mon avis, ce qui se passe c'est que sans le usleep, tu vides trop
> vite le buffer de la socket. En effet, quand le serveur web transmet
> des données à ton proxy, ces données sont stockées par l'OS dans un
> buffer. La transmission des données du serveur web à ton proxy étant
> plus lente que la lecture d'un buffer local, il se vide. Tu quittes
> alors ta boucle en n'ayant reçu qu'un message incomplet.
> Avec le usleep, plus de données ont eu le temps d'être transmises.
>
> Il faut donc que tu quittes ta boucle quand le transfert est fini,
> pas quand le buffer est vide.
> Est-ce le serveur qui décide de fermer la connexion ?
> Si oui, tu quittes la boucle qd recv() retourne -1.
>
> A+,
>
> Christophe
>
> > -----Original Message-----
> > From: Benoit Joseph [mailto:benoit.joseph@teledisnet.be]
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> >
> > Non en fait je contacte un serveur web et je rapatrie les données
> > qu'il m'envoie. (html, images, applet, etc...)
> > Et je peux avoir un nombre indéterminé de threads qui ouvrent des
> > connections une connection vers un serveur web.
> > Normalement, la zone mémoire n'est pas partagée entre les threads.
> > L'usage de sémaphores est impossible vu que je n'ai pas accès aux
> > serveurs webs et puis ce serait ultra inefficace... ;-)
> >
> > Voilà le symptôme mieux décrit:
> >
> > avec usleep et la valeur qu'il prend, pas de problème, je reçois
> > bien les pages en entier (sauf petit problème localisé)
> >
> > sans usleep, les pages qui passaient avant ne s'affiche plus en
> > entier. Souvent je n'ai que le début. Par exemple pour une image,
> > je n'ai que la moitié de l'image. Comme si on recevait la fin de
> > connection du proxy/server et que l'on envoyait la réponse au
> > client web.
> >
> > Le seul paramètre qui change, c'est le usleep. J'aimerais donc
> > savoir si j'ai loupé un truc quelque part au niveau gestion de la
> > mémoire et savoir si il y a des délais au niveau de
> > l'allocation/utilisation...
> >
> > Merci
> >
> > Ben
>
> [ Soyez précis dans vos sujets svp afin de déterminer directement ]
> [ le type de demande... ]
> [ Pour vous (dés)inscrire, aller sur http://unixtech.be/ml.php ]
> [ Archives de la mailing list: http://archives.unixtech.be/linux/ ]
> [ http://unixtech.be Contact: listmaster@unixtech.be ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE8A5ULLPnuiaZn1q4RAgHvAJ4k81FnOII79Rlcj8kan3NQZmWzuQCfUfcr
wMhDrOVysH9lzy24V1kFdNE=
=NfzE
-----END PGP SIGNATURE-----
[ Soyez précis dans vos sujets svp afin de déterminer directement ]
[ le type de demande... ]
[ Pour vous (dés)inscrire, aller sur http://unixtech.be/ml.php ]
[ Archives de la mailing list: http://archives.unixtech.be/linux/ ]
[ http://unixtech.be Contact: listmaster@unixtech.be ]