static_host_map ਅਤੇ advertise_addrs ਦੋਵੇਂ ਸੈਟਿੰਗਾਂ ਪੀਅਰ ਦੇ ਸਾਹਮਣੇ ਪਤਾ ਰੱਖਦੀਆਂ ਹਨ, ਅਤੇ ਉਹ ਵੱਖਰੇ ਸਵਾਲਾਂ ਦਾ ਜਵਾਬ ਦਿੰਦੀਆਂ ਹਨ। ਇੱਕ ਸਥਾਨਕ ਫਾਈਲ ਹੈ ਜੋ ਓਵਰਲੇ ਪਤਾ ਅਤੇ ਡਾਇਲ ਕਰਨ ਵਾਲਾ ਅੰਡਰਲੇ ਅੰਤ ਬਿੰਦੂ ਸੂਚੀਬੱਧ ਕਰਦੀ ਹੈ। ਦੂਜਾ ਹੋਸਟ ਹੈ ਜੋ ਆਪਣੇ ਲਾਈਟਹਾਊਸਾਂ ਨੂੰ ਦੱਸਦਾ ਹੈ ਕਿ ਕਿਹੜੇ ਵਾਧੂ ਅੰਤ ਬਿੰਦੂ ਉਸ ਤੱਕ ਪਹੁੰਚ ਸਕਦੇ ਹਨ। ਅਸਲ ਫ਼ਰਕ ਮਾਲਕੀ ਹੈ: ਨਕਸ਼ਾ ਉਹ ਸਾਰੇ ਸੰਭਾਲਦੇ ਹਨ ਜਿਨ੍ਹਾਂ ਨੂੰ ਇਸਦੀ ਲੋੜ ਹੈ, ਅਤੇ ਇਸ਼ਤਿਹਾਰ ਹੋਸਟ ਆਪ।

ਫੈਸਲਾ ਕਰੋ ਕਿ ਜਾਣਕਾਰੀ ਕਿਸ ਕੋਲ ਹੈ

SettingWhere it livesBest for
static_host_mapEvery peer that needs the entryBootstrap endpoints, deliberately fixed paths
advertise_addrsThe host's own configEndpoints the host cannot otherwise discover

ਹਰ ਪੀਅਰ ਦੀ ਸਥਿਰ ਫਾਈਲ ਵਿੱਚ ਹਰ ਬਦਲਦਾ ਪੀਅਰ ਸੰਭਾਲ ਦਾ ਕੰਮ ਹੈ ਜੋ ਬੇੜੇ ਦੇ ਵਰਗ ਨਾਲ ਵਧਦਾ ਹੈ। ਇਹੀ ਵਿਹਾਰਕ ਕਾਰਨ ਹੈ ਕਿ ਜਦੋਂ ਹੋਸਟ ਆਪ ਜਵਾਬ ਜਾਣਦਾ ਹੈ ਤਾਂ ਦੂਜੀ ਸੈਟਿੰਗ ਵੱਲ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ।

ਮਾਲਕੀ ਦਾ ਸਵਾਲ ਇਹ ਵੀ ਦੱਸਦਾ ਹੈ ਕਿ ਪਤਾ ਬਦਲਣ 'ਤੇ ਕੀ ਹੁੰਦਾ ਹੈ। ਸਥਿਰ ਨਕਸ਼ੇ ਨਾਲ, ਪੁਰਾਣੀ ਐਂਟਰੀ ਰੱਖਣ ਵਾਲੇ ਹਰ ਪੀਅਰ ਨੂੰ ਕਿਸੇ ਨੇ ਯਾਦ ਰੱਖਣਾ ਪੈਂਦਾ ਹੈ। ਇਸ਼ਤਿਹਾਰ ਨਾਲ, ਹੋਸਟ ਨਵਾਂ ਅੰਤ ਬਿੰਦੂ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਦਾ ਹੈ ਅਤੇ ਉਸਦੇ ਲਾਈਟਹਾਊਸ ਇਸਨੂੰ ਅੱਗੇ ਭੇਜਦੇ ਹਨ, ਇਸ ਲਈ ਤਬਦੀਲੀ ਹਿਲੀ ਮਸ਼ੀਨ 'ਤੇ ਹੀ ਸਥਾਨਕ ਰਹਿੰਦੀ ਹੈ।

Bootstrap ਨੂੰ ਅਜੇ ਵੀ ਸਥਿਰ ਐਂਟਰੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ

ਕਲਾਇੰਟ ਨੂੰ ਦੂਜੇ ਪੀਅਰਾਂ ਬਾਰੇ ਕਿਸੇ ਨੂੰ ਪੁੱਛਣ ਤੋਂ ਪਹਿਲਾਂ ਘੱਟੋ-ਘੱਟ ਇੱਕ ਲਾਈਟਹਾਊਸ ਤੱਕ ਪਹੁੰਚਣਾ ਚਾਹੀਦਾ ਹੈ। ਉਹ ਪਹਿਲੀ ਛਾਲ ਖੋਜ ਤੋਂ ਨਹੀਂ ਆ ਸਕਦੀ, ਇਸ ਲਈ ਇਹ ਕਲਾਇੰਟ ਦੀ ਕਨਫਿਗਰੇਸ਼ਨ ਵਿੱਚ ਸਥਿਰ ਐਂਟਰੀ 'ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ। ਉਹ ਇੱਕ ਐਂਟਰੀ ਠੀਕ ਕਰੋ ਅਤੇ ਬਾਕੀ ਓਵਰਲੇ ਸਿੱਖਿਆ ਜਾ ਸਕਦਾ ਹੈ।

ਨਕਸ਼ਾ ਐਂਟਰੀ Nebula ਪਤੇ ਨੂੰ ਇੱਕ ਜਾਂ ਵੱਧ ਪਹੁੰਚਯੋਗ IP ਜਾਂ DNS ਅੰਤ ਬਿੰਦੂਆਂ ਅਤੇ ਪੋਰਟਾਂ ਨਾਲ ਜੋੜਦੀ ਹੈ। ਲਾਈਟਹਾਊਸ ਉੱਥੇ ਰੱਖਣਾ ਆਮ ਹੈ; ਹਰ ਪੀਅਰ ਉੱਥੇ ਰੱਖਣਾ ਉਹ ਨਮੂਨਾ ਹੈ ਜੋ ਮਾੜਾ ਬੁੱਢਾ ਹੁੰਦਾ ਹੈ, ਕਿਉਂਕਿ ਹਰ ਨਵਾਂ ਪੀਅਰ ਤੁਹਾਡੇ ਕੰਟਰੋਲ ਤੋਂ ਬਾਹਰ ਹੋ ਸਕਣ ਵਾਲੀਆਂ ਮਸ਼ੀਨਾਂ 'ਤੇ ਫਾਈਲਾਂ ਸੋਧਣਾ ਹੈ। ਸੂਚੀ ਨੂੰ ਇੰਨੀ ਛੋਟੀ ਰੱਖੋ ਕਿ ਇੱਕ ਵਿਅਕਤੀ ਪੜ੍ਹ ਕੇ ਇਸਦੀ ਪੁਸ਼ਟੀ ਕਰ ਸਕੇ।

ਜਦੋਂ ਹੋਸਟ ਅੰਤ ਬਿੰਦੂ ਜਾਣਦਾ ਹੈ ਤਾਂ ਇਸ਼ਤਿਹਾਰ ਦਿਓ

ਪੋਰਟ ਫਾਰਵਰਡਿੰਗ ਪਿੱਛੇ ਦਾ ਹੋਸਟ ਇੱਕ ਜਨਤਕ ਪਤੇ 'ਤੇ ਪਹੁੰਚਯੋਗ ਹੁੰਦਾ ਹੈ ਜੋ ਉਸਦੇ ਕਿਸੇ ਵੀ ਇੰਟਰਫੇਸ ਨੂੰ ਨਹੀਂ ਦਿੱਤਾ ਗਿਆ। ਉਹ ਆਪਣੇ ਆਪ ਨੂੰ ਦੇਖ ਕੇ ਉਹ ਪਤਾ ਨਹੀਂ ਲੱਭ ਸਕਦਾ। advertise_addrs ਉਸਨੂੰ ਆਪਣੇ ਲਾਈਟਹਾਊਸਾਂ ਰਾਹੀਂ ਅੰਤ ਬਿੰਦੂ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਨ ਦਿੰਦਾ ਹੈ ਤਾਂ ਜੋ ਦੂਜੇ ਪੀਅਰ ਅਸਲ ਵਿੱਚ ਕੰਮ ਕਰਨ ਵਾਲਾ ਰਸਤਾ ਸਿੱਖਣ। ਇਹ ਸੈਟਿੰਗ ਠੀਕ ਇਸ ਲਈ ਹੈ ਕਿ ਮੈਪਿੰਗ ਹੋਈ ਹੈ ਇਹ ਹੋਸਟ ਹੀ ਇੱਕੋ-ਇੱਕ ਧਿਰ ਜਾਣਦੀ ਹੈ।

ਉਹ ਪਤਾ ਅਤੇ ਪੋਰਟ ਵਰਤੋ ਜਿੱਥੇ ਦੂਜੇ ਪੀਅਰ ਅਸਲ ਵਿੱਚ ਪਹੁੰਚ ਸਕਦੇ ਹਨ। ਉਹੀ ਤਰਕ ਕਈ ਨੈੱਟਵਰਕ ਰਸਤਿਆਂ ਵਾਲੇ ਹੋਸਟ 'ਤੇ ਵੀ ਲਾਗੂ ਹੁੰਦਾ ਹੈ, ਜਿੱਥੇ ਕਿਸੇ ਖਾਸ ਨੈੱਟਵਰਕ ਦੇ ਪੀਅਰਾਂ ਲਈ ਇੱਕ ਰਸਤਾ ਬਿਹਤਰ ਹੈ। ਇਸ਼ਤਿਹਾਰ ਅੰਡਰਲੇ ਬਾਰੇ ਬਿਆਨ ਹੈ, ਕਿਸੇ ਚੀਜ਼ ਦੀ ਬੇਨਤੀ ਨਹੀਂ। ਜਦੋਂ ਮੈਪਿੰਗ ਬਦਲਦੀ ਹੈ, ਹੋਸਟ 'ਤੇ ਇਸ਼ਤਿਹਾਰ ਅੱਪਡੇਟ ਕਰੋ ਅਤੇ ਖੋਜ ਨੂੰ ਇਸਨੂੰ ਚੁੱਕਣ ਦਿਓ, ਪੂਰੇ ਬੇੜੇ ਵਿੱਚ ਸਥਿਰ ਫਾਈਲਾਂ ਸੋਧਣ ਦੀ ਬਜਾਏ।

ਇਸ਼ਤਿਹਾਰ ਪਹੁੰਚ ਨਹੀਂ ਹੈ

ਅੰਤ ਬਿੰਦੂ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਨ ਨਾਲ ਰਾਊਟਰ ਦਾ ਫਾਰਵਰਡਿੰਗ ਨਿਯਮ ਨਹੀਂ ਬਣਦਾ, ਉੱਪਰਲਾ ਫਾਇਰਵਾਲ ਨਹੀਂ ਖੁੱਲ੍ਹਦਾ ਅਤੇ DNS ਨਾਮ ਹੱਲ ਨਹੀਂ ਹੁੰਦਾ। ਇਹ ਕੰਮ ਦੇ ਵੱਖਰੇ ਹਿੱਸੇ ਹਨ, ਅਤੇ ਗੁੰਮ ਪੋਰਟ ਫਾਰਵਰਡਿੰਗ ਵਾਲਾ ਸਹੀ ਇਸ਼ਤਿਹਾਰ ਉਹੀ ਫੇਲ੍ਹ ਹੋਣਾ ਪੈਦਾ ਕਰਦਾ ਹੈ ਜਿਸਨੂੰ ਤੁਸੀਂ ਠੀਕ ਕਰਨਾ ਚਾਹੁੰਦੇ ਸੀ। ਇਸ਼ਤਿਹਾਰ ਪਹੁੰਚ ਬਾਰੇ ਦਾਅਵਾ ਹੈ, ਇਸਨੂੰ ਸਥਾਪਿਤ ਕਰਨ ਵਾਲਾ ਕੋਈ ਵਿਧੀ ਨਹੀਂ।

ਖੋਜ ਨੂੰ ਦੋਸ਼ ਦੇਣ ਤੋਂ ਪਹਿਲਾਂ ਬਾਹਰੋਂ ਰਸਤਾ ਜਾਂਚੋ। ਜੋ ਪੀਅਰ ਅੰਤ ਬਿੰਦੂ ਸਿੱਖਦਾ ਹੈ ਪਰ ਹੈਂਡਸ਼ੇਕ ਪੂਰਾ ਨਹੀਂ ਕਰ ਸਕਦਾ, ਉਸਨੂੰ ਅੰਡਰਲੇ 'ਤੇ ਰਾਊਟਿੰਗ ਜਾਂ ਫਿਲਟਰਿੰਗ ਦੀ ਸਮੱਸਿਆ ਹੈ, ਅਤੇ ਦੋਵਾਂ ਸੈਟਿੰਗਾਂ ਵਿੱਚ ਉਹੀ ਪਤਾ ਦੁਹਰਾਉਣ ਨਾਲ ਇਹ ਨਹੀਂ ਬਦਲੇਗਾ।

ਓਵਰਲੇ ਪਤੇ ਨੂੰ ਅੰਤ ਬਿੰਦੂ ਤੋਂ ਵੱਖ ਰੱਖੋ

ਨੋਡ ਦਾ ਸਰਟੀਫਿਕੇਟ ਉਸਦਾ Nebula ਪਤਾ ਪਛਾਣਦਾ ਹੈ। ਘੋਸ਼ਿਤ ਪਤੇ ਅਧੀਨ ਨੈੱਟਵਰਕ ਦੇ ਹਨ, ਅਤੇ ਸਰਟੀਫਿਕੇਟ ਨੂੰ ਛੂਹੇ ਬਿਨਾਂ ਬਦਲ ਸਕਦੇ ਹਨ। ਵੱਖਰੇ ਓਵਰਲੇ IP ਨਾਲ ਨਵਾਂ ਸਰਟੀਫਿਕੇਟ ਜਾਰੀ ਕਰਨਾ ਇੱਕ ਵੱਖਰੀ ਕਾਰਵਾਈ ਹੈ, ਪੁਰਾਣੇ ਨੂੰ ਪਿੰਨ ਕਰਨ ਵਾਲੇ ਹਰ ਭਰੋਸੇ ਦੇ ਸੰਬੰਧ ਲਈ ਆਪਣੇ ਨਤੀਜਿਆਂ ਨਾਲ। ਰਨਬੁੱਕ ਵਿੱਚ ਦੋਵੇਂ ਬਦਲਾਅ ਵੱਖ ਰੱਖੋ, ਨਹੀਂ ਤਾਂ ਅੰਤ ਬਿੰਦੂ ਦੀ ਭੇਜ-ਫੇਰ ਮੁੜ-ਜਾਰੀ ਵਜੋਂ ਦਰਜ ਹੋਵੇਗੀ।

ਜਦੋਂ ਟ੍ਰਾਇਜ ਅਟਕ ਜਾਂਦਾ ਹੈ, ਦੋਵੇਂ ਪਰਤਾਂ ਸਪਸ਼ਟ ਰੂਪ ਵਿੱਚ ਵੱਖ ਕਰੋ: ਕੀ ਖੋਜ ਉਮੀਦ ਕੀਤਾ ਅੰਤ ਬਿੰਦੂ ਵਾਪਸ ਦਿੰਦੀ ਹੈ, ਅਤੇ ਕੀ ਹੈਂਡਸ਼ੇਕ ਉੱਥੇ ਪਹੁੰਚਦਾ ਹੈ? ਜੇ ਖੋਜ ਸਹੀ ਹੈ ਅਤੇ ਪੈਕਟ ਫੇਲ੍ਹ ਹੁੰਦੇ ਹਨ, ਸਮੱਸਿਆ ਓਵਰਲੇ ਦੇ ਹੇਠਾਂ ਹੈ। ਜੇ ਖੋਜ ਗਲਤ ਹੈ, ਸਮੱਸਿਆ ਨਕਸ਼ੇ ਜਾਂ ਇਸ਼ਤਿਹਾਰ ਵਿੱਚ ਹੈ, ਅਤੇ ਸੁਧਾਰ ਉੱਥੇ ਹੀ ਹੈ।

ਸੰਬੰਧਿਤ ਲੇਖ