OkHttp-ის რესურსების ხელახლა გამოყენება სხვა პროქსის არჩევისას

OkHttp-ის მოთხოვნას არ აქვს ზოგადი ცვლადი პროქსის ველი. ზარის შექმნამდე აირჩიეთ კლიენტი სასურველი მარშრუტით.

როცა დანარჩენი კონფიგურაცია საერთო უნდა დარჩეს, მარშრუტიზებული კლიენტი გამოიყვანეთ არსებული კლიენტიდან:

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

საბოლოო წერტილი მხოლოდ მაგალითია. საჯარო HTTP საბოლოო წერტილები HTTP პროქსების სიიდან შეიძლება ავსებდეს ამ სოკეტის მისამართს დაშვებული საჯარო სერვისის მარშრუტისთვის, იმ პირობით, რომ საბაზისო კლიენტის პოლიტიკა ახალ საბოლოო წერტილს პროქსის სერტიფიკატებს არ აწვდის. OkHttp ადასტურებს, რომ newBuilder აზიარებს კავშირების აუზისა და ნაკადების რესურსებს ორიგინალ კლიენტთან. ეს არ ნიშნავს, რომ ერთი პროქსით დამყარებული სოკეტი სხვა მარშრუტად შეიძლება გადაეფასოს. კავშირის ვარგისიანობა კვლავ მარშრუტისა და მისამართის კონფიგურაციაზეა დამოკიდებული.

განმეორებადი სამუშაოსთვის შეინახეთ შეზღუდული კლიენტების ნაკრები, გასაღებად აღებული იმ მარშრუტიზაციის პოლიტიკით, რომელიც ნამდვილად გჭირდებათ. მოერიდეთ შეუზღუდავ რუკას, რომლის გასაღებები შეიცავს ყველა ოდესმე დანახულ დროებით ანგარიშს ან პროქსის ვარიაციას.

რესურსების გაზიარება გამორთვაზეც მოქმედებს. საერთო ქეშის დახურვამ ან საერთო დისპეტჩერის გამორთვამ შეიძლება გავლენა მოახდინოს ამ რესურსებით მოსარგებლე სხვა წარმოებულ კლიენტებზე. მიანიჭეთ რესურსების საკუთრებას მკაფიო აპლიკაციის დონის სიცოცხლის ხანგრძლივობა იმის ნაცვლად, რომ ყოველი წარმოებული კლიენტი იზოლირებულ ქსელურ სტეკად მოიხსენიოთ.

დაბოლოს, ჩართეთ არჩეული პროქსის იდენტობა თავად ზარის მეტამონაცემებში. გლობალური ცვლადი „ბოლოს არჩეული პროქსი“ ვერ ამოიცნობს რამდენიმე ერთდროული მოთხოვნის მარშრუტს.