क्या मैं नेटवर्किंग में बाइट ऑर्डर को सुरक्षित रूप से अनदेखा कर सकता हूं?

Question

मैं एक सर्वर-क्लाइंट एप्लिकेशन विकसित कर रहा हूं जहां क्लाइंट विंडोज पर चलेगा और सर्वर शायद लिनक्स पर। हो सकता है कि मैं बाद में क्लाइंट को मैक और लिनक्स पर पोर्ट कर दूं, लेकिन अभी तक नहीं।

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

यह सिर्फ अनावश्यक काम है। तो, मेरा सवाल यह है: क्या मैं सुरक्षित रूप से धीरज को अनदेखा कर सकता हूं और बस थोड़ा-सा एंडियन डेटा भेज सकता हूं? नुकसान क्या हैं?

Comments

यदि सामान्य / मानक बड़े-एंडियन डेटा के बजाय छोटे एंडियन डेटा प्राप्त कर रहे हैं, तो मशीन कैसे जानेंगे?

— Ixrec

आपको नेटवर्क प्रोटोकॉल के लिए आवश्यक मेटाडेटा, और पेलोड के बीच अंतर करने की आवश्यकता है, जो आपके कोड को छोड़कर सभी के लिए बिना किसी व्याख्या किए बाइट्स का एक गुच्छा है। मुझे आशा है कि आप अपने खुद के नेटवर्किंग स्टैक को रोल नहीं कर रहे हैं। नतीजतन मुझे लगता है कि सवाल केवल पेलोड के बारे में है, सही है?

@ डेलनान हाँ, केवल पेलोड के बारे में बात कर रहे हैं। मैं अभी भी नेटवर्क-बाइट-ऑर्डर में नेटवर्क-स्टैक से ही बात करूंगा ।

— tkausl

पक्ष में सिर्फ एक विचार: क्या आपके लिए वास्तव में एक अमूर्त स्तर पर काम करना आवश्यक है, जहां धीरज एक चिंता का विषय है? यह प्रोटोकॉल का उपयोग करने पर विचार करने के लिए सार्थक हो सकता है जिसके लिए उपयुक्त पुस्तकालय मौजूद हैं जो इस सभी निम्न-स्तरीय "गड़बड़" को अंजाम देते हैं। फिर, आपके पास अतिरिक्त बोनस भी है जो आगे के ग्राहकों को जोड़कर बहुत आसान हो सकता है।

— गॉडफादरफॉल्का

@tkausl पक्ष में सिर्फ दो और विचार: एक सामान्य नियम के रूप में, IO अभिकलन की तुलना में बहुत धीमा है, इसलिए किसी भी उपरि एक उच्च अमूर्त स्तर पर काम करके शुरू की गई सबसे अधिक संभावना नगण्य है। यह भी हो सकता है कि कुछ पुस्तकालयों ने चतुर संसाधन पूलिंग और अतुल्यकालिक हैंडलिंग आदि के कारण कार्यान्वयन को नियंत्रित किया हो .. इसलिए, मैं पहले मौजूदा समाधानों का सावधानीपूर्वक मूल्यांकन करूंगा। इसके अलावा, आपके विवरण को देखते हुए, मैं प्रदर्शन के बजाय मापनीयता पर कुछ विचार भी खर्च करूंगा, यहां आप उच्च-स्तर के प्रोटोकॉल का उपयोग करने से फिर से लाभान्वित हो सकते हैं।

— गॉडफादरऑफोलका

Answer 1

... मैं बाइट्स को पुनर्व्यवस्थित क्यों करूँगा ... जब मुझे पहले से ही पता है कि दोनों, सर्वर और क्लाइंट थोड़ा एंडियन पर चलते हैं? Thats सिर्फ अनावश्यक काम करने के लिए।

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

एक नेटवर्क-मानक बाइट ऑर्डर है। यह बड़ा-एंडियन है, लेकिन कुछ भी नहीं कहता है कि आपको अपने प्रोटोकॉल को डिजाइन करते समय इसका पालन करना होगा। यदि आप समय से पहले जानते हैं कि आपके कोड को चलाने वाली अधिकांश प्रणालियाँ थोड़ी-सी होंगी और प्रदर्शन महत्वपूर्ण है, तो घोषित करें कि "tkausl standard byte order" और उसके साथ जाएं। जहाँ आप सामान्य रूप htons()से अपनी आवश्यकता के अनुसार सामान रखने के लिए कहेंगे , वहीं एक मैक्रो लिखिए htots()जो सशर्त रूप से छोटे-से-एंडियन आर्किटेक्चर पर कुछ भी करने के लिए संकलित करता है और बड़े-एंडियन पर फिर से व्यवस्था करता है।

इनबाउंड और आउटबाउंड रूपांतरण करने के लिए कोड बनाए रखना वास्तव में एक बड़ा प्रयास नहीं है। यदि आपके पास बहुत बड़ी संख्या में संदेश हैं, तो उन्हें व्यक्त करने का एक तरीका खोजें और इनबाउंड और आउटबाउंड रूपांतरण उत्पन्न करने के लिए एक कार्यक्रम लिखें।

Comments

शब्दांकन when designing your protocolमहत्वपूर्ण है, क्योंकि यह भी स्पष्ट रूप से कहता है कि यह विकल्प केवल एक नया प्रोटोकॉल डिजाइन करते समय मौजूद है और कुछ मौजूदा प्रोटोकॉल को लागू करते समय नहीं। और htots(और वास्तव में फ़ंक्शंस के एक पूरे परिवार) की आवश्यकता का उल्लेख करते हुए , यह भी स्पष्ट करता है कि एक अलग बाइट ऑर्डर को चुनना कुछ ऐसा नहीं है जो कोड को सरल बनाने के लिए करता है, लेकिन यह इसे थोड़ा तेज़ कर सकता है।

— कैस्परड

वहाँ (अमानक लेकिन बहुत आम इन दिनों) कार्य हैं htole32(), htole16(), le16toh(), आदि, कार्य अच्छी तरह के रूप में उपलब्ध। इन घोषित को शामिल करने के लिए फाइल दुर्भाग्य से भी कम मानक है: <endian.h>या <sys/types.h>प्लेटफॉर्म पर निर्भर करता है।

— torek

यह उत्तर ठीक है, लेकिन मुझे लगता है कि यह धारणा कि प्रदर्शन महत्वपूर्ण हो सकता है दिए गए मामले में शायद सबसे गलत धारणा है, तथ्यों की तुलना में अंधविश्वास पर आधारित है।

— डॉक ब्राउन

@DocBrown: मैं हमेशा यह बताना चाहता हूं कि एक्स प्रोटोकॉल ने 30 वर्षों के लिए अपने स्वयं के बाइट ऑर्डर को चुनने का समर्थन किया है, और जब तक संसाधन वापस आ चुके थे, तब किसी ने भी शिकायत नहीं की कि यह एक समस्या थी।

— ब्लरफ्ल

Answer 2

यह आपका प्रोटोकॉल है।

आप इसे सुरक्षित रूप से अनदेखा नहीं कर सकते। लेकिन आप इसे सुरक्षित रूप से लेबल कर सकते हैं। आप क्लाइंट और सर्वर को नियंत्रित करते हैं। आप प्रोटोकॉल को नियंत्रित करते हैं। क्या यह समझ में नहीं आता है कि क्या यह परवाह नहीं है कि यह बड़े-एंडियन या छोटे-एंडियन हैं, जब तक आप जानते हैं कि दोनों पक्ष सहमत हैं या नहीं?

इसका मतलब ओवरहेड है। अब आपको किसी तरह अपने अंतर्मन को चिह्नित करना होगा। ऐसा करो, और मैं इसे कुछ भी पढ़ सकता हूं।

यदि आप डेटा ओवरहेड नहीं चाहते हैं, और आपका सीपीयू ऊब गया है और कुछ करने की तलाश में है, तो अनुरूप करें ।

Answer 3

तो, मेरा सवाल यह है: क्या मैं सुरक्षित रूप से धीरज को अनदेखा कर सकता हूं और बस थोड़ा-सा एंडियन डेटा भेज सकता हूं?

इसकी दो व्याख्याएँ हैं:

• यदि आप अपने एप्लिकेशन / प्रोटोकॉल को हमेशा ¹ -एंडियन भेजते हैं, तो आप एंडियन की अनदेखी नहीं कर रहे हैं।

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

  क्या वह "सुरक्षित" ^{2 है} ? यह आपके लिए न्याय करने के लिए है! लेकिन निश्चित रूप से आम हार्डवेयर प्लेटफॉर्म हैं जो छोटे-एंडियन, बड़े-एंडियन या ... द्वि-एंडियन का उपयोग करते हैं।

  संदर्भ:

  • https://en.wikipedia.org/wiki/Endianness#Hardware

नुकसान क्या हैं?

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

स्पष्ट रूप से, अधिकांश वर्तमान पीढ़ी के प्लेटफ़ॉर्म मूल रूप से छोटे-एंडियन हैं, लेकिन 1) कुछ नहीं हैं, और 2) हम केवल अनुमान लगा सकते हैं कि भविष्य में क्या होगा।

---

^{1 - हमेशा ... उन प्लेटफार्मों पर शामिल है जो मूल रूप से बड़े-एंडियन हैं।}

^{2 - वास्तव में, "सुरक्षित" का क्या अर्थ है? यदि आप हमसे हार्डवेयर प्लेटफार्मों की भविष्य की दिशा की भविष्यवाणी करने के लिए कह रहे हैं ... तो मुझे डर है कि यह उद्देश्यपूर्ण उत्तर देने योग्य नहीं है।}

Answer 4

अंतःकरण केवल विचार नहीं है। पूर्णांकों का आकार है, वहाँ संरचनाओं की पैकिंग है जिसे आप भेजना चाहते हैं या प्राप्त कर सकते हैं, और इसी तरह।

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

आमतौर पर यह ज्यादा कोड नहीं है। लेकिन इसका बहुत बड़ा लाभ है: आपके कोड को पढ़ने वाले लोगों को संदेह नहीं होगा कि आप कुलीन हैं, बाहरी डेटा को इंटरचेंज करने के बारे में कुछ भी नहीं जानते हैं, और कोड लिखते हैं जो आमतौर पर भरोसा नहीं किया जा सकता है।

Answer 5

सी में मानक बीएसडी नेटवर्किंग स्टैक में hton/ ntohकार्यक्षमता ( network-to-host/ host-to-network) है जो नेटवर्क-देशी मशीनों (बड़े एंडियन) पर नो-ऑप तक विस्तारित होती है। आपको अपने स्वयं के समकक्षों की आवश्यकता होगी इस परिदृश्य के लिए जिसमें नेटवर्क-मूल बाइट ऑर्डर थोड़ा एंडियन है।

ऐसा करने का यह मजबूत तरीका है।

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

Answer 6

सर्वरों के बीच डेटा संचारित करने के लिए उपयोग किए जाने वाले विभिन्न प्रोटोकॉल कम एंडियन संख्याओं का उपयोग करते हैं:

1. BSON
2. प्रोटोकॉल बफ़र्स
3. कैपन प्रोटो

विभिन्न स्वरूपों के विवरणों के लिए https://en.wikipedia.org/wiki/Comparison_of_data_serialization_formats देखें , जिनमें से कुछ के पास छोटे-एंडियन नंबर हैं, और कुछ के पास बड़े-एंडियन नंबर हैं।

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

यदि आप इन मौजूदा प्रोटोकॉल में से किसी एक पर अपने प्रोटोकॉल का निर्माण करते हैं, तो आपको इस मुद्दे के बारे में चिंता करने की ज़रूरत नहीं है, इसका पहले से ही ख्याल रखा गया है। जब आप अपने कोड को बड़े-एंडियन प्लेटफ़ॉर्म पर चलाने का निर्णय लेते हैं, तो इन प्रोटोकॉल को लागू करने वाले पुस्तकालय स्वचालित रूप से यह सुनिश्चित करने का ध्यान रखेंगे कि आप मूल्यों को सही ढंग से डिकोड करें।

Answer 7

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

तो यह निर्भर करता है कि आप 'लिनक्स' से क्या मतलब रखते हैं, लेकिन यदि आप कभी भी अपने सर्वर ऐप को राउटर जैसे छोटे सिस्टम पर चलाना चाहते हैं तो OpenWRT चल रहा है तो आपको बड़े एंडियन समर्थन पर विचार करना पड़ सकता है।

हमेशा की तरह, मान्यताओं को सरल बनाना एक पूर्ण समझदार अनुकूलन है जब तक कि आप उस चीज को नहीं मारते हैं जो मान्यताओं को फिट नहीं करता है। केवल आप कह सकते हैं कि यदि आप कभी भी ऐसी समस्या में आते हैं, तो उन्हें खोलना कितना दर्दनाक होगा।

Answer 8

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

चलो 4 बाइट्स लेते हैं और उन्हें एक इंट के रूप में व्याख्या करते हैं। एक छोटे से एंडियन सिस्टम बाइट्स को एक बड़े एंडियन सिस्टम पर राइट-टू-लेफ्ट और वाइस-वर्का से व्याख्या किया जाएगा। जाहिर है कि एक अंत की व्याख्या के लिए सहमत होना महत्वपूर्ण है।

आधुनिक नेटवर्क प्रोटोकॉल के लिए थोड़ा सा ज़ूम आउट करें जो कि json या xml का उपयोग कर सकता है। उन स्वरूपों में से कोई भी 4 बाइट्स के रूप में एक इंट ट्रांसफर नहीं करेगा। वे डेटा को पाठ के रूप में स्थानांतरित करेंगे जो प्राप्त पक्ष पर एक इंट के रूप में पार्स किया जाएगा।

तो अंत में जबसन या xml का उपयोग करते समय कोई फर्क नहीं पड़ता। हमें अभी भी टीसीपी हेडर के लिए बड़े एंडियन का उपयोग करने की आवश्यकता है, यही वजह है कि इसे नेटवर्क बाइट ऑर्डर कहा जाता है, लेकिन अधिकांश प्रोग्रामर को दैनिक आधार पर गड़बड़ करने की आवश्यकता नहीं होती है।

सबसे व्यापक रूप से इस्तेमाल किया जाने वाला एन्कोडिंग आज utf-8 है, जो एंडियननेस के बारे में समस्याओं के प्रति भी खुश है ।

तो मैं कहूँगा हाँ। यूटीएफ -8 का उपयोग करके हस्तांतरित पाठ आधारित प्रारूपों का उपयोग करते समय धीरज की उपेक्षा करना सुरक्षित है।

Comments

दो वोट नीचे और कोई टिप्पणी नहीं। महान।

— एबेन स्कोव पेडरसन 6

मैं नीच नहीं था लेकिन यह जवाब पूरी तरह से वैध सवाल को नजरअंदाज / खारिज कर रहा है। सिर्फ इसलिए कि कुछ प्रोटोकॉल पाठ आधारित हैं इसका मतलब यह नहीं है कि सभी प्रोटोकॉल होने चाहिए।

— पीटर ग्रीन

मैंने इसे उकेरा क्योंकि यह इस तथ्य को छूता है कि पेलोड प्रारूप का अंतर्निहित प्रोटोकॉल से कोई लेना-देना नहीं है। कुछ लोगों को सिर्फ बनी-बनाई समस्याओं में खोदना पसंद होता है।

— Zdenek

Answer 9

बिग एंडियन सिस्टम अपने तरीके से बाहर हो रहे हैं। कई पारंपरिक यूनिक्स ने बड़े एंडियन का इस्तेमाल किया लेकिन वे x86 पर लिनक्स के पक्ष में वर्षों से गिरावट में हैं।

हाथ द्वि-एंडियन है लेकिन बड़े एंडियन संस्करण को शायद ही कभी देखा जाता है।

दोनों वेरिएंट में कूल्हे मौजूद हैं। Afaict बड़ा एंडियन संस्करण ज्यादातर नेटवर्किंग एप्लिकेशन (ऐतिहासिक कारणों से इंटरनेट प्रोटोकॉल आमतौर पर बड़े एंडियन का उपयोग करता है) पर देखा जाता है।

पीपीसी परंपरागत रूप से दोनों एंडियन का समर्थन करने वाले कुछ हिस्सों के साथ बड़ा एंडियन था लेकिन आईबीएम अब 64-बिट पीपीसी के लिए थोड़ा एंडियन मोड को आगे बढ़ा रहा है (उन्होंने हाल ही में पीपीसी64 पोर्ट को डेबियन और उबंटू में धकेल दिया है)।

स्पार्क सामान्य रूप से बड़ा एंडियन होता है लेकिन फिर से गिरावट में लगता है।

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

आप या तो शुरू से मैक्रोज़ में डाल सकते हैं जो कि छोटे एंडियन सिस्टम पर नो-ऑप्स होंगे या आप तब तक परेशान नहीं कर सकते हैं जब तक कि / आपको एक बड़े एंडियन सिस्टम को पोर्ट करने की आवश्यकता न हो।