我正在用 C# 构建一个低功耗蓝牙测试应用程序，以使两个 Windows 10 应用程序进行通信(中央应用程序使用商业 .NET Framework SDK，外围应用程序使用商业 .NET Framework SDK一个使用 UWP)，我正在尝试了解 MTU(最大传输单元)在应用程序级别的影响。到目前为止我的理解是这样的:
在蓝牙堆栈的L2CAP层中，“大”数据包会发生一些碎片和重组。因此，如果数据超过 MTU，它将以 block 的形式发送。
在 UWP 中，我们使用 GattLocalCharacteristic.WriteRequested 回调来处理接收到的数据。在我正在处理的示例中，当发送 2-3K 数据时，每 block 522 字节都会调用它(可能是协商的 MTU？)，所以看来我必须在应用程序级别处理重组，尽管它应该在 L2CAP 级别完成(如果我理解正确的话)。这意味着我必须检测数据何时完整(使用某种长度字段、“EOF”或任何机制)，这给协议(protocol)增加了一些负担，并且对我来说感觉非常低级。我本以为 WriteRequested 事件只会触发一次，其中包含所有数据。
最重要的是，UWP SDK(Windows.Devices.Bluetooth 命名空间)似乎没有提供了解实际 MTU 的方法(例如 requestMtu在 Android 上)，所以在这里我必须再次制作一些自定义管道。
所以我想问题是:我是否必须检测协商的 MTU(在 UWP 中如何？)并自己分段和重新组合数据包？
最佳答案
您不必在 Windows 10 上协商 MTU。
它仅取决于所使用的蓝牙版本。
BLE4.0/4.1 的最大 MTU 为 23 字节，BLE4.2 的最大 MTU 为 251 字节。
对于 Windows 10 上的其他版本，我不知道最大值。
MTU 由 L2CAP 定义，可以是 23 到无穷大之间的任意值。蓝牙堆栈的实现是确定客户端和外设上的 MTU 的关键因素。
Windows 10 设备将始终尝试协商最大 MTU。
关于c# - 我们是否必须在应用程序级别处理蓝牙 LE 通信中的 MTU？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/57660713/