ਇਵੈਂਟ-ਫੋਟੋ ਐਪਸ ਦੇ ਡਿਵੈਲਪਰਾਂ ਕੋਲ ਹੁਣ ਭੀੜ ਵਾਲੇ ਸਥਾਨਾਂ ਵਿੱਚ ਬ੍ਰਾਊਜ਼ਰ ਅੱਪਲੋਡਸ ਨੂੰ ਜਾਰੀ ਰੱਖਣ ਲਈ ਇੱਕ ਪੱਕੀ ਚੈੱਕਲਿਸਟ ਹੈ। ਇੱਕ ਸਿੰਗਲ ਯੂਜ਼ਰ ਵਾਈ-ਫਾਈ ਤੋਂ ਸੈਲੂਲਰ 'ਤੇ ਜਾ ਸਕਦਾ ਹੈ ਜਦੋਂ ਕਿ ਦਰਜਨਾਂ ਡਿਵਾਈਸਾਂ ਇੱਕੋ ਹੌਟਸਪੌਟ ਲਈ ਮੁਕਾਬਲਾ ਕਰ ਰਹੀਆਂ ਹੋਣ। ਇਹ ਗਾਈਡ ਦਿਖਾਉਂਦੀ ਹੈ ਕਿ ਕਿਵੇਂ ਕਿਸੇ ਫੋਟੋ ਨੂੰ “upload complete” ਟੋਸਟ ਤੋਂ ਬਾਅਦ ਗਾਇਬ ਹੋਣ ਤੋਂ ਰੋਕਿਆ ਜਾ ਸਕਦਾ ਹੈ, ਭਾਵੇਂ ਮਹਿਮਾਨ ਫ਼ੋਨ ਨੂੰ ਲੌਕ ਕਰ ਦੇਵੇ ਜਾਂ ਨੈੱਟਵਰਕ ਵਿੱਚ ਕੋਈ ਖਰਾਬੀ ਆ ਜਾਵੇ।
ਵਿਆਹਾਂ ਅਤੇ ਤਿਉਹਾਰਾਂ ਵਿੱਚ ਆਮ ਅੱਪਲੋਡਸ ਕਿਉਂ ਫੇਲ੍ਹ ਹੋ ਜਾਂਦੇ ਹਨ
ਇੱਕ ਦਫ਼ਤਰ ਵਿੱਚ, ਇੱਕ ਲੈਪਟਾਪ ਇੱਕ ਸਥਿਰ Ethernet ਲਿੰਕ 'ਤੇ ਹੁੰਦਾ ਹੈ ਅਤੇ ਇੱਕ ਸਿੰਗਲ ਯੂਜ਼ਰ “send” 'ਤੇ ਕਲਿੱਕ ਕਰਦਾ ਹੈ। ਵਿਆਹ ਦੇ ਰਿਸੈਪਸ਼ਨ ਜਾਂ ਮਿਊਜ਼ਿਕ ਫੈਸਟੀਵਲ ਵਿੱਚ, ਇਹੀ ਕਾਰਵਾਈ ਸਮੱਸਿਆਵਾਂ ਦੀ ਇੱਕ ਲੜੀ ਸ਼ੁਰੂ ਕਰ ਸਕਦੀ ਹੈ: ਮਹਿਮਾਨ ਸੈਰੇਮਨੀ ਹਾਲ ਤੋਂ ਪਾਰਕਿੰਗ ਲੋਟ ਤੱਕ ਜਾਂਦਾ ਹੈ, ਰੋਟਰ ਸੈਂਕੜੇ ਫ਼ੋਨਾਂ ਦੇ ਬੋਝ ਹੇਠ ਦਬ ਜਾਂਦਾ ਹੈ, ਜਾਂ ਫ਼ੋਨ ਵਾਈ-ਫਾਈ ਤੋਂ ਡਿਸਕਨੈਕਟ ਹੋ ਕੇ ਸੈਲੂਲਰ 'ਤੇ ਆ ਜਾਂਦਾ ਹੈ। ਬ੍ਰਾਊਜ਼ਰ ਨੇ ਸ਼ਾਇਦ ਸਰਵਰ ਨੂੰ ਹਰ ਬਾਈਟ ਸਟ੍ਰੀਮ ਕਰ ਦਿੱਤਾ ਹੋਵੇ, ਪਰ ਸਰਵਰ ਨੇ ਅਜੇ ਫਾਈਲ ਨੂੰ ਸਟੋਰੇਜ ਵਿੱਚ ਸੇਵ ਨਹੀਂ ਕੀਤਾ ਹੁੰਦਾ। ਜੇਕਰ UI ਪ੍ਰੋਗਰੈਸ ਬਾਰ 100% ਹੋਣ 'ਤੇ ਹੀ ਸਫਲਤਾ ਦਾ ਐਲਾਨ ਕਰ ਦਿੰਦਾ ਹੈ, ਤਾਂ ਮਹਿਮਾਨ ਫੋਟੋ ਡਿਲੀਟ ਕਰ ਸਕਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਆਯੋਜਕ ਕੋਲ ਇੱਕ ਗੁੰਮ ਹੋਈ ਫਾਈਲ ਰਹਿ ਜਾਂਦੀ ਹੈ।
“ਸਿਰਫ਼ ਅੱਪਲੋਡ ਕਰੋ” ਦੀ ਲੁਕੀ ਹੋਈ ਕੀਮਤ
ਇੱਕ ਸਰਲ ਪਹੁੰਚ ਅੱਪਲੋਡ ਨੂੰ ਇੱਕ ਸਿੰਗਲ HTTP POST ਵਜੋਂ ਮੰਨਦੀ ਹੈ। ਇਹ ਉਦੋਂ ਕੰਮ ਕਰਦਾ ਹੈ ਜਦੋਂ ਕਨੈਕਸ਼ਨ ਸਥਿਰ ਹੋਵੇ, ਪਰ ਇੱਕ ਭੀੜ ਵਾਲੇ ਨੈੱਟਵਰਕ 'ਤੇ ਹਰ ਰੁਕਾਵਟ ਪੂਰੀ ਫਾਈਲ ਨੂੰ ਦੁਬਾਰਾ ਸ਼ੁਰੂ ਕਰਨ ਲਈ ਮਜਬੂਰ ਕਰਦੀ ਹੈ। ਜਦੋਂ ਦਰਜਨਾਂ ਫ਼ੋਨ ਇੱਕੋ ਸਮੇਂ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹਨ, ਤਾਂ ਯੂਜ਼ਰ ਨਿਰਾਸ਼ ਹੋ ਜਾਂਦੇ ਹਨ ਅਤੇ ਬੈਂਡਵਿਡਥ ਵਿੱਚ ਅਚਾਨਕ ਵਾਧਾ ਹੁੰਦਾ ਹੈ। ਫਾਈਲ ਨੂੰ ਛੋਟੇ ਹਿੱਸਿਆਂ (chunks) ਵਿੱਚ ਵੰਡਣਾ ਅਤੇ ਹਰੇਕ ਹਿੱਸੇ ਨੂੰ ਟਰੈਕ ਕਰਨਾ ਗੁੰਝਲਦਾਰ ਹੈ, ਪਰ ਇਸ ਦਾ ਫਾਇਦਾ ਇੱਕ ਅਜਿਹਾ ਟ੍ਰਾਂਸਫਰ ਹੈ ਜੋ ਨੈੱਟਵਰਕ ਬਦਲਣ 'ਤੇ ਵੀ ਜਾਰੀ ਰਹਿੰਦਾ ਹੈ।
ਇੱਕ ਰੀਜ਼ਿਊਮੇਬਲ, ਚੰਕਡ ਅੱਪਲੋਡ ਸਿਸਟਮ ਬਣਾਉਣਾ
ਹੇਠਾਂ ਇੱਕ ਵਿਵਹਾਰਕ, ਸਟੈਪ-ਬਾਈ-ਸਟੈਪ ਤਰੀਕਾ ਦਿੱਤਾ ਗਿਆ ਹੈ।
1. ਕਿਸੇ ਵੀ ਡੇਟਾ ਦੇ ਬ੍ਰਾਊਜ਼ਰ ਤੋਂ ਬਾਹਰ ਜਾਣ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਅੱਪਲੋਡ ID ਬਣਾਓ
ਸਥਾਨਕ ਤੌਰ 'ਤੇ ਇੱਕ universally unique identifier (UUID) ਬਣਾਓ ਅਤੇ ਇਸਨੂੰ ਪਹਿਲੀ ਬੇਨਤੀ ਵਜੋਂ ਸਰਵਰ ਨੂੰ ਭੇਜੋ। ਸਰਵਰ ਉਸ ID ਦੇ ਅਧੀਨ ਇੱਕ ਸੈਸ਼ਨ ਰਿਕਾਰਡ ਕਰਦਾ ਹੈ। ਜੇਕਰ ਬ੍ਰਾਊਜ਼ਰ ਬਾਅਦ ਵਿੱਚ ਟਾਈਮਆਊਟ ਕਾਰਨ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ, ਤਾਂ ਇਹ ਉਹੀ UUID ਸ਼ਾਮਲ ਕਰਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਸਰਵਰ ਸੈਸ਼ਨ ਨੂੰ ਪਛਾਣ ਲੈਂਦਾ ਹੈ ਅਤੇ ਡੁਪਲੀਕੇਟ ਐਂਟਰੀ ਤੋਂ ਬਚਦਾ ਹੈ। ਇਹ ਵਰਕਫਲੋ ਨੂੰ idempotent ਬਣਾਉਂਦਾ ਹੈ—ਇੱਕੋ ਬੇਨਤੀ ਨੂੰ ਦੁਹਰਾਉਣ ਨਾਲ ਕੋਈ ਨੁਕਸਾਨਦੇਹ ਪ੍ਰਭਾਵ ਨਹੀਂ ਪੈਂਦਾ।
2. ਫਾਈਲ ਨੂੰ 5 – 10 MB ਦੇ ਚੰਕਸ ਵਿੱਚ ਵੰਡੋ
ਚੰਕ ਸਾਈਜ਼ ਇੱਕ ਸਮਝੌਤਾ ਹੈ। ਛੋਟੇ ਚੰਕਸ (1 MB ਤੋਂ ਘੱਟ) HTTP ਰਿਕੁਐਸਟਾਂ ਦੀ ਗਿਣਤੀ ਅਤੇ ਨਾਲ ਸੰਬੰਧਿਤ ਹੈਡਰ ਓਵਰਹੈੱਡ ਨੂੰ ਵਧਾਉਂਦੇ ਹਨ। ਬਹੁਤ ਵੱਡੇ ਚੰਕਸ ਕਿਸੇ ਵੀ ਰੁਕਾਵਟ ਨੂੰ ਮਹਿੰਗਾ ਬਣਾ ਦਿੰਦੇ ਹਨ ਕਿਉਂਕਿ ਕਲਾਇੰਟ ਨੂੰ ਇੱਕ ਵੱਡਾ ਹਿੱਸਾ ਦੁਬਾਰਾ ਭੇਜਣਾ ਪੈਂਦਾ ਹੈ। ਆਮ ਫੋਟੋਆਂ ਅਤੇ ਛੋਟੇ ਵੀਡੀਓਜ਼ ਲਈ, 5 – 10 MB ਇੱਕ ਸੰਤੁਲਨ ਬਣਾਉਂਦਾ ਹੈ: ਹਰੇਕ ਰਿਕੁਐਸ ਇੰਨੀ ਜਲਦੀ ਖਤਮ ਹੋ ਜਾਂਦੀ ਹੈ ਕਿ UI ਰਿਸਪੌਂਸਿਵ ਰਹੇ, ਫਿਰ ਵੀ ਰਿਕੁਐਸਾਂ ਦੀ ਗਿਣਤੀ ਕਾਬਲ-ਏ-ਕਾਬਲ ਰਹਿੰਦੀ ਹੈ।
3. ਪੈਰਲਲ ਅੱਪਲੋਡਸ ਦੀ ਗਿਣਤੀ ਨੂੰ ਸੀਮਤ ਕਰੋ
ਮੋਬਾਈਲ ਬ੍ਰਾਊਜ਼ਰ ਕਈ ਕਨੈਕਸ਼ਨ ਖੋਲ੍ਹ ਸਕਦੇ ਹਨ, ਪਰ ਇੱਕ ਭੀੜ ਵਾਲੇ ਵਾਈ-ਫਾਈ ਨੈੱਟਵਰਕ 'ਤੇ ਹਰੇਕ ਵਾਧੂ ਸਟ੍ਰੀਮ ਸੀਮਤ ਬੈਂਡਵਿਡਥ ਲਈ ਮੁਕਾਬਲਾ ਕਰਦੀ ਹੈ। ਦੋ ਸਥਿਰ ਸਟ੍ਰੀਮਾਂ ਅੱਠ ਮੁਕਾਬਲੇਬਾਜ਼ ਸਟ੍ਰੀਮਾਂ ਨਾਲੋਂ ਬਿਹਤਰ ਹਨ। ਘੱਟ ਬੈਂਡਵਿਡਥ ਵਾਲੀਆਂ ਸਥਿਤੀਆਂ ਦਾ ਪਤਾ ਲਗਾਉਣ ਅਤੇ ਆਟੋਮੈਟਿਕ ਤੌਰ 'ਤੇ ਕੰਕਰੈਂਸੀ ਨੂੰ ਘਟਾਉਣ ਲਈ navigator.connection API ਦੀ ਵਰਤੋਂ ਕਰੋ।
4. IndexedDB ਵਿੱਚ ਅੱਪਲੋਡ ਸਟੇਟ ਨੂੰ ਸੁਰੱਖਿਅਤ ਰੱਖੋ
ਅੱਪਲੋਡ ID, ਪਹਿਲਾਂ ਤੋਂ ਭੇਜੇ ਗਏ ਚੰਕਸ ਦੀ ਸੂਚੀ, ਅਤੇ ਸਰਵਰ ਦੁਆਰਾ ਸਵੀਕਾਰ ਕੀਤੇ ਗਏ ਕਿਸੇ ਵੀ ਆਫਸੈੱਟ ਨੂੰ ਬ੍ਰਾਊਜ਼ਰ ਦੇ IndexedDB ਵਿੱਚ ਸਟੋਰ ਕਰੋ। ਜੇਕਰ ਪੇਜ ਰੀਲੋਡ ਹੁੰਦਾ ਹੈ ਜਾਂ ਯੂਜ਼ਰ ਟੈਬ ਬੰਦ ਕਰ ਦਿੰਦਾ ਹੈ, ਤਾਂ ਕਲਾਇੰਟ ਅਗਲੀ ਲੋਡ 'ਤੇ ਸਟੇਟ ਨੂੰ ਰਿਕਵਰ ਕਰ ਸਕਦਾ ਹੈ। ਜਦੋਂ ਯੂਜ਼ਰ ਪੇਜ ਨੂੰ ਦੁਬਾਰਾ ਖੋਲ੍ਹਦਾ ਹੈ, ਤਾਂ ਉਹਨਾਂ ਨੂੰ ਉਹੀ ਫਾਈਲ ਚੁਣਨ ਲਈ ਕਹੋ; ਸਟੋਰ ਕੀਤਾ ਗਿਆ ਮੈਟਾਡਾਟਾ ਅੱਪਲੋਡ ਨੂੰ ਦੁਬਾਰਾ ਸ਼ੁਰੂ ਕਰਨ ਦੀ ਬਜਾਏ ਆਖਰੀ ਕਨਫਰਮ ਕੀਤੇ ਗਏ ਚੰਕ ਤੋਂ ਜਾਰੀ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ।
5. ਸਿਰਫ਼ navigator.onLine ਹੀ ਨਹੀਂ, ਸਗੋਂ ਅਸਲ ਨੈੱਟਵਰਕ ਤਬਦੀਲੀਆਂ ਦਾ ਪਤਾ ਲਗਾਓ
navigator.onLine ਫਲੈਗ ਅਕਸਰ “online” ਰਿਪੋਰਟ ਕਰਦਾ ਹੈ ਭਾਵੇਂ ਕਨੈਕਸ਼ਨ ਵਰਤੋਂ ਯੋਗ ਨਾ ਹੋਵੇ। ਇਸ ਦੀ ਬਜਾਏ, ਹਰੇਕ ਚੰਕ ਲਈ ਇੱਕ ਛੋਟਾ ਰਿਕੁਐਸ ਟਾਈਮਆਊਟ (ਜਿਵੇਂ ਕਿ 5 ਸੈਕਿੰਡ) ਸੈੱਟ ਕਰੋ। ਜੇਕਰ ਟਾਈਮਆਊਟ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਨੈੱਟਵਰਕ ਨੂੰ ਡਾਊਨ ਮੰਨੋ। ਜਦੋਂ ਕਨੈਕਟੀਵਿਟੀ ਵਾਪਸ ਆਉਂਦੀ ਹੈ, ਤਾਂ ਸਰਵਰ ਤੋਂ ਉਹਨਾਂ ਚੰਕਸ ਦੀ ਸੂਚੀ ਪੁੱਛੋ ਜੋ ਉਸ ਕੋਲ ਪਹਿਲਾਂ ਹੀ ਹਨ, ਫਿਰ ਸਿਰਫ਼ ਗੁੰਮ ਹੋਏ ਹਿੱਸਿਆਂ ਨੂੰ ਅੱਪਲੋਡ ਕਰਨਾ ਜਾਰੀ ਰੱਖੋ। ਇਹ ਥੋੜ੍ਹੇ ਸਮੇਂ ਦੇ ਕਟਾਵ ਤੋਂ ਬਾਅਦ ਡੁਪਲੀਕੇਟ ਡੇਟਾ ਭੇਜਣ ਤੋਂ ਬਚਾਉਂਦਾ ਹੈ।
6. ਰੀਟਰਾਈਜ਼ ਲਈ ਜਿੱਟਰ ਦੇ ਨਾਲ ਐਕਸਪੋਨੈਂਸ਼ੀਅਲ ਬੈਕਆਫ ਲਾਗੂ ਕਰੋ
ਜਦੋਂ ਬਹੁਤ ਸਾਰੇ ਮਹਿਮਾਨਾਂ ਦੇ ਡਿਵਾਈਸਾਂ ਨੂੰ ਪਤਾ ਲੱਗਦਾ ਹੈ ਕਿ ਨੈੱਟਵਰਕ ਵਾਪਸ ਆ ਗਿਆ ਹੈ, ਤਾਂ ਉਹ ਸਾਰੇ ਇੱਕੋ ਸਮੇਂ ਰੀਟਰਾਈ ਕਰ ਸਕਦੇ ਹਨ, ਜਿਸ ਨਾਲ ਸਰਵਰ 'ਤੇ ਬੋਝ ਪੈ ਸਕਦਾ ਹੈ। Exponential backoff ਹਰੇਕ ਰੀਟਰਾਈ ਨੂੰ ਪਿਛਲੇ ਵਾਲੇ ਨਾਲੋਂ ਜ਼ਿਆਦਾ ਦੇਰ ਇੰਤਜ਼ਾਰ ਕਰਵਾਉਂਦਾ ਹੈ, ਜ
ਸਿਰਫ਼ ਰੰਗ 'ਤੇ ਹੀ ਨਿਰਭਰ ਰਹਿਣ ਤੋਂ ਬਚੋ; ਆਈਕਨਾਂ ਨੂੰ ਛੋਟੇ ਟੈਕਸਟ ਦੇ ਨਾਲ ਜੋੜੋ ਤਾਂ ਜੋ ਸਕ੍ਰੀਨ-ਰੀਡਰ ਦੀ ਵਰਤੋਂ ਕਰਨ ਵਾਲੇ ਯੂਜ਼ਰ ਵੀ ਪ੍ਰਗਤੀ ਨੂੰ ਸਮਝ ਸਕਣ।
ਅਜੇ ਵੀ ਕੀ ਗਲਤ ਹੋ ਸਕਦਾ ਹੈ?
ਇੱਕ ਚੰਗੀ ਤਰ੍ਹਾਂ ਤਿਆਰ ਕੀਤਾ ਗਿਆ ਰੀਜ਼ਿਊਮੇਬਲ ਅਪਲੋਡ (resumable upload) ਵੀ ਕੁਝ ਐਜ ਕੇਸਾਂ (edge cases) ਵਿੱਚ ਅੜ ਸਕਦਾ ਹੈ।
ਅੱਗੇ ਕਿਸ ਚੀਜ਼ ਦਾ ਧਿਆਨ ਰੱਖਣਾ ਹੈ
ਵੈੱਬ ਪਲੇਟਫਾਰਮ ਵਿਕਸਤ ਹੋ ਰਿਹਾ ਹੈ।
ਮੁੱਖ ਗੱਲ
ਇੱਕ ਰੀਜ਼ਿਊਮੇਬਲ, ਚੰਕਡ ਅਪਲੋਡ (resumable, chunked upload) ਜੋ ਹਰ ਹਿੱਸੇ ਨੂੰ ਟ੍ਰੈਕ ਕਰਦਾ ਹੈ, ਸਟੇਟ (state) ਨੂੰ ਸਥਾਨਕ ਤੌਰ 'ਤੇ ਸਟੋਰ ਕਰਦਾ ਹੈ, ਅਤੇ ਸਮਝਦਾਰੀ ਨਾਲ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ, ਇੱਕ ਅਸਥਿਰ ਇਵੈਂਟ ਨੈੱਟਵਰਕ ਨੂੰ ਮਹਿਮਾਨਾਂ ਦੀਆਂ ਫੋਟੋਆਂ ਲਈ ਇੱਕ ਭਰੋਸੇਯੋਗ ਮਾਧਿਅਮ ਵਿੱਚ ਬਦਲ ਦਿੰਦਾ ਹੈ। ਉੱਪਰ ਦਿੱਤੀ ਚੈੱਕਲਿਸਟ ਨੂੰ ਲਾਗੂ ਕਰੋ।