Requests: कुल समय समाप्त

हाय @ emgerner-msft,

संदर्भ के लिए, इस विषय पर सभी भिन्नताएं निम्नलिखित हैं यदि यह सटीक सुविधा अनुरोध नहीं है:

• https://github.com/kennethreitz/requests/issues/2327
• https://github.com/kennethreitz/requests/issues/2685
• https://github.com/kennethreitz/requests/issues/1928
• (और मुझे यकीन है कि और भी हैं)

हमने इस पर https://github.com/sigmavirus24/requests-toolbelt/issues/51 पर भी चर्चा की है

आप देखेंगे कि अंतिम लिंक इस पैकेज पर चर्चा करता है जो इसे अनुरोधों में जोड़े बिना आपके लिए इसे संभालना चाहिए। वास्तविकता यह है कि ऐसा करने के लिए अनुरोधों की कोई आवश्यकता नहीं है जब कोई अन्य पैकेज पहले से ही इसे बहुत अच्छी तरह से करता है।

आपके द्वारा संदर्भित पैकेज वेब अनुरोध को चलाने के लिए एक अलग प्रक्रिया को फोर्क करके करता है। यह एक टाइमआउट के सरल लक्ष्य को प्राप्त करने का एक बहुत ही भारी तरीका है, और मेरे विचार में किसी भी तरह से मूल टाइमआउट सुविधा वाले अनुरोधों का विकल्प नहीं है।

@jribbens यदि आप ऐसे तरीके से आ सकते हैं जो न तो धागे और न ही प्रक्रियाओं का उपयोग करता है, तो यह आश्चर्यजनक होगा। तब तक, यदि आप एक वॉल क्लॉक टाइमआउट चाहते हैं तो आपका सबसे अच्छा दांव वह पैकेज है क्योंकि यह इस समय इसे प्राप्त करने का सबसे विश्वसनीय तरीका है।

मुझे नहीं लगता कि @jribbens कोई थ्रेड या प्रक्रिया नहीं कह रहा है। बस एक प्रक्रिया _per_ वेब अनुरोध अत्यधिक है। कई भाषाओं में एक अतिरिक्त थ्रेड या प्रक्रिया को साझा करने वाले एकाधिक टाइमर का एक तरीका होता है। मुझे इस बात की जानकारी नहीं है कि पायथन में यह सबसे अच्छा कैसे किया जाए।

ऐसा लगता है कि #1928 में विकल्पों की सबसे अधिक चर्चा है, लेकिन अधिकांश में बहुत सी चेतावनियां हैं (यह आपके उपयोग के मामले आदि के लिए काम नहीं करेगी)। मैं अपनी लाइब्रेरी में कुछ कस्टम कोड रखने और अपना स्वयं का कस्टम समाधान लिखने के साथ ठीक हूं यदि यह वास्तव में अनुरोधों से संबंधित नहीं है, लेकिन मुझे लगता है कि मुझे इस बारे में थोड़ी और जानकारी चाहिए कि यह कैसा दिखेगा। हमारे द्वारा अनुरोधों का उपयोग करने का पूरा कारण निम्न स्तर के टीसीपी कनेक्शन पूलिंग लॉजिक से दूर होना है, लेकिन ऐसा लगता है कि इस थ्रेड को पढ़ने के लिए इस कस्टम कोड को लिखने के लिए मुझे उस तर्क को जानने की जरूरत है, और यही मुझे कुछ परेशानी हो रही है .

@ emgerner-msft सही है। मैं @ sigmavirus24 की टिप्पणी से थोड़ा भ्रमित हूं, धागे या प्रक्रियाओं का उपयोग किए बिना "कुल टाइमआउट" होना काफी पैदल चलने वाला लगता है और बिल्कुल भी "अद्भुत" नहीं है। पूरी प्रक्रिया की शुरुआत में बस समय सीमा की गणना करें (उदाहरण के लिए deadline = time.time() + total_timeout ) और फिर किसी भी व्यक्तिगत ऑपरेशन पर टाइमआउट को deadline - time.time() पर सेट करें।

धागे या प्रक्रियाओं का उपयोग किए बिना "कुल टाइमआउट" होने से काफी पैदल यात्री लगता है और बिल्कुल "अद्भुत" नहीं होता है।

और आपका समाधान बल्कि आदिम है। कारण _सबसे_ लोग कुल (या दीवार घड़ी) टाइमआउट चाहते हैं, पढ़ने को "हैंग होने" से रोकने के लिए, दूसरे शब्दों में निम्न जैसा मामला:

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

जहां प्रत्येक पठन iter_content के बीच में एक लंबा समय लेता है, लेकिन यह रीड टाइमआउट से कम है (मुझे लगता है कि हम स्ट्रीमिंग करते समय इसे लागू करते हैं, लेकिन यह अभी भी ऐसा हो सकता है कि हम ऐसा नहीं करते हैं) उन्होंने निर्दिष्ट किया . निश्चित रूप से ऐसा लगता है कि इसे आपके समाधान @jribbens द्वारा आसानी से संभाला जाना चाहिए जब तक आपको याद न हो कि घड़ियां कैसे बहती हैं और दिन के उजाले की बचत का समय कैसे काम करता है और उन्हें time.time() अपर्याप्त रूप से अपर्याप्त है।

अंत में, यह ध्यान रखना महत्वपूर्ण है कि अनुरोध 'एपीआई जमे हुए है। कुल टाइमआउट निर्दिष्ट करने के लिए कोई अच्छा या सुसंगत API नहीं है। और अगर हमने आपके सुझाव के अनुसार एक टाइमआउट लागू किया है, तो हमारे पास अनगिनत बग होंगे जो उन्होंने एक मिनट लंबा कुल टाइमआउट निर्दिष्ट किया था, लेकिन इसमें अधिक समय लगा क्योंकि पिछली बार जब हमने जांच की थी तो हम एक मिनट से कम थे लेकिन उनका कॉन्फ़िगर किया गया रीड टाइमआउट इतना लंबा था कि उनका टाइमआउट डेढ़ मिनट के आसपास त्रुटि उठाई गई थी। यह एक _very_ रफ वॉल टाइमआउट है जो इसे ढूंढ रहे लोगों के लिए थोड़ा बेहतर होगा, लेकिन इसे स्वयं लागू करने वाले व्यक्ति से अलग नहीं है।

क्षमा करें यदि मैं अस्पष्ट था @ sigmavirus24 , तो आपने सिद्धांत के मेरे छद्म कोड चित्रण की आलोचना की है जैसे कि आपने सोचा था कि यह एक शाब्दिक पैच था। हालांकि मुझे यह बताना चाहिए कि time.time() उस तरह से काम नहीं करता जैसा आप स्पष्ट रूप से सोचते हैं - दिन के उजाले की बचत का समय प्रासंगिक नहीं है, और न ही हम जिस समय के बारे में बात कर रहे हैं, उस पर घड़ी का तिरछा होना है। इसके अलावा, आपने सुझाव को गलत समझा है यदि आपको लगता है कि आपके द्वारा वर्णित बग घटित होगा। अंत में मुझे यकीन नहीं है कि अनुरोध एपीआई द्वारा "जमे हुए" होने का आपका क्या मतलब है क्योंकि एपीआई को हाल ही में संस्करण 2.9.0 के रूप में बदल दिया गया था, इसलिए स्पष्ट रूप से जो कुछ भी आपका मतलब है वह वह नहीं है जिसे मैं सामान्य रूप से शब्द से समझता हूं।

बस मेरी चर्चा को अलग करने के लिए: मैं वास्तव में बहस नहीं कर रहा हूं यह आसान है। अगर यह पूरी तरह से सरल होता, तो मैं इसे लिख देता और आपको परेशान करना बंद कर देता। :)

मेरी समस्याएं हैं:
1) आपके द्वारा सूचीबद्ध धागों पर सब कुछ मंकी पैच था। यह ठीक है, लेकिन मैं इसे उत्पादन गुणवत्ता पुस्तकालय में उपयोग कर रहा हूं और आंतरिक परिवर्तनों की चेतावनी को सब कुछ तोड़ नहीं सकता।
2) आपके द्वारा दिए गए लिंक में टाइमआउट डेकोरेटर बहुत अच्छा है, लेकिन मैं इस बारे में स्पष्ट नहीं हूं कि यह कनेक्शन को कैसे प्रभावित करता है। यहां तक ​​​​कि अगर हम स्वीकार करते हैं कि टाइमआउट करने का एकमात्र अच्छा तरीका धागे के समूह के साथ है, तो यह पुस्तकालय कैसे लागू करता है कि सॉकेट बंद हो जाता है, कनेक्शन गिरा दिया जाता है, आदि। हम बहुत सारे कनेक्शन कर रहे हैं और यह संभावित रूप से काफी लगता है रिसाव प्रवण। अनुरोधों में 'निरस्त' विधि नहीं है जो मुझे मिल सकती है (अगर मैं गलत हूं तो मुझे सुधारें) तो कनेक्शन का शटडाउन कैसे हो रहा है?

मैं बस एक स्पष्ट 'धन्य' संस्करण की तलाश कर रहा हूं कि इस समस्या को अपने दम पर कैसे हल किया जाए, या यदि कोई सही समाधान नहीं है, तो कुछ समाधानों पर चर्चा की गई है। क्या इसका कोई मतलब है?

@emgerner-msft मान लें कि आप CPython का उपयोग कर रहे हैं, कनेक्शन शटडाउन तब होगा जब अनुरोध जारी नहीं रहेगा। उस समय अंतर्निहित कनेक्शन के सभी संदर्भ खो जाएंगे और सॉकेट बंद कर दिया जाएगा और इसका निपटान किया जाएगा।

@ लुकासा ठीक है, धन्यवाद! पुस्तकालय कैसे निर्धारित करता है कि अनुरोध अब जारी नहीं है? उदाहरण के लिए, अगर मैंने टाइमआउट डेकोरेटर रूट का इस्तेमाल किया और डाउनलोड के बीच में कट ऑफ किया, तो डाउनलोड वास्तव में कब रुकेगा? क्या मुझे स्ट्रीमिंग विकल्पों के साथ कुछ खास करने की ज़रूरत है?

यदि आप टाइमआउट डेकोरेटर का उपयोग करते हैं, तो टाइमआउट सक्रिय होने पर डाउनलोड बंद हो जाएगा। ऐसा इसलिए है क्योंकि सिग्नल सिस्को को बाधित करते हैं, जिसका अर्थ है कि सॉकेट में आगे कोई कॉल नहीं होगी। एक बार अनुरोध के दायरे में नहीं रहने के बाद (उदाहरण के लिए स्टैक आपके requests.* फ़ंक्शन के बाहर की ओर खुल गया है), यह इसमें है: CPython कनेक्शन ऑब्जेक्ट को साफ कर देगा और कनेक्शन को फाड़ देगा। वहां कोई विशेष स्ट्रीमिंग विकल्प की आवश्यकता नहीं है।

उत्तम। मुझे तब तक धागा बंद करना अच्छा लगता है, जब तक कि दूसरों के पास कहने के लिए और कुछ न हो।

दरअसल, क्षमा करें, एक और चिंता। टाइमआउट डेकोरेटर कोड को अधिक बारीकी से देख रहा था क्योंकि आपने कहा था कि यह सिग्नल का उपयोग करता है, जैसा कि पायथन टाइमर (संभवतः) जैसी किसी चीज़ के विपरीत था। ऐसा लगता है कि यह SIGALRM के साथ सिग्नल को कॉल करता है जिसे विंडोज पर काम नहीं करने के लिए पायथन सिग्नल में प्रलेखित किया गया है। मुझे यूनिक्स और विंडोज दोनों वातावरणों के साथ-साथ पायथन 2.7 और 3.3+ (स्वयं अनुरोधों की तरह) दोनों में काम करने की आवश्यकता है। मैं थोड़ा और आगे बढ़ूंगा और देख सकता हूं कि यह वास्तव में काम करेगा या नहीं।

@ emgerner-msft यह निराशाजनक है। =(

@ लुकासा हाँ, मूल उपयोग स्निपेट की कोशिश की और यह विंडोज़ पर काम नहीं करता है। मैंने कुछ और कोड/उदाहरण पढ़े और फिडेल किया और ऐसा लगता है कि अगर हम संकेतों का उपयोग नहीं करते हैं तो पैकेज काम कर सकता है, लेकिन सब कुछ चुनने योग्य होना चाहिए जो मेरे आवेदन के मामले में नहीं है। तो जहाँ तक मैं बता सकता हूँ, टाइमआउट डेकोरेटर मेरी समस्या का समाधान नहीं करेगा। कोई अन्य विचार?

@emgerner-msft क्या आप आश्वस्त हैं कि विंडोज़-विशिष्ट संकेतों में से कोई भी उपयुक्त नहीं है?

@ लुकासा कुंद होने के लिए, मैं बस नहीं जानता। मैंने पहले सिग्नल का उपयोग नहीं किया है, और बहुत कुछ मुझे तब तक एहसास नहीं हुआ जब तक आपने मुझे नहीं बताया कि वे अनुरोध को बाधित करेंगे, मुझे यकीन नहीं है कि क्या उचित है। मैं इसे केवल विंडोज़ पर काम करने की कोशिश नहीं कर रहा हूं। मुझे पूर्ण क्रॉसप्लेट समर्थन (विंडोज और यूनिक्स) और पायथन 2 और पायथन 3 समर्थन दोनों की आवश्यकता है। इतने सारे सिग्नल प्लेटफ़ॉर्म विशिष्ट दिखते हैं जो मुझे फेंक रहे हैं। Timer उन समाधानों में से एक था जिसे मैं देख रहा था जो कम निम्न स्तर का दिखता था और इस प्रकार मेरी बाधाओं का ख्याल रख सकता था, लेकिन मुझे यकीन नहीं है कि मैं कनेक्शन कैसे बंद कर सकता हूं। मैं और अधिक पढ़ सकता हूं, लेकिन यही कारण है कि मैं आप लोगों से अतिरिक्त मार्गदर्शन प्राप्त करने की उम्मीद कर रहा था। :)

तो यह वास्तव में एक मुश्किल जगह है।

वास्तविकता यह है कि किसी थ्रेड को बाधित करने के अलावा उसे मारने के लिए कमोबेश कोई क्रॉस-प्लेटफ़ॉर्म तरीका नहीं है, जो मूल रूप से एक संकेत है। इसका मतलब है, मुझे लगता है कि सिग्नल ही एकमात्र मार्ग है जो आपको वास्तव में प्लेटफार्मों पर यह काम करना है। मैं विंडोज़ी पाइथोनी विशेषज्ञ में पिंग करने की कोशिश करने के इच्छुक हूं: @brettcannon , क्या आपके पास यहां एक अच्छा सुझाव है?

रुचि से, क्या कार्यान्वयन और परीक्षण के अलावा अन्य अनुरोधों में "कुल टाइमआउट" लागू नहीं करने का कोई कारण है, इसके लिए काम की आवश्यकता है? मेरा मतलब है, अगर इसे लागू करने के लिए एक पैच आज जादुई रूप से प्रकट होता है तो क्या इसे सिद्धांत रूप में अस्वीकार कर दिया जाएगा या स्वीकार कर लिया जाएगा? मैं "अनावश्यक जटिलता को खत्म करने" के दृष्टिकोण की सराहना करता हूं और सहमत हूं, लेकिन "आप इसे एक अलग प्रक्रिया को फोर्क करके कर सकते हैं" मेरी राय में इस सुविधा को अनावश्यक नहीं बनाता है।

@jribbens इसके साथ कुछ समस्याएं हैं।

भाग 1 यह है कि ऐसे पैच की जटिलता बहुत अधिक होती है। इसे सही ढंग से व्यवहार करने के लिए आपको सॉकेट स्तर पर बार-बार टाइमआउट बदलने की जरूरत है। इसका मतलब यह है कि पैच को व्यापक रूप से पारित करने की आवश्यकता है, हालांकि httplib, जिसे हम पहले से ही जितना चाहते हैं उससे अधिक पैच कर चुके हैं। अनिवार्य रूप से, हमें इस कार्यात्मक परिवर्तन को प्राप्त करने के लिए httplib तक पहुँचने और इसके अधिक जटिल तरीकों के लगभग 50% को फिर से लागू करने की आवश्यकता होगी।

भाग 2 यह है कि ऐसे पैच का रखरखाव अपेक्षाकृत बोझिल है। हमें इसे सफलतापूर्वक करने के लिए httplib (इस समय अधिक उचित रूप से http.client) के समानांतर कांटे की मात्रा को बनाए रखना शुरू करना होगा। वैकल्पिक रूप से, हमें एक अलग HTTP स्टैक के रखरखाव के बोझ को उठाना होगा जो इस तरह के बदलाव के लिए अधिक अनुकूल है। यह हिस्सा है, मुझे संदेह है, आमतौर पर उन लोगों द्वारा याद किया जाता है जो इस तरह की सुविधा चाहते हैं: इसे लागू करने की लागत अधिक है, लेकिन सभी प्लेटफार्मों पर इस तरह की सुविधा का समर्थन करने की चल रही रखरखाव लागत की तुलना में यह कुछ भी नहीं है।

भाग 3 यह है कि ऐसे पैच का लाभ स्पष्ट नहीं है। यह मेरा अनुभव रहा है कि ज्यादातर लोग जो कुल टाइमआउट पैच चाहते हैं, वे पूरी तरह से स्पष्ट रूप से नहीं सोच रहे हैं कि वे क्या चाहते हैं। ज्यादातर मामलों में, कुल टाइमआउट पैरामीटर बिना किसी कारण के पूरी तरह से अच्छे अनुरोधों को मारने का प्रभाव डालते हैं।

उदाहरण के लिए, मान लें कि आपने कुछ कोड डिज़ाइन किया है जो फ़ाइलें डाउनलोड करता है, और आप हैंग को संभालना चाहते हैं। हालांकि यह शुरू में एक फ्लैट कुल टाइमआउट सेट करना चाहता है ("कोई अनुरोध 30 सेकंड से अधिक समय नहीं ले सकता!"), ऐसे टाइमआउट बिंदु को याद करते हैं। उदाहरण के लिए, यदि कोई फ़ाइल 30एमबी से 30 जीबी आकार में बदल जाती है, तो ऐसी फ़ाइल उस समय अंतराल में कभी भी डाउनलोड नहीं हो सकती, भले ही डाउनलोड पूरी तरह से स्वस्थ हो।

दूसरे शब्दों में कहें, तो कुल समयबाह्य एक आकर्षक उपद्रव है: वे एक समस्या को हल करने के लिए प्रतीत होते हैं, लेकिन वे इसे प्रभावी ढंग से नहीं करते हैं। एक अधिक उपयोगी तरीका, मेरी राय में, प्रति-सॉकेट-एक्शन टाइमआउट का लाभ उठाना है, जो stream=True और iter_content के साथ संयुक्त है, और डेटा के भाग के लिए खुद को टाइमआउट असाइन करें। जिस तरह से iter_content काम करता है, कुछ नियमित अंतराल में नियंत्रण का प्रवाह आपके कोड पर वापस आ जाएगा। इसका मतलब है कि आप अपने आप को सॉकेट-स्तरीय टाइमआउट (जैसे 5s) और फिर iter_content काफी छोटे हिस्से (जैसे 1KB डेटा) पर सेट कर सकते हैं और अपेक्षाकृत आश्वस्त रहें कि जब तक आप पर सक्रिय रूप से हमला नहीं किया जाता है, तब तक सेवा से इनकार नहीं किया जाता है यहां संभव है। यदि आप सेवा से इनकार करने के बारे में वास्तव में चिंतित हैं, तो अपने सॉकेट-स्तरीय टाइमआउट को बहुत कम और अपने चंक आकार को छोटा (0.5s और 512 बाइट्स) सेट करें ताकि यह सुनिश्चित हो सके कि आप नियमित रूप से नियंत्रण प्रवाह आपको वापस सौंप रहे हैं।

इस सब का नतीजा यह है कि मेरा मानना ​​​​है कि इस तरह की लाइब्रेरी में कुल टाइमआउट एक मिसफीचर है। सबसे अच्छा प्रकार का टाइमआउट वह है जिसे बड़ी प्रतिक्रियाओं को शांति से डाउनलोड करने के लिए पर्याप्त समय की अनुमति देने के लिए ट्यून किया गया है, और इस तरह के टाइमआउट को सॉकेट-स्तरीय टाइमआउट और iter_content द्वारा सबसे अच्छा परोसा जाता है।

हो सकता है कि @zooba के पास एक विचार हो क्योंकि वह वास्तव में जानता है कि विंडोज कैसे काम करता है। :)

(असंबद्ध रूप से, मेरी पसंदीदा चीजों में से एक गिटहब मुद्दे में विशेषज्ञों की डेज़ी-श्रृंखला स्थापित करना है।)

हाहा, मैं पहले से ही @zooba और @brettcannon को जानता हूं। मैं उनके साथ यहां या आंतरिक रूप से चर्चा कर सकता हूं क्योंकि इसका समाधान शायद उनकी भी मदद करेगा।

@ emgerner-msft मुझे लगा कि आप कर सकते हैं, लेकिन यह अनुमान नहीं लगाना चाहते थे: MSFT एक बड़ा संगठन है!

@ लुकासा बस ऊपर लिखे गए पाठ की दीवार के माध्यम से पढ़ रहा है - दिलचस्प! स्ट्रीम = ट्रू और iter_content टू टाइम डाउनलोड की चर्चा पर, बड़े अपलोड को संभालने का समान तरीका क्या है?

_PS_: ऊपर दिया गया पैराग्राफ 'एक और रास्ता रखो, ..' से शुरू होता है, वह उस तरह का मार्गदर्शन है जिसे मैंने डॉक्स में खोजा था। अधिकतम टाइमआउट के लिए आपको प्राप्त होने वाले अनुरोधों की संख्या को देखते हुए (और ऐसा न करने के आपके वैध कारण), शायद सबसे अच्छी बात यह है कि टाइमआउट डॉक्स में उस जानकारी में से कुछ को जोड़ना है?

lol @lukasa मैं रखरखाव के बारे में आपकी बात लेता हूं, जो पहले से ही मेरे दिमाग में था, लेकिन "फीचर बनाम मिसफीचर" पर मुझे डर है कि मैं आपके बिल्कुल विपरीत हूं। मुझे लगता है कि कोई भी जो _नहीं_ कुल टाइमआउट चाहता है वह स्पष्ट रूप से नहीं सोच रहा है कि वे क्या चाहते हैं, और मुझे ऐसी स्थिति की कल्पना करने में कठिनाई हो रही है जहां आप एक बग के रूप में वर्णित करते हैं "30 एमबी डाउनलोड 30 जीबी में बदल जाता है और इसलिए विफल रहता है" नहीं है वास्तव में एक लाभकारी विशेषता!

जैसा कि आप कहते हैं कि आप कुछ ऐसा ही कर सकते हैं (लेकिन मुझे कुल टाइमआउट के अधिकांश लाभों के बिना संदेह है) stream=True का उपयोग करके, लेकिन मैंने सोचा कि अनुरोधों की बात यह थी कि यह आपके लिए चीजों को संभाला ...

मुझे लगा कि अनुरोधों की बात यह थी कि इसने आपके लिए चीजों को संभाला

यह आपके लिए HTTP को हैंडल करता है। तथ्य यह है कि हम पहले से ही कनेक्शन को संभालते हैं और टाइमआउट पढ़ते हैं और हमें कई वर्षों की सुविधा फ्रीज में कुछ छूट मिली है, उपयोगिता, वांछनीयता, स्थिरता (कई प्लेटफार्मों में), और रखरखाव की चर्चा के लिए स्पर्शरेखा है। हम आपकी प्रतिक्रिया और आपकी राय की सराहना करते हैं। यदि आपके पास प्रस्तुत करने के लिए नई जानकारी है, तो हम इसकी सराहना करेंगे।

यह यह भी बता सकता है कि इस परियोजना पर अस्वीकृत फीचर अनुरोधों की संख्या और इस तथ्य से कि अनुरोध सब कुछ संभाल नहीं पाते हैं, उपयोगकर्ताओं के लिए सामान्य उपयोग पैटर्न (अनुरोध टूलबेल्ट) को लागू करने वाली एक अलग परियोजना है। यदि कुल टाइमआउट कहीं भी है, तो यह वहां होगा, लेकिन फिर से, इसे विंडोज़, बीएसडी, लिनक्स और ओएसएक्स पर उत्कृष्ट परीक्षण कवरेज के साथ काम करना होगा और इसे बनाए रखने के लिए एक दुःस्वप्न नहीं होना चाहिए।

स्ट्रीम = ट्रू और iter_content टू टाइम डाउनलोड की चर्चा पर, बड़े अपलोड को संभालने का समान तरीका क्या है?

अपने अपलोड के लिए एक जनरेटर परिभाषित करें, और उसे data पर भेज दें। या, यदि खंडित एन्कोडिंग आपके लिए विजेता नहीं है, तो एक फ़ाइल जैसी वस्तु को जादू read विधि से परिभाषित करें और _that_ को data पास करें।

मुझे थोड़ा विस्तार से बताएं। यदि आप जनरेटर को data पर पास करते हैं, तो अनुरोध उस पर फिर से शुरू हो जाएंगे, और बदले में प्रत्येक खंड को भेज देंगे। इसका मतलब यह है कि डेटा भेजने के लिए हमें आवश्यक रूप से प्रत्येक खंड के लिए आपके कोड पर नियंत्रण का प्रवाह सौंपना होगा। यह आपको उस समय में जो कुछ भी आप चाहते हैं वह करने देता है, जिसमें अनुरोध को पूरी तरह से निरस्त करने के लिए अपवाद फेंकना शामिल है।

यदि किसी कारण से आप अपने अपलोड के लिए खंडित स्थानांतरण एन्कोडिंग का उपयोग नहीं कर सकते हैं (संभावना नहीं है, लेकिन संभव है यदि प्रश्न में सर्वर वास्तविक रूप से खराब है), तो आप एक फ़ाइल जैसी वस्तु बनाकर ऐसा कर सकते हैं जिसकी लंबाई है और फिर अपनी read कॉल में जादू, जिसे बार-बार 8192-बाइट विखंडू के लिए बुलाया जाएगा। फिर, यह सुनिश्चित करता है कि नियंत्रण का प्रवाह रुक-रुक कर आपके कोड से गुजरता है, जिससे आप अपने तर्क का उपयोग कर सकते हैं।

पुनश्च: 'एक और रास्ता रखो, ..' से शुरू होने वाला पैराग्राफ उस तरह का मार्गदर्शन है जिसे मैंने डॉक्स में देखा था। अधिकतम टाइमआउट के लिए आपको मिलने वाले अनुरोधों की संख्या को देखते हुए (और ऐसा न करने के आपके वैध कारण), शायद सबसे अच्छी बात यह है कि टाइमआउट दस्तावेज़ों में उस जानकारी में से कुछ जोड़ना है?

मुझे लगता है_। सामान्यतया, हालाँकि, मैं हमेशा कुछ रक्षात्मक पाठ को दस्तावेज़ीकरण में डालने से घबराता हूँ। मेरे अनुमान से यह अक्सर पूछे जाने वाले प्रश्न में जा सकता है, लेकिन पाठ जो बताता है कि हमारे पास _don't_ कुछ क्यों है, दस्तावेज़ीकरण में शायद ही कभी उपयोगी होता है। डॉक्स में जगह बेहतर होगी, मुझे संदेह है, कुछ करने के लिए एक नुस्खा द्वारा।

मुझे लगता है कि जो कोई कुल टाइमआउट नहीं चाहता है वह स्पष्ट रूप से नहीं सोच रहा है कि वे क्या चाहते हैं, और मुझे ऐसी स्थिति की कल्पना करने में कठिनाई हो रही है जहां आप एक बग के रूप में वर्णित करते हैं "30 एमबी डाउनलोड 30 जीबी में बदल जाता है और इसलिए विफल रहता है" नहीं है वास्तव में एक लाभकारी विशेषता!

हे, मैं नहीं हूँ:

• पैकेज मैनेजर (उदाहरण के लिए पाइप, जो अनुरोधों का उपयोग करता है), जहां पैकेज डेटा आकार में बेतहाशा भिन्न हो सकते हैं
• वेब स्क्रैपर, जो कई साइटों के विरुद्ध चल सकता है जो आकार में बेतहाशा भिन्न होते हैं
• एक लॉग एग्रीगेटर जो मेजबानों से लॉग फाइल डाउनलोड करता है जिसमें हमारे स्तर में बेतहाशा भिन्नता होती है (और इसलिए लॉग फ़ाइल आकार)
• वीडियो डाउनलोडर (वीडियो आकार में बेतहाशा भिन्न हो सकते हैं)

वास्तव में, मुझे लगता है कि जिस मामले में डेवलपर परिमाण के एक क्रम के भीतर जानता है कि वे किस फ़ाइल आकार से निपटेंगे, वह असामान्य मामला है। ज्यादातर मामलों में डेवलपर्स को पता नहीं होता है। और आम तौर पर मैं कहूंगा कि उन आकारों के बारे में धारणा बनाना नासमझी है। यदि आपके पास डाउनलोड आकार पर बाधाएं हैं तो आपके कोड को जानबूझकर उन धारणाओं (उदाहरण के लिए सामग्री-लंबाई पर चेक के रूप में) को एन्कोड करना चाहिए, बजाय उन्हें स्पष्ट रूप से एन्कोड करना और उन्हें उपयोगकर्ता के नेटवर्क की बैंडविड्थ के साथ मिलाना ताकि अन्य लोग पढ़ सकें कोड उन्हें स्पष्ट रूप से देख सकता है।

लेकिन मैंने सोचा कि अनुरोधों की बात यह थी कि यह आपके लिए चीजों को संभालता है ...

अनुरोध बहुत जानबूझकर उपयोगकर्ताओं के लिए सब कुछ संभाल नहीं पाते हैं। सब कुछ करने की कोशिश करना एक असंभव काम है, और ऐसा करने के लिए एक अच्छी लाइब्रेरी बनाना असंभव है। हम नियमित रूप से उपयोगकर्ताओं को कुछ हासिल करने के लिए urllib3 पर ड्रॉप डाउन करने के लिए कहते हैं।

हम अनुरोधों में कोड तभी डालते हैं जब हम इसे अधिकांश उपयोगकर्ताओं की तुलना में बेहतर या साफ-सुथरा कर सकते हैं। यदि नहीं, तो कोई मूल्य नहीं है। मैं वास्तव में उन चीजों में से एक होने के नाते कुल टाइमआउट पर अभी तक बेचा नहीं गया हूं, विशेष रूप से जो मुझे हमारे उपयोगकर्ता-आधार में एकत्रित होने पर अपेक्षाकृत मामूली उपयोगिता के रूप में माना जाता है।

उस ने कहा, मैं आश्वस्त होने के लिए खुला हूं कि मैं गलत हूं: मैंने अभी तक इसके लिए एक ठोस तर्क नहीं देखा है (और, पास पर आपको बताने के लिए, "मुझे इसकी आवश्यकता है!" एक ठोस तर्क नहीं है: कुछ कारण बताना होगा!)

@sigmavirus24

यदि कुल टाइमआउट कहीं भी है, तो यह वहां होगा, लेकिन फिर से, इसे विंडोज़, बीएसडी, लिनक्स और ओएसएक्स पर उत्कृष्ट परीक्षण कवरेज के साथ काम करना होगा और इसे बनाए रखने के लिए एक दुःस्वप्न नहीं होना चाहिए।

माना!

@lukasa मुझे लगता है कि मेरी सोच यह है कि न केवल मैं इसे चाहता हूं, वास्तव में लगभग सभी उपयोगकर्ता इसे चाहते हैं यदि वे इसके बारे में सोचते हैं (या उन्हें नहीं पता कि यह पहले से ही नहीं है)। ऊपर आपके उपयोग परिदृश्यों में से आधा जहां आप कहते हैं कि इसे टाला जाना चाहिए, मैं कहूंगा कि यह महत्वपूर्ण है (वेब ​​स्क्रैपर और लॉग एग्रीगेटर) - अन्य दो यह कम आवश्यक है क्योंकि उपयोगकर्ता के परिणाम की प्रतीक्षा करने की संभावना है जो मैन्युअल रूप से डाउनलोड को रद्द कर सकता है यदि वे चाहते हैं। कुछ भी जो यूआई के बिना पृष्ठभूमि में चलता है और समग्र टाइमआउट का उपयोग नहीं करता है, मेरे विचार में छोटी है!

मुझे लगता है कि मेरी सोच यह है कि न केवल मैं इसे चाहता हूं, वास्तव में लगभग सभी उपयोगकर्ता इसे चाहते हैं यदि वे इसके बारे में सोचते हैं (या उन्हें नहीं पता कि यह पहले से ही नहीं है)।

@jribbens हमारे पास हमारे उपयोगकर्ताओं की जरूरतों के साथ बात करने और समझने के लिए कई सालों (एक दशक से अधिक यदि आप हम तीनों के अनुभवों को जोड़ते हैं)। लगभग सभी (कम से कम 98%) उपयोगकर्ताओं के लिए जो आवश्यक हो गया है वह है कनेक्शन और रीड टाइमआउट। हम समझते हैं कि हमारे उपयोगकर्ताओं का एक बहुत ही मुखर अल्पसंख्यक एक समग्र टाइमआउट चाहता है। यह देखते हुए कि हम उस सुविधा के लिए संभावित उपयोगकर्ताओं के समूह के आकार के रूप में क्या एक्सट्रपलेशन कर सकते हैं बनाम उस सुविधा की आवश्यकता वाले उपयोगकर्ताओं के संभावित आकार और सुविधा के रखरखाव और विकास की जटिलता क्या है, यह वास्तव में ऐसा कुछ नहीं है जो हम जा रहे हैं करने के लिए।

यदि आपके पास साझा करने के लिए कुछ भी _new_ है, तो हम उसे सुनना चाहेंगे, लेकिन अब तक आपने केवल इतना ही कहा है कि आपकी राय में समग्र समयबाह्य के बिना अनुरोधों का उपयोग करना छोटा है और मैं कल्पना कर सकता हूं कि बहुत सारे उपयोगकर्ता हैं जो आपके इस दावे पर आपत्ति होगी कि उनके डिजाइन निर्णय छोटी हैं। इसलिए, कृपया हमारे उपयोगकर्ताओं की बुद्धिमत्ता का अपमान करने से बचें।

@sigmavirus24 इस पूरे सूत्र में आप अनावश्यक रूप से कृपालु, भड़काऊ और असभ्य रहे हैं, और मैं आपसे विनम्रता से पूछ रहा हूं, कृपया रुकें।

@ लुकासा मैंने आपके सुझावों पर विस्तार से देखा कि कैसे स्ट्रीमिंग अपलोड करें और इन विषयों पर डॉक्स को डाउनलोड और पढ़ें। यदि आप मेरी धारणाओं/प्रश्नों को मान्य कर सकते हैं तो यह बहुत अच्छा होगा।

1. डाउनलोड स्ट्रीमिंग के लिए अगर मैं रीड टाइमआउट '(जैसे 5s) और फिर iter_content का उपयोग काफी छोटे हिस्सों (उदाहरण के लिए 1 केबी डेटा) पर करता हूं, तो इसका मतलब है कि अनुरोध पुस्तकालय 1 केबी के प्रत्येक पढ़ने के लिए 5 एस टाइमआउट लागू करेगा और टाइमआउट अगर यह 5s से अधिक लेता है। सही?
2. स्ट्रीमिंग अपलोड के लिए यदि मैं एक जनरेटर या फ़ाइल जैसी वस्तु का उपयोग करता हूं जो डेटा का हिस्सा लौटाती है और मैंने रीड टाइमआउट को 5s पर सेट किया है, तो अनुरोध लाइब्रेरी प्रत्येक चंक के लिए 5s टाइमआउट लागू करेगी और यदि इसमें अधिक समय लगता है तो टाइमआउट। सही?
3. अगर मैं अपलोड करने के लिए जेनरेटर का उपयोग नहीं करता और सीधे बाइट पास करता हूं, तो अनुरोध लाइब्रेरी मेरे द्वारा सेट किए गए रीड टाइमआउट को लागू करने का निर्णय कैसे लेती है? उदाहरण के लिए, यदि मैं आकार 4 एमबी का एक हिस्सा पास करता हूं और 5 एस का एक पठन टाइमआउट पास करता हूं, तो वह रीड टाइमआउट वास्तव में कब लागू होता है?
4. यदि मैं iter_content का उपयोग नहीं करता हूं और केवल अनुरोध करता हूं कि सभी सामग्री को सीधे 5s के रीड टाइमआउट के साथ अनुरोध में डाउनलोड करें, तो वह रीड टाइमआउट वास्तव में कब लागू होता है?

मुझे सॉकेट्स/टीसीपी प्रोटोकॉल/आदि की सामान्य समझ है, लेकिन यह बिल्कुल नहीं है कि urllib इन अवधारणाओं के साथ निचले स्तर पर कैसे काम करता है या यदि अनुरोध मूल्यों को नीचे पारित करने के अलावा कुछ विशेष करता है। मैं ठीक से समझना चाहता हूं कि टाइमआउट कैसे लागू होते हैं क्योंकि नियंत्रण प्रवाह को वापस प्राप्त करना और अपनी खुद की टाइमआउट योजना लागू करना थ्रेड को समाप्त करने के साथ क्रॉसप्लेट मुद्दों को देखते हुए काम नहीं करता है। यदि मेरे प्रश्नों का उत्तर देने के लिए अतिरिक्त पठन सामग्री है, तो बेझिझक मुझे देखें! किसी भी मामले में, उम्मीद है कि यह मेरे प्रश्नों का अंतिम सेट होना चाहिए। :)

अब तक आपकी मदद के लिए धन्यवाद।

@ emgerner-msft ठीक है:

1. नहीं, यह उससे कहीं अधिक जटिल है, दुख की बात है। जैसा कि चर्चा की गई है, प्रत्येक टाइमआउट _per सॉकेट कॉल_ पर लागू होता है, लेकिन हम गारंटी नहीं दे सकते कि किसी दिए गए हिस्से में कितने सॉकेट कॉल हैं। इसका काफी जटिल कारण यह है कि मानक पुस्तकालय बैकिंग सॉकेट को बफर ऑब्जेक्ट में लपेटता है (आमतौर पर io.BufferedReader जैसा कुछ)। यह उतने ही recv_into कॉल करेगा, जब तक कि उसे पर्याप्त डेटा उपलब्ध न कराने की आवश्यकता हो। यह शून्य जितना कम हो सकता है (यदि बफर में पहले से पर्याप्त डेटा है) या यदि रिमोट पीयर आपको एक बार में एक बाइट ड्रिप-फीडिंग कर रहा है तो आपको प्राप्त बाइट्स की संख्या जितनी अधिक हो सकती है। इसके बारे में हम वास्तव में बहुत कम कर सकते हैं: इस तरह के बफर किए गए ऑब्जेक्ट के खिलाफ read() कॉल की प्रकृति के कारण हमें प्रत्येक recv_into कॉल के बीच नियंत्रण का प्रवाह भी नहीं मिलता है।

इसका मतलब यह है कि यह गारंटी देने का _only_ तरीका है कि आपको n-सेकंड प्रतीक्षा से अधिक नहीं मिलता है iter_content को 1 $ के एक बड़े आकार के साथ करना है। फ़ाइल डाउनलोड करने का यह एक बेतुका अक्षम तरीका है (पायथन कोड में बहुत अधिक समय व्यतीत करता है), लेकिन यह गारंटी प्राप्त करने का एकमात्र तरीका है जो आप चाहते हैं।

1. मेरा यह भी मानना ​​है कि इसका उत्तर नहीं है। वर्तमान में हमारे पास _send_ टाइमआउट की कोई धारणा नहीं है। एक पाने का तरीका socket.setdefaulttimeout का उपयोग करना है।
2. रीड टाइमआउट केवल पढ़ने के लिए लागू होते हैं, इसलिए इससे कोई फर्क नहीं पड़ता कि आप शरीर को कैसे पास करते हैं।
3. वह रीड टाइमआउट iter_content मामले के समान ही चिंता का विषय है: यदि आपके पास सब कुछ डाउनलोड करने का अनुरोध है तो हम बॉडी को डाउनलोड करने के लिए जितनी आवश्यकता हो उतनी recv_into कॉल उत्सर्जित करेंगे, और टाइमआउट लागू होता है प्रत्येक को बारी-बारी से।

आप यहां मूल समस्या से टकरा रहे हैं: अनुरोध केवल सॉकेट के इतने करीब नहीं आते हैं कि आप जो खोज रहे हैं उसे प्राप्त करने के लिए। हम एक सेंड टाइमआउट जोड़ सकते हैं: यह एक फीचर रिक्वेस्ट वर्क पर विचार कर रहा है, और इसे रीड टाइमआउट जैसी समस्याओं का सामना नहीं करना पड़ता है, लेकिन बाकी सब चीजों के लिए हम फंस गए हैं क्योंकि httplib स्वैपिंग पर जोर देते हैं (ठीक है) एक बफ़र्ड सॉकेट प्रतिनिधित्व के लिए, और फिर शेष httplib उस बफ़र किए गए प्रतिनिधित्व का उपयोग करता है।

@लुकासा

आह, क्या गड़बड़ है, हाहा। मैंने सोचा कि ऐसा हो सकता है लेकिन मैं वास्तव में उम्मीद कर रहा था कि मैं गलत था।

सबसे पहले, हमें एक प्रेषण टाइमआउट की सख्त जरूरत है। मैं बस अपने उपयोगकर्ताओं को यह नहीं बता सकता कि उनके अपलोड असीमित रूप से लटक सकते हैं और हमारे पास समस्या को ठीक करने की कोई योजना नहीं है। :/

ऐसा लगता है कि मैं इस समय एक असंभव स्थिति में हूं। कुल टाइमआउट (जिसे मैं समझता हूं) के लिए कोई पुस्तकालय समर्थन नहीं है। इस बात की कोई गारंटी नहीं है कि मौजूदा टाइमआउट विभिन्न चंक आकारों के साथ कैसे काम करता है - यदि वहां था, तो मैं केवल समय को जोड़ सकता था: टाइमआउट कनेक्ट करें + टाइमआउट पढ़ें * खंड आकार। स्ट्रीम मोड और जेनरेटर के साथ प्रवाह को बाधित करने में सक्षम होना अच्छा है, लेकिन चूंकि मेरे पास क्रॉस प्लेटफॉर्म तरीके से धागे को वास्तव में निरस्त करने का कोई समाधान नहीं है, इससे कोई मदद नहीं मिलती है। क्या आप आगे बढ़ने के लिए अन्य विकल्प देखते हैं? अन्य उपयोगकर्ता इन समस्याओं को हल करने के लिए क्या कर रहे हैं?

सबसे पहले, हमें एक प्रेषण टाइमआउट की सख्त जरूरत है। मैं बस अपने उपयोगकर्ताओं को यह नहीं बता सकता कि उनके अपलोड असीमित रूप से लटक सकते हैं और हमारे पास समस्या को ठीक करने की कोई योजना नहीं है। :/

इसलिए अनुरोधों में प्रयुक्त टाइमआउट तर्क मूल रूप से urllib3 का है, इसलिए यह वहां परिवर्तन करने के लिए पर्याप्त होना चाहिए: एक सुविधा अनुरोध खोलने के लिए स्वतंत्र महसूस करें और हम परिवर्तन के माध्यम से आपकी सहायता कर सकते हैं। और छोटी अवधि में, बेझिझक setdefaulttimeout का उपयोग करके जांच करें।

क्या आप आगे बढ़ने के लिए अन्य विकल्प देखते हैं? अन्य उपयोगकर्ता इन समस्याओं को हल करने के लिए क्या कर रहे हैं?

आपके पास यहां मौजूद विकल्प आपकी विशिष्ट बाधाओं पर निर्भर करते हैं।

यदि आपके पास एक नियत समयबाह्य है (अर्थात, यदि आपके लिए यह गारंटी देना संभव है कि अनुरोध _n_ सेकंड से अधिक नहीं लगेगा) तो आप पाइथन मानक पुस्तकालय के साथ आसानी से ऐसा नहीं कर सकते क्योंकि यह आज मौजूद है। पायथन 2.7 में आपको प्रत्येक recv कॉल के लिए अनुक्रमिक टाइमआउट चलाने की अनुमति देने के लिए socket._fileobject पैच करने की आवश्यकता होगी, लेकिन पायथन 3 में यह और भी कठिन है क्योंकि आपको उस वर्ग में पैच करने की आवश्यकता है जिसका कार्यान्वयन सी ( io.BufferedReader ) में है, जो एक दुःस्वप्न होने वाला है।

अन्यथा, इसे प्राप्त करने का एकमात्र तरीका मानक पुस्तकालय में _off_ बफरिंग को चालू करना है। यह httplib और उसके ऊपर हमारे सभी पैच को तोड़ देगा, जो मानते हैं कि हम read(x) कॉल कर सकते हैं जो सॉकेट पर read syscall की तरह व्यवहार नहीं करेगा बल्कि इसके बजाय read # की तरह व्यवहार करेगा किसी फ़ाइल पर

एक और तरीका रखें: यदि आप एक नियतात्मक टाइमआउट _need_ करते हैं, तो आप पाएंगे कि बड़ी संख्या में पुस्तकालय इसे आपके लिए प्रदान करने में असमर्थ हैं। मूल रूप से, यदि वे httplib या socket.makefile का उपयोग करते हैं तो आप भाग्य से बाहर होने जा रहे हैं: यह गारंटी देने का कोई साफ तरीका नहीं है कि बार-बार जारी करने के अलावा परिभाषित समय में नियंत्रण आपको वापस लौटाता है -1 पढ़ता है। आप ऐसा कर सकते हैं, लेकिन यह आपके प्रदर्शन को नुकसान पहुंचाएगा।

तो आपके पास यहां एक ट्रेडऑफ़ है: यदि आप एक नियतात्मक टाइमआउट चाहते हैं, तो जिस तरह से बफ़रिंग को पायथन मानक पुस्तकालय (और इसलिए, अनुरोधों में) में लागू किया गया है, वह आपको उपलब्ध नहीं कराने वाला है। आप बफ़रिंग को अक्षम करके और कोड को फिर से लिखकर इसे वापस प्राप्त कर सकते हैं, लेकिन यह आपके प्रदर्शन को संभावित रूप से काफी बुरी तरह से नुकसान पहुंचाता है जब तक कि आप बफ़रिंग को इस तरह से लागू नहीं करते हैं जो टाइमआउट को स्वीकार करता है।

आप BufferedReader वर्ग में पायथन मानक पुस्तकालय में आवश्यक कोड को लागू करने का लक्ष्य रख सकते हैं: यदि आप रुचि रखते हैं तो आप निश्चित रूप से पायथन लोगों से पूछ सकते हैं। लेकिन मैं अपनी सांस नहीं रोकूंगा।

इसलिए अनुरोधों में प्रयुक्त टाइमआउट तर्क मूल रूप से urllib3 का है, इसलिए यह वहां परिवर्तन करने के लिए पर्याप्त होना चाहिए: एक सुविधा अनुरोध खोलने के लिए स्वतंत्र महसूस करें और हम परिवर्तन के माध्यम से आपकी सहायता कर सकते हैं। और छोटी अवधि में, सेटडिफॉल्टटाइमआउट का उपयोग करके जांच करने के लिए स्वतंत्र महसूस करें।

urllib3 में या यहाँ फ़ीचर अनुरोध? एक (या दोनों) ASAP खोलेगा।

urllib3 में फ़ीचर अनुरोध: हमें अनुरोधों में कुछ भी नया दिखाने की ज़रूरत नहीं है।