Comment faire une requete asynchrone avec curl ?

[Jean-Francois Ortolo]

Bonjour

Vous connaissez peut-être la librairie curl en php

J'ai absolument besoin de faire des requêtes http asynchrone, et je
sais que je ne peux pas utiliser les fonctions de socket type
fsockopen() ( D'ailleurs je crois que ce n'est plus recommandé de les
utiliser ).

Pour faire une requête http asynchrone en get avec curl, suffit-il de
procéder comme celà ?

On fait :

<?php

function callback($ch, $str)
{
global $fd;

// Toute la chaîne $str est écrite.
$len = fwrite($fd, $str);

// La longueur lue et donc écrite,
// de $str, doit être rendue
// par la fonction de callback.
return($len);
}

$fd = open("filename", "w");
// Vérifications sur $fd ...

$ch = curl_init();
// Vérifications éventuelles sur $ch ...

// Les variables sotncensées être définies avant.
curl_setopt($ch, CURLOPT_URL, $url);
curl_setopt($ch, CURLOPT_TIMEOUT, 3600);
curl_setopt($ch, CURLOPT_USERAGENT, $user_agent);

curl_setopt($ch, CURLOPT_WRITEFUNCTION, "callback");

curl_exec();

fclose($fd);

exit;
?>

Première question :

Faut-il mettre curl_setopt($ch, CURLOPT_RETURNTRANSFER, true); , pour
que le résultat soit écrit dansle fichier "filename"et non pas affiché ?

Deuxième question :

Ce code permet-il réellement, de faire une requête http asynchrone ?

Celà, il me semble, n'est pas précisé dans le PHP Manual.

Merci beaucoup de vos réponses.

Amicalement.

Jean-François Ortolo

[Mickael Wolff]

Post by Jean-Francois Ortolo
J'ai absolument besoin de faire des requêtes http asynchrone

Ce n'est pas possible en PHP. Le flux d'exécution est séquentiel, et
ne permet pas d'exécuter des actions parallèles. Il te faut donc trouver
une autre solution. (tu peux éventuellement regarder du côté de
l'instruction declare, et comprendre le fonctionnement des ticks)

Ceci dit, pourquoi cette absolue nécessité ?

Post by Jean-Francois Ortolo
que je ne peux pas utiliser les fonctions de socket type fsockopen() (
D'ailleurs je crois que ce n'est plus recommandé de les utiliser ).

Pourquoi ?

[Jean-Francois Ortolo]

Bonjour Monsieur

Je vais reposer ma question sous une autre forme :

Il y aura une seule requête http, pas plusieurs.

Celà implique, que le serveur cible, recevra une requête http en GET.

Ma question est : Est-ce que le serveur peut avoir connaissance,
d'une manière ou d'une autre, que le traitement de réception des données
reçues suite à cette requête http, est fait de manière synchrone, ou
asynchrone ?

J'ajoute, que dans mon cas, il ne s'agit pas du tout de multi-thread,
ou même de plusieurs requêtes simultanées : Il n'y a qu'une seule
requête http à la fois, et la précédente requête, est terminée, avant
que la suivante ne soit envoyée.

Pour tout vous dire, je simule en php le comportement Javascript d'un
site, qui fait des requêtes http asynchrones, mais lui c'est normal, car
c'est de la programmation objet, et dans son cas, plusieurs requêtes
peuvent être simultanées.

Pour la simulation, je n'ai pas besoin de faire de requêtes
simultanées, les faire les unes après les autres, me suffit.

Dans ces conditions, si le code que je présente dans mon message
précédent, ne fait pas de traitement asynchrone, à quoi sert le fait que
ce paramètre CURLOPT_WRITEFUNCTION de la fonction curl_setopt(), soit
disponible, et qu'il permette une prise en compte progressive de la
réception des données ? N'est-ce pas ipso facto, un traitement asynchrone ?

Par ailleurs, le délai d'attente de réception des données sera très
court, et il n'y a donc pas besoin stricto sensu, de faire du traitement
asynchrone.

Si je fais du traitement synchrone classique ... :

Mon seul critère, est que le serveur cible ne s'aperçoive pas que je
fais un traitement synchrone de réception des données.

D'où ma question : Le serveur cible, est-il capable, d'une quelconque
manière, de savoir que je fais du traitement synchrone, et non pas
asynchrone de la réception des données, compte tenu du fait qu'il n'y a
qu'une seule requête http en même temps ?

Merci beaucoup de votre réponse.

Bien à vous.

Amicalement.

Jean-François Ortolo

[Mickael Wolff]

Post by Jean-Francois Ortolo
Il y aura une seule requête http, pas plusieurs.
Celà implique, que le serveur cible, recevra une requête http en GET.
Ma question est : Est-ce que le serveur peut avoir connaissance, d'une
manière ou d'une autre, que le traitement de réception des données
reçues suite à cette requête http, est fait de manière synchrone, ou
asynchrone ?

Je ne vois pas ce qui lui permettrait de le savoir.

Post by Jean-Francois Ortolo
Pour tout vous dire, je simule en php le comportement Javascript d'un
site, qui fait des requêtes http asynchrones, mais lui c'est normal, car
c'est de la programmation objet, et dans son cas, plusieurs requêtes
peuvent être simultanées.

Je ne vois pas la relation avec la programation objet. Par contre,
PHP n'exécute pas de séquence de code entre deux attentes, une fois la
séquence achevée, le script se termine.

Post by Jean-Francois Ortolo
Pour la simulation, je n'ai pas besoin de faire de requêtes simultanées,
les faire les unes après les autres, me suffit.
Dans ces conditions, si le code que je présente dans mon message
précédent, ne fait pas de traitement asynchrone, à quoi sert le fait que
ce paramètre CURLOPT_WRITEFUNCTION de la fonction curl_setopt(), soit
disponible, et qu'il permette une prise en compte progressive de la
réception des données ? N'est-ce pas ipso facto, un traitement asynchrone ?

Ce n'est pas un traitement asynchrone, mais plutôt un traitement
progressif.

Post by Jean-Francois Ortolo
D'où ma question : Le serveur cible, est-il capable, d'une quelconque
manière, de savoir que je fais du traitement synchrone, et non pas
asynchrone de la réception des données, compte tenu du fait qu'il n'y a
qu'une seule requête http en même temps ?

J'ai du mal à comprendre l'intérêt de la question. En fait, j'ai du
mal à comprendre comment et pourquoi le site distant détecterait des
accès synchrones ou non. Quel est l'intérêt ? Si c'est un problème que
tu ne peux pas exposer publiquement, mon adresse électronique est valide.

[Jean-Francois Ortolo]

Bonjour Monsieur

Voir mes réponses à vos deux réponses, ci-dessous.

Merci beaucoup pour vos réponses, qui répondent bien à ma question.

Amicalement.

Jean-François Ortolo

Post by Mickael Wolff

Post by Jean-Francois Ortolo
Ma question est : Est-ce que le serveur peut avoir connaissance, d'une
manière ou d'une autre, que le traitement de réception des données
reçues suite à cette requête http, est fait de manière synchrone, ou
asynchrone ?

Je ne vois pas ce qui lui permettrait de le savoir.

Ok.
Donc je peux faire des requêtes synchrones.

Post by Mickael Wolff

Post by Jean-Francois Ortolo
Dans ces conditions, si le code que je présente dans mon message
précédent, ne fait pas de traitement asynchrone, à quoi sert le fait que
ce paramètre CURLOPT_WRITEFUNCTION de la fonction curl_setopt(), soit
disponible, et qu'il permette une prise en compte progressive de la
réception des données ? N'est-ce pas ipso facto, un traitement asynchrone ?

Ce n'est pas un traitement asynchrone, mais plutôt un traitement
progressif.

Donc, même chose, je n'ai pas besoin de faire du code progressif, car
les délais d'attente sont à priori très très courts.

Post by Mickael Wolff

Post by Jean-Francois Ortolo
D'où ma question : Le serveur cible, est-il capable, d'une quelconque
manière, de savoir que je fais du traitement synchrone, et non pas
asynchrone de la réception des données, compte tenu du fait qu'il n'y a
qu'une seule requête http en même temps ?

J'ai du mal à comprendre l'intérêt de la question. En fait, j'ai du mal
à comprendre comment et pourquoi le site distant détecterait des accès
synchrones ou non. Quel est l'intérêt ? Si c'est un problème que tu ne
peux pas exposer publiquement, mon adresse électronique est valide.

Merci beaucoup de votre réponse.

Je sais maintenant, que je peux faire des requêtes synchrones, donc
soit avec des fonctiosn types fsockopen(), soit avec des fonctions curl_*().

J'ai la réponse à ma question.

Merci beaucoup de votre réponse.

Bien à vous.

Amicalement.

Jean-François Ortolo