પ્રોક્સી થયેલ WebSocket ફરી કનેક્ટ પછી, સેશન પણ પુનઃસ્થાપિત કરો

ફરી કનેક્ટ થવાનો કૉલબેક ચાલે છે અને નવું સોકેટ ખૂલે છે. તે ટ્રાન્સપોર્ટ રિકવરી છે. તેનો અર્થ એ નથી કે તમારી સબસ્ક્રિપ્શન, સંદેશ પુષ્ટિ અથવા એપ્લિકેશન સેશન ત્યાંથી ચાલુ રહ્યું જ્યાં અગાઉનું કનેક્શન અટક્યું હતું.

એક જ પ્રોક્સી એન્ડપોઇન્ટ પણ નવું આઉટગોઇંગ કનેક્શન બનાવી શકે છે. બદલાયેલ એક્ઝિટ IP ગંતવ્યની પોતાની સેશન નીતિ પણ સક્રિય કરી શકે છે. નવા સોકેટને નવા કનેક્શન તરીકે ગણો અને એપ્લિકેશનના દસ્તાવેજીકૃત રિકવરી વિનિમયને અનુસરો. ફરી કનેક્ટ કરતી વખતે વર્કફ્લો તેનો પ્રોક્સી માર્ગ રાખવો જોઈએ કે નહીં તે નક્કી કરો.

છેલ્લા URL કરતાં થોડું વધુ રાખો

ઉપયોગી રિકવરી સ્થિતિમાં અધિકૃત સેશન ઓળખ, ઇચ્છિત સબસ્ક્રિપ્શન, છેલ્લી પુષ્ટિ થયેલ ઘટનાનો ઓળખકર્તા અને હજી પુષ્ટિની રાહ જોતી કામગીરીનો સમાવેશ થઈ શકે છે. તે ક્ષેત્રો એપ્લિકેશન પ્રોટોકોલના છે; WebSocket સાર્વત્રિક રિઝ્યુમ ટોકન વ્યાખ્યાયિત કરતું નથી.

કર્સરથી ફરી શરૂ કરવું, નવું સ્નેપશોટ લેવું કે અંતર સ્વીકારવું તે નક્કી કરો. જો ઘટના સ્રોત કોઈ રિપ્લે ઇન્ટરફેસ આપતું ન હોય, તો ઝડપથી ફરી કનેક્ટ કરવાથી સાબિત થઈ શકતું નથી કે કોઈ સંદેશ ચૂક્યા નથી.

બે વાર મોકલવું એટલે બે વાર કરવું હોઈ શકે

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

જ્યાં ઉપલબ્ધ હોય ત્યાં સેવાના વિનંતી ઓળખકર્તા, આઇડેમ્પોટેન્સી સપોર્ટ અથવા સમાધાન પદ્ધતિનો ઉપયોગ કરો. ટ્રાન્સપોર્ટનું ફરી કનેક્શન એપ્લિકેશન ક્રિયાને ઉલટાવી શકાય તેવી બનાવી શકતું નથી કે તેને આપોઆપ નકલમુક્ત કરી શકતું નથી.

ફરી કનેક્ટ થવાના પ્રયાસો મર્યાદિત અને એપ્લિકેશનની નીતિ મુજબ ગતિમાં રાખો. RFC 6455 અસામાન્ય બંધ પછી પાછળ હટવાની સલાહ આપે છે; તરત જ ફરી પ્રયાસ કરતા ક્લાયન્ટનો સમૂહ વિક્ષેપનો ભાર વધારી શકે છે.

દરેક પ્રયાસે કયો પ્રોક્સી માર્ગ પસંદ કર્યો તે નોંધો, પણ માર્ગ રિકવરીને એપ્લિકેશન રિકવરીથી અલગ રાખો. “ફરી કનેક્ટ થયું” ઉપયોગી પુરાવો છે. “સાથે આવી ગયા અને વધુ કામ સબમિટ કરવા તૈયાર” માટે તે સ્થાપિત કરતો વધારાનો એપ્લિકેશન વિનિમય જરૂરી છે.