connectivity/bluetooth/api/mesh/blob_srv.html · connectivity/bluetooth/api/mesh/blob_srv.rst 공식 원문 ↗

Zephyr 3.7.0 · Connectivity · Bluetooth Mesh

BLOB Transfer Server

Block·chunk를 순서와 관계없이 추적하고 중단된 transfer를 persistent state에서 복구합니다.

Official pathconnectivity/bluetooth/api/mesh/blob_srv.html
Source fileconnectivity/bluetooth/api/mesh/blob_srv.rst
Source versionZephyr 3.7.0
TranslationFull · reviewed

본문 기준: Zephyr 3.7.0 LTS3 · 이후 유지보수 패치는 별도입니다.

Part 1

요약·해설

Server 준비, BLOB stream 연결, timeout suspension과 reboot recovery를 공식 상호작용 도식과 함께 설명합니다.

Role

Receiver

Concurrency

1 BLOB

Suspend

Timer based

Recovery

Persistent

Part 2

접을 수 있는 영어 원문 전체

영어 원문 전체 펼치기
원문 SHA-256 F14B42180C4DAC5903E8EFDE13D06AD48082DDBB45482EF27F381B9B793BCC9A
.. _bluetooth_mesh_blob_srv:

BLOB Transfer Server
####################

The Binary Large Object (BLOB) Transfer Server model implements reliable receiving of large binary
objects. It serves as the backend of the :ref:`bluetooth_mesh_dfu_srv`, but can also be used for
receiving other binary images.

BLOBs
*****

As described in :ref:`bluetooth_mesh_blob`, the binary objects transferred by the BLOB Transfer
models are divided into blocks, which are divided into chunks. As the transfer is controlled by the
BLOB Transfer Client model, the BLOB Transfer Server must allow blocks to come in any order. The
chunks within a block may also come in any order, but all chunks in a block must be received before
the next block is started.

The BLOB Transfer Server keeps track of the received blocks and chunks, and will process each block
and chunk only once. The BLOB Transfer Server also ensures that any missing chunks are resent by the
BLOB Transfer Client.

Usage
*****

The BLOB Transfer Server is instantiated on an element with a set of event handler callbacks:

.. code-block:: C

   static const struct bt_mesh_blob_srv_cb blob_cb = {
       /* Callbacks */
   };

   static struct bt_mesh_blob_srv blob_srv = {
       .cb = &blob_cb,
   };

   static const struct bt_mesh_model models[] = {
       BT_MESH_MODEL_BLOB_SRV(&blob_srv),
   };

A BLOB Transfer Server is capable of receiving a single BLOB transfer at a time. Before the BLOB
Transfer Server can receive a transfer, it must be prepared by the user. The transfer ID must be
passed to the BLOB Transfer Server through the :c:func:`bt_mesh_blob_srv_recv` function before the
transfer is started by the BLOB Transfer Client. The ID must be shared between the BLOB Transfer
Client and the BLOB Transfer Server through some higher level procedure, like a vendor specific
transfer management model.

Once the transfer has been set up on the BLOB Transfer Server, it's ready for receiving the BLOB.
The application is notified of the transfer progress through the event handler callbacks, and the
BLOB data is sent to the BLOB stream.

The interaction between the BLOB Transfer Server, BLOB stream and application is shown below:

.. figure:: ../../../../../../connectivity/bluetooth/api/mesh/images/blob_srv.svg
   :align: center
   :alt: BLOB Transfer Server model interaction

   BLOB Transfer Server model interaction

Transfer suspension
*******************

The BLOB Transfer Server keeps a running timer during the transfer, that is reset on every received
message. If the BLOB Transfer Client does not send a message before the transfer timer expires, the
transfer is suspended by the BLOB Transfer Server.

The BLOB Transfer Server notifies the user of the suspension by calling the :c:member:`suspended
<bt_mesh_blob_srv_cb.suspended>` callback. If the BLOB Transfer Server is in the middle of receiving
a block, this block is discarded.

The BLOB Transfer Client may resume a suspended transfer by starting a new block transfer. The BLOB
Transfer Server notifies the user by calling the :c:member:`resume <bt_mesh_blob_srv_cb.resume>`
callback.

Transfer recovery
*****************

The state of the BLOB transfer is stored persistently. If a reboot occurs, the BLOB Transfer Server
will attempt to recover the transfer. When the Bluetooth Mesh subsystem is started (for instance by
calling :c:func:`bt_mesh_init`), the BLOB Transfer Server will check for aborted transfers, and call
the :c:member:`recover <bt_mesh_blob_srv_cb.recover>` callback if there is any. In the recover
callback, the user must provide a BLOB stream to use for the rest of the transfer. If the recover
callback doesn't return successfully or does not provide a BLOB stream, the transfer is abandoned.
If no recover callback is implemented, transfers are always abandoned after a reboot.

After a transfer is successfully recovered, the BLOB Transfer Server enters the suspended state. It
will stay suspended until the BLOB Transfer Client resumes the transfer, or the user cancels it.

.. note::
   The BLOB Transfer Client sending the transfer must support transfer recovery for the transfer to
   complete. If the BLOB Transfer Client has already given up the transfer, the BLOB Transfer Server
   will stay suspended until the application calls :c:func:`bt_mesh_blob_srv_cancel`.

API reference
*************

.. doxygengroup:: bt_mesh_blob_srv
   :project: Zephyr
   :members:

Part 3

한국어 전문 번역

BLOB Transfer Server

Server model은 큰 binary object를 신뢰성 있게 수신합니다. Bluetooth Mesh DFU Server의 backend이지만 다른 binary image를 받는 데도 사용할 수 있습니다.

BLOB

BLOB은 block으로, block은 chunk로 나뉩니다. Transfer를 Client가 제어하므로 Server는 block이 어떤 순서로 오더라도 받아야 합니다. 한 block 내부의 chunk도 순서와 관계없이 올 수 있지만 다음 block을 시작하기 전에 현재 block의 모든 chunk를 받아야 합니다.

Server는 수신한 block과 chunk를 추적하고 각각 한 번만 처리합니다. 누락된 chunk가 있으면 Client가 다시 보내도록 보장합니다.

사용법

Event handler callback set과 함께 element에 BLOB Transfer Server를 instance화합니다.

static const struct bt_mesh_blob_srv_cb blob_cb = {
    /* Callbacks */
};

static struct bt_mesh_blob_srv blob_srv = {
    .cb = &blob_cb,
};

static const struct bt_mesh_model models[] = {
    BT_MESH_MODEL_BLOB_SRV(&blob_srv),
};

Server 하나는 한 번에 BLOB transfer 하나만 받을 수 있습니다. Transfer를 받기 전에 사용자가 준비해야 하며, Client가 transfer를 시작하기 전에 bt_mesh_blob_srv_recv로 transfer ID를 Server에 전달해야 합니다.

ID는 Client와 Server에서 같아야 하며 vendor-specific transfer management model 같은 상위 procedure로 공유합니다. 설정이 끝나면 Server가 BLOB을 받을 준비가 됩니다. Application은 event callback으로 진행 상황을 통지받고 BLOB data는 BLOB stream으로 전달됩니다.

BLOB Transfer Server model interaction
BLOB Transfer Server model과 BLOB stream, application의 상호작용

Transfer suspension

Server는 transfer 중 timer를 계속 실행하고 message를 받을 때마다 reset합니다. Client가 timer 만료 전에 message를 보내지 않으면 Server가 transfer를 suspend합니다.

Server는 bt_mesh_blob_srv_cb.suspended callback으로 suspension을 알립니다. Block 수신 중이었다면 그 block은 버립니다. Client는 새 block transfer를 시작해 suspended transfer를 resume할 수 있고 Server는 bt_mesh_blob_srv_cb.resume callback으로 application에 알립니다.

Transfer recovery

BLOB transfer 상태는 persistent storage에 저장됩니다. Reboot 뒤 Server는 transfer 복구를 시도합니다. 예를 들어 bt_mesh_init으로 Bluetooth Mesh subsystem이 시작되면 중단된 transfer를 확인하고 존재할 경우 bt_mesh_blob_srv_cb.recover callback을 호출합니다.

Recover callback에서 사용자는 남은 transfer에 사용할 BLOB stream을 제공해야 합니다. Callback이 성공하지 못하거나 stream을 제공하지 않으면 transfer를 포기합니다. Recover callback을 구현하지 않은 경우 reboot 뒤 transfer를 항상 포기합니다.

복구가 성공하면 Server는 suspended 상태로 들어갑니다. Client가 transfer를 resume하거나 사용자가 취소할 때까지 그 상태를 유지합니다.

API Reference

공식 bt_mesh_blob_srv Doxygen group이 Server callback, receive, cancel과 recovery API를 생성합니다.

Source

출처

영어 원문에는 문단, 문서 지시문, 표, 코드, 코드 심벌, 경로를 그대로 보존했습니다.