«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 ਨੈੱਟਵਰਕਿੰਗ» ਦਾ ਅੰਦਾਜ਼ਾ ਲਾਉਣ ਦੀ ਥਾਂ ਬੇਨਤੀ ਦਾ ਮੁਲਾਂਕਣ ਕਰ ਸਕੇਗਾ।

ਸੰਬੰਧਿਤ ਲੇਖ