Lines Matching +full:operating +full:- +full:mode

13 bytes). The BLOB transfer protocol has built-in recovery procedures for packet losses, and sets up
19 BLOB to be transferred in 10-15 minutes. However, network conditions, transfer capabilities and
52 The BLOB transfer protocol does not provide any built-in integrity checks, encryption or
58 ------
68 ------
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
80 When operating in Pull BLOB Transfer Mode, the BLOB Transfer Server will request a small number of
92 In the BLOB Transfer models' APIs, the BLOB data handling is separated from the high-level transfer
99 RAM, or on a peripheral. The BLOB stream is opened with an access mode (read or write) before it's
104 -----------
108 stream is always opened in write mode, and when used with a BLOB Transfer Client, it's always opened
109 in read mode.
112 :c:member:`block_start <bt_mesh_blob_io.block_start>`. Then, depending on the access mode, the BLOB
119 ---------------
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
161 intended for transferring BLOBs to Target nodes acting as :ref:`bluetooth_mesh_lpn`. When operating
162 in Pull BLOB Transfer Mode, the BLOB Transfer Server will request chunks from the BLOB Transfer