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

TCP ટનલ સ્થપાયા પછી SOCKS તેની અંદરના સંદેશાઓ વ્યાખ્યાયિત કરતું નથી. લક્ષ્ય પહેલા મોકલી શકે છે. બંને બાજુઓ સ્વતંત્ર રીતે મોકલી શકે છે. એક બાજુ ટૂંકું રેકોર્ડ મોકલીને પછી બીજી બાજુના જવાબની રાહ જોઈ શકે છે.

બાઇટ મોકલો, અનુમાનિત વ્યવહારો નહીં

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

બંને દિશાઓને સેવા આપવા એપ્લિકેશનનું હાલનું સમાંતર મોડેલ વાપરો: ઇવેન્ટ લૂપ, અસિંક્રોનસ I/O અથવા બીજી જાણી જોઈને પસંદ કરેલી રચના. મહત્વનું વર્તન એ છે કે એક દિશામાં પ્રગતિ માટે બીજી દિશામાં ઘડેલી સંદેશ-સીમાની જરૂર ન પડે.

બે મર્યાદિત બાકી બફર રાખો

ક્લાયન્ટ પાસેથી વાંચેલો ડેટા હજી લક્ષ્ય સુધી પહોંચવાની રાહ જોતો હોઈ શકે છે, જ્યારે લક્ષ્યનો ડેટા ક્લાયન્ટ સુધી પહોંચવાની રાહ જુએ છે. એ બાકી બાઇટને અલગથી ટ્રૅક કરો.

મોકલવાની ક્રિયા માંગેલા કરતાં ઓછા બાઇટ લખી શકે છે. ન લખાયેલો ભાગ રાખો; તેને ફેંકી ન દો અને આખું બફર ફરી ન ચલાવો. અસ્થાયી રીતે લખી ન શકાય તેવું સૉકેટ યોગ્ય તૈયારી-ઘટનાની રાહ જોવાનું કારણ છે, સતત ફરતા રહેવાનું નહીં.

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

એક દિશામાં અંત માટે નીતિ જરૂરી છે

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

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

સંબંધિત લેખો