https://www.btframework.com/rfcomm.htm#channel
- Handle - a Bluetooth service's handle. This is an internal field and usualy means nothing for an application;
- Uuid - this is the service's UUID, what we are looking for;
- Channel - an RFCOMM channel number (see below);
- Name - service's name;
- Comment - service's comment, may contains some additional information about service implementation details.
RFCOMM Channel Number
As described above, a Bluetooth Service UUID just describes some feature (service) that is supported by a Bluetooth enabled device. It is something like TCP/IP service: HTTP, FTP, TelNet or others. You can connect to any Internet service by using its IP address and service.
However, Bluetooth device may have few services with identical UUID. For example, a device may have two Serial Port Profile (SPP) services: one for configuration and other for communication. It is similar if an Internet server has two HTTP servers running: one is public and other is for administration.
And now we have a question: how a Bluetooth Client device may select which service it wants to connect to? Again, refer to the Internet: there is something known as TCP/IP port. If an Interner server has two HTTP servers then one may run on standard HTTP port 80 and the other may run on port 8080. So when connecting to such server browser uses default port 80 when it specifies HTTP service in connection request. But we also may provide TCP/IP port (8080) and a Web browser connects to specified port.
The same appears when we connect to a Bluetooth RFCOMM service. But instead of Port in Bluetooth world it is called RFCOMM channel number (the Channel field in the wclBluetoothService structure). Each RFCOMM service has own unique RFCOMM channel number. This channel number can be hardcoded or can be dynamically assigned. But it is always unique.
When Bluetooth RFCOMM client connects to a remote Bluetooth RFCOMM server it always connects to an RFCOMM channel. If application does not provide a channel number in connection request, OS queries remote Bluetooth device about its services and tries to resolve the RFCOMM channel number by service's UUID. If there are two or more services with the same UUID OS uses first found randomly.
However, in case of few services with the same UUID an application may query device about supported service, find required one (by its name or comment) and provide RFCOMM channel number in connection request to connect to exactly required service. Or, if RFCOMM channel number is hardcoded on a device's side an application may simple provide well-known RFCOMM channel number without quering device services.
When you run a Bluetooth RFCOMM server you also provides service's UUID and (if required) RFCOMM channel number. If (by default) an application does not provide a channel number (this is recomended way) an OS assigns it automaticaly. However an application may provide fixed RFCOMM channel number. But in this case server may not start if OS already uses this channel number. The RFCOMM channel number can be any from 1 to 31 (including both).
https://www.cnblogs.com/hzl6255/p/3801732.html
關注了：清晨上馬，其文章簡略分析了大部分藍牙協議
https://blog.csdn.net/ylangeia/article/category/8664886
https://blog.csdn.net/ylangeia/article/details/87102183