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.

[supergg02]

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

merci, je posterais egalement si je trouve une implémentation claire du pipelining.

En attendans, je me debrouille un peu avec le multi-threading mais c'est chaud au niveau synchro car tous les threads font exactement la meme chose:

shematiquement, charque thread fait ça:

var top_depart=0;
While top_depart=0 do

Begin

Source_htm=HttpGet( server.cgi?numero_course=1500);
top_depart=cherche (Source_htm,'topdepart=ok'); // ou la fonction index...

End;

Action();// seule le thread qui aura détecter le top départ en 1er doit executer L'Action(). les autres thread doivent être tué aussitot !!

Finallement, je crois que le multi-threading n'est vraiment pas intélligent comme solution si les thread font la meme chose car on a aucune garantie sur l'ordre d'execution d'une ligne à l'autre....
je ne sais pas non plus si le multi-process serait finalement plus adapté à mon cas (en se servant de la base de registre pour la communication entre les processus par simple flag...)

[Sub0]

Ça me rappelle un système que j'avais réalisé pour un tchat, pour détecter lorsque l'utilisateur a un nouveau message. Dans une 1ère version, c'était l'utilisateur qui vérifiait régulièrement, toutes les 2 secondes si il y avait un message sur le serveur. Mais cela consommait beaucoups de ressources et de bande passante. Ensuite, j'ai modifié le système de façon à ce que ce soit le serveur qui avertisse l'utilisateur : Le client poste 1 seule requête et lance une boucle de détection sur le serveur. Le client attend la réponse de sa requête tant qu'il n'y a pas de nouveau message sur le serveur. Le client est averti aussitôt d'un nouveau message dès qu'il reçoit la réponse de sa requête. Pour réaliser cela, il n'y a pas besoin de pipeline ni de multithread et c'est très rapide, très peu de ressources cpu et bande passante du client et du serveur sont nécessaires pour réaliser ce système. Peut-être est-ce la solution que tu recherches...

Autrement, il ya la communication directe par socket qui pourrait te permettre d'obtenir un signal très rapide du serveur. Enfin tout dépend si le service que tu veux programmer est destiné à une utilisation privée (intranet) ou publique (internet).

[supergg02]

helas, je n'ai pas la main sur le serveur distant. Je ne peux agir que coté client.

ceci dit, je viens d'apprendre que la librairy libcul supporte justement le pipelining....pour l'instant, je n'ai testé que le binaire curl et ça l'air de marcher.

la communication par socket avec un serveur distant ? tu veux dire faire passer une requette http par UDP et non pas par TCP ? pense pas que les serveur HTTP répondent à ce genre de requettes UDP
pourtant c pas con comme solution c même très pratique ds certains cas...

[Sub0]

• Attend, tu veux dire que tu ne peux même pas installer un script PHP sur ce serveur ? Tu n'as pas un accès FTP sur ce serveur ? Tu veux utiliser un script qui n'est pas de toi, que tu n'as pas installer ?

[supergg02]

• Attend, tu veux dire que tu ne peux même pas installer un script PHP sur ce serveur ? Tu n'as pas un accès FTP sur ce serveur ? Tu veux utiliser un script qui n'est pas de toi, que tu n'as pas installer ?

non, rien à voir avec php. J'essaye seulement de programmer un client http avec la possibilité d'utiliser le pipelining . Hélas, j'ai bien peur que le pipelining fait partie de la couche TCP, donc va falloire que je descent encore plus bas dans la programmtion HTTP (couche transport)

[Sub0]

helas, je n'ai pas la main sur le serveur distant. Je ne peux agir que coté client.

Tu veux accéder à des fonctions d'un serveur qui ne t'appartient pas ? C'est ça qui me semble bizarre... Selon moi, tu ne pourras pas faire grand chose niveau détection, excepté en postant une requête pour recevoir un résultat, et dans ce cas, cela consomme pas mal de ressouces, même avec le pipelining. Une idée : Tu peux éventuellement regarder du côté de la méthode HEAD pour obtenir les infos (type et taille) d'un fichier sur le serveur sans devoir télécharger le contenu... Bon courage.

[supergg02]

Tu veux accéder à des fonctions d'un serveur qui ne t'appartient pas ? C'est ça qui me semble bizarre... Selon moi, tu ne pourras pas faire grand chose niveau détection, excepté en postant une requête pour recevoir un résultat, et dans ce cas, cela consomme pas mal de ressouces, même avec le pipelining. Une idée : Tu peux éventuellement regarder du côté de la méthode HEAD pour obtenir les infos (type et taille) d'un fichier sur le serveur sans devoir télécharger le contenu... Bon courage.

là, tu es parti dans une direction type "hack" !!

Rien à voir, je veux seulement economiser des paquets TCP inutiles en utilisant une connexion persistante (keep-alive), c'esy bien prevu par la le protocole HTTP 1.1 et ça n'a rien d'illégale ! sauf que sont rare les composent ou librairies qui l'implémente en intégralité (et correctement !)

[Sub0]

Ai-je parlé de hack? non, rien à voir. En fait, si j'ai bien compris ton objectif, tu veux détecter un signal du serveur le plus rapidement possible tout en économisant les ressources CPU et la bande passante. Mais comme tu n'as pas la main sur le serveur, je te donne mon avis : Le pipelining ne te servira pas à grand chose selon moi. Tu seras surtout obligé d'effectuer une requête pour chaque tentative de détection.

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

[EDIT] Voici quelques liens trouvés avec Google, peut-être y trouveras-tu ce que tu cherches...

http://www.elists.org/pipermail/twso...ly/034158.html
http://www.mail-archive.com/twsocket.../msg05050.html

[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