扭曲的 RPC 是否能保证按顺序到达？
我正在使用twisted 来实现客户端和服务器。我已经在客户端和服务器之间设置了 RPC。因此，在客户端上，我执行了 protocol.REQUEST_UPDATE_STATS(stats) 操作，这意味着在客户端传输上使用 transport.write 发送消息，该消息是 的某种编码版本[“update_stats”，统计数据]。当服务器收到此消息时，将调用服务器协议上的 dataReceived 函数，对其进行解码，并根据该消息调用一个函数，例如中的 CMD_UPDATE_STATS(stats)这个案例。
如果在客户端上我执行以下操作：
protocol.REQUEST_UPDATE_STATS("stats1")
protocol.REQUEST_UPDATE_STATS("stats2")
...我能否保证 "stats1" 消息先于服务器上的 "stats2" 消息到达？
更新：为了更加清晰而进行了编辑。但现在答案似乎很明显——不可能。
I'm using twisted to implement a client and a server. I've set up RPC between the client and the server. So on the client I do protocol.REQUEST_UPDATE_STATS(stats), which translates into sending a message with transport.write on the client transport that is some encoded version of ["update_stats", stats]. When the server receives this message, the dataReceived function on the server protocol is called, it decodes it, and calls a function based on the message, like CMD_UPDATE_STATS(stats) in this case.
If, on the client, I do something like:
protocol.REQUEST_UPDATE_STATS("stats1")
protocol.REQUEST_UPDATE_STATS("stats2")
...am I guaranteed that the "stats1" message arrives before the "stats2" message on the server?
UPDATE: Edited for more clarity. But now the answer seems obvious - no way.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
它们将按照 Python 进程接收请求的顺序到达。这包括连接建立时间以及包含请求数据的数据包。因此，不，这不能保证是发送进程发送请求的顺序，因为网络延迟、丢弃的数据包、发送方数据包排队等。“按顺序”对于分布式系统也有松散的定义。
但是，是的，一般来说，只要它们相隔相对较长的时间（通过互联网传输数百毫秒），您就可以指望它们按顺序交付。
They will arrive in the order that the request is received by the Python process. This includes the connection setup time plus the packets containing the request data. So no, this is not guaranteed to be the order that the sending processes sent the request, because of network latency, dropped packets, sender-side packet queuing, etc. "In-order" is also loosely defined for distributed systems.
But yes, in general you can count on them being delivered in-order as long as they're separated by a relatively large amount of time (100's of ms over the internet).