ਸਕਾਈਪ ਤੋਂ WebRTC ਤੱਕ: ਅਸੀਂ ਵੈੱਬ ਰਾਹੀਂ ਵੀਡੀਓ ਸੰਚਾਰ ਦਾ ਪ੍ਰਬੰਧ ਕਿਵੇਂ ਕੀਤਾ

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

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

ਇਤਿਹਾਸ ਦਾ ਇੱਕ ਬਿੱਟ

2017 ਦੀਆਂ ਗਰਮੀਆਂ ਵਿੱਚ, ਸਕਾਈਂਗ ਵਿਕਾਸ ਦੇ ਮੁਖੀ, ਸਰਗੇਈ ਸਫੋਨੋਵ, ਨੇ ਬੈਕਐਂਡ ਕਨਫ ਵਿੱਚ ਇੱਕ ਕਹਾਣੀ ਦੇ ਨਾਲ ਗੱਲ ਕੀਤੀ ਕਿ ਕਿਵੇਂ ਅਸੀਂ "ਸਕਾਈਪ ਨੂੰ ਛੱਡ ਦਿੱਤਾ ਅਤੇ WebRTC ਨੂੰ ਲਾਗੂ ਕੀਤਾ।" ਦਿਲਚਸਪੀ ਰੱਖਣ ਵਾਲੇ ਇਸ 'ਤੇ ਭਾਸ਼ਣ ਦੀ ਰਿਕਾਰਡਿੰਗ ਦੇਖ ਸਕਦੇ ਹਨ ਲਿੰਕ ਨੂੰ (~ 45 ਮਿੰਟ), ਅਤੇ ਇੱਥੇ ਮੈਂ ਸੰਖੇਪ ਰੂਪ ਵਿੱਚ ਇਸਦੇ ਤੱਤ ਦੀ ਰੂਪਰੇਖਾ ਦੇਵਾਂਗਾ।

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

ਅਸਲ ਵਿੱਚ, ਵੀਡੀਓ ਸੰਚਾਰ ਲਈ ਸਾਡੀਆਂ ਲੋੜਾਂ ਲਗਭਗ ਹੇਠਾਂ ਦਿੱਤੀਆਂ ਸਨ:
- ਸਥਿਰਤਾ;
- ਪ੍ਰਤੀ ਪਾਠ ਘੱਟ ਕੀਮਤ;
- ਰਿਕਾਰਡਿੰਗ ਪਾਠ;
- ਪਤਾ ਲਗਾਉਣਾ ਕਿ ਕੌਣ ਕਿੰਨਾ ਬੋਲਦਾ ਹੈ (ਸਾਡੇ ਲਈ ਇਹ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿ ਵਿਦਿਆਰਥੀ ਪਾਠਾਂ ਦੌਰਾਨ ਅਧਿਆਪਕ ਨਾਲੋਂ ਵੱਧ ਬੋਲਦੇ ਹਨ);
- ਰੇਖਿਕ ਸਕੇਲਿੰਗ;
- UDP ਅਤੇ TCP ਦੋਵਾਂ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੀ ਯੋਗਤਾ।

ਸਭ ਤੋਂ ਪਹਿਲਾਂ 2013 ਵਿੱਚ ਟੋਕਬਾਕਸ ਨੂੰ ਲਾਗੂ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ ਗਈ ਸੀ। ਸਭ ਕੁਝ ਚੰਗਾ ਸੀ, ਪਰ ਇਹ ਬਹੁਤ ਮਹਿੰਗਾ ਨਿਕਲਿਆ - ਪ੍ਰਤੀ ਪਾਠ 113 ਰੂਬਲ - ਅਤੇ ਮੁਨਾਫ਼ਾ ਖਾ ਗਿਆ.

ਫਿਰ 2015 ਵਿੱਚ, ਵੌਕਸਿਮਪਲਾਂਟ ਨੂੰ ਏਕੀਕ੍ਰਿਤ ਕੀਤਾ ਗਿਆ ਸੀ। ਇੱਥੇ ਇੱਕ ਫੰਕਸ਼ਨ ਸੀ ਜਿਸ ਦੀ ਸਾਨੂੰ ਇਹ ਪਤਾ ਲਗਾਉਣ ਲਈ ਲੋੜ ਸੀ ਕਿ ਕੌਣ ਕਿੰਨਾ ਬੋਲਦਾ ਹੈ, ਅਤੇ ਉਸੇ ਸਮੇਂ ਹੱਲ ਬਹੁਤ ਸਸਤਾ ਸੀ: ਜੇਕਰ ਸਿਰਫ ਆਡੀਓ ਰਿਕਾਰਡ ਕੀਤਾ ਗਿਆ ਸੀ, ਤਾਂ ਇਸਦੀ ਕੀਮਤ ਪ੍ਰਤੀ ਪਾਠ 20 ਰੂਬਲ ਹੈ। ਹਾਲਾਂਕਿ, ਇਹ ਸਿਰਫ਼ UDP ਰਾਹੀਂ ਕੰਮ ਕਰਦਾ ਸੀ ਅਤੇ TCP 'ਤੇ ਸਵਿਚ ਨਹੀਂ ਕਰ ਸਕਦਾ ਸੀ। ਹਾਲਾਂਕਿ, ਲਗਭਗ 40% ਵਿਦਿਆਰਥੀਆਂ ਨੇ ਇਸਦਾ ਉਪਯੋਗ ਕਰਨਾ ਬੰਦ ਕਰ ਦਿੱਤਾ।

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

ਹੱਲ - WebRTC ਅਤੇ Janus

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

ਸਾਡੇ ਲਈ ਇੱਕ ਨਿਯਮਤ p2p ਕੁਨੈਕਸ਼ਨ ਕਾਫ਼ੀ ਨਹੀਂ ਹੈ, ਕਿਉਂਕਿ ਅਸੀਂ ਸ਼ਿਕਾਇਤਾਂ ਦੇ ਮਾਮਲੇ ਵਿੱਚ ਹੋਰ ਵਿਸ਼ਲੇਸ਼ਣ ਲਈ ਪਾਠ ਰਿਕਾਰਡ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹਾਂ। ਇਸ ਲਈ ਅਸੀਂ ਇੱਕ ਰੀਲੇਅ ਰਾਹੀਂ WebRTC ਸਟ੍ਰੀਮ ਭੇਜਦੇ ਹਾਂ ਮੀਟੇਚੋ ਦੁਆਰਾ ਜੈਨਸ ਗੇਟਵੇ. ਨਤੀਜੇ ਵਜੋਂ, ਕਲਾਇੰਟਸ ਇੱਕ ਦੂਜੇ ਦੇ ਪਤੇ ਨਹੀਂ ਜਾਣਦੇ, ਸਿਰਫ ਜੈਨਸ ਸਰਵਰ ਐਡਰੈੱਸ ਨੂੰ ਵੇਖਦੇ ਹੋਏ; ਇਹ ਇੱਕ ਸਿਗਨਲ ਸਰਵਰ ਦੇ ਕੰਮ ਵੀ ਕਰਦਾ ਹੈ। ਜੈਨਸ ਦੀਆਂ ਬਹੁਤ ਸਾਰੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਹਨ ਜਿਨ੍ਹਾਂ ਦੀ ਸਾਨੂੰ ਲੋੜ ਹੈ: ਜੇਕਰ ਕਲਾਇੰਟ ਨੇ UDP ਬਲੌਕ ਕੀਤਾ ਹੈ ਤਾਂ ਆਪਣੇ ਆਪ TCP ਵਿੱਚ ਬਦਲ ਜਾਂਦਾ ਹੈ; UDP ਅਤੇ TCP ਸਟ੍ਰੀਮਾਂ ਨੂੰ ਰਿਕਾਰਡ ਕਰ ਸਕਦਾ ਹੈ; ਸਕੇਲੇਬਲ; ਈਕੋ ਟੈਸਟਾਂ ਲਈ ਇੱਕ ਬਿਲਟ-ਇਨ ਪਲੱਗਇਨ ਵੀ ਹੈ। ਜੇਕਰ ਲੋੜ ਹੋਵੇ, ਤਾਂ Twilio ਤੋਂ STUN ਅਤੇ TURN ਸਰਵਰ ਆਪਣੇ ਆਪ ਕਨੈਕਟ ਹੋ ਜਾਂਦੇ ਹਨ।

2017 ਦੀਆਂ ਗਰਮੀਆਂ ਵਿੱਚ, ਸਾਡੇ ਕੋਲ ਦੋ ਜੈਨਸ ਸਰਵਰ ਚੱਲ ਰਹੇ ਸਨ, ਨਾਲ ਹੀ ਰਿਕਾਰਡ ਕੀਤੀਆਂ ਕੱਚੀਆਂ ਆਡੀਓ ਅਤੇ ਵੀਡੀਓ ਫਾਈਲਾਂ ਦੀ ਪ੍ਰੋਸੈਸਿੰਗ ਲਈ ਇੱਕ ਵਾਧੂ ਸਰਵਰ ਸੀ, ਤਾਂ ਜੋ ਮੁੱਖ ਦੇ ਪ੍ਰੋਸੈਸਰਾਂ 'ਤੇ ਕਬਜ਼ਾ ਨਾ ਕੀਤਾ ਜਾ ਸਕੇ। ਕਨੈਕਟ ਕਰਨ ਵੇਲੇ, ਜੈਨਸ ਸਰਵਰਾਂ ਨੂੰ ਔਡ-ਈਵਨ ਆਧਾਰ (ਕੁਨੈਕਸ਼ਨ ਨੰਬਰ) 'ਤੇ ਚੁਣਿਆ ਗਿਆ ਸੀ। ਉਸ ਸਮੇਂ, ਇਹ ਕਾਫ਼ੀ ਸੀ, ਸਾਡੀਆਂ ਭਾਵਨਾਵਾਂ ਦੇ ਅਨੁਸਾਰ, ਇਸਨੇ ਲਗਭਗ ਚਾਰ ਗੁਣਾ ਸੁਰੱਖਿਆ ਮਾਰਜਿਨ ਦਿੱਤਾ, ਲਾਗੂ ਕਰਨ ਦੀ ਪ੍ਰਤੀਸ਼ਤਤਾ ਲਗਭਗ 80 ਸੀ. ਉਸੇ ਸਮੇਂ, ਕੀਮਤ ਨੂੰ ਘਟਾ ਕੇ ~ 2 ਰੂਬਲ ਪ੍ਰਤੀ ਪਾਠ, ਨਾਲ ਹੀ ਵਿਕਾਸ ਅਤੇ ਸਮਰਥਨ ਕੀਤਾ ਗਿਆ ਸੀ।

ਵੀਡੀਓ ਸੰਚਾਰ ਦੇ ਵਿਸ਼ੇ 'ਤੇ ਵਾਪਸ ਜਾ ਰਿਹਾ ਹਾਂ

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

ਉਸ ਸਮੇਂ, ਸਾਡਾ ਵੀਡੀਓ ਸੰਚਾਰ ਅਜੇ ਵੀ MVP ਮੋਡ ਵਿੱਚ ਸੀ। ਸਧਾਰਨ ਰੂਪ ਵਿੱਚ, ਉਹਨਾਂ ਨੇ ਇਸਨੂੰ ਲਾਂਚ ਕੀਤਾ, ਇਸਨੇ ਕੰਮ ਕੀਤਾ, ਉਹਨਾਂ ਨੇ ਇਸਨੂੰ ਇੱਕ ਵਾਰ ਸਕੇਲ ਕੀਤਾ, ਉਹਨਾਂ ਨੇ ਸਮਝ ਲਿਆ ਕਿ ਇਸਨੂੰ ਕਿਵੇਂ ਕਰਨਾ ਹੈ - ਠੀਕ ਹੈ, ਬਹੁਤ ਵਧੀਆ. ਜੇਕਰ ਇਹ ਕੰਮ ਕਰਦਾ ਹੈ, ਤਾਂ ਇਸਨੂੰ ਠੀਕ ਨਾ ਕਰੋ। ਕਿਸੇ ਨੇ ਵੀ ਜਾਣਬੁੱਝ ਕੇ ਸੰਚਾਰ ਗੁਣਵੱਤਾ ਦੇ ਮੁੱਦੇ ਨੂੰ ਸੰਬੋਧਿਤ ਨਹੀਂ ਕੀਤਾ। ਅਗਸਤ ਤੱਕ, ਇਹ ਸਪੱਸ਼ਟ ਹੋ ਗਿਆ ਕਿ ਇਹ ਜਾਰੀ ਨਹੀਂ ਰਹਿ ਸਕਦਾ, ਅਤੇ ਅਸੀਂ ਇਹ ਪਤਾ ਲਗਾਉਣ ਲਈ ਇੱਕ ਵੱਖਰੀ ਦਿਸ਼ਾ ਸ਼ੁਰੂ ਕੀਤੀ ਕਿ WebRTC ਅਤੇ Janus ਵਿੱਚ ਕੀ ਗਲਤ ਸੀ।

ਇਨਪੁਟ 'ਤੇ, ਇਹ ਦਿਸ਼ਾ ਪ੍ਰਾਪਤ ਹੋਈ: ਇੱਕ MVP ਹੱਲ, ਕੋਈ ਮੈਟ੍ਰਿਕਸ ਨਹੀਂ, ਕੋਈ ਟੀਚੇ ਨਹੀਂ, ਸੁਧਾਰ ਲਈ ਕੋਈ ਪ੍ਰਕਿਰਿਆ ਨਹੀਂ, ਜਦੋਂ ਕਿ 7% ਅਧਿਆਪਕ ਸੰਚਾਰ ਦੀ ਗੁਣਵੱਤਾ ਬਾਰੇ ਸ਼ਿਕਾਇਤ ਕਰਦੇ ਹਨ (ਵਿਦਿਆਰਥੀਆਂ 'ਤੇ ਵੀ ਕੋਈ ਡਾਟਾ ਨਹੀਂ ਸੀ)।

ਇੱਕ ਨਵੀਂ ਦਿਸ਼ਾ ਚੱਲ ਰਹੀ ਹੈ

ਕਮਾਂਡ ਕੁਝ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦਿੰਦੀ ਹੈ:

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

ਸ਼ੁਰੂ ਕਰਨ ਲਈ, ਅਸੀਂ ਇੱਕ ਮੁਕਾਬਲਤਨ ਭਰੋਸੇਮੰਦ ਮੈਟ੍ਰਿਕ ਸਥਾਪਤ ਕੀਤਾ ਹੈ ਜੋ ਸੰਚਾਰ ਗੁਣਵੱਤਾ ਮੁਲਾਂਕਣਾਂ (ਦਿਨਾਂ, ਹਫ਼ਤਿਆਂ, ਮਹੀਨਿਆਂ ਵਿੱਚ ਔਸਤ) ਵਿੱਚ ਤਬਦੀਲੀਆਂ ਨੂੰ ਟਰੈਕ ਕਰਦਾ ਹੈ। ਉਸ ਸਮੇਂ, ਇਹ ਅਧਿਆਪਕਾਂ ਦੇ ਗ੍ਰੇਡ ਸਨ; ਬਾਅਦ ਵਿੱਚ ਵਿਦਿਆਰਥੀਆਂ ਦੇ ਗ੍ਰੇਡ ਉਹਨਾਂ ਵਿੱਚ ਸ਼ਾਮਲ ਕੀਤੇ ਗਏ ਸਨ। ਫਿਰ ਉਹਨਾਂ ਨੇ ਇਸ ਬਾਰੇ ਪਰਿਕਲਪਨਾ ਬਣਾਉਣਾ ਸ਼ੁਰੂ ਕੀਤਾ ਕਿ ਕੀ ਗਲਤ ਕੰਮ ਕਰ ਰਿਹਾ ਸੀ, ਇਸ ਨੂੰ ਠੀਕ ਕਰੋ, ਅਤੇ ਗਤੀਸ਼ੀਲਤਾ ਵਿੱਚ ਤਬਦੀਲੀਆਂ ਨੂੰ ਦੇਖੋ। ਅਸੀਂ ਘੱਟ ਲਟਕਣ ਵਾਲੇ ਫਲ ਲਈ ਗਏ: ਉਦਾਹਰਨ ਲਈ, ਅਸੀਂ vp8 ਕੋਡੇਕ ਨੂੰ vp9 ਨਾਲ ਬਦਲ ਦਿੱਤਾ, ਪ੍ਰਦਰਸ਼ਨ ਵਿੱਚ ਸੁਧਾਰ ਹੋਇਆ। ਅਸੀਂ ਜੈਨਸ ਸੈਟਿੰਗਾਂ ਨਾਲ ਖੇਡਣ ਅਤੇ ਹੋਰ ਪ੍ਰਯੋਗ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ - ਜ਼ਿਆਦਾਤਰ ਮਾਮਲਿਆਂ ਵਿੱਚ ਉਹਨਾਂ ਨੇ ਕੁਝ ਵੀ ਨਹੀਂ ਲਿਆ.

ਦੂਜੇ ਪੜਾਅ 'ਤੇ, ਇੱਕ ਅਨੁਮਾਨ ਉਭਰਿਆ: WebRTC ਇੱਕ ਪੀਅਰ-ਟੂ-ਪੀਅਰ ਹੱਲ ਹੈ, ਅਤੇ ਅਸੀਂ ਮੱਧ ਵਿੱਚ ਇੱਕ ਸਰਵਰ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ। ਸ਼ਾਇਦ ਸਮੱਸਿਆ ਇੱਥੇ ਹੀ ਹੈ? ਅਸੀਂ ਖੁਦਾਈ ਸ਼ੁਰੂ ਕੀਤੀ ਅਤੇ ਹੁਣ ਤੱਕ ਦਾ ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ ਸੁਧਾਰ ਪਾਇਆ ਹੈ।

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

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

ਅਸੀਂ ਹਾਲ ਹੀ ਵਿੱਚ ਇੱਕ ਹੋਰ ਗੈਰ-ਸਪੱਸ਼ਟ, ਪਰ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਮਹੱਤਵਪੂਰਨ ਚੀਜ਼ ਦੀ ਖੋਜ ਕੀਤੀ ਹੈ: ਇੱਕ ਮੋਟੇ ਚੈਨਲ 'ਤੇ ਇੱਕ ਸ਼ਕਤੀਸ਼ਾਲੀ ਜੈਨਸ ਸਰਵਰ ਦੀ ਬਜਾਏ, ਪਤਲੇ ਬੈਂਡਵਿਡਥ ਵਾਲੇ ਦੋ ਸਰਲ ਹੋਣਾ ਬਿਹਤਰ ਹੈ। ਇਹ ਉਦੋਂ ਸਪੱਸ਼ਟ ਹੋ ਗਿਆ ਜਦੋਂ ਅਸੀਂ ਉਹਨਾਂ ਵਿੱਚ ਇੱਕੋ ਸਮੇਂ ਬਹੁਤ ਸਾਰੇ ਕਮਰੇ (ਸੰਚਾਰ ਸੈਸ਼ਨਾਂ) ਨੂੰ ਭਰਨ ਦੀ ਉਮੀਦ ਵਿੱਚ ਸ਼ਕਤੀਸ਼ਾਲੀ ਮਸ਼ੀਨਾਂ ਖਰੀਦੀਆਂ। ਸਰਵਰਾਂ ਦੀ ਇੱਕ ਬੈਂਡਵਿਡਥ ਸੀਮਾ ਹੁੰਦੀ ਹੈ, ਜਿਸਦਾ ਅਸੀਂ ਰੂਮਾਂ ਦੀ ਸੰਖਿਆ ਵਿੱਚ ਸਹੀ ਅਨੁਵਾਦ ਕਰ ਸਕਦੇ ਹਾਂ - ਅਸੀਂ ਜਾਣਦੇ ਹਾਂ ਕਿ ਕਿੰਨੇ ਖੋਲ੍ਹੇ ਜਾ ਸਕਦੇ ਹਨ, ਉਦਾਹਰਨ ਲਈ, 300 Mbit/s. ਜਿਵੇਂ ਹੀ ਇੱਕ ਸਰਵਰ 'ਤੇ ਬਹੁਤ ਸਾਰੇ ਕਮਰੇ ਖੁੱਲ੍ਹਦੇ ਹਨ, ਅਸੀਂ ਇਸਨੂੰ ਨਵੀਆਂ ਗਤੀਵਿਧੀਆਂ ਲਈ ਚੁਣਨਾ ਬੰਦ ਕਰ ਦਿੰਦੇ ਹਾਂ ਜਦੋਂ ਤੱਕ ਲੋਡ ਘੱਟ ਨਹੀਂ ਹੁੰਦਾ। ਇਹ ਵਿਚਾਰ ਇਹ ਸੀ ਕਿ, ਇੱਕ ਸ਼ਕਤੀਸ਼ਾਲੀ ਮਸ਼ੀਨ ਖਰੀਦਣ ਤੋਂ ਬਾਅਦ, ਅਸੀਂ ਇਸ ਵਿੱਚ ਚੈਨਲ ਨੂੰ ਵੱਧ ਤੋਂ ਵੱਧ ਲੋਡ ਕਰਾਂਗੇ, ਤਾਂ ਜੋ ਅੰਤ ਵਿੱਚ ਇਹ ਪ੍ਰੋਸੈਸਰ ਅਤੇ ਮੈਮੋਰੀ ਦੁਆਰਾ ਸੀਮਿਤ ਹੋਵੇ, ਨਾ ਕਿ ਬੈਂਡਵਿਡਥ ਦੁਆਰਾ. ਪਰ ਇਹ ਪਤਾ ਚਲਿਆ ਕਿ ਖੁੱਲੇ ਕਮਰੇ (420) ਦੀ ਇੱਕ ਨਿਸ਼ਚਤ ਗਿਣਤੀ ਦੇ ਬਾਅਦ, ਇਸ ਤੱਥ ਦੇ ਬਾਵਜੂਦ ਕਿ ਪ੍ਰੋਸੈਸਰ, ਮੈਮੋਰੀ ਅਤੇ ਡਿਸਕ 'ਤੇ ਲੋਡ ਅਜੇ ਵੀ ਸੀਮਾਵਾਂ ਤੋਂ ਬਹੁਤ ਦੂਰ ਹੈ, ਤਕਨੀਕੀ ਸਹਾਇਤਾ 'ਤੇ ਨਕਾਰਾਤਮਕਤਾ ਆਉਣੀ ਸ਼ੁਰੂ ਹੋ ਜਾਂਦੀ ਹੈ. ਜ਼ਾਹਰਾ ਤੌਰ 'ਤੇ, ਜੈਨਸ ਦੇ ਅੰਦਰ ਕੁਝ ਵਿਗੜ ਰਿਹਾ ਹੈ, ਸ਼ਾਇਦ ਉੱਥੇ ਵੀ ਕੁਝ ਪਾਬੰਦੀਆਂ ਹਨ. ਅਸੀਂ ਪ੍ਰਯੋਗ ਕਰਨਾ ਸ਼ੁਰੂ ਕੀਤਾ, ਬੈਂਡਵਿਡਥ ਸੀਮਾ ਨੂੰ 300 ਤੋਂ 200 Mbit/s ਤੱਕ ਘਟਾ ਦਿੱਤਾ, ਅਤੇ ਸਮੱਸਿਆਵਾਂ ਦੂਰ ਹੋ ਗਈਆਂ। ਹੁਣ ਅਸੀਂ ਘੱਟ ਸੀਮਾਵਾਂ ਅਤੇ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਦੇ ਨਾਲ ਇੱਕੋ ਸਮੇਂ ਤਿੰਨ ਨਵੇਂ ਸਰਵਰ ਖਰੀਦੇ ਹਨ, ਅਸੀਂ ਸੋਚਦੇ ਹਾਂ ਕਿ ਇਸ ਨਾਲ ਸੰਚਾਰ ਦੀ ਗੁਣਵੱਤਾ ਵਿੱਚ ਸਥਿਰ ਸੁਧਾਰ ਹੋਵੇਗਾ। ਬੇਸ਼ੱਕ, ਅਸੀਂ ਇਹ ਪਤਾ ਲਗਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਨਹੀਂ ਕੀਤੀ ਕਿ ਉੱਥੇ ਕੀ ਹੋ ਰਿਹਾ ਸੀ; ਸਾਡੀਆਂ ਬੈਸਾਖੀਆਂ ਸਭ ਕੁਝ ਹਨ। ਸਾਡੇ ਬਚਾਅ ਵਿੱਚ, ਆਓ ਇਹ ਕਹੀਏ ਕਿ ਉਸ ਸਮੇਂ ਦਬਾਅ ਵਾਲੀ ਸਮੱਸਿਆ ਨੂੰ ਜਿੰਨੀ ਜਲਦੀ ਹੋ ਸਕੇ ਹੱਲ ਕਰਨਾ ਜ਼ਰੂਰੀ ਸੀ, ਨਾ ਕਿ ਇਸਨੂੰ ਸੁੰਦਰਤਾ ਨਾਲ ਕਰਨਾ; ਇਸ ਤੋਂ ਇਲਾਵਾ, ਸਾਡੇ ਲਈ ਜੈਨਸ C ਵਿੱਚ ਲਿਖਿਆ ਇੱਕ ਬਲੈਕ ਬਾਕਸ ਹੈ, ਇਸ ਨਾਲ ਟਿੰਕਰ ਕਰਨਾ ਬਹੁਤ ਮਹਿੰਗਾ ਹੈ।

ਖੈਰ, ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ ਅਸੀਂ:

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

ਪ੍ਰਯੋਗਾਂ ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਤਬਦੀਲੀਆਂ ਨੇ ਅਧਿਆਪਕਾਂ ਵਿੱਚ ਸੰਚਾਰ ਪ੍ਰਤੀ ਅਸੰਤੁਸ਼ਟੀ ਨੂੰ ਜਨਵਰੀ 7,1 ਵਿੱਚ 2018% ਤੋਂ ਜਨਵਰੀ 2,5 ਵਿੱਚ 2019% ਤੱਕ ਘਟਾਉਣਾ ਸੰਭਵ ਬਣਾਇਆ।

ਅੱਗੇ ਕੀ ਹੈ

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

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

1. ਲੜਾਈ ਦੀਆਂ ਸਥਿਤੀਆਂ ਵਿੱਚ ਨਿਯਮਤ p2p ਨਾਲ ਜੈਨਸ ਦੁਆਰਾ ਵੀਡੀਓ ਦੀ ਤੁਲਨਾ ਕਰੋ। ਇਹ ਪ੍ਰਯੋਗ ਪਹਿਲਾਂ ਹੀ ਕੀਤਾ ਜਾ ਚੁੱਕਾ ਹੈ, ਸਾਡੇ ਹੱਲ ਅਤੇ p2p ਵਿਚਕਾਰ ਕੋਈ ਅੰਕੜਾਤਮਕ ਤੌਰ 'ਤੇ ਮਹੱਤਵਪੂਰਨ ਅੰਤਰ ਨਹੀਂ ਮਿਲਿਆ;
2. ਆਉ ਉਹਨਾਂ ਕੰਪਨੀਆਂ ਤੋਂ (ਮਹਿੰਗੀਆਂ) ਸੇਵਾਵਾਂ ਦੀ ਸਪਲਾਈ ਕਰੀਏ ਜੋ ਸਿਰਫ਼ ਵੀਡੀਓ ਸੰਚਾਰ ਹੱਲਾਂ 'ਤੇ ਪੈਸਾ ਕਮਾਉਂਦੀਆਂ ਹਨ, ਅਤੇ ਮੌਜੂਦਾ ਇੱਕ ਨਾਲ ਉਹਨਾਂ ਤੋਂ ਨਕਾਰਾਤਮਕਤਾ ਦੀ ਮਾਤਰਾ ਦੀ ਤੁਲਨਾ ਕਰੀਏ।

ਇਹ ਦੋ ਪ੍ਰਯੋਗ ਸਾਨੂੰ ਇੱਕ ਪ੍ਰਾਪਤੀ ਯੋਗ ਟੀਚੇ ਦੀ ਪਛਾਣ ਕਰਨ ਅਤੇ ਇਸ 'ਤੇ ਧਿਆਨ ਕੇਂਦਰਿਤ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦੇਣਗੇ।

ਇਸ ਤੋਂ ਇਲਾਵਾ, ਇੱਥੇ ਬਹੁਤ ਸਾਰੇ ਕੰਮ ਹਨ ਜੋ ਨਿਯਮਤ ਤੌਰ 'ਤੇ ਹੱਲ ਕੀਤੇ ਜਾ ਸਕਦੇ ਹਨ:

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

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

ਅਤੇ, ਬੇਸ਼ੱਕ, ਅਸੀਂ ਵੀਡੀਓ ਸੰਚਾਰ ਨਾਲ ਕੰਮ ਕਰਨ ਵਾਲੇ ਲੋਕਾਂ ਅਤੇ ਕੰਪਨੀਆਂ ਨਾਲ ਸਰਗਰਮੀ ਨਾਲ ਸੰਚਾਰ ਕਰਨਾ ਜਾਰੀ ਰੱਖਦੇ ਹਾਂ। ਜੇ ਤੁਸੀਂ ਸਾਡੇ ਨਾਲ ਅਨੁਭਵ ਦਾ ਆਦਾਨ-ਪ੍ਰਦਾਨ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਅਸੀਂ ਖੁਸ਼ ਹੋਵਾਂਗੇ! ਟਿੱਪਣੀ ਕਰੋ, ਸੰਪਰਕ ਕਰੋ - ਅਸੀਂ ਸਾਰਿਆਂ ਦਾ ਜਵਾਬ ਦੇਵਾਂਗੇ।

ਸਰੋਤ: www.habr.com