NFC P2P - SNEP 客户端/服务器
NFC P2P - SNEP Client / Server
正如我在另一个 post () 中所写，我目前正在尝试在 PN532 芯片上实施 LLCP 和 SNEP 协议。
我在另一个 post 中遇到的问题是关于 LLCP 中定义的对称过程，它允许
实际上绕过原始发起者/目标角色（命令/响应），即给每个对等设备
更改为随时发送消息。
如果我没记错的话，SNEP 协议定义了客户端/服务器方法。该角色实际上定义在
当一个设备（客户端）向对等设备（服务器）发送 CONN-PDU 时的 LLCP 级别。
之后，客户端可以使用 SNEP 中定义的 "PUT Request" 向服务器发送 NDEF 消息。
现在假设，客户端已将其 NDEF 消息发送到服务器，并且 - 根据应用程序 -
当前充当服务器的对等设备想要将新的（不是响应）NDEF 消息发送回
当前客户。
我的假设是当前服务器将向当前客户端发送一个新的 CONN-PDU，如果成功，
两个设备都改变了它们的初始角色，即初始客户端现在变成了服务器等
最初建立的连接会怎样？它会被关闭还是仍然可以与新的平行存在？
此外（如果我上面的假设是正确的），是否也有必要在 NFC MAC 级别上更改客户端/服务器
还要求更改启动器/目标角色，或者两个设备能否保持其初始 (MAC) 模式？
非常感谢！
If i got it right, the SNEP-protocol defines a Client / Server
approach. The role is actually defined at the LLCP-level when one
device (client) sends a CONN-PDU to the peer device (server).
不，事情不是这样的。角色不是这样定义的。从规范上看并不明显，但每个对等点通常同时是客户端和服务器。
请注意，规范第 6.1 节 "Functional Description" 定义了以下默认行为：
The default server SHALL NOT accept Get requests.
这意味着，客户端通常不允许请求 NDEF 消息。如果可用，客户端应该推送它自己的消息。
SNEP 中的常规消息流如下所示：
初始状态：LLCP link 已关闭。每个对等点都有一个 SNEP 服务器注册并等待连接。
在 LLCP 连接上：每个想要发送消息的对等点都尝试使用自己的 SNEP 客户端连接到对方的 SNEP 服务器。
在 SNEP 连接上，SNEP 服务器将：等待 SNEP PUT 命令。然后它可以接受消息或拒绝消息：
在 SNEP 连接上，SNEP 客户端将：发送 PUT 命令及其 NDEF 数据。
一旦每一方都传输了它的消息（如果他们愿意的话），他们就让 SNEP 连接保持打开状态。无论如何都没有关闭此连接的正确方法，也没有与之相关的成本。如果愿意，每个客户端都可以随时发送额外的 PUT 请求。这对于通过 SNEP 建立双向数据流很有用。
Android 不允许这种双向数据流，因为他们稍微简化了 SNEP 并且不允许发送第二条消息，但他们会很乐意接受传递给它的其他消息。
正如我在另一个 post (
如果我没记错的话，SNEP 协议定义了客户端/服务器方法。该角色实际上定义在 当一个设备（客户端）向对等设备（服务器）发送 CONN-PDU 时的 LLCP 级别。 之后，客户端可以使用 SNEP 中定义的 "PUT Request" 向服务器发送 NDEF 消息。
现在假设，客户端已将其 NDEF 消息发送到服务器，并且 - 根据应用程序 - 当前充当服务器的对等设备想要将新的（不是响应）NDEF 消息发送回 当前客户。
我的假设是当前服务器将向当前客户端发送一个新的 CONN-PDU，如果成功， 两个设备都改变了它们的初始角色，即初始客户端现在变成了服务器等
最初建立的连接会怎样？它会被关闭还是仍然可以与新的平行存在？
此外（如果我上面的假设是正确的），是否也有必要在 NFC MAC 级别上更改客户端/服务器 还要求更改启动器/目标角色，或者两个设备能否保持其初始 (MAC) 模式？
非常感谢！
If i got it right, the SNEP-protocol defines a Client / Server approach. The role is actually defined at the LLCP-level when one device (client) sends a CONN-PDU to the peer device (server).
不，事情不是这样的。角色不是这样定义的。从规范上看并不明显，但每个对等点通常同时是客户端和服务器。
请注意，规范第 6.1 节 "Functional Description" 定义了以下默认行为：
The default server SHALL NOT accept Get requests.
这意味着，客户端通常不允许请求 NDEF 消息。如果可用，客户端应该推送它自己的消息。
SNEP 中的常规消息流如下所示：
初始状态：LLCP link 已关闭。每个对等点都有一个 SNEP 服务器注册并等待连接。
在 LLCP 连接上：每个想要发送消息的对等点都尝试使用自己的 SNEP 客户端连接到对方的 SNEP 服务器。
在 SNEP 连接上，SNEP 服务器将：等待 SNEP PUT 命令。然后它可以接受消息或拒绝消息：
在 SNEP 连接上，SNEP 客户端将：发送 PUT 命令及其 NDEF 数据。
一旦每一方都传输了它的消息（如果他们愿意的话），他们就让 SNEP 连接保持打开状态。无论如何都没有关闭此连接的正确方法，也没有与之相关的成本。如果愿意，每个客户端都可以随时发送额外的 PUT 请求。这对于通过 SNEP 建立双向数据流很有用。
Android 不允许这种双向数据流，因为他们稍微简化了 SNEP 并且不允许发送第二条消息，但他们会很乐意接受传递给它的其他消息。