«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 संभाषण आहे; ब्रॉडकास्ट डेटाग्राम नाही। एक रचना पहिली पूर्ण करू शकते आणि दुसरी नाही, आणि पहिली सिद्ध करणारी चाचणी दुसऱ्याबद्दल काहीही सांगत नाही।

नोड प्रकार क्लायंट काय मागतो हे ठरवतात

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 नेटवर्किंग» अंदाज लावण्याऐवजी विनंतीचे मूल्यांकन करू शकेल।

संबंधित लेख