2008-09-18 10 views

उत्तर

16

एप्लिकेशन परत (बर्कले सॉकेट शैली एपीआई का उपयोग करके) पर आप घड़ी देखते हैं, और जिस दर पर आप सीमित करना चाहते हैं उस पर डेटा पढ़ या लिखते हैं।

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

आवेदन परत पर आप केवल अनुमानित हो सकते हैं - आप हार्ड सीमाओं की गारंटी नहीं दे सकते हैं जैसे कि "किसी भी एक सेकंड में 10 से अधिक केबी नेटवर्क में किसी दिए गए बिंदु को पास नहीं करेगा"। लेकिन अगर आप जो प्राप्त करते हैं उसका ट्रैक रखते हैं, तो आप लंबे समय तक औसत अधिकार प्राप्त कर सकते हैं।

4

नेटवर्क परिवहन मानते हुए, एक टीसीपी/आईपी आधारित एक, पैकेट को दूसरी तरफ एसीके/नाक पैकेट के जवाब में भेजा जाता है।

आने वाले पैकेट की प्राप्ति को स्वीकार करते हुए पैकेट की दर सीमित करके, आप उस दर को कम कर देंगे जिस पर नए पैकेट भेजे जाते हैं।

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

+0

क्या इसे निम्न-स्तर के टीसीपी/आईपी स्टैक पर जाने की आवश्यकता नहीं है, और मानक सॉकेट परत को छोड़कर? – Branan

1

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

जो धीरे-धीरे पढ़ते हैं वह बफर भरता है, और नेटवर्क अंत में एक अंतिम स्टॉल का कारण बनता है - लेकिन इसका कोई नियंत्रण नहीं है कि यह कैसे होता है या कब होता है।

तुम सच में एक समय में केवल इतना डेटा को पढ़ने के लिए चाहते हैं, आप कुछ इस तरह कर सकते हैं:

ReadFixedRate() { 
    while(Data_Exists()) { 
    t = GetTime(); 
    ReadBlock(); 
    while(t + delay > GetTime()) { 
     Delay()' 
    } 
    } 
} 
+0

बफर के पास अधिकतम मूल्य हैं। कैश? इसमें कोई कैश शामिल नहीं है। –

+0

आप निश्चित रूप से बिल्कुल सही हैं। मैंने कैश सामान हटा दिया, और बफर के बारे में थोड़ा जोड़ा। – Branan

0

wget --limit-दर विकल्प के साथ यह प्रबंधित करने के लिए लगता है। यहाँ आदमी पेज से है:

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

0

जैसा कि अन्य ने कहा है, ओएस कर्नेल यातायात का प्रबंधन कर रहा है और आप बस कर्नेल मेमोरी से डेटा की एक प्रति पढ़ रहे हैं।केवल एक आवेदन की दर को सीमित करने के लिए, आपको डेटा के अपने पढ़ने में देरी करने की आवश्यकता है और आने वाले पैकेट को कर्नेल में बफर करने की अनुमति है, जो अंततः आने वाले पैकेट की पावती को धीमा कर देगा और उस सॉकेट पर दर को कम करेगा।

यदि आप मशीन पर सभी ट्रैफिक धीमा करना चाहते हैं, तो आपको अपने आने वाले टीसीपी बफर के आकारों को समायोजित करने और समायोजित करने की आवश्यकता है। लिनक्स में, आप/proc/sys/net/ipv4/tcp_rmem (मेमोरी बफर आकार पढ़ें) और अन्य tcp_ * फ़ाइलों में मानों को बदलकर इस परिवर्तन को प्रभावित करेंगे।

1

ऐसा लगता है कि एक निश्चित संख्या में एफपीएस को गेम सीमित करते समय।

extern int FPS; 
....  
timePerFrameinMS = 1000/FPS; 

while(1) { 
time = getMilliseconds(); 
DrawScene(); 
time = getMilliseconds()-time; 
if (time < timePerFrameinMS) { 
    sleep(timePerFrameinMS - time); 
} 
} 

इस तरह आप सुनिश्चित करते हैं कि गेम रीफ्रेश दर अधिकतर एफपीएस पर होगी। उसी तरह DrawScene सॉकेट स्ट्रीम में बाइट पंप करने के लिए उपयोग किया जाने वाला फ़ंक्शन हो सकता है।

0

Branan के जवाब देने के लिए जोड़ने के लिए:

आप स्वेच्छा से रिसीवर अंत में पढ़ने की गति को सीमित करते हैं, तो अंत में कतारों दोनों अंत में भर जाएगा। फिर प्रेषक या तो भेजें() कॉल में भेजे गए अपेक्षित लंबाई से कम प्रेषित() कॉल के साथ भेजें() कॉल या प्रेषण() कॉल से वापस आ जाएगा।

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

0

छोटे सॉकेट को सेट करें और बफर प्राप्त करें, 1k या 2k कहें, जैसे कि बैंडविड्थ * देरी उत्पाद = बफर आकार। हो सकता है कि आप तेज़ लिंक पर पर्याप्त छोटा न हो।

संबंधित मुद्दे