ஒரு காபி ஷாப் WiFi மூலம் இரண்டு ஜிகாபைட் வீடியோவை பதிவேற்றுவது என்பது ஒரு நம்பிக்கையின் சோதனை போன்றது. புரோகிரஸ் பார் எழுபது சதவீதத்தை நோக்கி மெதுவாக நகர்வதைப் பார்த்துக் கொண்டிருக்கும்போதே, இணைப்பு துண்டிக்கப்படுகிறது. பதிவேற்றம் தோல்வியடைகிறது. நீங்கள் மீண்டும் முயற்சிக்கும்போது, சர்வர் ஒரு புதிய கோப்பையே எதிர்பார்க்கிறது. நீங்கள் மீண்டும் பூஜ்ஜியத்திலிருந்து தொடங்க வேண்டியுள்ளது. பயனர் உருவாக்கும் வீடியோக்களைக் கையாளும் ஒரு செயலியை உருவாக்கும் எவருக்கும், இது ஒரு அரிதான நிகழ்வு அல்ல; இதுவே இயல்பான ஒன்று. இந்தத் பிரச்சனையைத் தீர்ப்பதற்காகவே tus புரோட்டோகால் உருவாக்கப்பட்டது. இது சாதாரண HTTP மூலம் இயங்கும் ஒரு திறந்த தரநிலை (open standard) மற்றும் பதிவேற்றங்களுக்கு ஒரு நினைவாற்றலை (memory) வழங்குகிறது. நெட்வொர்க் மீண்டும் கிடைக்கும்போது, கோப்புப் பரிமாற்றம் சரியாக எங்கு நின்றதோ அங்கிருந்தே தொடரும்.
ஏன் சாதாரண பதிவேற்றங்கள் தோல்வியடைகின்றன
சாதாரண மல்டிபார்ட் (multipart) கோப்பு பதிவேற்றங்கள், முழுத் தரவையும் (payload) ஒரே பரிமாற்றமாக (single transaction) கருதுகின்றன. பிரவுசர் அல்லது செயலி ஒரு TCP இணைப்பைத் தொடங்கி, பைட்களை (bytes) பாய்ச்சுகிறது (streams), மேலும் இறுதியில் 200 OK என்ற பதிலை எதிர்பார்க்கிறது. பயனர் LTE-யிலிருந்து WiFi-க்கு மாறினாலோ அல்லது லேப்டாப் ஸ்லீப் (sleep) நிலைக்குச் சென்றாலோ இணைப்பு துண்டிக்கப்படலாம்; அப்போது எந்தெந்த பைட்கள் பாதுகாப்பாக வந்து சேர்ந்தன என்பதை சர்வரால் கண்டறிய முடியாது. பெரும்பாலான கட்டமைப்புகள் (frameworks) அந்தப் பகுதித் தரவை அப்படியே நீக்கிவிடுகின்றன. பயனருக்குத் தோல்வியடைந்த படிவமும் (form), மனக்கசப்பும் மட்டுமே மிஞ்சும். வீடியோ கோப்புகள் பெரியவை என்பதால், நிலையற்ற நெட்வொர்க்கில் உள்ள மொபைல் சாதனங்களிலிருந்து பதிவேற்றப்படும்போது இந்தத் தொல்லை இன்னும் அதிகமாகிறது. மேலும், முழு கோப்பும் சரியாகப் பதிவேற்றப்படும் வரை அவற்றைச் செயலாக்க முடியாத வடிவங்களில் (formats) அவை பெரும்பாலும் குறியாக்கம் (encoded) செய்யப்பட்டிருக்கும்.
Tus எவ்வாறு விளையாட்டை மாற்றுகிறது
Tus பதிவேற்றத்தை ஒருமுறை மட்டும் நடக்கும் நிகழ்வாகக் கருதாமல், ஒரு தொடர்ச்சியான உரையாடல் (stateful conversation) போல மாற்றியமைக்கிறது. ஒரு கோப்பைத் தொடர்ச்சியான பைட்களாக அனுப்பாமல், கிளையண்ட் (client) அந்தத் தரவைச் சிறு துண்டுகளாக (chunks) பிரிக்கிறது. மிக முக்கியமாக, சர்வர் இதுவரை பெற்ற பைட்களின் துல்லியமான எண்ணிக்கையை (offset) நினைவில் வைத்துக்கொள்கிறது. இந்தத் தரவுத் தொடர்ச்சிதான் (state persistence) மீண்டும் தொடங்குவதை (resumption) சாத்தியமாக்குகிறது. இந்த புரோட்டோகால் வேண்டுமென்றே எளிமையாக வடிவமைக்கப்பட்டுள்ளது. இதற்கு WebSockets, gRPC அல்லது பிரத்யேக SDK-கள் தேவையில்லை. உங்களுக்கு ஏற்கனவே தெரிந்த HTTP முறைகளையே இது பயன்படுத்துகிறது.
மீண்டும் தொடங்குவதை இயக்கும் மூன்று கோரிக்கைகள் (Requests)
ஒவ்வொரு tus பதிவேற்றமும் ஒரு கணிக்கக்கூடிய வரிசையைப் பின்பற்றுகிறது.
முதலாவதாக, கிளையண்ட் ஒரு தெரிந்த tus endpoint-க்கு POST கோரிக்கையை அனுப்புகிறது. அதன் ஹெடர்கள் (headers) கோப்பைப் பற்றிய விவரங்களைக் கூறுகின்றன. Upload-Length ஹெடர் பைட்களில் அதன் இறுதி அளவைக் குறிப்பிடுகிறது, மேலும் கோப்பின் பெயர் அல்லது உள்ளடக்க வகை (content type) போன்ற விருப்பத்தேர்வு மெட்டாடேட்டா (metadata), Upload-Metadata ஹெடரில் கமா மூலம் பிரிக்கப்பட்ட base64-குறியாக்கம் செய்யப்பட்ட key-value ஜோடிகளாகச் செல்லும். சர்வர் ஒரு காலியான பதிவேற்ற வளத்தை (upload resource) உருவாக்கி, 201 Created என்ற நிலையுடன், ஒரு தனித்துவமான URL-ஐக் காட்டும் Location ஹெடரையும் பதிலளிக்கிறது. இந்த URL தான் அந்தப் பதிவேற்றத்தின் வாழ்நாள் முழுமைக்கும் அதன் முகவரியாகும்.
அடுத்து PATCH கோரிக்கை வருகிறது. கிளையண்ட் அந்தத் தனித்துவமான URL-க்கு மூல பைனரி தரவின் (raw binary data) துண்டுகளை அனுப்புகிறது. தரவோடு (payload) இரண்டு முக்கியமான ஹெடர்கள் வருகின்றன. Content-Type என்பது application/offset+octet-stream ஆக இருக்க வேண்டும், மேலும் Upload-Offset என்பது அந்தத் துண்டு தொடங்கும் பைட் இடத்தோடு (byte position) ஒத்துப்போக வேண்டும். சர்வர் அந்த offset தனது பதிவுகளுடன் ஒத்துப்போகிறதா என்பதைச் சரிபார்க்கிறது. அப்படி இல்லையென்றால், தரவு சிதைந்துவிடாமல் இருக்க சர்வர் 409 Conflict என்ற பதிலை அளிக்கிறது. அனைத்தும் சரியாக இருந்தால், சர்வர் அந்த பைட்களைச் சேர்த்து, தனது உள் offset-ஐப் புதுப்பித்து, புதிய Upload-Offset உடன் 204 No Content என்ற பதிலை அளிக்கிறது. துண்டுகளின் அளவு (chunk size) மாற்றியமைக்கக்கூடியது, ஆனால் பொதுவாக சில நூறு கிலோபைட்டுகள் முதல் சில மெகாபைட்டுகள் வரை இருக்கும். சிறிய துண்டுகள் அதிக HTTP overhead-ஐ உருவாக்கும், ஆனால் பிழைகளிலிருந்து விரைவாக மீண்டுவிடும். பெரிய துண்டுகள் பயண நேரத்தைக் (round trips) குறைக்கும், ஆனால் அவை பாதியிலேயே தோல்வியடைந்தால் அதிக பேண்ட்வித் (bandwidth) வீணாகும்.
இறுதியாக, HEAD கோரிக்கை. இது ஒரு பாதுகாப்பு வலை (safety net). ஒரு PATCH கோரிக்கை ஒரு துண்டின் பாதியிலேயே தோல்வியடைந்தால் (உதாரணமாக, ஐந்து மெகாபைட்டில் மூன்று மெகாபைட்டிற்குப் பிறகு), இணைப்பு துண்டிக்கப்படும். கிளையண்ட் மீண்டும் நெட்வொர்க் வசதியைப் பெற்றவுடன், பதிவேற்ற URL-க்கு ஒரு HEAD கோரிக்கையை அனுப்புகிறது. சர்வர் தற்போதைய Upload-Offset-ஐப் பதிலளிக்கிறது. கிளையண்ட் ஒப்பிடுகிறது