«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 નેટવર્કિંગ» વિશે અનુમાન કરવાને બદલે વિનંતીનું મૂલ્યાંકન કરી શકશે.

સંબંધિત લેખો