Azure IoT Python: налада MQTT праз WebSockets праз проксі
Наладзьце падтрыманыя параметры проксі кліента Azure IoT Python і свядома выберыце MQTT праз WebSockets.
У праграме, якая ўжо выкарыстоўвае 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 пераносіць любы пратакол, не забяспечваюць такой сумяшчальнасці.