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

ਇੱਕ ਫੀਚਰ ਦਾਅਵੇ ਅੰਦਰ ਤਿੰਨ ਸਵਾਲ

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

ਲਿੰਕ ਦਾ ਆਕਾਰ ਤੈਅ ਕਰਦਿਆਂ ਇਹਨਾਂ ਨੂੰ ਵੱਖਰਾ ਰੱਖੋ। ਸਰਵਰ ਪਾਸੇ ਬਾਹਰ ਜਾਣ ਵਾਲਾ ਬਜਟ ਸਿਰਫ਼ ਤੀਜਾ ਸਵਾਲ ਤੈਅ ਕਰਦਾ ਹੈ।

ਯੂਜ਼ਰਸਪੇਸ ਸਰਵਰ ਗਰੁੱਪ ਪੈਕਟ ਨਾਲ ਕੀ ਕਰਦਾ ਹੈ

ਰਵਾਇਤੀ OpenVPN 2.6 ਯੂਜ਼ਰਸਪੇਸ ਸਰਵਰ ਵਿੱਚ, ਆਉਂਦਾ ਬ੍ਰਾਡਕਾਸਟ ਜਾਂ ਮਲਟੀਕਾਸਟ ਪੈਕਟ TUN/TAP ਇਨਪੁਟ ਮਾਰਗ ਵਿੱਚ ਸ਼੍ਰੇਣੀਬੱਧ ਹੁੰਦਾ ਹੈ ਅਤੇ ਪ੍ਰਤੀ-ਗਰੁੱਪ ਖੋਜ ਦੀ ਥਾਂ ਬ੍ਰਾਡਕਾਸਟ ਫੈਨ-ਆਉਟ ਰੁਟੀਨ ਨੂੰ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ। ਉਹ ਰੁਟੀਨ ਕਲਾਇੰਟ ਇੰਸਟੈਂਸਾਂ ਵਿੱਚੋਂ ਲੰਘਦਾ ਹੈ, ਭੇਜਣ ਵਾਲੇ ਅਤੇ ਰੁਕੇ ਹੋਏ ਕਿਸੇ ਵੀ ਇੰਸਟੈਂਸ ਨੂੰ ਛੱਡ ਦਿੰਦਾ ਹੈ, ਜਿੱਥੇ VLAN ਸੰਰਚਿਤ ਹੈ ਉੱਥੇ ਆਪਣੀ ਜਾਂਚ ਲਾਗੂ ਕਰਦਾ ਹੈ, ਅਤੇ ਬਾਕੀ ਹਰ ਕਲਾਇੰਟ ਲਈ ਇੱਕ ਕਾਪੀ ਕਤਾਰ ਵਿੱਚ ਰੱਖਦਾ ਹੈ। ਉਸ ਲੂਪ ਦਾ ਕੋਈ ਵੀ ਕਦਮ ਮੈਂਬਰਸ਼ਿਪ ਟੇਬਲ ਨਹੀਂ ਪੁੱਛਦਾ। ਇਹ ਬ੍ਰਾਡਕਾਸਟ ਸ਼ੈਲੀ ਦੀ ਰੈਪਲੀਕੇਸ਼ਨ ਹੈ, ਅਤੇ ਪੂਰੀ ਕਾਰਜਪ੍ਰਣਾਲੀ ਇਹੀ ਹੈ।

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

ਕੁਝ ਵੀ ਮਾਪਣ ਤੋਂ ਪਹਿਲਾਂ ਕਾਪੀਆਂ ਦਾ ਬਜਟ ਬਣਾਓ

ਪੇਲੋਡ ਦਰ ਲਓ ਅਤੇ ਯੋਗ ਕਲਾਇੰਟਾਂ ਦੀ ਗਿਣਤੀ ਨਾਲ ਗੁਣਾ ਕਰੋ। ਪ੍ਰਤੀ ਸਕਿੰਟ ਇੱਕ ਮੈਗਾਬਿਟ ਵੀਹ ਕਲਾਇੰਟਾਂ ਨੂੰ ਭੇਜਣ ਵਾਲੀ ਸਟਰੀਮ ਪ੍ਰਤੀ ਸਕਿੰਟ ਵੀਹ ਮੈਗਾਬਿਟ ਪੇਲੋਡ ਪੈਦਾ ਕਰਦੀ ਹੈ ਜੋ ਸਰਵਰ ਛੱਡਦਾ ਹੈ, ਐਨਕੈਪਸੂਲੇਸ਼ਨ, ਮੁੜ-ਪ੍ਰਸਾਰਣ ਅਤੇ ਪ੍ਰਤੀ-ਕਲਾਇੰਟ ਕਿਸੇ ਵੀ ਓਵਰਹੈੱਡ ਤੋਂ ਪਹਿਲਾਂ। ਉਹ ਗਣਿਤ ਇੱਕ ਬਜਟ ਹੈ, ਤੁਹਾਡੀ ਤੈਨਾਤੀ ਦਾ ਮਾਪ ਨਹੀਂ।

ip -s link show tun0

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

ਕਾਊਂਟਰ ਵਿੱਚ ਤੁਹਾਡਾ ਆਪਣਾ ਟਨਲ ਟ੍ਰੈਫਿਕ ਵੀ ਸ਼ਾਮਲ ਹੈ, ਇਸ ਲਈ ਟੈਸਟ ਵਿੰਡੋ ਛੋਟੀ ਅਤੇ ਹੋਸਟ ਬਾਕੀ ਸਮੇਂ ਸ਼ਾਂਤ ਰੱਖੋ। ਸ਼ੁੱਧਤਾ ਪਰਿਮਾਣ ਦੇ ਕ੍ਰਮ ਨਾਲੋਂ ਘੱਟ ਮਹੱਤਵਪੂਰਨ ਹੈ, ਅਤੇ ਇੱਕ ਕਾਪੀ ਨੂੰ ਵੀਹ ਤੋਂ ਵੱਖ ਕਰਨ ਲਈ ਐਨਾ ਹੀ ਕਾਫ਼ੀ ਹੈ।

ਦੋ ਕਲਾਇੰਟਾਂ ਦਾ ਟੈਸਟ ਜੋ ਦਾਇਰੇ ਦਾ ਸਵਾਲ ਤੈਅ ਕਰਦਾ ਹੈ

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

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

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

ਸੀਮਾਵਾਂ ਹਟਾਉਣ ਦੀ ਥਾਂ ਸੀਮਤ ਡਿਜ਼ਾਈਨ ਚੁਣਨਾ

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

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

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

ਸੰਬੰਧਿਤ ਲੇਖ