मुझे आश्चर्य है कि बाइनरी और टेक्स्ट आधारित प्रोटोकॉल के बीच मतभेद क्या हैं। मैंने पढ़ा है कि बाइनरी प्रोटोकॉल प्रक्रिया के लिए अधिक कॉम्पैक्ट/तेज हैं। यह कैसे काम करता है? चूंकि आपको समान मात्रा में डेटा भेजना है? नहीं?द्विआधारी बनाम पाठ प्रोटोकॉल
ई.g बाइनरी प्रारूप में स्ट्रिंग "हैलो" आकार में भिन्न कैसे होगा?
धन्यवाद
यदि आप जो भी कर रहे हैं वह टेक्स्ट ट्रांसमिट कर रहा है, तो हाँ, दोनों के बीच का अंतर बहुत महत्वपूर्ण नहीं है। लेकिन चीजों को प्रेषित करने की कोशिश करने पर विचार करें:
स्ट्रिंग "हैलो" आकार में भिन्न नहीं होगी। आकार/प्रदर्शन अंतर अतिरिक्त जानकारी में है जो सीरियलाइजेशन प्रस्तुत करता है (सीरियलाइजेशन यह है कि प्रोग्राम डेटा को स्थानांतरित करने के लिए कैसे प्रतिनिधित्व करता है ताकि इसे पाइप के दूसरे छोर पर पहुंचने के बाद फिर से गठित किया जा सके)।
उदाहरण के लिए, जब एक्सएमएल (पाठ क्रमबद्धता तरीकों में से एक) का उपयोग कर serializing .NET में निम्नलिखित:
string helloWorld = "Hello World!";
आप की तरह कुछ मिल सकता है (मैं जानता हूँ कि यह सटीक नहीं है):
<helloWorld type="String">Hello World!</helloWorld>
जबकि बाइनरी सीरियलाइजेशन सभी अतिरिक्त मार्कअप के बिना बाइनरी में मूल रूप से उस डेटा का प्रतिनिधित्व करने में सक्षम होगा।
आप इस तरह भेजने के लिए "हैलो" एक प्रोटोकॉल संदेश में ASN.1 और संख्या का उपयोग करते हैं:
ProtocolMessage ::= String
;
तो 1 बाइट इसके पहचानकर्ता octer एन्कोड करने के लिए ले जाता है, 1 बाइट लंबाई एन्कोड करने के लिए ले जाता है और "हैलो" का यूटीएफ -8 एन्कोडिंग एक और 5 बाइट है। तो परिणाम संदेश 7 बाइट्स है। यदि आप नियंत्रण बिट्स/बाइट्स
उपयोग कर रहे हैं यानी बजाय संदेश भेजने
द्विआधारी प्रोटोकॉल बेहतर हैं: हैलो बाइनरी में यह 0x01 अपने संदेश के बाद हो सकता है (यह मानते हुए 0x01 एक नियंत्रण बाइट जो संदेश के लिए खड़ा है)
तो, के बाद से पाठ प्रोटोकॉल में आप संदेश भेजने: हैलो \ 0 ... यह 10 बाइट्स जहां के रूप में द्विआधारी प्रोटोकॉल में यह 0x01Hello \ 0 होगा ... इस शामिल 7 बाइट्स
और एक और उदाहरण शामिल , मान लीजिए कि आप एक संख्या 255 कहें, पाठ में 3 बाइट जहां बाइनरी में 1 बाइट i.e 0xFF
बड़े इंटीजर का समर्थन करने के लिए यह आमतौर पर 4 कच्चे बाइट्स (0x0000_00FF) होगा, और आपको आमतौर पर पाठ प्रोटोकॉल में डिलीमीटर की गणना करनी होगी, कम से कम 4 बाइट भी देनी चाहिए ("255" + 1)। –
@ रोगर पाट: बिंदु यह है कि बाइनरी प्रोटोकॉल में * संभावित रूप से * पाठ प्रोटोकॉल की तुलना में एक उच्च एन्ट्रॉपी है। अगर मुझे पता था कि संख्या 1 और 255 के बीच है तो मैं इसे एन्कोड करने के लिए एक पूर्णांक का उपयोग क्यों करूं? मैं आपके उदाहरण को चारों ओर भी बदल सकता हूं: यदि वास्तव में बड़ी संख्या की आवश्यकता है (उदा। 1 से 4,294,967,295 से पूर्णांक) तो 99 9 से बड़ा कोई भी संख्या 4 बाइट्स के बजाय 32 निश्चित बिट्स के साथ अधिक कुशलता से एन्कोड किया जा रहा है। – Caffeine
@ कैफीन: जैसा कि दिखाया गया है, मैं "बाइट" का उपयोग "8 बिट्स" के रूप में कर रहा हूं, इसलिए 32 बिट्स 4 बाइट्स के समान हैं। –
मैं यह नहीं कहूंगा कि द्विआधारी प्रारूप प्रक्रिया के लिए अधिक तेज़ हैं। यदि आपके पास सीएसवी या फिक्स्ड-फील्ड-लम्बाई टेक्स्टुअल प्रारूप है तो यह अभी भी संसाधित हो सकता है।
मैं कहूंगा, सब कुछ इस बात पर निर्भर करता है कि उपभोक्ता कौन है।यदि इंसान अंत में है (जैसे HTTP या आरएसएस के लिए), तो डेटा को कॉम्पैक्ट करने की आवश्यकता नहीं है, सिवाय इसके कि इसे संपीड़ित किया जा सके।
बाइनरी प्रोटोकॉल को पार्सर्स/कन्वर्टर्स की आवश्यकता होती है, जो विस्तार करना मुश्किल होती है और पिछड़े संगतता को बनाए रखती है। जितना अधिक आप प्रोटोकॉल स्टैक में जाते हैं, उतना अधिक मानवीय उन्मुख प्रोटोकॉल होते हैं (टीसीपी द्विआधारी है, क्योंकि पैकेट को उच्च गति पर राउटर द्वारा संसाधित किया जाना चाहिए, लेकिन एक्सएमएल अधिक मानव-अनुकूल है)।
मुझे लगता है कि आकार भिन्नता आज बहुत मायने रखती नहीं है। आपके उदाहरण के लिए, hello समान प्रारूप को टेक्स्ट प्रारूप में बाइनरी प्रारूप में ले जाएगा, क्योंकि पाठ प्रारूप कंप्यूटर के लिए "बाइनरी" भी है - केवल डेटा मामलों को समझने के तरीके के रूप में।
-1 बाइनरी प्रारूप प्रक्रिया के लिए बहुत तेज हो सकता है क्योंकि वे मशीन के प्रतिनिधित्व से काफी बेहतर मिलान कर सकते हैं। HTTP कंप्यूटर-टू-कंप्यूटर संचार के साथ-साथ कंप्यूटर-टू-मशीन के लिए भी उपयोग किया जाता है। बाइनरी प्रोटोकॉल (कर सकते हैं) पाठ प्रोटोकॉल की तुलना में पार्सर्स/कन्वर्टर्स के लिए कम आवश्यकता है। जितना अधिक आप प्रोटोकॉल स्टैक में जाते हैं, उतना अधिक ** अमूर्त ** प्रोटोकॉल मानव-केंद्रित नहीं होते हैं। और बाइनरी को मानवीय उन्मुख के रूप में माना जा सकता है बशर्ते आपके पास एक अच्छा पाठक हो (जीआईएफएफ या जेपीजी के बारे में क्या)। आकार भिन्नता काफी मायने रख सकती है - मोबाइल उपकरणों और मोबाइल वेब के बारे में सोचें। – MarkJ
यह इतने सारे स्तरों पर गलत है कि यह मजेदार भी नहीं है –
आपको प्रोटोकॉल का हिस्सा क्या है और डेटा का हिस्सा क्या है, इस बारे में स्पष्ट होना चाहिए। टेक्स्ट प्रोटोकॉल बाइनरी डेटा भेज सकते हैं और बाइनरी प्रोटोकॉल टेक्स्ट डेटा भेज सकते हैं।
प्रोटोकॉल संदेश का हिस्सा है "हाय क्या मैं कनेक्ट कर सकता हूं? मुझे कुछ डेटा मिला है, मुझे इसे कहां रखना चाहिए ?, आपको मेरे लिए जवाब मिला है? बढ़िया! धन्यवाद, अलविदा!" मुझे यकीन है कि आप के अनुक्रम के साथ आ सकता है
अगर आप एक एन्कोडिंग मानक था:
रूपांतरण के प्रत्येक बिट है (शायद) एक द्विआधारी प्रोटोकॉल में बहुत छोटे, उदाहरण के लिए HTTP ले लो (जो पाठ आधारित है) वर्ण छोटे हैं कि 'पुश' शब्द के लिए आवश्यक 4 बाइट्स
दूसरी ओर, 3 बाइट छोटे "बहुत छोटे" नहीं हैं। हां, यह जोड़ सकता है, लेकिन कभी-कभी लोग संभावित 75% बचत से उत्साहित हो जाते हैं और आगे नहीं देखते हैं। (और रिकॉर्ड के लिए, मैं इस बार कुछ बार दोषी रहा हूं।) –
पाठ प्रोटोकॉल पठनीयता, पुन: कार्यान्वयन में आसानी, और डिबगिंग में आसानी के मामले में बेहतर हैं। बाइनरी प्रोटोकॉल अधिक कॉम्पैक्ट हैं।
हालांकि, आप अपने पाठ LZO या Zlib की तरह एक पुस्तकालय का उपयोग कर सेक कर सकते हैं, और इस लगभग के रूप में कॉम्पैक्ट बाइनरी के रूप में है (संपीड़न/विसंपीड़न के लिए बहुत कम प्रदर्शन हिट के साथ।)
आप के बारे में अधिक जानकारी पढ़ सकते हैं यहां विषय:
http://www.faqs.org/docs/artu/ch05s01.html
आप बाइनरी डेटा को भी संपीड़ित कर सकते हैं। टेक्स्ट gzipped के रूप में संख्याओं को प्रेषित करना शुद्ध संख्या से धीमा तरीका है। – bokan
बाइनरी या टेक्स्ट आधारित प्रोटोकॉल चुनने के लिए एक और दिलचस्प सवाल _when_ होगा, यानी उनके सामान्य (डी) फायदे क्या हैं। मैक्स ई के जवाब में लिंक यहां सहायक है। –
यह एक और दिलचस्प सवाल है जब आप पहले से ही बाइनरी और टेक्स्ट प्रोटोकॉल के बीच का अंतर जानते हैं, लेकिन मेरे जैसे लोग अभी भी इसे सीखना चाहते हैं :) –
संभावित डुप्लिकेट [बाइनरी प्रोटोकॉल मृत हैं?] (Http: // stackoverflow .com/प्रश्न/2525188/हैं-बाइनरी-प्रोटोकॉल-मृत) –