აპლიკაციაში, რომელიც უკვე იყენებს Azure IoT Python SDK-ს, აირჩიეთ MQTT ტრანსპორტი და მისი პროქსის პარამეტრები ერთად. ეს კონფიგურაცია ირჩევს MQTT-ს WebSockets-ით:

proxy = ProxyOptions(proxy_type='HTTP',
                     proxy_addr='203.0.113.10', proxy_port=8080)
client = IoTHubDeviceClient.create_from_connection_string(
    connection_string, websockets=True, proxy_options=proxy
)

კლასები მოდის SDK-ის დოკუმენტირებული ინტერფეისიდან. მოწყობილობის კავშირის სტრიქონი გადაეცით აპლიკაციის საიდუმლო კონფიგურაციის მეშვეობით და შეცვალეთ მაგალითის პროქსის საბოლოო წერტილი. საჯაროდ ხელმისაწვდომი IoT Hub საბოლოო წერტილისთვის, სადაც საჯარო შუამავლები დაშვებულია, HTTP პროქსების სია გთავაზობთ კანდიდატებს HTTP ჰოსტისა და პორტისთვის; დაადასტურეთ, რომ სერვისი ნებას რთავს მარშრუტს დანიშნულებისკენ. ეს არის SDK-ის ცხადი პარამეტრები; ბრაუზერში მომუშავე პროქსი ან ოპერაციული სისტემის ზოგადი პარამეტრი არ ამყარებს მოწყობილობის კლიენტის მარშრუტს.

შეამოწმეთ ProxyOptions ცნობარი არჩეული პროქსის ტიპისთვის. ის განასხვავებს HTTP, SOCKS4 და SOCKS5 ველებს და აღწერს ტიპისთვის დამახასიათებელ მომხმარებლის სახელის/პაროლის ქცევას, მათ შორის HTTP-ის შეზღუდვებს. ველის არსებობა არ იძლევა ყველა ავთენტიფიკაციის მექანიზმის გარანტიას.

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

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

დაკავშირებული სტატიები