In 'n toepassing wat reeds die Azure IoT Python SDK gebruik, kies die MQTT-transport en sy proxy-opsies saam. Hierdie konfigurasie kies MQTT oor 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
)

Die klasse kom uit die SDK se gedokumenteerde koppelvlak. Voorsien die toestel se verbindingstring deur die toepassing se geheime konfigurasie en vervang die voorbeeld-proxy-eindpunt. Vir 'n publiek bereikbare IoT Hub-eindpunt waar openbare tussengangers toegelaat word, bied die HTTP-proxylys kandidate vir die HTTP-gasheer en -poort; bevestig dat die diens die bestemmingsroete toelaat. Dit is eksplisiete SDK-opsies; 'n werkende proxy in 'n blaaier of 'n algemene bedryfstelselinstelling vestig nie die toestelkliënt se roete nie.

Kontroleer die ProxyOptions-verwysing vir die gekose proxy-tipe. Dit onderskei HTTP-, SOCKS4- en SOCKS5-velde en dokumenteer tipe-spesifieke gebruikersnaam/wagwoord-gedrag, insluitend beperkings vir HTTP. Die teenwoordigheid van 'n veld belowe nie elke verifikasiemeganisme nie.

Die proxy-rekening en die toestelidentiteit magtig verskillende stadiums. 'n Verwerpte tussenganger-uitruiling kan die verbinding stop voordat die broker die toestelbewys evalueer. Die keuse van WebSockets laat ook die proxy se bestemmings- en toegangsbeperkings van krag.

Teken die gekose transport, bestemming en eerste mislukte stadium aan. Die SDK-kliënt, proxy-implementering en toegelate roete moet ooreenstem; nog 'n suksesvolle blaaiernavraag nog 'n algemene bewering dat SOCKS elke protokol dra, lewer daardie versoenbaarheid.

Verwante artikels