在JSON-RPC连接上读取多个JSON对象

我正在制作一个流API，它处理RPC样式的调用以及从服务器到客户端的通知（而不是JSON-RPC规范中的客户端到服务器的通知）。不幸的是，最后一部分排除了JSON-RPC+持久HTTP

该API基于JSON和JSON-RPC规范

JSON-

JSON-RPC-

典型的会话可能是：

-> Sending to server
<- Receiving from server    

-> {'id': 0, 'method':'login','params':{'token':'secret'}}
<- {'id': 0, 'method':'login','result':0}
-> {'id': 1, 'method':'subscribe','params':{'symbol':'VOD.L'}}
<- {'id': 1, 'method':'subscribe','result':0}
...
<- {'method':'notifyPrice','params':{'symbol':'VOD.L', 'bid':10.1, 'ask':10.03}}
<- {'method':'notifyPrice','params':{'symbol':'VOD.L', 'bid':10.2, 'ask':10.03}}

->发送到服务器
{'id'：0，'method'：'login'，'params'：{'token'：'secret'}
{'id'：1，'method'：'subscribe'，'params'：{'symbol'：'VOD.L'}
您缺少了一些内容：-）

每个JSON-RPC消息都是有效的JSON值。JSON值可以由以下任意一种方式生成：


数组
对象
一个
字符串
a
编号

JSON-RPC信封是一个
对象

如果这是一个原始套接字（如Telnet），那么…

对象以
{
开头，以
}
结尾。
如果您在接收器上使用了正确类型的解析器（pull或面向事件的解析器），那么无论
对象和
数组的嵌套程度如何，您仍然可以知道最后一个
}
是何时到达的

上述消息，特别是通知，可以以任何顺序出现在同一数据包中

只要请求不是交错的（一个在下一个开始之前完成），那么就根本没有问题。这取决于您是否还需要信封的换行终止（也称为面向行的协议）

但是，当您处理HTTP时…

为什么不按照JSON-RPC规范使用消息？
是的，我同意你所说的一切，但正如我在问题中所说的，面向SAX/事件的JSON解析器并不多——这些解析器没有经过良好测试/使用。而且，我不需要一个面向SAX/事件的实现——消息不长，内存也不短，而且我不希望解析消息只是为了找到它何时终止。另外，我没有使用HTTP，不管怎样，使用批处理都没有帮助，因为如果不使用SAX/面向事件的解析器，您仍然不知道批处理何时结束。此外，问题是“是否真的没有标准的方法来分离通过线路传入的多个JSON消息？”您说过我可以使用换行终止符，但这不在规范中，肯定会导致与其他JSON RPC库不兼容？
我可以使用换行符，但规范中没有，在什么规范中？JSON-RPC规范与传输协议无关。HTTP包含大量的换行符（这对HTTP来说意味着什么，但对JSON-RPC来说并不意味着什么），它是JSON-RPC最常用的传输协议。JSON-RPC规范处理特定结构的JSON消息。它不关心您在其中嵌入这些JSON消息的其他协议。您是否花了一些时间阅读了有关批处理消息的内容？我认为您对JSON-RPC规范的内容、传输协议以及各种库的功能感到非常困惑。消息的批处理发生在JSON-RPC消息本身内部。您无需进行任何额外的解析（除了识别JSON-RPC消息本身的结尾）。如果您使用的传输协议没有自然分隔符（即：原始TCP套接字），那么您必须自己跟踪协议状态。就这点而言，SAX/事件解析器通常是常量内存解析器。。。为什么内存会成为一个问题呢？好的，关于JSON-RPC和底层协议之间的分离。我错过了。这就是问题的答案——没有办法分离消息，因为这不是JSON-RPC协议的责任。好。：）