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 并且不允许发送第二条消息,但他们会很乐意接受传递给它的其他消息。