蓝牙编程指南：探索无线短距通信技术

需积分: 1 120 浏览量更新于2024-07-24 收藏 219KB PDF 举报

"PartOfBTBook.pdf 是一份针对程序员的蓝牙技术参考资料，由Albert Huang和Larry Rudolph编写，涵盖了蓝牙通信的基本概念和技术细节。" 在《Bluetooth for Programmers》这本书中，作者旨在帮助软件开发者理解并掌握蓝牙技术。蓝牙技术是一种无线通信方式，允许设备在短距离内进行通信。尽管其范围广泛，但开发基于蓝牙通信的应用程序是简单易行的。 1.1 理解蓝牙：软件开发者的视角对于软件开发者来说，理解蓝牙可能最初会显得有些复杂，因为它的应用领域非常广泛。通常，技术名称或规范都指向非常具体且范围有限的领域。例如，以太网定义了如何将多台机器连接在一起形成简单的网络，而TCP/IP仅涉及构成互联网基础的两个特定通信协议。同样，HTTP是支持万维网的核心协议。然而，蓝牙则不同，它不仅仅是一个协议，而是一套完整的规范，包括了从设备发现、配对到数据传输等一系列过程。蓝牙规格详尽地描述了这些过程，包括蓝牙核心规范、蓝牙低功耗（BLE）技术、蓝牙 Profiles（定义了特定用途的服务）以及如何在不同设备间建立连接。作为开发者，你需要理解蓝牙协议栈的层次结构，从物理层到应用层，每个层都负责不同的功能，如调制解调、错误校验、数据包处理和应用接口等。 1.2 蓝牙的主要组件与特性 - **蓝牙核心系统**：包含了蓝牙规范的基本部分，包括无线链路控制和管理层，用于设备间的连接和通信。 - **蓝牙服务**（Profiles）：定义了设备如何提供特定功能，如音频流传输（A2DP）、健康设备（HDP）或文件传输（FTP）等。 - **设备发现与配对**：蓝牙设备可以广播其存在，并能通过安全的配对过程与其他设备建立连接。 - **蓝牙低功耗（BLE）**：针对电池供电设备设计，具有高效能和节能的特点，常用于物联网（IoT）设备。 - **安全**：蓝牙提供了加密和认证机制，确保数据在传输过程中的安全性。 1.3 开发蓝牙应用的关键点 - **API和库的使用**：大多数现代操作系统（如Android、iOS、Windows和Linux）都提供了蓝牙API，允许开发者轻松集成蓝牙功能。理解这些API并知道如何使用它们是成功开发蓝牙应用的关键。 - **适配器和控制器**：硬件层面，蓝牙通信依赖于蓝牙适配器或控制器，开发者需要了解它们的兼容性和性能限制。 - **测试和调试**：由于蓝牙涉及到实际的无线通信，测试环境的复杂性增加了，开发者需要进行充分的测试以确保应用在各种条件下的正常运行。《Bluetooth for Programmers》为开发者提供了一个深入理解蓝牙技术的起点，涵盖了从理论概念到实际开发的方方面面，帮助他们构建能够利用蓝牙通信能力的创新应用。

Chapter 1. Introduction

Requirement Internet Bluetooth

Reliable, datagram TCP RFCOMM or L2CAP with

inﬁnite retransmit

Best-effort, datagram UDP L2CAP (0-1279 ms retransmit)

1.2.3. Port numbers and the Service Discovery Protocol

The second part of ﬁguring out how to communicate with a remote machine, once a numerical address

and transport protocol are known, is to choose the port number. Almost all Internet transport protocols in

common usage are designed with the notion of port numbers, so that multiple applications on the same

host may simultaneously utilize a transport protocol. Bluetooth is no exception, but uses slightly

different terminology. In L2CAP, ports are called Protocol Service Multiplexers, and can take on

odd-numbered values between 1 and 32767. Don’t ask why they have to be odd-numbered values,

because you won’t get a convincing answer. In RFCOMM, channels 1-30 are available for use. These

differences aside, both protocol service multiplexers and channels serve the exact same purpose that

ports do in TCP/IP. L2CAP, unlike RFCOMM, has a range of reserved port numbers (1-1023) that are

not to be used for custom applications and protocols. This information is summarized in Table 1-2.

Throughout the rest of this book, we’ll often use the word port instead of protocol service multiplexer

and channel, mostly for clarity.

Table 1-2. Port numbers and their terminology for various protocols

protocol terminology reserved/well-known

ports

dynamically

assigned ports

TCP port 1-1024 1025-65535

UDP port 1-1024 1025-65535

RFCOMM channel none 1-30

L2CAP PSM odd numbered 1-4095 odd numbered 4097 -

32765

In Internet programming, server applications traditionally make use of well known port numbers that are

chosen and agreed upon at design time. Client applications will use the same well known port number to

connect to a server. The main disadvantage to this approach is that it is not possible to run two server

applications which both use the same port number. Due to the relative youth of TCP/IP and the large

number of available port numbers to choose from, this has not yet become a serious issue.

The Bluetooth transport protocols, however, were designed with many fewer available port numbers,

which means we cannot choose an arbitrary port number at design time. Although this problem is not as

signiﬁcant for L2CAP, which has around 15,000 unreserved port numbers, RFCOMM has only 30

different port numbers. A consequence of this is that there is a greater than 50% chance of port number

collision with just 7 server applications. In this case, the application designer clearly should not

arbitrarily choose port numbers. The Bluetooth answer to this problem is the Service Discovery Protocol

(SDP).

Chapter 1. Introduction

Instead of agreeing upon a port to use at application design time, the Bluetooth approach is to assign

ports at runtime and follow a publish-subscribe model. The host machine operates a server application,

called the SDP server, that uses one of the few L2CAP reserved port numbers. Other server applications

are dynamically assigned port numbers at runtime and register a description of themselves and the

services they provide (along with the port numbers they are assigned) with the SDP server. Client

applications will then query the SDP server (using the well deﬁned port number) on a particular machine

to obtain the information they need.

1.2.3.1. Service ID

This raises the question of how do clients know which service description is the one they are looking for.

The easy answer would be to just assign every single service a unique identiﬁer and be done with it. This

approach has been done before, and the Internet Engineering Task Force has a standard method for

developers to independently come up with their own 128-bit Universally Unique Identiﬁers (UUID).

This is the basic idea around which SDP revolves, and this identiﬁer is called the service’s Service ID.

Speciﬁcally, a developer chooses this UUID at design time and when the program is run, it registers its

Service ID with the SDP server for that device. A client application trying to ﬁnd a speciﬁc service would

query the SDP server on each device it ﬁnds to see if the device offers any services with that same UUID.

UUIDs are typically referred to as a hyphen-separated series of digits of the form

"XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX", where each ’X’ is a hexadecimal digit.

The ﬁrst segment of 8 digits corresponds to bits 1-32 of the UUID, the next segment of 4 digits is bits

33-36, and so on.

1.2.3.2. Service Class ID list

Although a Service ID by itself can take us a pretty long way in terms of identifying services and ﬁnding

the one we want, it’s really meant for custom applications built by a single development team. The

Bluetooth designers wanted to distinguish between these custom applications and classes of applications

that all do the same thing. For example, two different companies might both release Bluetooth software

that provides audio services over Bluetooth. Even though they’re completely different programs written

by different people, they both do the same thing. To handle this, Bluetooth introduces a second UUID,

called the Service Class ID. Now, the two different programs can just advertise the same Service Class

ID, and all will be well in Bluetooth Land. Of course, this is only useful if the two companies agree on

which Service Class ID to use.

Another thought to consider is this: what if I have a single application that can provide multiple services?

For example, many Bluetooth headsets can function as a simple headphone and speaker, and advertise

that service class; but they also are capable of controlling a phone call - ansewring an incoming call,

muting the microphone, hanging up, and so on. Although it’s possible to just register two separate

services in this case, each with a speciﬁc service class, the Bluetooth designers chose to allow every

service to have a list of service classes that the service provides. So while a single service can only have

one Service ID, it can have many Service Class IDs.

剩余40页未读，继续阅读

花剑泪

粉丝: 0
资源: 1

蓝牙编程指南：探索无线短距通信技术

实验室设备管理系统 SSM毕业设计 附带论文.zip

PPT高效插件神器推荐-最新发布.zip

数据中心机房基础设计及规划方案.pdf

Visio软件全套资源及教程-最新发布.zip

2000-2022年中国地级市生态韧性数据集（含原始数据、计算代码及结果，最新）.zip

Spring Cloud 配置相关项目.zip

全国2009-2021年农业高质量发展指数测算（重磅，更新！）乡村振兴

Jupyter_这本书被命名为《木星笔记》.zip

1949-2021年中国民政统计年鉴-最新数据发布.zip

Jupyter_用于plot dash的OOP组件，使仪表板组件可组合、可重用和可配置.zip

最新资源

实验室设备管理系统 SSM毕业设计附带论文.zip