Resumable Chunked Uploads Keep Wedding Photos Alive on Congested Wi-Fi

நிகழ்வு-புகைப்பட செயலிகளை (event-photo apps) உருவாக்கும் டெவலப்பர்களுக்கு, கூட்ட நெரிசல் மிகுந்த இடங்களில் உலாவியின் (browser) பதிவேற்றங்கள் துண்டிக்கப்படாமல் தொடரச் செய்வதற்கான ஒரு தெளிவான சரிபார்ப்புப் பட்டியல் இப்போது கிடைக்கிறது. ஒரு பயனர் Wi-Fi-லிருந்து செல்லுலார் நெட்வொர்க்கிற்கு மாறலாம், அதே நேரத்தில் டஜன் கணக்கான சாதனங்கள் ஒரே ஹாட்ஸ்பாட்டைப் பயன்படுத்தப் போட்டியிடலாம். விருந்தினர் தனது ஃபோனை லாக் செய்தாலோ அல்லது நெட்வொர்க்கில் தடங்கல் ஏற்பட்டாலோ கூட, ஒரு புகைப்படம் “upload complete” என்ற அறிவிப்பு வந்த பிறகு காணாமல் போகாமல் தடுப்பது எப்படி என்பதை இந்த வழிகாட்டி காட்டுகிறது.

திருமணங்கள் மற்றும் திருவிழாக்களில் சாதாரண பதிவேற்றங்கள் ஏன் தோல்வியடைகின்றன

ஒரு அலுவலகத்தில், லேப்டாப் நிலையான ஈதர்நெட் (Ethernet) இணைப்பில் இருக்கும்போது ஒரு பயனர் “send” என்பதைக் கிளிக் செய்கிறார். ஆனால் ஒரு திருமண வரவேற்பு அல்லது இசைத் திருவிழாவில், அதே செயல் தொடர்ச்சியான சிக்கல்களைத் தூண்டலாம்: விருந்தினர் சடங்கு நடைபெறும் மண்டபத்திலிருந்து பார்க்கிங் பகுதிக்கு நடக்கலாம், நூற்றுக்கணக்கான ஃபோன்களால் ரூட்டர் திணறலாம், அல்லது ஃபோன் Wi-Fi இணைப்பை இழந்து செல்லுலார் நெட்வொர்க்கிற்கு மாறலாம். உலாவியானது ஒவ்வொரு பைட்டையும் சர்வருக்கு அனுப்பியிருக்கலாம், ஆனால் சர்வர் இன்னும் கோப்பைச் சேமிப்பகத்தில் (storage) பதிவு செய்திருக்காது. முன்னேற்றப் பட்டி (progress bar) 100% எட்டியவுடன் UI வெற்றியை அறிவித்தால், விருந்தினர் அந்தப் புகைப்படத்தை நீக்கிவிடலாம், இதனால் ஒருங்கிணைப்பாளருக்கு ஒரு கோப்பு விடுபட்டுவிடும்.

“வெறுமனே பதிவேற்று” (just upload) என்பதன் மறைமுகச் செலவு

ஒரு எளிமையான அணுகுமுறை, பதிவேற்றத்தை ஒற்றை HTTP POST ஆகக் கருதுகிறது. இணைப்பு நிலையாக இருக்கும்போது இது வேலை செய்யும், ஆனால் நெரிசலான நெட்வொர்க்கில் ஒவ்வொரு தடங்கலும் முழு கோப்பையும் மீண்டும் ஆரம்பத்திலிருந்து பதிவேற்றத் தூண்டும். டஜன் கணக்கான ஃபோன்கள் ஒரே நேரத்தில் மீண்டும் முயற்சிக்கும்போது பயனர்கள் விரக்தியடைகிறார்கள் மற்றும் பேண்ட்வித் (bandwidth) பயன்பாடு திடீரென அதிகரிக்கிறது. கோப்பைத் துண்டுகளாகப் பிரித்து (chunks), ஒவ்வொரு துண்டையும் கண்காணிப்பது சிக்கலைச் சேர்க்கலாம், ஆனால் அதன் பலன் நெட்வொர்க் மாற்றங்களிலும் தடையின்றிச் செயல்படும் ஒரு நிலையான, குறைந்த சுமை கொண்ட பரிமாற்றமாகும்.

மீண்டும் தொடரக்கூடிய, துண்டுகளாகப் பதிவேற்றும் முறையை உருவாக்குதல்

கீழே கொடுக்கப்பட்டுள்ளவை நடைமுறை ரீதியான, படிப்படியான வழிமுறைகள்.

1. தரவு உலாவியை விட்டு வெளியேறுவதற்கு முன்பே ஒரு பதிவேற்ற ஐடியை (upload ID) உருவாக்குங்கள்

உள்ளூர் அளவில் ஒரு உலகளாவிய தனித்துவ அடையாளங்காட்டியை (UUID) உருவாக்கி, அதை முதல் கோரிக்கையாக சர்வருக்கு அனுப்பவும். சர்வர் அந்த ஐடியின் கீழ் ஒரு அமர்வை (session) பதிவு செய்யும். காலாவதி (timeout) காரணமாக உலாவியானது பின்னர் மீண்டும் முயற்சிக்கும்போது, அதே UUID-ஐ உள்ளடக்கியிருக்கும், இது சர்வர் அந்த அமர்வை அடையாளம் கண்டு நகல் பதிவுகளைத் தவிர்க்க உதவும். இது பணிப்பாய்வை ஐடெம்போடென்ட் (idempotent) ஆக்குகிறது—அதாவது ஒரே கோரிக்கையைத் திரும்பத் திரும்பச் செய்தாலும் எந்தப் பாதிப்பும் ஏற்படாது.

2. கோப்பை 5 – 10 MB துண்டுகளாகப் பிரியுங்கள்

துண்டுகளின் அளவு என்பது ஒரு சமநிலை (trade-off) சார்ந்த விஷயம். சிறிய துண்டுகள் (1 MB-க்கும் குறைவானவை) HTTP கோரிக்கைகளின் எண்ணிக்கையையும் அதனுடன் தொடர்புடைய ஹெடர் ஓவர்ஹெட் (header overhead) அளவையும் அதிகரிக்கும். மிகப் பெரிய துண்டுகள் எந்தவொரு தடங்கலையும் செலவு மிக்கதாக்கும், ஏனெனில் கிளையண்ட் ஒரு பெரிய பகுதியை மீண்டும் அனுப்ப வேண்டியிருக்கும். பொதுவான புகைப்படங்கள் மற்றும் குறுகிய வீடியோக்களுக்கு, 5 – 10 MB என்பது ஒரு சரியான சமநிலையைத் தருகிறது: ஒவ்வொரு கோரிக்கையும் UI-ஐத் தடையின்றி வைத்திருக்க போதுமான வேகத்தில் முடிவடைகிறது, அதே சமயம் கோரிக்கைகளின் எண்ணிக்கையும் கட்டுப்படியாகக் கூடிய அளவில் இருக்கும்.

3. இணையான பதிவேற்றங்களின் (parallel uploads) எண்ணிக்கையைக் கட்டுப்படுத்துங்கள்

மொபைல் உலாவிகள் பல இணைப்புகளைத் திறக்க முடியும், ஆனால் நெரிசலான Wi-Fi நெட்வொர்க்கில் ஒவ்வொரு கூடுதல் இணைப்பும் குறைந்த பேண்ட்வித்ஸிற்காகப் போட்டியிடும். எட்டு இணைப்புகள் போட்டியிடுவதை விட, இரண்டு நிலையான இணைப்புகள் சிறப்பாகச் செயல்படும். குறைந்த பேண்ட்வித் நிலைகளைக் கண்டறிந்து, தானாகவே இணையான செயல்பாடுகளைக் (concurrency) குறைக்க navigator.connection API-ஐப் பயன்படுத்தவும்.

4. IndexedDB-இல் பதிவேற்ற நிலையைச் சேமிக்கவும்

பதிவேற்ற ஐடி, ஏற்கனவே அனுப்பப்பட்ட துண்டுகளின் பட்டியல் மற்றும் சர்வரால் அங்கீகரிக்கப்பட்ட ஆஃப்செட்டுகள் (offsets) ஆகியவற்றை உலாவியின் IndexedDB-இல் சேமிக்கவும். பக்கம் ரீலோட் செய்யப்பட்டாலோ அல்லது பயனர் டேப்பை மூடினாலோ, அடுத்த முறை பக்கம் திறக்கும்போது கிளையண்ட் அந்த நிலையை மீட்டெடுக்க முடியும். பயனர் பக்கத்தை மீண்டும் திறக்கும்போது, அதே கோப்பைத் தேர்ந்தெடுக்கச் சொல்லவும்; சேமிக்கப்பட்ட மெட்டாடேட்டா (metadata) பதிவேற்றத்தை மீண்டும் ஆரம்பத்திலிருந்து தொடங்காமல், கடைசியாக உறுதி செய்யப்பட்ட துண்டிலிருந்து தொடர உதவும்.

5. navigator.onLine-ஐ மட்டும் பார்க்காமல், உண்மையான நெட்வொர்க் மாற்றங்களைக் கண்டறியவும்

navigator.onLine ஃபிளாக் பெரும்பாலும் இணைப்பு பயன்படுத்த முடியாத நிலையிலும் கூட “online” என்று காட்டக்கூடும். அதற்குப் பதிலாக, ஒவ்வொரு துண்டிற்கும் ஒரு குறுகிய கோரிக்கை காலாவதி நேரத்தை (உதாரணமாக, 5 வினாடிகள்) அமைக்கவும். காலாவதி ஏற்பட்டால், நெட்வொர்க் துண்டிக்கப்பட்டதாகக் கருதவும். இணைப்பு திரும்பும்போது, சர்வரிடம் ஏற்கனவே உள்ள துண்டுகளின் பட்டியலைக் கேட்டு, விடுபட்ட துண்டுகளை மட்டும் பதிவேற்றத் தொடரவும். இது ஒரு சிறியத் தடங்கலுக்குப் பிறகு நகல் தரவுகளை அனுப்புவதைத் தவிர்க்கிறது.

6. மீண்டும் முயற்சிகளுக்கு (retries) 'exponential backoff with jitter'-ஐப் பயன்படுத்தவும்

நெட்வொர்க் மீண்டும் கிடைப்பதை பல விருந்தினர்களின் சாதனங்கள் உணரும்போது, அவை அனைத்தும் ஒரே நேரத்தில் மீண்டும் முயற்சித்தால் சர்வர் முடங்கிவிடக்கூடும். 'Exponential backoff' ஒவ்வொரு முறையும் முந்தைய முறையை விட அதிக நேரம் காத்திருக்கச் செய்கிறது, அதே சமயம் 'jitter' என்பது ஒரு சீரற்ற சிறிய கால இடைவெளியைச் சேர்க்கிறது. இந்தத் தொகுப்பு மீண்டும் முயற்சிக்கும் டிராஃபிக்கை சில வினாடிகளுக்குப் பரவச் செய்து, திடீர் அதிகரிப்பைத் தடுக்கிறது.

7. அடுக்குமுறை மற்றும் எளிதில் அணுகக்கூடிய பின்னூட்டத்தைக் காட்டவும்

மூன்று நிலைகளைக் கொண்ட ஒரு நிலைத் தடி (status bar) கோப்பின் உண்மையான நிலையைத் தெரிவிக்கும்:

• Received – சர்வர் ஒவ்வொரு துண்டையும் சேமித்து, கோப்பு முழுமையாக முடிவடைந்ததாகக் குறித்துக் கொண்டுள்ளது.
• Preparing – சர்வர் தம்ப்நெயில்களை (thumbnails) உருவாக்கி வருகிறது அல்லது வீடியோவை டிரான்ஸ்கோடிங் (transcoding) செய்கிறது.
• Available – ஒருங்கிணைப்பாளர் கோப்பைப் பார்க்கவோ அல்லது பதிவிறக்கம் செய்யவோ முடியும்.

நிறத்தை மட்டும் நம்பியிருப்பதைத் தவிர்க்கவும்; திரை வாசகர் (screen-reader) பயனர்களும் முன்னேற்றத்தைப் புரிந்துகொள்ளும் வகையில், சின்னங்களுடன் (icons) சுருக்கமான உரையை இணைக்கவும்.

இன்னும் என்ன தவறுகள் நடக்கலாம்?

நன்கு வடிவமைக்கப்பட்ட மீண்டும் தொடங்கக்கூடிய பதிவேற்றம் (resumable upload) கூட சில விதிவிலக்கான சூழல்களில் (edge cases) சிக்கல்களைச் சந்திக்கலாம்.

அடுத்து எதைக் கவனிக்க வேண்டும்

வெப் பிளாட்ஃபார்ம் (web platform) தொடர்ந்து வளர்ந்து வருகிறது.

முக்கியக் கருத்து

ஒவ்வொரு பகுதியையும் கண்காணிக்கும், நிலையை உள்ளூரிலேயே (locally) சேமிக்கும் மற்றும் புத்திசாலித்தனமாக மீண்டும் முயற்சிக்கும் ஒரு மீண்டும் தொடங்கக்கூடிய, துண்டுகளாகப் பிரிக்கப்பட்ட பதிவேற்றம் (resumable, chunked upload), ஒரு நிலையற்ற நிகழ்வு நெட்வொர்க்கை விருந்தினரின் புகைப்படங்களுக்கான ஒரு நம்பகமான வழியாக மாற்றுகிறது. மேலே உள்ள சரிபார்ப்புப் பட்டியலைப் பயன்படுத்தவும்.