11.11. Канали L2CAP

GATT — це модель «ключ/значення». Операції, які вона надає (читання, запис, сповіщення, індикація), переміщують одне коротке значення за раз, а найбільший одиничний пакет, який вони можуть переносити, визначається узгодженим значенням MTU — у кращому разі кілька сотень байт. Це добре працює для показань датчиків, регістрів команд і статусних прапорів. Але на кілобайтах чи мегабайтах усе розсипається: розбиття довгої плями на сотні малих записів коштує зайвих обмінів, а радіоканал значно швидший за це.

Для потоків об’ємних даних — захопленого кадру, який камера передає на телефон, образу оновлення прошивки по повітрю, пакетного експорту вимірювань — BLE пропонує альтернативний шлях: Logical Link Control and Adaptation Protocol, L2CAP. L2CAP знаходиться між канальним рівнем і GATT та дозволяє застосунку зайняти власний з’єднано-орієнтований канал поверх того самого радіозв’язку. Канал є байтовим шляхом з управлінням потоком на основі кредитів, набагато більшим MTU на пакет і без GATT-фреймінгу посередині.

11.11.1. Коли використовувати L2CAP

Канали L2CAP — правильний інструмент, коли:

  • Обсяг передачі перевищує кілька сотень байт.

  • Обидва кінці знають, що буде використовуватися канал L2CAP (він не відображається в рекламному пакеті; клієнт має знати мультиплексор протоколу/сервісу каналу, або PSM, заздалегідь).

  • Застосунок готовий відмовитися від зручностей GATT: немає вбудованої адресації за UUID, немає виявлення клієнтами через стандартні застосунки, немає сповіщень.

Найпоширенішим випадком у застосунках на основі aioble є передача двійкової плями між двома програмними компонентами, які обидва знають про конвенцію PSM — власний протокол камера-до-телефону, пара камер openmv, що спілкуються між собою, внутрішній шлях оновлення мікропрограми під GATT-сервісом периферійного пристрою.

Для всього іншого залишайтеся на GATT. Короткий статус, регістр керування, показання датчика — все це належить характеристиці.

11.11.2. Встановлення каналу

L2CAP працює поверх наявного aioble.DeviceConnection, тому процес виявлення/реклами/підключення на стороні GAP точно такий самий, як і для GATT. Як тільки обидві сторони мають підключення, одна сторона слухає на PSM, інша — підключається до нього.

PSM — це просто мале ціле число. Bluetooth SIG резервує нижній діапазон для стандартизованого використання (0x0001-0x007F); для каналів конкретного застосунку використовуйте число з динамічного діапазону (0x0080-0x00FF для фіксованих PSM, 0x0040 і далі зазвичай вільні для власного використання). Обидві сторони мають заздалегідь погодити значення.

MTU на каналі L2CAP — це найбільший одиничний SDU (Service Data Unit), який кожна зі сторін доставить за один send() — не MTU BLE-зв’язку. Aioble автоматично фрагментує більші пакети. BLE-хост камери обмежує MTU L2CAP до 1017 байт; 512 — розумний за замовчуванням, що залишає місце з обох боків без зайвих витрат RAM.

На стороні слухача (наприклад, камера як периферійний пристрій):

async def serve_l2cap(connection, image_bytes):
    channel = await connection.l2cap_accept(psm=0x80, mtu=512)
    async with channel:
        # image_bytes is a bytearray -- e.g. csi0.snapshot().bytearray()
        # or a compressed JPEG buffer. send() fragments into MTU-sized
        # chunks automatically and awaits flow-control credits between.
        await channel.send(image_bytes)
        await channel.flush()

На стороні з’єднувача (наприклад, телефон або центральний пристрій):

async def open_l2cap(connection, total_bytes):
    channel = await connection.l2cap_connect(psm=0x80, mtu=512)
    async with channel:
        image_bytes = bytearray(total_bytes)
        view = memoryview(image_bytes)
        received = 0
        while received < total_bytes:
            n = await channel.recvinto(view[received:])
            if n == 0:
                break
            received += n
        return image_bytes

l2cap_accept() блокується до підключення партнера (або спрацьовування timeout_ms); l2cap_connect() блокується до прийняття слухачем (або невдачі). Обидва повертають aioble.L2CAPChannel — сам по собі асинхронний контекстний менеджер, який закриває канал при виході.

11.11.3. Надсилання та отримання

Дві основні операції на каналі: send() (записує байти до партнера) і recvinto() (читає в попередньо виділений буфер). Обидві є корутинами.

  • send() фрагментує буфер на частини розміром MTU і очікує між ними кредити управління потоком канального рівня. Тривале відправлення — це один await з точки зору застосунку; внутрішньо воно може ставити в чергу багато пакетів і призупинятися, коли кредити прийому партнера вичерпуються.

  • recvinto() заповнює переданий буфер тим, що є (до MTU каналу), і повертає кількість байт. Чекає, якщо нічого не доступно.

  • available() синхронно повертає True, якщо є буферизовані дані — корисно для опитування без призупинення.

  • flush() чекає, поки будь-яке незавершене надсилання не буде повністю передано до контролера.

Канали L2CAP подібні до потоків у тому сенсі, що байти надходять по порядку і без втрат, але межі одного send зберігаються — кожен SDU виходить з одного recvinto. Це відрізняється від TCP, де межі одного send() можуть розмиватися в кількох викликах recv().

11.11.4. Обробка від’єднання

Канал зникає за трьох умов: будь-яка сторона викликає disconnect(), базове GAP-з’єднання обривається, або надходить відключення на рівні L2CAP. Активні операції генерують виняток aioble.L2CAPDisconnectedError. Як і на стороні GATT, це проявляється як виняток у корутині, яка очікувала, і блок async with channel завершується чисто.

Якщо канал стає недосяжним через відключення на рівні GAP, застосунок повертається до реклами або сканування так само, як при відключенні GATT.

11.11.5. Витрати пам’яті

Більші MTU і довші черги використовують більше RAM з обох боків. MTU 512 байт плюс буфер прийому на канал займає близько 1 КБ на канал — це не безкоштовно на маленькій камері, якщо одночасно відкрито кілька каналів. Тримайтеся одного каналу на з’єднання і вибирайте MTU, який відповідає очікуваному розміру повідомлення; типово одного L2CAPChannel на DeviceConnection достатньо для більшості застосунків.

L2CAP — це запобіжний клапан BLE. GATT — це те, до чого майже кожен застосунок звертається першим, і решта прикладів центрального/периферійного пристрою в цьому розділі залишаються на GATT. API на основі каналів — це відповідь, коли застосунок переростає модель «ключ/значення».