पूरी तरह से समझने के लिए कि डुप्लेक्स बेमेल क्यों होता है, आपको यह समझने की आवश्यकता है कि तकनीक कैसे विकसित हुई।
मूल रूप से, सभी ईथरनेट आधे-द्वैध थे। जब पूर्ण-द्वैध चित्र में प्रवेश किया, तो किसी ने समझदारी से निर्णय लिया कि उपकरणों (विशेष रूप से आधा-द्वैध और पूर्ण-द्वैध उपकरण) को आपस में इस बात पर सहमत होने में सक्षम होना चाहिए कि वे कैसे संवाद करेंगे और साथ ही साथ ऑटो-बातचीत भी प्रवेश करेंगे।
हालांकि, उन पुराने आधे-डुप्लेक्स उपकरणों में से कोई भी ऑटो-बातचीत करने के लिए डिज़ाइन नहीं किया गया था, इसलिए जब मानक लिखा गया था, तो यह ऑटो-बातचीत डिवाइस द्वारा माना जाना है कि यदि दूसरा पक्ष बातचीत में भाग नहीं लेता है, तो उसे चलाना था आधे-द्वैध मोड में क्योंकि दूसरी तरफ डिवाइस केवल आधा-द्वैध में सक्षम होना चाहिए।
जैसा कि दूसरों ने बताया है, ऑटो-बातचीत हमेशा अच्छी तरह से काम नहीं करती थी, इसलिए कई उपकरणों को स्थिर गति और द्वैध सेटिंग्स (अक्सर 100 / पूर्ण) के साथ कॉन्फ़िगर किया गया था, और जब एक बातचीत डिवाइस इस तरह के डिवाइस से जुड़ा होता है, तो एक डुप्लेक्स बेमेल होता है।
समस्या के रूप में, एक डुप्लेक्स मिसमैच आधे-डुप्लेक्स मोड में चलने से बहुत खराब हो सकता है। ऐसा इसलिए है क्योंकि एक पक्ष (पूर्ण-द्वैध) सोचता है कि यह किसी भी समय संचारित हो सकता है, भले ही यह वर्तमान प्राप्त हो। आधा-द्वैध पक्ष इसे टकराव और बैक ऑफ के रूप में देखेगा, जबकि पूर्ण-द्वैध पक्ष संचारित रखेगा।
यदि पूर्ण-द्वैध पक्ष बहुत अधिक डेटा संचारित करता है, तो यह आधे-द्वैध पक्ष को "भूखा" कर सकता है क्योंकि यह संचारित करने से पहले माध्यम के खाली होने की प्रतीक्षा कर रहा है, जिससे फ्रेम कतारबद्ध हो जाता है और अंततः गिर जाता है।
सब सब में, एक बुरा स्थिति में और आप को ठीक करना चाहिए।
जब बेमेल का पता लगाने की बात आती है, तो आप त्रुटियों की तलाश कर सकते हैं। पूर्ण-द्वैध पक्ष पर, आप आमतौर पर कई रन और अक्सर सीआरसी त्रुटियां देखेंगे (विक्रेता कई बार अलग-अलग शब्दों का उपयोग कर सकते हैं)। आधे-द्वैध पक्ष पर, आप अक्सर टकराव और बफर विफलताओं को देखेंगे। कोई भी सभ्य प्रबंधन प्रणाली आपको उन इंटरफेस की एक सूची प्रदान करने में सक्षम होनी चाहिए जो त्रुटियों की अपेक्षित संख्या से अधिक उत्पन्न कर रहे हैं।