Requests: délai d'attente global

Salut @emgerner-msft,

Pour référence, voici toutes les variations sur ce thème si ce n'est cette demande de fonctionnalité exacte :

• https://github.com/kennethreitz/requests/issues/2327
• https://github.com/kennethreitz/requests/issues/2685
• https://github.com/kennethreitz/requests/issues/1928
• (et je suis sûr qu'il y en a d'autres)

Nous en avons également discuté sur https://github.com/sigmavirus24/requests-toolbelt/issues/51

Vous remarquerez que le dernier lien traite de ce package qui devrait gérer cela pour vous sans l'ajouter aux demandes. La réalité, c'est qu'il n'y a pas besoin de requêtes pour le faire alors qu'un autre paquet le fait déjà très bien.

Le package que vous référencez le fait en créant un processus distinct pour exécuter la requête Web. C'est un moyen très lourd d'atteindre l'objectif simple d'un délai d'attente et, à mon avis, ne remplace en aucun cas les demandes elles-mêmes ayant une fonctionnalité de délai d'attente native.

@jribbens Si vous pouviez trouver un moyen qui n'utilise ni threads ni processus, ce serait incroyable. Jusque-là, si vous voulez une horloge murale, votre meilleur pari est ce paquet car c'est le moyen le plus fiable d'y parvenir pour le moment.

Je ne pense pas que @jribbens dise qu'il n'y a pas de threads ni de processus. Juste qu'une demande Web de processus _par_ est excessive. De nombreux langages permettent à plusieurs minuteurs de partager un seul thread ou processus supplémentaire. Je ne sais tout simplement pas comment faire cela au mieux en Python.

Il semble que # 1928 ait le plus de discussions sur les alternatives, mais la plupart comportent de nombreuses mises en garde (cela ne fonctionnera pas pour votre cas d'utilisation, etc.). Je suis d'accord pour avoir du code personnalisé dans ma bibliothèque et écrire ma propre solution personnalisée si cela n'appartient vraiment pas aux demandes, mais je pense que j'ai besoin d'un peu plus d'informations sur ce à quoi cela ressemblerait. La raison pour laquelle nous utilisons des requêtes est de s'éloigner de la logique de regroupement de connexions TCP de bas niveau, mais il semble que lire ce fil que pour écrire ce code personnalisé, j'ai besoin de connaître cette logique, et c'est ce que j'ai des problèmes avec .

@emgerner-msft est correct. Je suis un peu confus par le commentaire de @ sigmavirus24 , avoir un "timeout total" sans utiliser de threads ou de processus semble assez banal et pas du tout "incroyable". Calculez simplement le délai au début de l'ensemble du processus (par exemple, deadline = time.time() + total_timeout ) puis, pour toute opération individuelle, définissez le délai d'attente sur deadline - time.time() .

avoir un "timeout total" sans utiliser de threads ou de processus semble assez banal et pas du tout "incroyable".

Et votre solution est plutôt primitive. La raison pour laquelle _la plupart des gens_ veulent un délai d'expiration total (ou mural) est d'empêcher une lecture de "se bloquer", en d'autres termes un cas comme celui-ci :

r = requests.get(url, stream=True)
for chunk in r.iter_content(chunksize):
    process_data(chunk)

Où chaque lecture prend beaucoup de temps au milieu de iter_content mais c'est moins que le délai de lecture (je suppose que nous appliquons cela lors de la diffusion, mais il se peut toujours que nous ne le fassions pas), ils ont spécifié . Certes, il semblerait que cela devrait être simplement géré par votre solution @jribbens jusqu'à ce que vous vous rappeliez comment les horloges dérivent et que l'heure d'été fonctionne et que time.time() est terriblement insuffisant.

Enfin, il est important de garder à l'esprit que l'API de Requests est gelée. Il n'y a pas d'API bonne ou cohérente pour spécifier un délai d'expiration total. Et si nous implémentions un délai d'attente comme vous le suggérez, nous aurions d'innombrables bogues pour lesquels ils spécifiaient un délai d'attente total d'une minute, mais cela a pris plus de temps car la dernière fois que nous avons vérifié, nous étions sous une minute, mais leur délai de lecture configuré était suffisamment long pour que leur délai d'attente erreur a été soulevée environ une minute et demie. C'est un délai d'attente de mur _très_ approximatif qui serait légèrement meilleur pour les personnes qui recherchent cela, mais pas différent de la personne qui l'implémente elle-même.

Toutes mes excuses si je n'étais pas clair @ sigmavirus24 , vous semblez avoir critiqué mon illustration de principe pseudocode comme si vous pensiez qu'il s'agissait d'un patch littéral. Je dois cependant souligner que time.time() ne fonctionne pas comme vous le pensez apparemment - l'heure d'été n'est pas pertinente, et le décalage d'horloge non plus sur les échelles de temps dont nous parlons ici. De plus, vous avez mal compris la suggestion si vous pensez que le bogue que vous décrivez se produirait. Enfin, je ne suis pas sûr de ce que vous entendez par l'API Requests étant "gelée" car l'API a été modifiée aussi récemment que la version 2.9.0, donc clairement ce que vous voulez dire, ce n'est pas ce que je comprendrais normalement par le mot.

Juste pour séparer ma discussion : je ne dis pas que c'est facile. Si c'était totalement simple, je l'écrirais et arrêterais de vous embêter. :)

Mes problèmes sont :
1) Tout sur les discussions que vous avez énumérées était des correctifs de singe. C'est bien, mais je l'utilise dans une bibliothèque de qualité de production et je ne peux pas supporter la mise en garde des changements internes qui cassent tout.
2) Le décorateur de délai d'attente dans le lien que vous avez donné est génial, mais je ne sais pas comment cela affecte la connexion. Même si nous acceptons que la seule bonne façon de faire des délais d'attente est avec un tas de threads, comment cette bibliothèque s'assure-t-elle que le socket est arrêté, la connexion abandonnée, etc. Nous faisons beaucoup de connexions et cela semble potentiellement assez sujet aux fuites. les requêtes n'ont pas de méthode "abandon" que je peux trouver (corrigez-moi si je me trompe), alors comment se passe l'arrêt de la connexion ?

Tout ce que je recherche, c'est une version claire "bénie" de la façon de résoudre ce problème par moi-même, ou s'il n'y a pas de solution parfaite, quelques solutions avec les mises en garde discutées. Cela a-t-il du sens?

@ emgerner-msft En supposant que vous utilisez CPython, l'arrêt de la connexion se produira lorsque la demande ne se poursuivra plus. À ce stade, toutes les références à la connexion sous-jacente seront perdues et le socket sera fermé et supprimé.

@Lukasa D'accord, merci ! Comment la bibliothèque détermine-t-elle que la demande ne se poursuit plus ? Par exemple, si j'utilisais la route du décorateur de délai d'attente et que je coupais au milieu du téléchargement, quand le téléchargement s'arrêterait-il réellement ? Dois-je faire quelque chose de spécial avec les options de streaming ?

Si vous utilisez le décorateur de délai d'attente, le téléchargement s'arrêtera lorsque le délai d'attente se déclenchera. C'est parce que les signaux interrompent les appels système, ce qui signifie qu'il n'y aura plus d'appels dans la socket. Une fois que la requête n'est plus dans la portée (par exemple, la pile s'est déroulée à l'extérieur de votre fonction requests.* ), c'est dans : CPython nettoiera l'objet de connexion et détruira la connexion. Aucune option de streaming spéciale n'est requise ici.

Parfait. Je suis bon pour fermer le fil alors, à moins que d'autres n'aient plus à dire.

En fait, désolé, encore un souci. Je regardais de plus près le code du décorateur de délai d'attente depuis que vous avez dit qu'il utilise des signaux était pertinent, par opposition à quelque chose comme Python Timers (vraisemblablement). Il semble qu'il appelle signal avec SIGALRM qui est documenté dans Python Signal pour ne pas fonctionner sous Windows. J'ai besoin que cela fonctionne dans les environnements Unix et Windows, ainsi que dans Python 2.7 et 3.3+ (un peu comme les demandes elles-mêmes). Je vais fouiller un peu plus et voir si cela fonctionnera réellement étant donné cela.

@ emgerner-msft C'est frustrant. =(

@Lukasa Yup, a essayé l' extrait d'utilisation de base et cela ne fonctionne pas sous Windows. J'ai lu un peu plus de code/d'exemples et j'ai tripoté et il semble que si nous n'utilisons pas de signaux, le paquet pourrait fonctionner, mais tout doit être sélectionnable, ce qui n'est pas le cas pour mon application. Donc, pour autant que je sache, le décorateur de délai d'attente ne résoudra pas mon problème. D'autres idées ?

@emgerner-msft Êtes-vous sûr qu'aucun des signaux spécifiques à Windows ne convient ?

@Lukasa Pour être franc, je ne sais tout simplement pas. Je n'ai jamais utilisé de signaux auparavant, et tout comme je ne m'en suis pas rendu compte jusqu'à ce que vous me disiez qu'ils interrompraient la demande, je ne sais pas ce qui est approprié. Je n'essaie pas non plus de faire fonctionner cela uniquement sous Windows. J'ai besoin d'une prise en charge complète de crossplat (Windows et Unix) et de la prise en charge de Python 2 et Python 3. Tant de signaux semblent spécifiques à la plate-forme, ça me jette. La minuterie était l'une des solutions que j'envisageais qui semblait moins de bas niveau et pouvait donc prendre en charge mes contraintes, mais je ne sais pas alors comment je pourrais fermer la connexion. Je peux faire plus de lecture, mais c'est pourquoi j'espérais obtenir des conseils supplémentaires de votre part. :)

C'est donc un endroit vraiment délicat.

La réalité est qu'il n'y a plus ou moins aucun moyen multiplateforme de tuer un thread, sauf en l'interrompant, ce qui est essentiellement ce qu'est un signal. Cela signifie, je pense, que les signaux sont le seul moyen dont vous disposez pour que cela fonctionne sur toutes les plateformes. Je suis enclin à essayer d'envoyer un ping à un expert de Windowsy Pythony : @brettcannon , avez-vous une bonne suggestion ici ?

Par intérêt, y a-t-il une raison de ne pas implémenter le "délai d'expiration total" dans les demandes autre que cette mise en œuvre et son test nécessitent du travail ? Je veux dire, si un correctif pour l'implémenter apparaissait comme par magie aujourd'hui, serait-il en théorie rejeté ou accepté ? J'apprécie et suis d'accord avec le point de vue "éliminer la complexité inutile", mais "vous pouvez le faire en bifurquant un processus séparé" ne rend pas cette fonctionnalité inutile à mon avis.

@jribbens Il y a quelques problèmes avec cela.

La partie 1 est que la complexité d'un tel patch est très élevée. Pour qu'il se comporte correctement, vous devez modifier à plusieurs reprises les délais d'attente au niveau du socket. Cela signifie que le correctif doit être transmis de manière omniprésente via httplib, que nous avons déjà corrigé plus que nous ne le souhaiterions. Essentiellement, nous aurions besoin d'atteindre httplib et de réimplémenter environ 50% de ses méthodes plus complexes afin de réaliser ce changement fonctionnel.

La partie 2 est que la maintenance d'un tel patch est relativement lourde. Nous aurions probablement besoin de commencer à maintenir ce qui équivaut à un fork parallèle de httplib (plus correctement http.client pour le moment) afin de le faire avec succès. Alternativement, nous aurions besoin de prendre en charge la charge de maintenance d'une pile HTTP différente qui se prête mieux à ce type de changement. Cette partie est, je suppose, souvent manquée par ceux qui souhaitent disposer d'une telle fonctionnalité : le coût de sa mise en œuvre est élevé, mais ce n'est rien comparé aux coûts de maintenance permanents liés à la prise en charge d'une telle fonctionnalité sur toutes les plates-formes.

La partie 3 est que l'avantage d'un tel patch n'est pas clair. D'après mon expérience, la plupart des gens qui veulent un patch de délai d'attente total ne pensent pas très clairement à ce qu'ils veulent. Dans la plupart des cas, les paramètres de délai d'attente total finissent par avoir pour effet de tuer des requêtes parfaitement bonnes sans raison.

Par exemple, supposons que vous ayez conçu un morceau de code qui télécharge des fichiers et que vous souhaitiez gérer les blocages. Bien qu'il soit initialement tentant de vouloir définir un délai d'attente total fixe ("aucune requête ne peut prendre plus de 30 secondes !"), un tel délai passe à côté de l'essentiel. Par exemple, si un fichier passe de 30 Mo à 30 Go, un tel fichier ne peut _jamais_ être téléchargé dans ce type d'intervalle de temps, même si le téléchargement peut être entièrement sain.

En d'autres termes, les délais d'attente totaux sont une nuisance attrayante : ils semblent résoudre un problème, mais ils ne le font pas efficacement. Une approche plus utile, à mon avis, consiste à tirer parti du délai d'expiration de l'action par socket, combiné à stream=True et iter_content , et à vous attribuer des délais d'expiration pour les blocs de données. De la façon dont iter_content fonctionne, le flux de contrôle sera renvoyé à votre code à un intervalle assez régulier. Cela signifie que vous pouvez définir vous-même des délais d'attente au niveau du socket (par exemple, 5 s), puis iter_content sur des morceaux assez petits (par exemple, 1 Ko de données) et être relativement sûr que, à moins que vous ne soyez activement attaqué, aucun déni de service est possible ici. Si vous êtes vraiment préoccupé par le déni de service, réglez votre délai d'attente au niveau du socket beaucoup plus bas et votre taille de bloc plus petite (0,5 s et 512 octets) pour vous assurer que vous recevez régulièrement le flux de contrôle.

Le résultat de tout cela est que je crois que les délais d'attente totaux sont un défaut dans une bibliothèque comme celle-ci. Le meilleur type de délai d'attente est celui qui est réglé pour laisser suffisamment de temps aux réponses volumineuses pour télécharger en paix, et un tel délai d'attente est mieux servi par les délais d'attente au niveau du socket et iter_content .

Peut-être que @zooba a une idée car il sait réellement comment fonctionne Windows. :)

(Indépendamment, l'une de mes choses préférées à faire est de mettre en place une chaîne d'experts en guirlande d'experts dans un problème GitHub.)

Haha, je connais déjà @zooba et @brettcannon. Je peux discuter avec eux ici ou en interne car une solution à cela les aiderait probablement aussi.

@emgerner-msft Je pensais que oui, mais je ne voulais pas présumer : MSFT est une grande organisation !

@Lukasa Je viens de lire à travers le mur de texte que vous venez d'écrire ci-dessus - intéressant ! Sur la discussion de stream=True et iter_content pour chronométrer les téléchargements, quelle est la manière équivalente de gérer les téléchargements plus volumineux ?

_PS_ : Le paragraphe ci-dessus commençant par "Mettre une autre manière, .." est le genre de conseils que j'ai recherchés dans les docs. Étant donné le nombre de demandes que vous recevez pour un délai d'expiration maximal (et vos raisons valables de ne pas le faire), peut-être que la meilleure chose à faire est d'ajouter certaines de ces informations dans la documentation sur le délai d'expiration ?

lol @lukasa Je comprends votre point sur la maintenance, qui était déjà dans mon esprit, mais sur "fonctionnalité contre défaut", j'ai bien peur d'être complètement opposé à vous. Je pense que quiconque ne veut pas un délai d'attente total ne pense pas clairement à ce qu'il veut, et j'ai du mal à imaginer une situation où ce que vous décrivez comme un bogue "le téléchargement de 30 Mo passe à 30 Go et échoue donc" n'est pas en fait une caractéristique bénéfique!

Vous pouvez comme vous le dites faire quelque chose d'un peu similaire (mais je suppose que sans la plupart des avantages d'un délai d'attente total) en utilisant stream=True mais je pensais que le but des demandes était qu'il gérait les choses pour vous ...

Je pensais que le but des demandes était qu'il gérait les choses pour vous

Il gère HTTP pour vous. Le fait que nous gérons déjà les délais de connexion et de lecture et que nous avons eu quelques exemptions à notre gel des fonctionnalités de plusieurs années est tangentiel à la discussion sur l'utilité, l'opportunité, la cohérence (sur plusieurs plates-formes) et la maintenabilité. Nous apprécions vos commentaires et votre opinion. Si vous avez de nouvelles informations à présenter, nous vous en serions reconnaissants.

Il peut également être révélateur que les demandes ne gèrent pas tout, par le nombre de demandes de fonctionnalités rejetées sur ce projet et le fait qu'il existe un projet distinct mettant en œuvre des modèles d'utilisation communs pour les utilisateurs (la ceinture à outils des demandes). Si un délai d'attente total appartient n'importe où, il serait là, mais encore une fois, il devrait fonctionner sur Windows, BSD, Linux et OSX avec une excellente couverture de test et sans que ce soit un cauchemar à maintenir.

Sur la discussion de stream=True et iter_content pour chronométrer les téléchargements, quelle est la manière équivalente de gérer les téléchargements plus volumineux ?

Définissez un générateur pour votre téléchargement et transmettez-le à data . Ou, si l'encodage fragmenté n'est pas un gagnant pour vous, définissez un objet de type fichier avec une méthode magique read et passez _that_ à data .

Permettez-moi d'élaborer un peu. Si vous passez un générateur à data , les requêtes itéreront dessus et enverront chaque morceau à tour de rôle. Cela signifie que pour envoyer des données, nous devrons nécessairement transmettre le flux de contrôle à votre code pour chaque morceau. Cela vous permet de faire ce que vous voulez pendant ce temps, y compris de lancer des exceptions pour abandonner complètement la demande.

Si, pour une raison quelconque, vous ne pouvez pas utiliser l'encodage de transfert fragmenté pour vos téléchargements (peu probable, mais possible si le serveur en question est vraiment mauvais), vous pouvez faire de même en créant un objet de type fichier qui a une longueur, puis en faisant votre magie dans l'appel read , qui sera appelé à plusieurs reprises pour des morceaux de 8192 octets. Encore une fois, cela garantit que le flux de contrôle passe par votre code par intermittence, ce qui vous permet d'utiliser votre propre logique.

PS: Le paragraphe ci-dessus commençant par "Mettre une autre manière, .." est le genre de conseils que j'ai recherchés dans les docs. Étant donné le nombre de demandes que vous recevez pour un délai d'expiration maximal (et vos raisons valables de ne pas le faire), peut-être que la meilleure chose à faire est d'ajouter certaines de ces informations dans les documents sur le délai d'expiration ?

Je suppose_. De manière générale, cependant, je suis toujours nerveux à l'idée de mettre un texte quelque peu défensif dans la documentation. Cela pourrait aller dans une FAQ, je suppose, mais un texte qui explique pourquoi nous _n'avons pas_ quelque chose est rarement utile dans la documentation. L'espace dans les documents serait mieux servi, je suppose, par une recette pour faire quelque chose.

Je pense que quiconque ne veut pas d'un délai d'expiration total ne pense pas clairement à ce qu'il veut, et j'ai du mal à imaginer une situation où ce que vous décrivez comme un bogue "le téléchargement de 30 Mo passe à 30 Go et échoue donc" n'est pas en fait une caractéristique bénéfique!

Hein, je ne suis pas :

• gestionnaire de paquets (par exemple pip, qui utilise des requêtes), où les paquets peuvent varier énormément en taille de données
• web scraper, qui peut s'exécuter sur plusieurs sites dont la taille varie énormément
• un agrégateur de journaux qui télécharge les fichiers journaux à partir d'hôtes qui ont des niveaux très variables d'entre nous (et donc des tailles de fichiers journaux)
• téléchargeur de vidéos (les vidéos peuvent varier énormément en taille)

En réalité, je pense que le cas où le développeur sait dans un ordre de grandeur à quelle taille de fichier il aura affaire est le cas rare. Dans la plupart des cas, les développeurs n'en ont aucune idée. Et généralement, je dirais qu'il est imprudent de faire des hypothèses sur ces tailles. Si vous avez des contraintes sur la taille du téléchargement, votre code doit délibérément coder ces hypothèses (par exemple sous la forme de vérifications de la longueur du contenu), plutôt que de les coder implicitement et de les mélanger avec la bande passante du réseau de l'utilisateur afin que d'autres personnes lisant le code peut les voir clairement.

mais je pensais que le but des demandes était qu'il s'occupait des choses pour vous...

Les requêtes ne gèrent délibérément pas tout pour les utilisateurs. Essayer de tout faire est une tâche impossible, et il est impossible de construire une bonne bibliothèque qui le fasse. Nous disons régulièrement aux utilisateurs de descendre vers urllib3 afin de réaliser quelque chose.

Nous ne mettons du code dans les requêtes que si nous pouvons le faire mieux ou plus proprement que la plupart des utilisateurs ne pourront le faire. Sinon, il n'y a aucune valeur. Je ne suis vraiment pas encore convaincu que le délai d'attente total soit l'une de ces choses, en particulier compte tenu de ce que je perçois comme une utilité relativement marginale lorsqu'il est agrégé dans notre base d'utilisateurs.

Cela dit, je suis prêt à être convaincu que j'ai tort : je n'ai tout simplement pas encore vu d'argument convaincant pour cela (et, pour vous éviter la passe, "j'en ai besoin !" n'est pas un argument convaincant : faut donner des raisons!).

@sigmavirus24

Si un délai d'attente total appartient n'importe où, il serait là, mais encore une fois, il devrait fonctionner sur Windows, BSD, Linux et OSX avec une excellente couverture de test et sans que ce soit un cauchemar à maintenir.

D'accord!

@lukasa Je suppose que je pense que non seulement je le veux, mais en fait presque tous les utilisateurs le voudraient s'ils y pensaient (ou s'ils ne réalisent pas que ce n'est pas déjà là). La moitié de vos scénarios d'utilisation ci-dessus où vous dites que cela devrait être évité, je dirais que c'est vital (scraper Web et agrégateur de journaux) - les deux autres c'est moins nécessaire car il y a probablement un utilisateur qui attend le résultat qui peut annuler le téléchargement manuellement si Ils veulent. Tout ce qui s'exécute en arrière-plan sans interface utilisateur et n'utilise pas de délai d'expiration global est bogué à mon avis !

Je suppose que ma pensée est que non seulement je le veux, mais en fait presque tous les utilisateurs le voudraient s'ils y pensaient (ou s'ils ne réalisent pas que ce n'est pas déjà là).

@jribbens, nous avons plusieurs années (plus d'une décennie si vous combinez les expériences de nous trois) pour parler et comprendre les besoins de nos utilisateurs. Ce qui a été nécessaire pour presque tous les utilisateurs (au moins 98%) a été des délais de connexion et de lecture. Nous comprenons qu'une minorité très active de nos utilisateurs souhaite un délai d'expiration global. Étant donné ce que nous pouvons extrapoler comme étant la taille du groupe d'utilisateurs potentiels pour cette fonctionnalité par rapport à la taille potentielle des utilisateurs n'ayant pas besoin de cette fonctionnalité et la complexité de la maintenance et du développement de la fonctionnalité, ce n'est pas vraiment quelque chose que nous allons faire.

Si vous avez quelque chose de _nouveau_ à partager, nous aimerions l'entendre, mais tout ce que vous avez dit jusqu'à présent, c'est qu'à votre avis, tout ce qui utilise des requêtes sans délai d'expiration global est bogué et je peux imaginer qu'il y a beaucoup d'utilisateurs qui serait offensé par votre affirmation selon laquelle leurs décisions de conception sont boguées. Alors, s'il vous plaît, évitez d'insulter l'intelligence de nos utilisateurs.

@ sigmavirus24 Tout au long de ce fil, vous avez été inutilement condescendant, incendiaire et grossier, et je vous demande poliment d'arrêter.

@Lukasa J'ai examiné en détail vos suggestions sur la façon de télécharger et de télécharger en streaming et de lire les documents sur ces sujets. Si vous pouviez valider mes hypothèses/questions, ce serait formidable.

1. Pour les téléchargements en streaming, si j'utilise quelque chose comme un délai de lecture "(par exemple, 5 s) puis iter_content sur des morceaux assez petits (par exemple, 1 Ko de données)", cela signifie que la bibliothèque de requêtes appliquera le délai de 5 s pour chaque lecture de 1 Ko et le délai d'attente s'il prend plus de 5s. Correct?
2. Pour les téléchargements en continu, si j'utilise un générateur ou un objet semblable à un fichier qui renvoie des blocs de données et que je règle le délai de lecture sur 5 s, la bibliothèque de requêtes appliquera le délai de 5 s pour chaque bloc que je renvoie et le délai d'expiration si cela prend plus de temps. Correct?
3. Si je n'utilise pas de générateur pour le téléchargement et que je transmets simplement des octets directement, comment la bibliothèque de requêtes décide-t-elle d'appliquer le délai de lecture que j'ai défini ? Par exemple, si je passe un bloc de 4 Mo et un délai de lecture de 5 s, quand exactement ce délai de lecture est-il appliqué ?
4. Si je n'utilise pas iter_content et que les requêtes téléchargent simplement tout le contenu directement dans la requête avec un délai de lecture de 5 s, quand exactement ce délai de lecture est-il appliqué ?

J'ai une compréhension générale des sockets/TCP protocol/etc mais pas exactement comment urllib fonctionne avec ces concepts à un niveau inférieur ou si les demandes font quelque chose de spécial en plus de transmettre les valeurs. Je veux comprendre exactement comment les délais d'attente sont appliqués, car le simple fait de récupérer le flux de contrôle et d'appliquer mon propre schéma de délai d'attente ne fonctionne pas étant donné les problèmes de crossplat avec la fin du thread. S'il y a du matériel de lecture supplémentaire pour répondre à mes questions, n'hésitez pas à me référer! En tout cas, cela devrait être, espérons-le, ma dernière série de questions. :)

Merci pour votre aide jusqu'à maintenant.

@emgerner-msft D'accord :

1. Non. C'est plus complexe que ça, malheureusement. Comme indiqué, chaque délai d'attente s'applique _par appel de socket_, mais nous ne pouvons pas garantir le nombre d'appels de socket dans un morceau donné. La raison assez complexe en est que la bibliothèque standard enveloppe le socket de sauvegarde dans un objet tampon (généralement quelque chose comme io.BufferedReader ). Cela fera autant d'appels recv_into que nécessaire jusqu'à ce qu'il ait fourni suffisamment de données. Cela peut être aussi peu que zéro (s'il y a déjà suffisamment de données dans la mémoire tampon) ou autant que le nombre exact d'octets que vous avez reçus si le pair distant vous injecte un octet à la fois. Nous ne pouvons vraiment rien faire à ce sujet : en raison de la nature d'un appel read() contre un tel objet mis en mémoire tampon, nous ne récupérons même pas le flux de contrôle entre chaque appel recv_into .

Cela signifie que la _seule_ façon de garantir que vous n'obtiendrez pas plus d'une attente de n secondes est de faire iter_content avec une taille de morceau de 1 . C'est une façon absurdement inefficace de télécharger un fichier (passe beaucoup trop de temps dans le code Python), mais c'est la seule façon d'obtenir la garantie que vous souhaitez.

1. Je crois aussi que la réponse à cette question est non. Nous n'avons actuellement aucune idée d'un délai d'attente _send_. La façon d'en obtenir un est d'utiliser socket.setdefaulttimeout .
2. Les délais de lecture sont appliqués uniquement aux lectures, donc peu importe la façon dont vous passez le corps.
3. Ce délai de lecture souffre des mêmes problèmes que le cas iter_content : si vous avez des demandes de tout télécharger, nous finirons par émettre autant d'appels recv_into que nécessaire pour télécharger le corps, et le délai d'attente s'applique à chacun tour à tour.

Vous vous heurtez ici au problème principal : les requêtes ne se rapprochent tout simplement pas suffisamment du socket pour obtenir exactement ce que vous recherchez. Nous _pourrions_ ajouter un délai d'envoi : il s'agit d'un travail de demande de fonctionnalité, et il ne souffre pas des mêmes problèmes que le délai de lecture, mais pour tout le reste, nous sommes bloqués car httplib insiste (à juste titre) sur l'échange à une représentation de socket tamponnée, puis le reste de httplib utilise cette représentation tamponnée.

@Lukasa

Ah, quel gâchis, haha. Je pensais que c'était le cas, mais j'espérais vraiment que j'avais tort.

Tout d'abord, nous avons désespérément besoin d'un délai d'attente d'envoi. Je ne peux tout simplement pas dire à mes utilisateurs que leurs téléchargements peuvent se bloquer à l'infini et que nous n'avons pas de plan pour résoudre le problème. :/

Il semble que je sois dans une situation impossible à ce stade. Il n'y a pas de support de bibliothèque pour le délai d'attente total (ce que je comprends). Il n'y a aucune garantie sur le fonctionnement exact du délai d'attente existant avec différentes tailles de blocs - s'il y en avait, je pourrais simplement résumer le temps : délai de connexion + délai de lecture * taille du bloc. Pouvoir interrompre le flux avec le mode flux et les générateurs est agréable, mais comme je n'ai pas de solution pour interrompre réellement les threads de manière multiplateforme, cela n'aide pas non plus. Voyez-vous d'autres options pour aller de l'avant? Que font les autres utilisateurs pour résoudre ces problèmes ?

Tout d'abord, nous avons désespérément besoin d'un délai d'attente d'envoi. Je ne peux tout simplement pas dire à mes utilisateurs que leurs téléchargements peuvent se bloquer à l'infini et que nous n'avons pas de plan pour résoudre le problème. :/

Ainsi, la logique de temporisation utilisée dans les requêtes est fondamentalement celle d'urllib3, il devrait donc suffire d'y apporter le changement : n'hésitez pas à ouvrir une demande de fonctionnalité et nous pourrons vous aider à travers le changement. Et à plus court terme, n'hésitez pas à enquêter en utilisant setdefaulttimeout .

Voyez-vous d'autres options pour aller de l'avant? Que font les autres utilisateurs pour résoudre ces problèmes ?

Les options dont vous disposez ici dépendent de vos contraintes spécifiques.

Si vous _devez_ avoir un délai d'attente déterministe (c'est-à-dire s'il doit vous être possible de garantir qu'une requête ne prendra pas plus de _n_ secondes), vous ne pouvez pas le faire facilement avec la bibliothèque standard Python telle qu'elle existe aujourd'hui. Dans Python 2.7, vous auriez besoin de patcher socket._fileobject pour vous permettre d'exécuter un délai d'attente séquentiel pour chaque appel recv , mais dans Python 3, c'est encore plus difficile car vous devez patcher dans une classe dont l'implémentation est en C ( io.BufferedReader ), ce qui va être un cauchemar.

Sinon, la seule façon de l'obtenir est de désactiver la mise en mémoire tampon dans la bibliothèque standard. Cela cassera httplib et tous nos correctifs en plus, qui supposent que nous pouvons faire un appel read(x) qui ne se comportera pas comme l'appel système read sur un socket mais plutôt comme le read syscall sur un fichier (c'est-à-dire, retourne une longueur déterministe).

En d'autres termes : si vous avez _besoin_ d'un délai d'attente déterministe, vous constaterez qu'un grand nombre de bibliothèques sont tout simplement incapables de vous le fournir. Fondamentalement, s'ils utilisent httplib ou socket.makefile , vous n'aurez pas de chance : il n'y a tout simplement pas de moyen propre de garantir que le contrôle vous revienne dans un délai défini, sauf pour l'émission répétée de longueur -1 lit. Vous _pouvez_ le faire, mais cela nuira à vos performances.

Vous avez donc un compromis ici : si vous voulez un délai d'attente déterministe, la façon dont la mise en mémoire tampon est implémentée dans la bibliothèque standard Python (et donc, dans les requêtes) ne vous le rendra tout simplement pas disponible. Vous pouvez récupérer cela en désactivant la mise en mémoire tampon et en réécrivant le code, mais cela nuit potentiellement assez gravement à vos performances, à moins que vous ne réimplémentiez la mise en mémoire tampon d'une manière qui reconnaisse les délais d'attente.

Vous pouvez viser à implémenter le code requis dans la bibliothèque standard Python dans la classe BufferedReader : vous pouvez certainement demander aux gens de Python s'ils sont intéressés. Mais je ne retiendrais pas mon souffle.

Ainsi, la logique de temporisation utilisée dans les requêtes est fondamentalement celle d'urllib3, il devrait donc suffire d'y apporter le changement : n'hésitez pas à ouvrir une demande de fonctionnalité et nous pourrons vous aider à travers le changement. Et à plus court terme, n'hésitez pas à enquêter en utilisant setdefaulttimeout.

Demande de fonctionnalité dans urllib3 ou ici ? En ouvrira un (ou les deux) dès que possible.

Demande de fonctionnalité dans urllib3 : nous n'avons pas besoin d'exposer quoi que ce soit de nouveau dans les demandes.