Lines Matching full:transfer

3 BLOB Transfer models
6 The Binary Large Object (BLOB) Transfer models implement the Bluetooth Mesh Binary Large Object
7 Transfer Model specification version 1.0 and provide functionality for sending large binary objects
9 transport method for the :ref:`bluetooth_mesh_dfu`, but may be used for other object transfer
12 The BLOB Transfer models support transfers of continuous binary objects of up to 4 GB (2 \ :sup:`32`
13 bytes). The BLOB transfer protocol has built-in recovery procedures for packet losses, and sets up
14 checkpoints to ensure that all targets have received all the data before moving on. Data transfer
17 BLOB transfers are constrained by the transfer speed and reliability of the underlying mesh network.
19 BLOB to be transferred in 10-15 minutes. However, network conditions, transfer capabilities and
21 parameters of the transfer according to the application and network configuration, as well as
23 and reliability of the protocol. However, achieving transfer rates close to the ideal rate is
26 There are two BLOB Transfer models:
34 The BLOB Transfer Client is instantiated on the sender node, and the BLOB Transfer Server is
40 The BLOB transfer protocol introduces several new concepts to implement the BLOB transfer.
47 transfer through the mesh network. The BLOBs are continuous data objects, divided into blocks and
52 The BLOB transfer protocol does not provide any built-in integrity checks, encryption or
61 in size. Each block is transmitted separately, and the BLOB Transfer Client ensures that all BLOB
62 Transfer Servers have received the full block before moving on to the next. The block size is
63 determined by the transfer's ``block_size_log`` parameter, and is the same for all blocks in the
64 transfer except the last, which may be smaller. For a BLOB stored in flash memory, the block size is
70 Each block is divided into chunks. A chunk is the smallest data unit in the BLOB transfer, and must
72 mechanism for transferring chunks depends on the transfer mode.
74 When operating in Push BLOB Transfer Mode, the chunks are sent as unacknowledged packets from the
75 BLOB Transfer Client to all targeted BLOB Transfer Servers. Once all chunks in a block have been
76 sent, the BLOB Transfer Client asks each BLOB Transfer Server if they're missing any chunks, and
77 resends them. This is repeated until all BLOB Transfer Servers have received all chunks, or the BLOB
78 Transfer Client gives up.
80 When operating in Pull BLOB Transfer Mode, the BLOB Transfer Server will request a small number of
81 chunks from the BLOB Transfer Client at a time, and wait for the BLOB Transfer Client to send them
83 Transfer Server gives up.
85 Read more about the transfer modes in :ref:`bluetooth_mesh_blob_transfer_modes` section.
92 In the BLOB Transfer models' APIs, the BLOB data handling is separated from the high-level transfer
93 handling. This split allows reuse of different BLOB storage and transfer strategies for different
94 applications. While the high level transfer is controlled directly by the application, the BLOB data
98 and writing, the BLOB Transfer model gets full access to the BLOB data, whether it's kept in flash,
100 used, and the BLOB Transfer models will move around inside the BLOB's data in blocks and chunks,
107 :c:member:`open <bt_mesh_blob_io.open>` callback. When used with a BLOB Transfer Server, the BLOB
108 stream is always opened in write mode, and when used with a BLOB Transfer Client, it's always opened
111 For each block in the BLOB, the BLOB Transfer model starts by calling
115 calls :c:member:`block_end <bt_mesh_blob_io.block_end>`. When the transfer is complete, the BLOB
129 Transfer capabilities
132 Each BLOB Transfer Server may have different transfer capabilities. The transfer capabilities of
140 The :kconfig:option:`CONFIG_BT_MESH_BLOB_CHUNK_COUNT_MAX` option is also used by the BLOB Transfer
141 Client and affects memory consumption by the BLOB Transfer Client model structure.
143 To ensure that the transfer can be received by as many servers as possible, the BLOB Transfer Client
144 can retrieve the capabilities of each BLOB Transfer Server before starting the transfer. The client
145 will transfer the BLOB with the highest possible block and chunk size.
149 Transfer modes
152 BLOBs can be transferred using two transfer modes, Push BLOB Transfer Mode and Pull BLOB Transfer
153 Mode. In most cases, the transfer should be conducted in Push BLOB Transfer Mode.
155 In Push BLOB Transfer Mode, the send rate is controlled by the BLOB Transfer Client, which will push
156 all the chunks of each block without any high level flow control. Push BLOB Transfer Mode supports
157 any number of Target nodes, and should be the default transfer mode.
159 In Pull BLOB Transfer Mode, the BLOB Transfer Server will "pull" the chunks from the BLOB Transfer
160 Client at its own rate. Pull BLOB Transfer Mode can be conducted with multiple Target nodes, and is
162 in Pull BLOB Transfer Mode, the BLOB Transfer Server will request chunks from the BLOB Transfer
164 is repeated until the BLOB Transfer Server has received all chunks in a block. Then, the BLOB
165 Transfer Client starts the next block, and the BLOB Transfer Server requests all chunks of that
171 Transfer timeout
174 The timeout of the BLOB transfer is based on a Timeout Base value. Both client and server use the
177 The BLOB Transfer Server uses the following formula to calculate the BLOB transfer timeout::
182 For the BLOB Transfer Client, the following formula is used::
186 where TTL is time to live value set in the transfer.
191 This section contains types and defines common to the BLOB Transfer models.