正如我在另一篇文章（"Symmetry Procedure" in NFC P2P LLCP）中写的那样，我目前正试图实施LLCP＆amp; PN532芯片上的SNEP协议。 我在另一篇文章中提到的问题是关于LLCP中允许的对称程序 实际上绕过原始的发起者/目标角色（命令/响应），即给每个对等设备 随时发送消息的更改。
如果我做对了，SNEP协议定义了一个客户端/服务器方法。该角色实际上定义为 当一个设备（客户端）将CONN-PDU发送到对等设备（服务器）时的LLCP级别。 之后，客户端可以使用＆＃34; PUT请求＆＃34;将NDEF消息发送到服务器。如SNEP中所定义。
现在假设，客户端已将其NDEF消息发送到服务器，并且 - 取决于应用程序 - 当前充当服务器的对等设备想要将新的（非响应）NDEF消息发送回 现任客户。
我的假设是当前服务器会向当前客户端发送新的CONN-PDU，如果成功， 两个设备都会更改其初始角色，即初始客户端现在变为服务器等。
最初建立的连接会发生什么？它会被关闭还是仍然可以与新的平行存在？
另外（如果我的假设是正确的），在NFC MAC级别上还需要客户端/服务器更改 还要求更改启动器/目标角色，还是两个设备都能保持初始（MAC）模式？
非常感谢！
答案 0 :(得分：0)
如果我做对了，SNEP协议定义了一个客户端/服务器 做法。该角色实际上是在LLCP级别定义的 设备（客户端）将CONN-PDU发送到对等设备（服务器）。
不，这不是它的工作原理。角色没有这样定义。从规范来看并不明显，但每个对等体通常同时是客户端和服务器。
请注意，规范部分6.1“功能描述”定义了以下默认行为：
默认服务器不接受Get requests。
这意味着，通常不允许客户端请求NDEF消息。如果可用，客户端应该推送它自己的消息。
SNEP中的常见消息流如下所示：
初始状态：LLCP链接已关闭。每个对等体都注册了SNEP服务器并等待连接。
在LLCP连接上：每个想要发送消息的对等方都尝试使用自己的SNEP客户端连接到对方的SNEP服务器。
在SNEP上连接SNEP服务器将：等待SNEP PUT命令。然后它可以接受消息或拒绝它：
在SNEP连接上，SNEP客户端将：发送PUT命令及其NDEF数据。
一旦每一方都发送了它的消息（如果他们想要的话），他们就会让SNEP连接保持打开状态。无论如何都没有正确的方法来关闭此连接，也没有与之相关的成本。每个客户端可以 - 在任何时候 - 总是发送额外的PUT请求。这对于在SNEP上建立双向数据流非常有用。
Android不会允许这种双向数据流，因为它们稍微使SNEP失败了一些并且不允许发送第二条消息，但是他们很乐意接受传递给它的其他消息。