धीमा/लगी विंडोज़ फोन 7 (WP7) टीसीपी सॉकेट ट्रांसमिशन कैसे करें?

Question

हाल ही में, मैंने WP.N की आम रिलीज में पेश की गई System.Net.Sockets क्लास का उपयोग करना शुरू कर दिया है और आम तौर पर इसका आनंद ले रहा है, लेकिन सामान्य रूप से फोन पर चल रहे डीबग मोड बनाम डेटा में डेटा ट्रांसमिट करने की विलंबता में असमानता देखी है।

मैं एक "रिमोट कंट्रोल" ऐप लिख रहा हूं जो वाईफाई के माध्यम से मेरे लैन पर एक स्थानीय सर्वर पर एक बाइट ट्रांसमिट करता है क्योंकि उपयोगकर्ता ऐप में एक बटन टैप करता है। एर्गो, एप की कथित प्रतिक्रिया/समयबद्धता एक अच्छे उपयोगकर्ता अनुभव के लिए बेहद महत्वपूर्ण है।

यूएसबी केबल के माध्यम से अपने पीसी से जुड़े फोन और डीबग मोड में ऐप चलाने के साथ, टीसीपी कनेक्शन जैसे ही उपयोगकर्ता बटन टैप करता है, पैकेट को ट्रांसमिट करने लगता है।

पीसी से डिस्कनेक्ट किए गए फोन के साथ, उपयोगकर्ता 7 बटन तक टैप कर सकता है (और इस प्रकार सभी 7 बाइट भेजे जाने से पहले 1 बाइट पेलोड के साथ केस 7 "भेजें"।) यदि उपयोगकर्ता एक बटन टैप करता है और इंतजार करता है नल के बीच थोड़ा, 1 सेकंड की विलंबता प्रतीत होता है।

मैंने सेटिंग सॉकेट की कोशिश की है.नहीं सही और गलत दोनों के लिए, और ऐसा कोई फर्क नहीं पड़ता।

यह देखने के लिए कि क्या चल रहा था, मैंने पैकेट स्निफर का उपयोग किया ताकि यह देखने के लिए कि ट्रैफ़िक कैसा दिख रहा था।

• जब फोन पीसी (जो एक वाईफाई कनेक्शन का उपयोग कर रहा था) को USB के माध्यम से जुड़ा हुआ था, प्रत्येक व्यक्ति बाइट अपने स्वयं के पैकेट में था अलग ~ 200 मि.से स्थान दिया गया है जा रहा है।

• जब फोन अपने स्वयं के वाईफाई कनेक्शन (यूएसबी से डिस्कनेक्ट) पर काम कर रहा था, बाइट्स के पास अभी भी अपने पैकेट थे, लेकिन वे सभी 4 या 5 पैकेट के विस्फोटों में एक साथ समूहित हुए थे और प्रत्येक समूह ~ 1000ms से अलग था अगला।

बीटीडब्ल्यू, सर्वर पर मेरे वाईफाई नेटवर्क पर पिंग टाइम्स मेरे लैपटॉप से ​​मापा जाने वाला कम 2ms है।

मुझे एहसास है कि बफरिंग "भेजता है" शायद फोन को ऊर्जा बचाने की अनुमति देता है, लेकिन क्या इस "देरी" को अक्षम करने का कोई तरीका है? ऐप की प्रतिक्रिया शक्ति बचाने से अधिक महत्वपूर्ण है।

Answer 1

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

Answer 2

यह वास्तव में एक दिलचस्प सवाल है! मैं अपने 2 सेंट फेंकने जा रहा हूं लेकिन कृपया सलाह दीजिए, मैं WP7 पर System.Net.Sockets पर एक विशेषज्ञ नहीं हूं।

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

यदि आपको संदेह है कि पैकेट buffered किया जा रहा है (और यह एक उचित धारणा है), तो क्या आपने एक बड़ा पैकेट भेजने की कोशिश की है?पैकेट आकार और मापने विलंबता को रैखिक रूप से बढ़ाने का प्रयास करें। क्या आप उपकरण पर कोड में एक साधारण माइक्रो-प्रोफाइलर लिख सकते हैं यानी: विलंबता बनाम पैकेट आकार को लॉग करने के लिए डेटटाइम.अब या स्टॉपवॉच क्लास का उपयोग करना। उस ग्राफ को प्लॉट करने से आपको कुछ अच्छी अंतर्दृष्टि मिल सकती है कि आपका सिद्धांत सही है या नहीं। यदि आपको लगता है कि 10 बाइट (या यहां तक ​​कि 100byte) पैकेट तुरंत भेजे जाते हैं, तो मैं सुझाव देता हूं कि प्रति ट्रांसमिशन अधिक डेटा दबाएं। यह एक लंगड़ा हैक मुझे पता है, लेकिन अगर यह टूट गया तो ...

अंत में आप कहते हैं कि आप टीसीपी का उपयोग कर रहे हैं। क्या आप इसके बजाय UDP आज़मा सकते हैं? टीसीपी रीयल-टाइम संचार के लिए डिज़ाइन नहीं किया गया है, बल्कि सटीक संचार है। इसके विपरीत यूडीपी त्रुटि की जांच नहीं है, आप डिलीवरी की गारंटी नहीं दे सकते हैं लेकिन आप इससे तेज (अधिक हल्के, कम विलंबता) प्रदर्शन की उम्मीद कर सकते हैं। स्काइप और ऑनलाइन गेमिंग जैसे नेटवर्क यूडीपी पर टीसीपी नहीं बने हैं। यदि आपको वास्तव में रसीद की पावती की आवश्यकता है तो आप त्रुटि जांच और Request/Response (acknowledgement) protocol के लिए अपने Cyclic Redundancy Check का उपयोग करके, हमेशा यूडीपी पर अपना स्वयं का माइक्रो-प्रोटोकॉल बना सकते हैं।

ऐसे प्रोटोकॉल मौजूद हैं, में चर्चा की गई Reliable UDP पर एक नज़र डालें। आरयूडीपी के जावा आधारित कार्यान्वयन के बारे में है, लेकिन मुझे यकीन है कि कुछ हिस्सों को सी # पर पोर्ट किया जा सकता है। निश्चित रूप से पहला कदम यह जांचना है कि क्या यूडीपी वास्तव में मदद करता है!

---

इस पिछले प्रश्न को मिला जो इस मुद्दे पर चर्चा करता है। शायद एक डब्ल्यूपी 7 मुद्दा? Poor UDP performance with Windows Phone 7.1 (Mango)

फिर भी देखने के लिए दिलचस्पी होगी अगर पैकेट आकार में वृद्धि या UDP का उपयोग करने जा काम करता है

---

ठीक तो न सुझाव काम किया। मुझे नागल एल्गोरिदम का यह विवरण मिला जो आपके वर्णन के रूप में पैकेट समूह करता है। नोडेले को सेट करने में मदद की जानी चाहिए लेकिन जैसा कि आप कहते हैं, नहीं।

http://msdn.microsoft.com/en-us/library/system.net.sockets.socket.nodelay.aspx

इसके अलावा

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

Socket "Flush" by temporarily enabling NoDelay

Answer 3

ध्वनि अपने पढ़ता की तरह/राईट बफ़र कर रहे हैं। आप सॉकेट पर नोडेले प्रॉपर्टी को सत्य पर सेट करने का प्रयास कर सकते हैं, आप भेजें और प्राप्त बफर आकार को ट्रिम करने पर विचार कर सकते हैं। कम प्रतिक्रियाशीलता वाईफाई यातायात नहीं होने के उप-उत्पाद हो सकती है, मुझे यकीन नहीं है कि एमटीयू समायोजित करना एक विकल्प है, लेकिन एमटीयू को कम करने से प्रतिक्रिया समय में सुधार हो सकता है।

ये सभी निम्न बैंडविड्थ समाधान के लिए केवल विकल्प हैं, यदि आप किसी भी दिशा में डेटा के मेगाबाइट्स को फावड़ा करना चाहते हैं तो आप वाईफ़ाई पर बड़े बफर चाहते हैं, ट्रांसमिट विलंबता की क्षतिपूर्ति करने के लिए काफी बड़ा, आमतौर पर 32 के दायरे में -256K।

var socket = new System.Net.Sockets.Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp) 
    { 
     NoDelay = true, 
     SendBufferSize = 3, 
     ReceiveBufferSize = 3,     
    }; 

मैंने इसका परीक्षण नहीं किया, लेकिन आपको यह विचार मिलता है।

Answer 4

एंड्रयू बर्नेट-थॉम्पसन ने पहले ही इसका उल्लेख किया है, लेकिन उन्होंने यह भी लिखा है कि यह आपके लिए काम नहीं करता है। मुझे समझ में नहीं आता और मैं क्यों नहीं देखता। तो, मुझे उस मुद्दे को समझाएं:

नागल का एल्गोरिदम एक परिदृश्य से बचने के लिए पेश किया गया था जहां एक छोटे से पैकेट को टीसीपी नेटवर्क के माध्यम से भेजा जाना था। कोई भी मौजूदा अत्याधुनिक टीसीपी स्टैक डिफ़ॉल्ट रूप से नागल के एल्गोरिदम को सक्षम बनाता है!

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

नागल के एल्गोरिदम और इसकी पृष्ठभूमि का एक बेहतर स्पष्टीकरण found on Wikipedia हो सकता है।

तो, आपका पहला प्रयास: सॉकेट पर विकल्प TCP_NODELAY सेट करके, अपने टीसीपी कनेक्शन पर नागल के एल्गोरिदम को अक्षम करें। क्या इससे पहले ही आपकी समस्या हल हो गई है? क्या आप बिल्कुल कोई फर्क देखते हैं?

यदि ऐसा नहीं है, तो मुझे एक संकेत दें, और हम विवरण में आगे खोदेंगे।

लेकिन कृपया, उन मतभेदों के लिए दो बार देखें: विवरण जांचें। हो सकता है कि आप सभी के बारे में समझ लेंगे कि आपके ओएस के टीसीपी/आईपी-स्टैक में चीजें वास्तव में कैसे काम करती हैं।

Answer 5

क्या आपने SendBufferSize = 0 को सेट करने का प्रयास किया है? 'सी' में, आप SO_SNDBUF को 0 पर सेट करके विंसॉक बफरिंग को अक्षम कर सकते हैं, और मुझे लगता है कि SendBufferSize का अर्थ है C#

Answer 6

क्या आप किसी भी मौके से लुमिया 610 और माइक्रोटिक एक्सेसपॉइंट का उपयोग कर रहे थे?

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

आप अभी भी समस्या को दोहराने कर सकते हैं, मैं निम्नलिखित की कोशिश कर सुझाव देते हैं:

• पृष्ठभूमि में एक और कनेक्शन खोलने और यह सब समय पिंग।
• उपयोग 3 जी/वाईफ़ाई के बजाय GPRS (इंटरनेट के लिए अपने सर्वर को उजागर करना आवश्यक है)
• उपयोग दूसरे (या अपग्रेड किए गए) फोन
• उपयोग दूसरे (या अपग्रेड किए गए) एपी