libproxy მარშრუტს ირჩევს; კავშირს თქვენი კლიენტი ამყარებს
გამოიყენეთ libproxy-ის შედეგები URL-ის მიხედვით მარშრუტიზაციის კანდიდატებად, ნაცვლად იმისა, რომ ელოდოთ აღმოჩენის მიერ აპლიკაციის სოკეტების გადამისამართებას.
თუ libproxy აბრუნებს პროქსის URI-ს, ხოლო შემდეგი სოკეტი პირდაპირ უკავშირდება, შეამოწმეთ გადაცემა. libproxy პოლიტიკას აღმოაჩენს; ის არ იჭერს აპლიკაციის მიერ გახსნილ ყველა სოკეტს.
- ჰკითხეთ რესურსს. დოკუმენტირებულ libproxy 0.5 C API-ში შექმენით პროქსის ფაბრიკა და ითხოვეთ ნამდვილი დანიშნულების URL.
- განმარტეთ დალაგებული კანდიდატები. HTTP-, SOCKS- და პირდაპირი შედეგები განსხვავებულ დამუშავებას მოითხოვს. შეინარჩუნეთ მათი უპირატესობის რიგი და განზრახული წარუმატებლობის პოლიტიკა.
- კონფიგურაცია გაუკეთეთ მომხმარებელს. გადაეცით არჩეული პროქსის ტიპი, საბოლოო წერტილი და ავთენტიფიკაციის წესრიგი იმ ტრანსპორტს, რომელიც მათ მხარს უჭერს. ნედლი TCP სოკეტი დაბრუნებული URI-დან CONNECT ან SOCKS მოლაპარაკებას არ იძენს.
ნუ შეინახავთ ერთ პასუხს ყველა დანიშნულების მარშრუტად და ნუ გახდით პირდაპირ მარშრუტიზაციას მუდმივს მხოლოდ იმიტომ, რომ პირველი პროქსი ერთხელ ჩავარდა.
თუ HTTP კლიენტი უკვე ინტეგრირებს სისტემურ პროქსის ან PAC-ის აღმოჩენას, აირჩიეთ არჩევანის ერთი მფლობელი. ორი დამოუკიდებელი ამრჩევი და კიდევ ერთი გარსი შეიძლება შექმნან მარშრუტი, რომელიც არც ერთ პოლიტიკას არ ჰქონდა განზრახული.
მშობლიურ კოდში დაიცავით დაყენებული API-ის ფაბრიკისა და შედეგების მეხსიერების სასიცოცხლო ციკლი. ფაბრიკის ხელახალი გამოყენება შეიძლება შეინარჩუნოს სასარგებლო აღმოჩენის მდგომარეობა, მაგრამ ის მაინც მოითხოვს მოთხოვნას თითოეული დანიშნულებისთვის. ჩაწერეთ არჩევანი კავშირის შედეგისგან ცალკე: დაბრუნებული URI არ ადასტურებს წარმატებულ ავთენტიფიკაციას, გადაწყვეტას ან შემდგომ წვდომას.