Discussion :

[supergg02]

Bonjour,
j'ai cherché en vain des exemples de pipelining HTTP 1.1 coté client ( en gros le pipelining HTTP= est une technique consistant à combiner plusieurs requêtes HTTP dans une seule connexion TCP :voir http://fr.wikipedia.org/wiki/Pipelining_HTTP )

Alors ma question est:

auriez-vous un exemple de code (peu importe le language) afin que je puisse m'en inspirer ?

actuellement, les composents indy et ics n'en parle même pas de cette "technique" et pourtant c'est bien prévu par la RFC HTTP 1.1

merci infiniment

[Sub0]

Salut et bienvenue dans les forums de Developpez.com !

Cela ressemble fortement à du multithreading. ICS (et très certainement Indy) propose plusieurs démos montrant comment réaliser plusieurs requêtes sans attendre les réponses correspondant à chaque requête.

C'est justement ce que je suis entrain de développer avec DELPHP2. La difficulté a été t'intégrer le TimeOut côté client pour chaque requête et d'éviter que le même message d'erreur se répète pour tous les threads déjà lancés...

[supergg02]

Salut et bienvenue dans les forums de Developpez.com !

Cela ressemble fortement à du multithreading. ICS (et très certainement Indy) ...[/U].

merci Sub0 !

c'est vrai, ça ressemble au multithreading mais ce n'est vraiment pas ça ( le multithreading ouvre une session TCP pour chaque thread donc toujours une transaction en trois phases : ACK-SYNAck-ACK puis le GET)

Le pipelining, en revanche, n'utilise qu'un seul ACK-SYNAck-ACK pour plusieur get en cascades

C'est justement ce que je suis entrain de développer avec DELPHP2. La difficulté a été t'intégrer le TimeOut côté client pour chaque requête et d'éviter que le même message d'erreur se répète pour tous les threads déjà lancés...

avec les composent ICS j'imagine ? Helas, très mal documenté à mon sens ( seul support le mailing et ça vas dans tous les sens, sans moteur de recherche...etc)

merci en tous cas pour ta réponse

[Sub0]

• ok, je comprend. Mais quel est l'intérêt du pipelining, quel avantage par rapport au multithreading ?

• Tu as raison, j'utilise THttpCli d'ICS pour effectuer des requêtes Get, Head et Post car contrairement à Indy, ICS fournit ses sources. Le programme multithreading que j'ai mis au point fonctionne plutôt bien. J'avais déjà réalisé une première version monothread que j'ai repris du début. J'ai ajouté une fonction qui effectue l'upload de plusieurs gros fichiers par blocs de 2Mo avec un thread par fichier, exactement comme dans ce sujet pour la copie de fichier...

http://developpez.net/forums/showthr...=285958&page=4

[supergg02]

L'avantage est en terme de bande passante ( économie au niveau des accusés de reception ack-synack-ack au niveau TCP!) et par conséquent plus de rapidité....sans oublier, bien sûr, l'economie des problèmes liés à la synchronisation des thread.

sincèrement, je m'intéresse à cette technique du Pipelining HTTP car le facteur temps est très important dans mon projet (les millisecondes comptent, en effet le serveur distant met à jour les données en temps réel et le but du jeu et d'être le premier à détecter une une chaine qui fait office de " Top départ" dans le code source html de la page renvoyée
je regarderai avec bcp d'intéret tes exemple ( en espérant pouvoir l'adapter à mon cas)
merci encore

[Sub0]

Le pipelining m'intérresse également.
Je vais étudier le sujet avec ICS et je te tiens au courant.

[Sub0]

J'ai posé la question sur la newsgroup d'ICS pour avoir des informations concernant le pipelining. D'après l'auteur, le pipelining n'est pas supporté par la plupart des serveurs. La solution pour aller plus vite est d'utiliser les evénements ContentRangeBegin et ContentRangeEnd pour par exemple télécharger un même document avec plusieurs objets THttpCli. Le multithreading n'est même pas nécessaire dans ce cas... Si tu as des questions à poser, je peux toujours lui retransmettre.

[Edit] Pour ma part, je pense que le pipelining n'apportera pratiquement rien à ton projet. Je crois que le multithread avec une requête HEAD serait une solution plus appropriée. Tu peux peut-être aussi utiliser un serveur suplémentaire (celui-ci à toi cette fois ci) où tu pourras installer un script PHP, Perl ou CGI qui se chargera d'effectuer la détection et de t'envoyer le signal sur ton ordinateur...
à+

[supergg02]

Merci Sub0 pour tes efforts ( vraiment sympa pour une question probablement sans intéret )

Concernant le newsgroup d'ICS, t'as eu de la chance d'avoir une réponse rapide (moi, j'ai posté une seule fois (sur un autre sujet) et jamais eu de réponse réponses...dommage que ce newsgroup n'est pas doté d'un moteur de recherche)

Effectivement, ContentRangeBegin et ContentRangeEnd pourrait être une solution si la page renvoyé est de taille importante et que le serveur accepte ce genre de header_request (demander un bout de page par requette en gros). Hors, le serveur distant ne gère pas ça...sans oublier quela page est de petite taille (peut loger ds un seul paquet (avec un header de type : Content-encoding: gzip).

Savoir ce que l'on doit programmer est plus important que de savoir comment le faire, non ?

Tout à fait d'accord avec toi ! à une seule condition: que le facteur rapidité importe peu. dans mon cas, l'affaire se joue en quelques millisecondes: un peu comme un une course de 100 metres, celui qui réagira le 1er au top départ aura un avantage capital.
Je suis déja défovorisé par ma connexion adsl (512 k) sans oublier mon désavantage géographique par rapport à l'emplacement du serveur (Londre).

Je ne suis pas d'accord par contre, sur le multi-threading puisque avec 4 threads j'arrive a intérroger le serveur 10 fois par seconde (au lieu de 3 fois/s avec un seul thread)

merci encore pour ta collaboration

[Sub0]

Je crois que le multithread avec une requête HEAD serait une solution plus appropriée.

Je n'aurais rien d'autre à te proposer.

merci encore pour ta collaboration

Bon courage pour la suite, à+

[Edit] N'oublis pas d'ajouter le tag lorsque tu l'estimeras.

[Sub0]

F.Piette m'a finalement conseillé d'utiliser plutôt les connexions persistantes avec Http 1.1 plutôt que le pipelining car le pipelining ne fait pas d'économies de bande passante selon ses dires.

http://www.liafa.jussieu.fr/~yunes/i...t/http/#HTTP11

Connexions persistantes :
Une fois la connexion etablie, elle reste ouverte jusque le client (ou le serveur) demande sa fermeture (comportement par defaut). Durant une connexion, le client peut faire plusieurs reqûetes. Le client n’est pas oblige d’attendre la reponse pour envoyer une nouvelle requete. Le serveur doit repondre dans le meme ordre (pipelining des requetes et des reponses). Attention aux operations non-idempotentes.
Moyens :
• fermeture de connexion : timeout, Connection:close
• longueur reqûete/reponse :Content-Length
• negociation du maintient d’une connexion
– par le client :Expect: 100-continue
– par le serveur :HTTP/1.1 100 Continue
• eviter les envois inutiles : “binary exponential backoff”

Pour info, je suis tombé par hasard sur le protocol HTTP-NG durant mes recherches :
http://www.technosphere.tm.fr/chaine...es/http-ng.cfm