mirror/btstack
1
0
Fork 0
mirror of https://github.com/bluekitchen/btstack.git synced 2025-03-24 04:43:36 +00:00
Code Issues Packages Projects Releases Wiki Activity

doc: merge comment on RFCOMM packet boundaries from master

Browse Source
This commit is contained in:
Matthias Ringwald 2018-08-03 22:15:09 +02:00
parent e22dfdb8aa
commit 32b6d931de
2 changed files with 23 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
doc/manual/docs/profiles.md
View File

@ -172,7 +172,9 @@ bonding via the *gap_dedicated_bonding* function.
## SPP - Serial Port Profile
The SPP profile defines how to set up virtual serial ports and connect
two Bluetooth enabled devices.
two Bluetooth enabled devices. Please keep in mind that a serial port does not
preserve packet boundaries if you try to send data as packets and read about
[RFCOMM packet boundaries]({protocols/#sec:noRfcommPacketBoundaries}).
### Accessing an SPP Server on a remote device

20
doc/manual/docs/protocols.md
View File

@ -331,6 +331,26 @@ for the Serial Port Profile and other profiles used for
telecommunication like Head-Set Profile, Hands-Free Profile, Object
Exchange (OBEX) etc.
### No RFCOMM packet boundaries {#sec:noRfcommPacketBoundaries}
As RFCOMM emulates a serial port, it does not preserve packet boundaries.
On most operating systems, RFCOMM/SPP will be modeled as a pipe that allows
to write a block of bytes. The OS and the Bluetooth Stack are free to buffer
and chunk this data in any way it seems fit. In your BTstack application, you will
therefore receive this data in the same order, but there are no guarantees as
how it might be fragmented into multiple chunks.
If you need to preserve the concept of sending a packet with a specific size
over RFCOMM, the simplest way is to prefix the data with a 2 or 4 byte length field
and then reconstruct the packet on the receiving side.
Please note, that due to BTstack's 'no buffers' policy, BTstack will send outgoing RFCOMM data immediately
and implicitly preserve the packet boundaries, i.e., it will send the data as a single
RFCOMM packet in a single L2CAP packet, which will arrive in one piece.
While this will hold between two BTstack instances, it's not a good idea to rely on implementation details
and rather prefix the data as described.
### RFCOMM flow control {#sec:flowControlProtocols}
RFCOMM has a mandatory credit-based flow-control. This means that two