Sa isang aplikasyong gumagamit na ng Azure IoT Python SDK, piliin nang sabay ang MQTT transport at ang mga opsyon nito sa proxy. Pinipili ng configuration na ito ang MQTT sa 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
)

Ang mga klase ay nagmumula sa dokumentadong interface ng SDK. Ibibigay ang connection string ng device sa pamamagitan ng lihim na configuration ng aplikasyon at palitan ang halimbawang proxy endpoint. Para sa pampublikong naaabot na IoT Hub endpoint kung saan pinapayagan ang mga pampublikong tagapamagitan, ang listahan ng HTTP proxy ay nag-aalok ng mga kandidato para sa HTTP host at port; tiyakin na pinapayagan ng serbisyo ang ruta patungo sa destinasyon. Ang mga ito ay tahasang opsyon ng SDK; ang proxy na gumagana sa browser o pangkalahatang setting ng operating system ay hindi nagtatatag ng ruta ng device client.

Tingnan ang ProxyOptions reference para sa napiling uri ng proxy. Tinutukoy nito ang HTTP, SOCKS4 at SOCKS5 na field at idinodokumento ang pag-uugali ng username/password na partikular sa uri, kabilang ang mga limitasyon para sa HTTP. Ang pagkakaroon ng field ay hindi nangangako ng bawat mekanismo ng pagpapatunay.

Ang proxy account at pagkakakilanlan ng device ay nagbibigay ng awtorisasyon sa magkaibang yugto. Ang tinanggihang palitan ng tagapamagitan ay maaaring ihinto ang koneksyon bago suriin ng broker ang kredensyal ng device. Ang pagpili ng WebSockets ay nag-iiwan din ng mga paghihigpit sa destinasyon at pag-access ng proxy na may bisa.

Itala ang napiling transport, destinasyon at unang yugtong nabigo. Dapat magkasundo ang SDK client, implementasyon ng proxy at pinapayagang ruta; ni ang matagumpay na kahilingan ng browser ni ang pangkalahatang pag-aangkin na dinadala ng SOCKS ang bawat protocol ay hindi nagbibigay ng kompatibilidad na iyon.

Kaugnay na mga artikulo