ಈವೆಂಟ್-ಫೋಟೋ ಆಪ್ಗಳ (event-photo apps) ಡೆವಲಪರ್ಗಳಿಗೆ ಈಗ ಜನಸಂದಣಿ ಇರುವ ಸ್ಥಳಗಳಲ್ಲಿ ಬ್ರೌಸರ್ ಅಪ್ಲೋಡ್ಗಳು ಸ್ಥಗಿತಗೊಳ್ಳದಂತೆ ನೋಡಿಕೊಳ್ಳಲು ಒಂದು ಸ್ಪಷ್ಟವಾದ ಪರಿಶೀಲನಾ ಪಟ್ಟಿ (checklist) ಲಭ್ಯವಿದೆ. ಒಬ್ಬ ಬಳಕೆದಾರ ವೈ-ಫೈ ಇಂದ ಸೆಲ್ಯುಲರ್ ನೆಟ್ವರ್ಕ್ಗೆ ಬದಲಾಗಬಹುದು ಮತ್ತು ಏಕಕಾಲದಲ್ಲಿ ಡಜನ್ಗಟ್ಟಲೆ ಸಾಧನಗಳು ಒಂದೇ ಹಾಟ್ಸ್ಪಾಟ್ಗಾಗಿ ಸ್ಪರ್ಧಿಸಬಹುದು. ಅತಿಥಿಯು ಫೋನ್ ಅನ್ನು ಲಾಕ್ ಮಾಡಿದರೂ ಅಥವಾ ನೆಟ್ವರ್ಕ್ ಏರುಪೇರಾದರೂ, “upload complete” ಎಂಬ ಟೋಸ್ಟ್ (toast) ಸಂದೇಶ ಬಂದ ನಂತರವೂ ಫೋಟೋ ಕಣ್ಮರೆಯಾಗದಂತೆ ತಡೆಯುವುದು ಹೇಗೆ ಎಂಬುದನ್ನು ಈ ಮಾರ್ಗದರ್ಶಿ ತೋರಿಸುತ್ತದೆ.
ಮದುವೆ ಮತ್ತು ಹಬ್ಬಗಳಲ್ಲಿ ಸಾಮಾನ್ಯ ಅಪ್ಲೋಡ್ಗಳು ಏಕೆ ವಿಫಲವಾಗುತ್ತವೆ
ಕಚೇರಿಯಲ್ಲಿ, ಲ್ಯಾಪ್ಟಾಪ್ ಒಂದು ಸ್ಥಿರವಾದ ಇಥರ್ನೆಟ್ (Ethernet) ಸಂಪರ್ಕದಲ್ಲಿರುತ್ತದೆ ಮತ್ತು ಒಬ್ಬ ಬಳಕೆದಾರ ಕೇವಲ “send” ಕ್ಲಿಕ್ ಮಾಡುತ್ತಾನೆ. ಆದರೆ ಮದುವೆಯ ಸಮಾರಂಭ ಅಥವಾ ಸಂಗೀತ ಹಬ್ಬದಲ್ಲಿ, ಅದೇ ಕ್ರಿಯೆಯು ಸಮಸ್ಯೆಗಳ ಸರಮಾಲೆಯನ್ನು ಉಂಟುಮಾಡಬಹುದು: ಅತಿಥಿಯು ಸಮಾರಂಭದ ಹಾಲ್ನಿಂದ ಪಾರ್ಕಿಂಗ್ ಲಾಟ್ಗೆ ನಡೆಯಬಹುದು, ನೂರಾರು ಫೋನ್ಗಳಿಂದಾಗಿ ರೂಟರ್ ಕಾರ್ಯನಿರ್ವಹಿಸಲು ಕಷ್ಟವಾಗಬಹುದು, ಅಥವಾ ಫೋನ್ ವೈ-ಫೈ ಸಂಪರ್ಕ ಕಳೆದುಕೊಂಡು ಸೆಲ್ಯುಲರ್ ನೆಟ್ವರ್ಕ್ಗೆ ಬದಲಾಗಬಹುದು. ಬ್ರೌಸರ್ ಪ್ರತಿಯೊಂದು ಬೈಟ್ ಅನ್ನು ಸರ್ವರ್ಗೆ ಕಳುಹಿಸಿರಬಹುದು, ಆದರೆ ಸರ್ವರ್ ಇನ್ನೂ ಆ ಫೈಲ್ ಅನ್ನು ಸ್ಟೋರೇಜ್ಗೆ ಉಳಿಸಿರಲಿಕ್ಕಿಲ್ಲ (commit). ಪ್ರೋಗ್ರೆಸ್ ಬಾರ್ 100% ತಲುಪಿದ ತಕ್ಷಣವೇ UI ಯಶಸ್ಸನ್ನು ಘೋಷಿಸಿದರೆ, ಅತಿಥಿಯು ಫೋಟೋವನ್ನು ಡಿಲೀಟ್ ಮಾಡಬಹುದು, ಇದರಿಂದ ಆಯೋಜಕರಿಗೆ ಫೈಲ್ ಸಿಗದೆ ಹೋಗುವ ಸಾಧ್ಯತೆ ಇರುತ್ತದೆ.
"ಕೇವಲ ಅಪ್ಲೋಡ್ ಮಾಡಿ" ಎಂಬ ತಪ್ಪು ಕಲ್ಪನೆಯ ಅಡಗಿರುವ ವೆಚ್ಚ
ಸರಳವಾದ ವಿಧಾನವು ಅಪ್ಲೋಡ್ ಅನ್ನು ಒಂದೇ ಒಂದು HTTP POST ಎಂದು ಪರಿಗಣಿಸುತ್ತದೆ. ಸಂಪರ್ಕವು ಸ್ಥಿರವಾಗಿದ್ದಾಗ ಇದು ಕೆಲಸ ಮಾಡುತ್ತದೆ, ಆದರೆ ದಟ್ಟಣೆಯಾದ ನೆಟ್ವರ್ಕ್ನಲ್ಲಿ ಪ್ರತಿ ಅಡಚಣೆಯು ಇಡೀ ಫೈಲ್ ಅನ್ನು ಮೊದಲಿನಿಂದಲೇ ಮತ್ತೆ ಪ್ರಾರಂಭಿಸಲು ಒತ್ತಾಯಿಸುತ್ತದೆ. ಡಜನ್ಗಟ್ಟಲೆ ಫೋನ್ಗಳು ಏಕಕಾಲದಲ್ಲಿ ಮರುಪ್ರಯತ್ನ ಮಾಡಿದಾಗ ಬಳಕೆದಾರರು ಹತಾಶರಾಗುತ್ತಾರೆ ಮತ್ತು ಬ್ಯಾಂಡ್ವಿಡ್ತ್ ಏರಿಕೆ ಉಂಟಾಗುತ್ತದೆ. ಫೈಲ್ ಅನ್ನು ತುಣುಕುಗಳಾಗಿ (chunks) ವಿಂಗಡಿಸುವುದು ಮತ್ತು ಪ್ರತಿ ಭಾಗವನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡುವುದು ಸಂಕೀರ್ಣತೆಯನ್ನು ಹೆಚ್ಚಿಸುತ್ತದೆ, ಆದರೆ ಇದರ ಪ್ರಯೋಜನವೆಂದರೆ ನೆಟ್ವರ್ಕ್ ಬದಲಾವಣೆಗಳ ನಡುವೆಯೂ ಸ್ಥಿರವಾಗಿ ಮತ್ತು ಕಡಿಮೆ ಹೊರೆಯಾಗುವಂತೆ (low-overhead) ವರ್ಗಾವಣೆಯನ್ನು ಮಾಡಬಹುದು.
ಪುನರಾರಂಭಿಸಬಹುದಾದ (resumable), ತುಣುಕುಗಳ ರೂಪದ (chunked) ಅಪ್ಲೋಡ್ ವ್ಯವಸ್ಥೆಯನ್ನು ನಿರ್ಮಿಸುವುದು
ಕೆಳಗೆ ಒಂದು ಪ್ರಾಯೋಗಿಕ, ಹಂತ-ಹಂತದ ವಿಧಾನವಿದೆ.
1. ಯಾವುದೇ ಡೇಟಾ ಬ್ರೌಸರ್ನಿಂದ ಹೊರಹೋಗುವ ಮೊದಲು ಅಪ್ಲೋಡ್ ಐಡಿಯನ್ನು (upload ID) ಸೃಷ್ಟಿಸಿ
ಸ್ಥಳೀಯವಾಗಿ ಒಂದು ಯುನಿವರ್ಸಲಿ ಯೂನಿಕ್ ಐಡেন্টিಫೈಯರ್ (UUID) ಅನ್ನು ರಚಿಸಿ ಮತ್ತು ಅದನ್ನು ಮೊದಲ ವಿನಂತಿಯಾಗಿ ಸರ್ವರ್ಗೆ ಕಳುಹಿಸಿ. ಸರ್ವರ್ ಆ ಐಡಿಯ ಅಡಿಯಲ್ಲಿ ಒಂದು ಸೆಷನ್ ಅನ್ನು ದಾಖಲಿಸುತ್ತದೆ. ನಂತರ ಟೈಮೌಟ್ ಕಾರಣದಿಂದ ಬ್ರೌಸರ್ ಮರುಪ್ರಯತ್ನ ಮಾಡಿದರೆ, ಅದು ಅದೇ UUID ಅನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ, ಇದು ಸರ್ವರ್ಗೆ ಸೆಷನ್ ಅನ್ನು ಗುರುತಿಸಲು ಮತ್ತು ಡ್ಯುಪ್ಲಿಕೇಟ್ ಎಂಟ್ರಿಯನ್ನು ತಪ್ಪಿಸಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ. ಇದು ವರ್ಕ್ಫ್ಲೋ ಅನ್ನು ಐಡೆಂಪೊಟೆಂಟ್ (idempotent) ಮಾಡುತ್ತದೆ—ಅಂದರೆ ಒಂದೇ ವಿನಂತಿಯನ್ನು ಪದೇ ಪದೇ ಮಾಡಿದರೂ ಯಾವುದೇ ಅಡ್ಡಪರಿಣಾಮ ಬೀರದು.
2. ಫೈಲ್ ಅನ್ನು 5 – 10 MB ತುಣುಕುಗಳಾಗಿ (chunks) ವಿಂಗಡಿಸಿ
ಚಂಕ್ ಗಾತ್ರವು ಒಂದು ಸಮತೋಲನವಾಗಿದೆ. ಸಣ್ಣ ಚಂಕ್ಗಳು (1 MB ಗಿಂತ ಕಡಿಮೆ) HTTP ವಿನಂತಿಗಳ ಸಂಖ್ಯೆ ಮತ್ತು ಅದಕ್ಕೆ ಸಂಬಂಧಿಸಿದ ಹೆಡರ್ ಓವರ್ಹೆಡ್ ಅನ್ನು ಹೆಚ್ಚಿಸುತ್ತವೆ. ಅತೀ ದೊಡ್ಡ ಚಂಕ್ಗಳು ಯಾವುದೇ ಅಡಚಣೆಯನ್ನು ಉಂಟುಮಾಡಿದರೆ ಅದು ಹೆಚ್ಚು ವೆಚ್ಚದಾಯಕವಾಗುತ್ತದೆ, ಏಕೆಂದರೆ ಕ್ಲೈಂಟ್ ದೊಡ್ಡ ಭಾಗವನ್ನು ಮತ್ತೆ ಕಳುಹಿಸಬೇಕಾಗುತ್ತದೆ. ಸಾಮಾನ್ಯ ಫೋಟೋಗಳು ಮತ್ತು ಸಣ್ಣ ವೀಡಿಯೊಗಳಿಗೆ, 5 – 10 MB ಗಾತ್ರವು ಸಮತೋಲನವನ್ನು ಕಾಯ್ದುಕೊಳ್ಳುತ್ತದೆ: ಪ್ರತಿ ವಿನಂತಿಯು UI ಪ್ರತಿಕ್ರಿಯಿಸುವಂತೆ ವೇಗವಾಗಿ ಮುಕ್ತಾಯಗೊಳ್ಳುತ್ತದೆ ಮತ್ತು ವಿನಂತಿಗಳ ಸಂಖ್ಯೆಯೂ ನಿಯಂತ್ರಣದಲ್ಲಿರುತ್ತದೆ.
3. ಸಮಾಂತರ ಅಪ್ಲೋಡ್ಗಳ ಸಂಖ್ಯೆಯನ್ನು ಮಿತಿಗೊಳಿಸಿ
ಮೊಬೈಲ್ ಬ್ರೌಸರ್ಗಳು ಅನೇಕ ಸಂಪರ್ಕಗಳನ್ನು ತೆರೆಯಬಹುದು, ಆದರೆ ದಟ್ಟಣೆಯಾದ ವೈ-ಫೈ ನೆಟ್ವರ್ಕ್ನಲ್ಲಿ ಪ್ರತಿ ಹೆಚ್ಚುವರಿ ಸ್ಟ್ರೀಮ್ ಕೂಡ ಸೀಮಿತ ಬ್ಯಾಂಡ್ವಿಡ್ತ್ಗಾಗಿ ಸ್ಪರ್ಧಿಸುತ್ತದೆ. ಎಂಟು ಸ್ಪರ್ಧಿಸುವ ಸ್ಟ್ರೀಮ್ಗಳಿಗಿಂತ ಎರಡು ಸ್ಥಿರವಾದ ಸ್ಟ್ರೀಮ್ಗಳು ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ. ಕಡಿಮೆ ಬ್ಯಾಂಡ್ವಿಡ್ತ್ ಪರಿಸ್ಥಿತಿಗಳನ್ನು ಪತ್ತೆಹಚ್ಚಲು ಮತ್ತು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಏಕಕಾಲಿಕ ಪ್ರಕ್ರಿಯೆಗಳನ್ನು (concurrency) ಕಡಿಮೆ ಮಾಡಲು navigator.connection API ಬಳಸಿ.
4. IndexedDB ನಲ್ಲಿ ಅಪ್ಲೋಡ್ ಸ್ಥಿತಿಯನ್ನು ಉಳಿಸಿ
ಅಪ್ಲೋಡ್ ಐಡಿ, ಈಗಾಗಲೇ ಕಳುಹಿಸಲಾದ ಚಂಕ್ಗಳ ಪಟ್ಟಿ ಮತ್ತು ಸರ್ವರ್ ಅಂಗೀಕರಿಸಿದ ಆಫ್ಸೆಟ್ಗಳನ್ನು (offsets) ಬ್ರೌಸರ್ನ IndexedDB ನಲ್ಲಿ ಸಂಗ್ರಹಿಸಿ. ಪೇಜ್ ರಿಲೋಡ್ ಆದಾಗ ಅಥವಾ ಬಳಕೆದಾರರು ಟ್ಯಾಬ್ ಅನ್ನು ಮುಚ್ಚಿದಾಗ, ಮುಂದಿನ ಲೋಡ್ನಲ್ಲಿ ಕ್ಲೈಂಟ್ ಈ ಸ್ಥಿತಿಯನ್ನು ಮರಳಿ ಪಡೆಯಬಹುದು. ಬಳಕೆದಾರರು ಪೇಜನ್ನು ಮರುಪರಿಶೀಲಿಸಿದಾಗ, ಅದೇ ಫೈಲ್ ಅನ್ನು ಆಯ್ಕೆ ಮಾಡಲು ಅವರಿಗೆ ಸೂಚಿಸಿ; ಸಂಗ್ರಹಿಸಲಾದ ಮೆಟಾಡೇಟಾವು ಅಪ್ಲೋಡ್ ಅನ್ನು ಮೊದಲಿನಿಂದ ಪ್ರಾರಂಭಿಸುವ ಬದಲು ಕೊನೆಯ ದೃಢೀಕರಿಸಿದ ಚಂಕ್ನಿಂದ ಪುನರಾರಂಭಿಸಲು ಅನುಮತಿಸುತ್ತದೆ.
5. ಕೇವಲ navigator.onLine ಮಾತ್ರವಲ್ಲದೆ, ನೈಜ ನೆಟ್ವರ್ಕ್ ಬದಲಾವಣೆಗಳನ್ನು ಪತ್ತೆಹಚ್ಚಿ
ಸಂಪರ್ಕ ಬಳಕೆಗೆ ಯೋಗ್ಯವಾಗಿಲ್ಲದಿದ್ದರೂ ಸಹ navigator.onLine ಫ್ಲಾಗ್ ಹೆಚ್ಚಾಗಿ “online” ಎಂದು ವರದಿ ಮಾಡುತ್ತದೆ. ಬದಲಾಗಿ, ಪ್ರತಿ ಚಂಕ್ಗೆ ಒಂದು ಸಣ್ಣ ವಿನಂತಿ ಟೈಮೌಟ್ (ಉದಾಹರಣೆಗೆ 5 ಸೆಕೆಂಡುಗಳು) ನಿಗದಿಪಡಿಸಿ. ಟೈಮೌಟ್ ಸಂಭವಿಸಿದರೆ, ನೆಟ್ವರ್ಕ್ ಇಲ್ಲವೆಂದು ಪರಿಗಣಿಸಿ. ಸಂಪರ್ಕ ಮರಳಿ ಬಂದಾಗ, ಸರ್ವರ್ ಬಳಿ ಈಗಾಗಲೇ ಯಾವ ಚಂಕ್ಗಳಿವೆ ಎಂದು ವಿಚಾರಿಸಿ, ನಂತರ ಕೇವಲ ಬಿಟ್ಟುಹೋದ ಭಾಗಗಳನ್ನು ಮಾತ್ರ ಅಪ್ಲೋಡ್ ಮಾಡಲು ಮುಂದುವರಿಯಿರಿ. ಇದು ಅಲ್ಪಾವಧಿಯ ಸಂಪರ್ಕ ಕಡಿತದ ನಂತರ ಡ್ಯುಪ್ಲಿಕೇಟ್ ಡೇಟಾವನ್ನು ಕಳುಹಿಸುವುದನ್ನು ತಪ್ಪಿಸುತ್ತದೆ.
6. ಮರುಪ್ರಯತ್ನಗಳಿಗಾಗಿ (retries) 'exponential backoff with jitter' ಅನ್ವಯಿಸಿ
ಅನೇಕ ಅತಿಥಿಗಳ ಸಾಧನಗಳು ನೆಟ್ವರ್ಕ್ ಮರಳಿ ಬಂದಿರುವುದನ್ನು ಗಮನಿಸಿದಾಗ, ಅವೆಲ್ಲವೂ ಒಂದೇ ಕ್ಷಣದಲ್ಲಿ ಮರುಪ್ರಯತ್ನಗಳನ್ನು ಪ್ರಾರಂಭಿಸಬಹುದು, ಇದು ಸರ್ವರ್ ಮೇಲೆ ಅತಿಯಾದ ಒತ್ತಡವನ್ನು ಉಂಟುಮಾಡಬಹುದು. ಎಕ್ಸ್ಪೊನೆನ್ಶಿಯಲ್ ಬ್ಯಾಕ್ಆಫ್ (Exponential backoff) ಪ್ರತಿ ಮರುಪ್ರಯತ್ನವನ್ನು ಹಿಂದಿನದಕ್ಕಿಂತ ಹೆಚ್ಚು ಸಮಯ ಕಾಯುವಂತೆ ಮಾಡುತ್ತದೆ, ಮತ್ತು ಜಿಟ್ಟರ್ (jitter) ಒಂದು ಯಾದೃಚ್ಛಿಕ ಸಣ್ಣ ವ್ಯತ್ಯಾಸವನ್ನು ಸೇರಿಸುತ್ತದೆ. ಈ ಸಂಯೋಜನೆಯು ಮರುಪ್ರಯತ್ನದ ಟ್ರಾಫಿಕ್ ಅನ್ನು ಕೆಲವು ಸೆಕೆಂಡುಗಳ ಕಾಲ ಹರಡುತ್ತದೆ, ಇದರಿಂದ ಹಠಾತ್ ಏರಿಕೆಯನ್ನು ತಡೆಯಬಹುದು.
7. ಹಂತ ಹಂತವಾದ, ಸುಲಭವಾಗಿ ಅರ್ಥವಾಗುವ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು (feedback) ತೋರಿಸಿ
ಮೂರು ಹಂತದ ಸ್ಟೇಟಸ್ ಬಾರ್ ಫೈಲ್ನ ನೈಜ ಸ್ಥಿತಿಯನ್ನು ತಿಳಿಸುತ್ತದೆ:
- Received – ಸರ್ವರ್ ಪ್ರತಿಯೊಂದು ಚಂಕ್ ಅನ್ನು ಸಂಗ್ರಹಿಸಿದೆ ಮತ್ತು ಫೈಲ್ ಅನ್ನು ಪೂರ್ಣಗೊಂಡಿದೆ ಎಂದು ಗುರುತಿಸಿದೆ.
- Preparing – ಸರ್ವರ್ ಥಂಬ್ನೈಲ್ಗಳನ್ನು ಸಿದ್ಧಪಡಿಸುತ್ತಿದೆ ಅಥವಾ ವೀಡಿಯೊವನ್ನು ಟ್ರಾನ್ಸ್ಕೋಡ್ ಮಾಡುತ್ತಿದೆ.
- Available – ಆಯೋಜಕರು ಫೈಲ್ ಅನ್ನು ವೀಕ್ಷಿಸಬಹುದು ಅಥವಾ ಡೌನ್ಲೋಡ್ ಮಾಡಬಹುದು.
ಕೇವಲ ಬಣ್ಣದ ಮೇಲೆ ಅವಲಂಬಿತವಾಗುವುದನ್ನು ತಪ್ಪಿಸಿ; ಐಕಾನ್ಗಳೊಂದಿಗೆ ಸಂಕ್ಷಿಪ್ತ ಪಠ್ಯವನ್ನು ಜೋಡಿಸಿ, ಇದರಿಂದ ಸ್ಕ್ರೀನ್-ರೀಡರ್ ಬಳಕೆದಾರರು ಕೂಡ ಪ್ರಗತಿಯನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬಹುದು.
ಇನ್ನೂ ಏನೇನು ತಪ್ಪಾಗಬಹುದು?
ಉತ್ತಮವಾಗಿ ವಿನ್ಯಾಸಗೊಳಿಸಲಾದ resumable upload ಕೂಡ ಕೆಲವು edge cases ನಲ್ಲಿ ಎಡವುವ ಸಾಧ್ಯತೆ ಇರುತ್ತದೆ.
ಮುಂದೆ ಯಾವುದನ್ನು ಗಮನಿಸಬೇಕು
ವೆಬ್ ಪ್ಲಾಟ್ಫಾರ್ಮ್ ವಿಕಸನಗೊಳ್ಳುತ್ತಿದೆ.
ಸಾರಾಂಶ
ಪ್ರತಿಯೊಂದು ಭಾಗವನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡುವ, ಸ್ಥಿತಿಯನ್ನು (state) ಸ್ಥಳೀಯವಾಗಿ ಸಂಗ್ರಹಿಸುವ ಮತ್ತು ಬುದ್ಧಿವಂತಿಕೆಯಿಂದ ಮರುಪ್ರಯತ್ನಿಸುವ (retry) ಒಂದು resumable, chunked upload ವ್ಯವಸ್ಥೆಯು, ಅಸ್ಥಿರವಾದ ಇವೆಂಟ್ ನೆಟ್ವರ್ಕ್ ಅನ್ನು ಅತಿಥಿಗಳ ಫೋಟೋಗಳಿಗಾಗಿ ವಿಶ್ವಾಸಾರ್ಹ ಮಾರ್ಗವನ್ನಾಗಿ ಪರಿವರ್ತಿಸುತ್ತದೆ. ಮೇಲಿನ ಪರಿಶೀಲನಾ ಪಟ್ಟಿಯನ್ನು ಅನುಷ್ಠಾನಗೊಳಿಸಿ.