तो मैं सिर्फ नोड में गोता लगाने शुरू कर रहा हूँ और मैं समझता हूँ कि मैं/हे गैर अवरुद्ध है और वह घटना पाश ब्लॉक कर रहा है लेकिन क्या मैं सोच रहा हूँ:ईवेंट कतार अवरुद्ध होने पर एक Node.js सर्वर इनकमिंग अनुरोध स्वीकार कर सकता है?
आप कोड है, तो जो ब्लॉक कर रहा है घटना कतार, क्या सर्वर अभी भी कतार के अंत में आने वाले अनुरोधों को रखने में सक्षम होगा या उनमें से सभी बस समय/उछाल आएंगे?
इस नोड, या कम से कम इस चर्चा अब तक नोड के व्यवहार का कोई सबूत नहीं परिचय के साथ कोई संबंध नहीं है।
टीसीपी स्टैक स्वयं स्वीकार्य सॉकेट का उपयोग करने वाले प्रोग्राम से सहायता के बिना स्वयं की कतार में कनेक्शन स्वीकार करता है। यदि वह कतार भर जाती है, तो टीसीपी कनेक्शन कतार में स्थान होने तक प्रतीक्षा करने के लिए और अनुरोध किए जाते हैं। इस तरह के "अस्वीकार्य" कनेक्शन बाउंस नहीं किए जाते हैं, हालांकि अगर चीजें वास्तव में देरी हो जाती हैं तो वे समय निकाल सकते हैं।
नीचे की रेखा यह है कि कर्ल का उपयोग करते हुए नमूना उत्तर टीसीपी स्टैक के मूल व्यवहार से परे कुछ भी साबित नहीं करता है, लेकिन शायद इससे कोई फर्क नहीं पड़ता, क्योंकि मूल पोस्टर की चिंता यह थी कि कनेक्शन उछाल सकता है। यह तभी होगा जब आपका सर्वर इतना अधिभारित हो (या शायद बुरी तरह लिखा गया हो) कि यह प्रभावी रूप से ओवरलोड हो गया है, और कुछ अनुरोधों को डंप करना सबसे कम मौका है, कम से कम कुछ उपयोगकर्ताओं को कुछ सेवा प्रदान करना है।
धन्यवाद, मुझे वाकई यह जवाब पसंद है। मुझे टीसीपी स्टैक के बारे में बिल्कुल पता नहीं था –
हां। सर्वर अभी भी अनुरोध कतार में सक्षम है। प्रदर्शित करने के लिए, मैंने निम्न फ़ाइल बनाई जो 10 सेकंड के लिए ब्लॉक करता है, इसे चलाता है, और किसी अन्य टर्मिनल पर सर्वर को कर्ल करता है।
require('http').createServer(function(req, res) {
console.log('got a request!');
res.end('hello world!\n');
}).listen(3000);
var t = Date.now();
console.log('blocking..');
while(t + 10000 > Date.now());
console.log('not blocking anymore');
चलने से परिणाम यह
blocking..
not blocking anymore
got a request!
ठीक है मुझे लगता है कि यह अच्छी तरह से जवाब देता है। मैं सोच रहा हूं कि आने वाले अनुरोधों को अवरुद्ध होने के बाद कतार पर रखा गया था और फिर लॉग इन किया गया था या फिर लॉग इन करने के दौरान कतार पर रखा गया था और फिर 'अनुरोध प्राप्त हुआ' के बाद बाद में निकाल दिया गया था इवेंट लूप फ्री किया गया था। –
यह प्रश्न के अधिक महत्वपूर्ण पहलू का उत्तर देता है, हालांकि आने वाले अनुरोधों में उछाल नहीं आया ... जो मेरी मुख्य चिंता थी। धन्यवाद अच्छा श्रीमान –
यदि I/O वास्तव में async है तो इसे ब्लॉक के दौरान रखा जाना चाहिए था, लेकिन यदि ईवेंट कतार अवरुद्ध है तो मुझे नहीं लगता कि यह और घटनाओं को स्वीकार करने में सक्षम होगा ...जब तक कतार स्वयं एसिंक्रोनस वातावरण में बैठती है और प्रत्येक घटना को अवरुद्ध पर्यावरण में संभाला जाता है ... मुझे लगता है कि प्रश्न मौसम है क्यूई स्वयं एसिंक या अवरुद्ध वातावरण में है ... लेकिन सभी गहन उद्देश्यों के लिए, सवाल है जवाब दे दिया। मैं रात में सो सकता हूँ। –
यह एक अच्छा सवाल है जो Node.js के आंतरिक से परिचित कोई जवाब दे सकता है। मुझे * संदेह है कि '' http'' ऑब्जेक्ट की सी ++ लाइब्रेरी एक अलग थ्रेड में वास्तविक I/O को संभालने में सक्षम है, इसलिए * अनुरोधों को कतारबद्ध करना चाहिए (संभवतः ईवेंट लूप दिए जाने तक कतार में ईवेंट जोड़ना नहीं चाहिए दोबारा नियंत्रण और लंबित घटनाओं का अर्थ और जोड़ा गया है?) –
जो मैंने पढ़ा है, उससे मुझे पता है कि I/O असीमित है, लेकिन संक्षेप में आंतरिक रूप से एसिंक्रोनस प्रोग्रामिंग कैसे काम करता है, मैंने पढ़ा है कि मैंने एसिंक नए धागे को नहीं बढ़ाया है? क्या यह सच है? –
"एसिंक्रोनस प्रोग्रामिंग एकाधिक अनुरोधों को संसाधित करने के लिए एक ही थ्रेड का उपयोग करके बढ़ावा देता है, लेकिन थ्रेड को अवरुद्ध करने के लिए कोई अनुरोध नहीं है, क्योंकि हम बाद में देखेंगे कि अनुरोधों द्वारा किए गए संचालन को" टुकड़ों में "निष्पादित किया जाएगा।" http: // www। theserverside.com/discussions/thread.tss?thread_id=61693 –