正如我在另一篇文章中所写（"对称过程"中的" NFC P2P LLCP中的"对称过程"），我目前正在尝试实现LLCP＆amp;PN532芯片上的SNEP协议。我在另一篇文章中的问题是关于llcp中定义的对称过程，该过程允许实际绕过原始启动器/目标角色（命令/响应），即给出每个对等设备随时发送消息的更改。
如果我做对了，则SNEP-Protocol定义了客户端/服务器方法。该角色实际上是定义的当一个设备（客户端）将CONN-PDU发送到对等设备（服务器）时，LLCP级别时。之后，客户可以使用SNEP中定义的" PUT请求"将NDEF-Message发送到服务器。
现在假设，客户端已将其NDEF消息发送给服务器，并取决于应用程序 - 当前充当服务器的同行设备想要将新的（不是响应）NDEF消息发送回到当前客户。
我的假设是当前服务器将向当前客户端发送新的conn-pdu，以防万一，两种设备都会更改其初始角色，即初始客户端现在成为服务器等。
最初建立的连接会怎样？它会被关闭还是仍然可以与新的可以并行？
此外（如果我从上面的假设正确）授权还会更改启动器/目标角色，或者两个设备都可以保留在其初始（Mac）模式中？
非常感谢！
如果我正确地说，Snep-protocol定义了客户端/服务器 方法。当一个角色实际上是在LLCP级别定义的 设备（客户端）将CONN-PDU发送到对等设备（服务器）。
不，这不是它的工作方式。该角色不是这样定义的。从规范来看，这并不明显，但是每个同行通常是客户和服务器。
请注意，规格第6.1节"功能描述"定义了以下默认行为：
默认服务器不接受获取请求。
这意味着，一般不允许客户端请求NDEF消息。客户应该在可用的情况下按自己的消息。
SNEP中通常的消息流如下：
-
初始状态：LLCP链接下降。每个对等都有一个SNEP服务器注册并等待连接。
-
在llcp connect上：想要发送消息的每个同行都尝试使用自己的SNEP客户端连接到对方的SNEP服务器。
-
在SNEP上连接SNEP服务器将：等待SNEP put命令。然后，它可以接受该消息或拒绝消息：
-
在Snep Connect上，SNEP客户端将：发送一个put命令以及其NDEF数据。
双方都传输了它的消息（如果愿意的话），他们只需打开SNEP连接即可。无论如何，没有正确的方法可以关闭此连接，也没有与之相关的成本。每个客户在任何时候都可以（如果需要）始终发送额外的看请请求。这对于在SNEP上的双向数据流质量可能很有用。
Android不允许使用此双向数据流，因为它们在某种程度上有些愚蠢，不允许发送第二个消息，但是他们会很乐意接受传递给它的其他消息。