Í forriti sem notar þegar Azure IoT Python SDK skaltu velja MQTT-flutninginn og valkosti milliþjónsins saman. Þessi stilling velur MQTT yfir 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
)

Klassarnir koma úr skjalfestu viðmóti SDK-sins. Gefðu upp tengistreng tækisins í gegnum leynilega stillingu forritsins og skiptu út dæminu um endapunkt milliþjóns. Fyrir opinberlega aðgengilegan IoT Hub-endapunkt þar sem opinberir milliliðir eru leyfðir býður HTTP-milliþjónalistinn upp á frambjóðendur fyrir HTTP-hýsil og -gátt; staðfestu að þjónustan leyfi leiðina að áfangastað. Þetta eru skýrir valkostir SDK-sins; milliþjónn sem virkar í vafra eða almenn stilling stýrikerfis kemur ekki á leið tækjabiðlarans.

Skoðaðu ProxyOptions-tilvísunina fyrir valda tegund milliþjóns. Hún greinir HTTP-, SOCKS4- og SOCKS5-reiti og skjalfestir hegðun notandanafns/lykilorðs sem er sértæk fyrir tegund, þar á meðal takmarkanir fyrir HTTP. Viðvera reits lofar ekki hverri auðkenningaraðferð.

Milliþjónareikningurinn og auðkenni tækisins heimila mismunandi stig. Hafnaðri milliliðaskipti getur stöðvað tenginguna áður en brokerinn metur skilríki tækisins. Að velja WebSockets heldur einnig takmörkunum milliþjónsins á áfangastað og aðgangi í gildi.

Skráðu valda flutninginn, áfangastaðinn og fyrsta stigið sem mistókst. SDK-biðlarinn, útfærsla milliþjónsins og leyfða leiðin verða að stemma; hvorki farsæl vafrabeiðni né almenn fullyrðing um að SOCKS flytji hvert samskiptareglu veitir þá samhæfni.

Tengdir greinar