ਕੈਮਰਾ ਸਟ੍ਰੀਮ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਨਾ: RTSP ਅਤੇ HLS ਇੱਕੋ ਕੰਢਾ ਨਹੀਂ

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

VPN ਸਰੋਤ ਦਾ ਰਾਹ ਠੀਕ ਕਰਦਾ ਹੈ, ਦਰਸ਼ਕ ਦਾ ਨਹੀਂ

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

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

RTSP ਇੱਕ ਗੱਲਬਾਤ ਹੈ, ਇੱਕ ਪੋਰਟ ਨਹੀਂ

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

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

ਛੋਟੇ, ਜਾਣੇ-ਪਛਾਣੇ ਦਰਸ਼ਕ ਵਰਗ ਲਈ ਜਿਸ ਕੋਲ ਮੇਲ ਖਾਂਦੇ ਪਲੇਅਰ ਹੋਣ, ਜਾਣ-ਬੁੱਝ ਕੇ ਕਨਫਿਗਰ ਕੀਤਾ RTSP ਰਿਲੇ ਸਹੀ ਜਵਾਬ ਹੋ ਸਕਦਾ ਹੈ। ਸੀਮਤ ਕਰੋ ਕਿ ਇਹ ਕਿਹੜੇ ਸਰੋਤ ਤੋਂ ਖਿੱਚ ਸਕਦਾ ਹੈ ਅਤੇ ਰਿਲੇ 'ਤੇ ਪ੍ਰਮਾਣਿਕਤਾ ਮੰਗੋ। ਆਪਣੇ ਟੈਸਟ ਕੀਤੇ ਪਲੇਅਰ ਲਿਖ ਲਓ, ਕਿਉਂਕਿ VLC ਵਿੱਚ ਚੱਲਣ ਵਾਲੀ RTSP ਸਟ੍ਰੀਮ ਬ੍ਰਾਊਜ਼ਰ ਵਿੱਚ ਫਿਰ ਵੀ ਫੇਲ੍ਹ ਹੋ ਸਕਦੀ ਹੈ।

HLS ਇੱਕ ਪਲੇਲਿਸਟ ਅਤੇ ਸਰੋਤ ਹੈ

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

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

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

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

ਪ੍ਰਮਾਣਿਕਤਾ ਉਸ ਕੰਢੇ 'ਤੇ ਰੱਖੋ ਜਿਸ ਨੂੰ ਤੁਸੀਂ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਦੇ ਹੋ

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

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

ਫਿਰ ਸ਼੍ਰੰਖਲਾ ਚੱਲਦੀ ਹੈ ਅਜਿਹਾ ਮੰਨਣ ਦੀ ਥਾਂ ਤੁਸੀਂ ਅਸਲ ਵਿੱਚ ਬਣਾਏ ਦੋ ਸਿਰਿਆਂ ਦੀ ਜਾਂਚ ਕਰੋ:

$ ffprobe -v error -rtsp_transport tcp rtsp://10.50.0.9:554/stream1
$ curl -sI https://stream.example.net/live/index.m3u8
HTTP/2 200
content-type: application/vnd.apple.mpegurl

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

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