«NetBIOS राउटर पार गर्दैन» भन्ने वाक्य डिजाइन नै टुंग्याएजस्तै गरी दोहोर्याइन्छ। तर टुंग्याएको छैन। प्रसारणबाट नाम खोज्ने काम सामान्यतया आफ्नै प्रसारण डोमेनभित्रै रहन्छ, तर NetBIOS सेवाहरू राम्ररी रुट हुने लक्षित IP ट्राफिक पनि प्रयोग गर्न सक्छन्। उपयोगी प्रश्न NetBIOS राउटर पार गर्छ कि भन्ने होइन; प्रश्न यो हो कि तपाईंको अनुप्रयोगले त्यसका तीन सेवामध्ये कुन प्रयोग गर्छ।

सफ्टवेयर इन्टरफेस, एउटा तार प्रोटोकल होइन

RFC 1001 ले NetBIOS लाई अनुप्रयोगहरूले प्रोग्राम लेख्ने इन्टरफेसका रूपमा वर्णन गर्छ, र त्यसको तल धेरै यातायात छन्। यसको TCP/UDP मोडेलले नाम सेवा, डेटाग्राम वितरण र सत्र सेवा अलग गर्छ, र यसले IP प्रसारणसहित वा बिना काम गर्ने कुरालाई स्पष्ट रूपमा समर्थन गर्छ।

ServiceWhat it doesTransport dependence
NameRegisters and resolves namesBroadcast, point-to-point, or a name server
DatagramConnectionless messages, including broadcastBroadcast domain or directed delivery
SessionConnection-oriented exchangeTCP connection to a named endpoint

यही तालिकाले नारा किन असफल हुन्छ देखाउँछ। दुई नाम भएका होस्टबीचको सत्र सेवा एउटा IP संवाद हो; प्रसारण डेटाग्राम होइन। एउटा VPN डिजाइनले पहिलो पूरा गरेर दोस्रो नगर्न सक्छ, र पहिलो प्रमाणित गर्ने परीक्षणले दोस्रोबारे केही भन्दैन।

नोड प्रकारले क्लाइन्ट के माग्छ भन्ने निर्धारण गर्छ

RFC 1001 का प्रसारण, बिन्दु-देखि-बिन्दु र मिश्रित नोड मोडेलहरूले होस्टले नाम कसरी समाधान गर्छ वर्णन गर्छन्: स्थानीय सञ्जाललाई सोधेर, नाम सर्भरलाई सिधै सोधेर, वा एउटा प्रयास गरेर त्यसपछि अर्को। मोडेलले कुन ट्राफिकलाई अनुमति दिनुपर्छ भन्नेमा असर गर्छ, अनुप्रयोग नै चल्छ कि चल्दैन भन्नेमा होइन।

व्यवस्थापित नाम-सर्भर व्यवस्थाले क्लाइन्टहरूलाई बिन्दु-देखि-बिन्दु मार्ग दिन्छ, तर त्यो प्रयोग गर्न कन्फिगर भएका क्लाइन्टहरूलाई मात्र। सञ्जालमा कतै सर्भर राख्दा अनुप्रयोगले त्यसलाई सोध्न थाल्दैन, र प्रसारण मोडमा छाडिएको क्लाइन्टले स्थानीय खण्डलाई सोधिरहन्छ र समय सकिने अवस्थामा पुग्छ। सर्भरको ठेगाना क्लाइन्टको कन्फिगरेसनसम्म पुग्नुपर्छ, त्यो क्लाइन्टले आदर गर्ने जुनसुकै व्यवस्थापन मार्गबाट।

त्यसैले सम्बन्धित अनुप्रयोगका लागि तीन अवलोकन लेख्नुहोस्: यसले सर्भरको नामलाई ठेगानामा कसरी बदल्छ, खोज वा सन्देश पठाउने कामले प्रसारण वा लक्षित अन्त्य बिन्दु प्रयोग गर्छ, र वास्तविक सत्रले कुन ठेगाना र यातायात प्रयोग गर्छ। यी स्वतन्त्र तथ्य हुन्, र प्रत्येकको आफ्नै समाधान छ। एक सफल नाम-समाधान पहिलोबारे मात्र प्रमाण हो।

TCP/IP माथिको NetBIOS NetBEUI होइन

दुवैलाई पुरानो भनिने भएकाले गद्दलमा पारिन्छ। TCP/IP माथिको NetBIOS ले आफ्ना सेवाहरू IP प्याकेटभित्र बोक्छ, जुन रुट गरिएको सुरुङले पहिले नै ढुवानी गर्छ। NetBEUI तह 2 को यस्तो प्रोटोकल हो जसलाई रुट गर्न सकिँदैन, र IP सुरुङले केवल IP ढुवानी गर्छ भनेर जथाभावी इथरनेट फ्रेम ढुवानी गर्दैन।

IP मार्ग थप्दा IP नभएको फ्रेमलाई IP अनुप्रयोगमा बदल्न सकिँदैन। यदि अनुप्रयोग साँच्चै तह 2 को व्यवहारमा निर्भर छ भने, विकल्प भनेको स्पष्ट रूपमा सीमित तह 2 सेवा वा अनुप्रयोग बदल्नु हो; यी दुईमध्ये कुनैको पनि ठाउँ कुनै रुटिङ परिवर्तनले लिँदैन।

काम पूरा गर्ने सबैभन्दा सानो परिवर्तन छान्नुहोस्

स्वीकृत DNS नाम र स्पष्ट UNC मार्गबाट पुगिने विद्यमान SMB साझेदारीलाई इथरनेट विस्तार चाहिँदैन। फाइल-सेवा काम र ब्राउजिङ अनुभव फरक आवश्यकता हुन्, र दोस्रो मात्र छिमेकी सूचीमा निर्भर छ। नामबाट साझेदारीमा पुग्नुले प्रसारण डोमेन सुरुङभरि तान्नु नपरी काम समाधान गर्छ।

ब्राउजिङ त्यो भाग हो जो सामान्यतया असफल हुन्छ, र यो चुपचाप असफल हुन्छ। मेसिनले मार्गबाट साझेदारी खोल्न सक्छ, तर नजिकका कम्प्युटरहरूको सूची खाली रहन्छ, किनकि सूची प्रसारण खोजले भर्छ र मार्गले DNS प्रयोग गर्छ। तपाईंलाई सूची चाहिन्छ भनेर निर्णय गर्नु फाइल चाहिन्छ भनेर निर्णय गर्नुभन्दा फरक आवश्यकता हो। केही डिजाइन गर्नुअघि प्रयोगकर्ताले वास्तवमा कुन मागेको थियो लेख्नुहोस्।

जब पुरानो अनुप्रयोगले साँच्चै प्रसारण वा IP नभएका फ्रेम माग्छ, नाम भएको मालिकसहित सीमित तह 2 सेवा मूल्याङ्कन गर्नुहोस्, वा अनुप्रयोग बदल्नुहोस्। पुलले साझा असफलता-डोमेन र नीति-सीमा दुवै फराकिलो बनाउँछ, र त्यो NetBIOS लेखिएको चेकबक्स होइन, स्थापत्यको निर्णय हो। सुरुङले ढुवानी गर्नुपर्ने ठोस कामहरू अभिलेख गर्नुहोस्, तब प्रशासकले «सम्पूर्ण Windows सञ्जाल» अनुमान गर्नुको सट्टा अनुरोध मूल्याङ्कन गर्न सक्नेछ।

सम्बन्धित लेखहरू