કોફી શોપના WiFi પર બે-ગીગાબાઇટનો વીડિયો અપલોડ કરવાનો પ્રયાસ કરવો એ માત્ર આશાવાદ જ છે. તમે પ્રોગ્રેસ બારને સિત્તેર ટકા તરફ આગળ વધતા જુઓ છો, અને પછી કનેક્શન અસ્થિર થાય છે. અપલોડ નિષ્ફળ જાય છે. જ્યારે તમે ફરીથી પ્રયાસ કરો છો, ત્યારે સર્વર એક નવી ફાઇલની અપેક્ષા રાખે છે. તમારે શૂન્યથી શરૂઆત કરવી પડે છે. યુઝર-જનરેટેડ વીડિયો હેન્ડલ કરતી એપ્લિકેશન બનાવનાર કોઈપણ વ્યક્તિ માટે, આ કોઈ અપવાદરૂપ કિસ્સો નથી. તે સામાન્ય બાબત છે. tus પ્રોટોકોલ ખાસ કરીને આ સમસ્યાને દૂર કરવા માટે બનાવવામાં આવ્યો હતો. તે એક ઓપન સ્ટાન્ડર્ડ છે જે સામાન્ય HTTP પર ચાલે છે અને અપલોડ્સને 'મેમરી' આપે છે. જ્યારે નેટવર્ક પાછું આવે છે, ત્યારે ફાઇલ ટ્રાન્સફર બરાબર ત્યાંથી જ શરૂ થાય છે જ્યાં તે અટકી હતી.

સ્ટાન્ડર્ડ અપલોડ્સ કેમ નિષ્ફળ જાય છે

સ્ટાન્ડર્ડ મલ્ટીપાર્ટ ફાઇલ અપલોડ્સ સમગ્ર પેલોડને એક સિંગલ ટ્રાન્ઝેક્શન તરીકે ગણે છે. બ્રાઉઝર અથવા એપ એક TCP કનેક્શન ખોલે છે, બાઇટ્સ સ્ટ્રીમ કરે છે, અને અંતમાં 200 OK ની અપેક્ષા રાખે છે. જો યુઝર LTE થી WiFi પર સ્વિચ કરે અથવા લેપટોપ સ્લીપ મોડમાં જાય અને કનેક્શન રીસેટ થાય, તો સર્વર પાસે એ જાણવાનો કોઈ રસ્તો નથી હોતો કે કયા બાઇટ્સ સુરક્ષિત રીતે પહોંચ્યા છે. મોટાભાગના ફ્રેમવર્ક ફક્ત અધૂરા ડેટાને ડિસ્કાર્ડ કરી દે છે. યુઝર પાસે નિષ્ફળ ફોર્મ અને ખરાબ મૂડ જ બચે છે. વીડિયો ફાઇલો આ પીડાને વધારી દે છે કારણ કે તે મોટી હોય છે, અસ્થિર નેટવર્ક પર મોબાઈલ ઉપકરણો પરથી અપલોડ કરવામાં આવે છે, અને વારંવાર એવા ફોર્મેટમાં એન્કોડ કરવામાં આવે છે જેને આખી ફાઇલ સુરક્ષિત ન હોય ત્યાં સુધી પ્રોસેસ કરી શકાતી નથી.

Tus કેવી રીતે રમત બદલે છે

Tus અપલોડને વન-શોટ ડિલિવરીને બદલે સ્ટેટફુલ (stateful) વાતચીત તરીકે ફરીથી વિચારે છે. ફાઇલને બાઇટ્સના એક સતત પ્રવાહમાં મોકલવાને બદલે, ક્લાયન્ટ પેલોડને ટુકડાઓ (chunks) માં વિભાજિત કરે છે. વધુ મહત્વનું એ છે કે, સર્વર 'ઓફસેટ' (offset) યાદ રાખે છે, એટલે કે અત્યાર સુધી તેણે કેટલા બાઇટ્સ મેળવ્યા છે તેની ચોક્કસ સંખ્યા. આ સ્ટેટ પર્સિસ્ટન્સ (state persistence) જ રિઝ્યુમ (resumption) ને શક્ય બનાવે છે. આ પ્રોટોકોલ જાણીજોઈને સરળ બનાવવામાં આવ્યો છે. તેને WebSockets, gRPC, અથવા પ્રોપ્રાઇટરી SDKs ની જરૂર નથી. તે એ જ HTTP મેથડ્સનો ઉપયોગ કરે છે જે તમે પહેલેથી જાણો છો.

રિઝ્યુમ ને સક્ષમ કરતી ત્રણ વિનંતીઓ (Requests)

દરેક tus અપલોડ એક અનુમાનિત પ્રક્રિયાને અનુસરે છે.

પ્રથમ, ક્લાયન્ટ જાણીતા tus એન્ડપોઇન્ટ પર POST રિક્વેસ્ટ મોકલે છે. હેડર્સ ફાઇલનું વર્ણન કરે છે. Upload-Length હેડર બાઇટ્સમાં અંતિમ કદ જણાવે છે, અને ફાઇલનું નામ અથવા કન્ટેન્ટ ટાઇપ જેવી વૈકલ્પિક મેટાડેટા Upload-Metadata હેડરમાં base64-એન્કોડેડ કી-વેલ્યુ જોડીઓની અલ્પવિરામથી અલગ કરેલી યાદી તરીકે જાય છે. સર્વર એક ખાલી અપલોડ રિસોર્સ બનાવે છે અને 201 Created સ્ટેટસ સાથે પ્રતિસાદ આપે છે, જેમાં એક યુનિક URL તરફ નિર્દેશ કરતું Location હેડર હોય છે. આ URL અપલોડના બાકીના જીવન માટે તેનું સરનામું છે.

હવે PATCH રિક્વેસ્ટ આવે છે. ક્લાયન્ટ તે યુનિક URL પર રો (raw) બાઈનરી ડેટાના ટુકડાઓ મોકલે છે. પેલોડ સાથે બે મહત્વપૂર્ણ હેડર્સ હોય છે. Content-Type એ application/offset+octet-stream હોવું જોઈએ, અને Upload-Offset એ બાઇટ પોઝિશન સાથે મેળ ખાવો જોઈએ જ્યાંથી આ ટુકડો શરૂ થાય છે. સર્વર ચકાસે છે કે ઓફસેટ તેના પોતાના રેકોર્ડ સાથે મેળ ખાય છે કે નહીં. જો તે મેળ ખાતો ન હોય, તો સર્વર 409 Conflict રિટર્ન કરે છે, જે કરપ્ટ સ્ટેટ સામે રક્ષણ આપે છે. જો બધું બરાબર હોય, તો સર્વર બાઇટ્સ ઉમેરે છે, તેનો આંતરિક ઓફસેટ અપડેટ કરે છે, અને નવા Upload-Offset સાથે 204 No Content પ્રતિસાદ આપે છે. ચંક સાઈઝ કન્ફિગરેબલ છે, પરંતુ સામાન્ય રીતે તે થોડા સો કિલોબાઇટ્સથી લઈને થોડા મેગાબાઇટ્સની વચ્ચે હોય છે. નાના ચંક્સ વધુ HTTP ઓવરહેડ બનાવે છે પરંતુ ભૂલોમાંથી ઝડપથી રિકવર થાય છે. મોટા ચંક્સ રાઉન્ડ ટ્રિપ્સ ઘટાડે છે પરંતુ જો તે અધવચ્ચે નિષ્ફળ જાય તો વધુ બેન્ડવિડ્થ વેડફાય છે.

અંતે, HEAD રિક્વેસ્ટ. આ એક સેફ્ટી નેટ છે. જો કોઈ PATCH ચંકની અધવચ્ચે નિષ્ફળ જાય, ધારો કે પાંચ-મેગાબાઇટના સ્લાઈસમાંથી ત્રણ મેગાબાઇટ પછી, તો કનેક્શન તૂટી જાય છે. જ્યારે ક્લાયન્ટને નેટવર્ક એક્સેસ પાછું મળે છે, ત્યારે તે અપલોડ URL પર HEAD રિક્વેસ્ટ મોકલે છે. સર્વર વર્તમાન Upload-Offset સાથે જવાબ આપે છે. ક્લાયન્ટ સરખાવે છે