11.5. Kapcsolatok

Amint egy központ kiválaszt egy perifériát a hirdetési folyamból és csatlakozási kérést (connect request) küld neki, mindkét fél kilép a hirdetési / pásztázási módból és kapcsolatba (connection) lép. A rádió ettől kezdve a link réteg adatcsatornáin ütemezi a tevékenységét, és a csatlakozáskor megállapodott sorrend szerint pszeudo-véletlenszerűen ugrál közöttük. Minden, ami a link réteg fölött van – GATT, biztonság, L2CAP – az itt létrejött kapcsolat tetején fut.

11.5.1. A kapcsolati esemény

Egy BLE kapcsolatban lévő két eszköz nem folyamatosan közvetít adatot. Megegyeznek egy kapcsolati intervallumban (connection interval), és minden intervallumnál mindkét fél felébreszti a rádiót, kicseréli a sorban álló csomagokat, nyugtázza a kapott adatokat, majd visszaalszik. Minden ilyen csere egy kapcsolati esemény (connection event).

Mindkét oldalon a rádió csak a rövid kapcsolati események alatt van ébren, minden más alszik. A periféria a periféria-késleltetés (peripheral latency) alatt kihagyhat eseményeket.

Az ezt szabályozó számokról a csatlakozáskor egyeznek meg, és a link réteg kényszeríti ki őket. Az alkalmazás számára egyrészt kérés-oldali beállítóként, másrészt a visszajelzett eredményként láthatók.

• Kapcsolati intervallum. 7,5 ms és 4 s között, 1,25 ms-os lépésekben. A központ a periféria által kért értéket választja, kivéve, ha a kérés ésszerűtlen. A rövidebb intervallumok kisebb késleltetéssel szállítják az adatokat, cserébe több rádiótevékenységgel; a hosszabbak energiát takarítanak meg, de minden oda-vissza fordulót lassabbá tesznek.

• Periféria-késleltetés. Egy nemnegatív N egész szám. A periféria akár N kapcsolati eseményt is kihagyhat, ha nincs mit küldenie, és üres csere helyett visszaalhat ahelyett, hogy felébresztené a rádiót. Hasznos olyan érzékelőknél, amelyek másodpercenként egyszer ébrednek jelentést tenni, de a ritka azonnali üzenetekhez alacsony, reszponzív kapcsolati intervallumot szeretnének.

• Felügyeleti időkorlát (supervision timeout). 100 ms és 32 s között. Ha bármelyik fél ennyi ideig nem hall semmit a másiktól, a kapcsolatot elveszettnek nyilvánítják, és mindkét fél visszatér a hirdetéshez / pásztázáshoz. Az időkorlátnak hosszabbnak kell lennie, mint connection_interval * (1 + peripheral_latency) – a link réteg elutasítja az ezt megsértő értékeket.

A aioble.Device.connect() átveszi a min_conn_interval_us és max_conn_interval_us paramétereket, hogy a központ egy adott tartományt kérhessen; a rádió által ténylegesen beállított értéket a kapcsolat felépülése után a link réteg konfigurációján keresztül lehet visszaolvasni.

11.5.2. Mit jelent a „központ” és a „periféria” egy kapcsolaton belül

A hirdetéskor beállított szerepek a kapcsolat felépülése után is megmaradnak:

• A központ (central) vezérli az időzítést – ő birtokolja az ugrási sorrend és a kapcsolati események master oldalát.

• A periféria (peripheral) reaktív. Kérheti a kapcsolati paraméterek megváltoztatását (például lassabb intervallumot az energiatakarékosság érdekében), de a központ dönti el, hogy elfogadja-e.

A szerepek függetlenek attól, hogy ki tárolja a GATT adatbázist, ami egy külön tengely. Megállapodás szerint a periféria egyben a GATT kiszolgáló (server), a központ pedig a GATT kliens (client) is, de a BLE lehetővé teszi, hogy bármelyik oldal tárolja a GATT szolgáltatásokat. A kamerák szinte mindig követik a konvenciót: periféria + kiszolgáló a „kamera adatot tesz közzé” alkalmazásoknál, központ + kliens a „kamera egy érzékelőből olvas” alkalmazásoknál.

11.5.3. A maximális átviteli egység (MTU)

A link réteg alapértelmezés szerint rövid csomagokat szállít – 27 bájt hasznos adat, amelyből csak 23 áll a GATT rendelkezésére. Ez elegendő egy kis méréshez vagy egy rövid parancshoz, de aprócska bármilyen több bájtos adathoz képest. Mindkét fél felfelé tárgyalhatja ezt, egészen addig a határig, amelyet a rádió firmware-e támogat (modern vezérlőkön jellemzően néhány száz bájt).

Az aioble API a aioble.DeviceConnection.exchange_mtu() metóduson keresztül vezérli a tárgyalást, az eredmény pedig az mtu attribútumon válik elérhetővé. A nagyobb MTU kevesebb oda-vissza fordulót jelent minden ~20 bájtnál nagyobb érték esetén, csekély puffermemória-költség mellett.

11.5.4. Élettartam

Egy kapcsolat addig tart, amíg a következők egyike be nem következik:

• valamelyik fél meghívja a disconnect() metódust,

• elsül a felügyeleti időkorlát (hatótávolságon kívül, rádió kikapcsolva, a társ összeomlott), vagy

• explicit link réteg hiba (titkosítási eltérés, párosítás elutasítása) történik.

Amikor a kapcsolat megszakad, minden rajta sorban álló vagy folyamatban lévő GATT művelet aioble.DeviceDisconnectedError kivételt vált ki, és minden async with connection blokk, amelyben az alkalmazás éppen tartózkodik, tisztán kilép. A periféria jellemzően úgy reagál, hogy visszatér a aioble.advertise() hívásához és megvárja a következő központot; a központ vagy újra pásztáz, vagy a leválasztást az alkalmazás felé jelzi.

Az élettartam az egyik oka annak, hogy az aioble hasznos. Egy szinkron BLE API-nak leválasztási visszahívásokat és eseménymaszkokat kellene közzétennie; az asyncio változat a leválasztásokat abban a korutinban váltja kivétellé, amely a műveletre várt, és pontosan erre épül az async with takarítás.