तो, मान लें कि मैं एक वेब सर्वर लिख रहा हूं और मैं "बहुत बड़ी" फ़ाइल अपलोड का समर्थन करना चाहता हूं। आइए आगे यह मान लें कि मेरा मानक मल्टीपार्ट/फॉर्म-डेटा एमआईएमई प्रकार के माध्यम से ऐसा करना है। मुझे यह कहना चाहिए कि मैं एरलांग का उपयोग कर रहा हूं और मैं http12ets को इकट्ठा करने की योजना बना रहा हूं क्योंकि उन्हें erlang:decode_packet/2 से वापस कर दिया गया है, लेकिन मैं वास्तव में अनुरोधित सामग्री को एकत्र नहीं करना चाहता जब तक कि http अनुरोध हैंडलर अपलोड की गई सामग्री के लिए नहीं पाया जाता। क्या मुझेमैं एर्लंग वेब सर्वर में बहुत बड़ी फ़ाइल-अपलोड से कैसे निपटूं?
ए) आगे बढ़ना और शरीर को इकट्ठा करना, इसकी बहुत बड़ी संभावना होने की संभावना को अनदेखा करना और संभवतः सर्वर से बाहर निकलने के कारण सर्वर को दुर्घटनाग्रस्त करना चाहिए?
बी) हेडर पर संसाधित होने तक सॉकेट को प्राप्त करने से बचें (संभावित रूप से मौजूद नहीं) अनुरोध निकाय?
सी) कुछ और करें?
उत्तर सी के लिए एक उदाहरण हो सकता है: अपलोड की गई सामग्री को अस्थायी स्थान (स्मृति उपयोग को कम करने के क्रम में) को इकट्ठा करने और लिखने के लिए एक और प्रक्रिया तैयार करें, साथ ही भविष्य में प्रसंस्करण के लिए http अनुरोध हैंडलर को उस स्थान को देकर। लेकिन मुझे नहीं पता - क्या यहां एक मानक तकनीक है?
वैसे, सर्वसम्मति यह प्रतीत होती है कि मानक तरीका यह है कि मैंने विकल्प सी के लिए सुझाव दिया है। फिर भी, मुझे लगता है कि एक बेहतर तरीका होना चाहिए - मुझे अस्थायी फ़ाइलों की अजीबता से परेशान है - उन्हें खोलने के लिए अतिरिक्त एरलांग बंदरगाहों की आवश्यकता होती है (एक बार से अधिक यदि मैं किसी बिंदु पर फ़ाइल को वापस पढ़ने की योजना बना रहा हूं), और वे दो या दो से अधिक प्रक्रियाओं के बीच विभाजित होते हैं जिन्हें मैं एक करके संभालना चाहता हूं। हालांकि, यह है कि मैं क्या करने की योजना बना रहा था - मुझे उम्मीद थी कि कोई भी अलग तरीके से चीजें कर रहा है। – Aoriste
आपको डेटा स्टोर करने की आवश्यकता है। व्यावहारिक रूप से यह स्मृति में या भंडारण डिवाइस पर किया जाता है। आपका सवाल कहता है कि स्मृति एक विकल्प नहीं है; आपकी टिप्पणी कहती है कि आप इसे किसी डिवाइस पर संग्रहीत करना पसंद नहीं करते हैं। एकमात्र शेष विकल्प गूढ़ता है ... – Zed