અલગ પ્રોક્સી પસંદ કરતી વખતે OkHttp સંસાધનો ફરી વાપરો

OkHttp વિનંતીમાં સામાન્ય બદલી શકાય તેવું પ્રોક્સી ક્ષેત્ર નથી. તેનો કૉલ બનાવતા પહેલાં ઇચ્છિત માર્ગવાળો ક્લાયન્ટ પસંદ કરો.

જ્યારે બાકીનું રૂપરેખાંકન વહેંચાયેલું રહેવું જોઈએ, ત્યારે હાલના ક્લાયન્ટમાંથી માર્ગિત ક્લાયન્ટ મેળવો:

OkHttpClient routed = baseClient.newBuilder()
    .proxy(new Proxy(Proxy.Type.HTTP,
        new InetSocketAddress("203.0.113.10", 8080)))
    .build();

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

પુનરાવર્તિત કાર્ય માટે, તમને ખરેખર જરૂરી હોય તેવી રૂટિંગ નીતિ દ્વારા કી કરેલા મર્યાદિત ક્લાયન્ટનો સમૂહ રાખો. એવા અમર્યાદિત નકશાને ટાળો જેની કીમાં અત્યાર સુધી જોયેલા દરેક કામચલાઉ ખાતા કે પ્રોક્સી ભિન્નતા હોય.

સંસાધન વહેંચણી બંધ કરવા પર પણ અસર કરે છે. વહેંચાયેલ કૅશ બંધ કરવો કે વહેંચાયેલ ડિસ્પેચર બંધ કરવો તે સંસાધનો વાપરતા અન્ય વ્યુત્પન્ન ક્લાયન્ટને અસર કરી શકે છે. દરેક વ્યુત્પન્ન ક્લાયન્ટને અલગ નેટવર્ક સ્ટેક ગણવાને બદલે સંસાધન માલિકીને સ્પષ્ટ એપ્લિકેશન-સ્તરીય આયુષ્ય આપો.

છેલ્લે, પસંદ કરેલી પ્રોક્સી ઓળખ કૉલના પોતાના મેટાડેટામાં સામેલ કરો. વૈશ્વિક “છેલ્લે પસંદ કરેલી પ્રોક્સી” ચલ અનેક સમવર્તી વિનંતીઓનો માર્ગ ઓળખી શકતું નથી.