gpt4 book ai didi

Zeromq 1 to 1 async req-rep unreliable pattern(Zeromq 1到1的重复请求不可靠模式)

转载 作者:bug小助手 更新时间:2023-10-25 18:26:27 27 4
gpt4 key购买 nike



I have a 1 client to 1 server model, let's say the client will emit 100 req/s, but the server can only handle 50 req/s.

The client side is very tolerant. It says okay, I don't care about you dropping some of my requests, just process the latest one. What pattern should be applied in this situation?

我有一个1客户对1服务器的模型,假设客户端会发出100个请求/S,但服务器只能处理50个请求/S,客户端非常宽容。它说好吧,我不在乎你放弃我的一些请求,只要处理最新的请求即可。在这种情况下,应该采用什么模式?


Timeline ('<' denotes the server is processing the latest requests):
client: 1 -- 2 -- 3 -- 4 -- 5 -- 6 -- 7 -- 8 -- 9 -- 10
server: <<<<<<<<<< 1 <<<<<<< 3 <<<<<<<<<<<< 5 <<<<<<< (processing 8)

更多回答
优秀答案推荐

You probably want something like PUB/SUB with a low high water mark client to server, something like PUSH/PULL server to client, and something (like a GUID or serial number) in your requests that will be added to responses so that the client can work out what request a return from the server pertains to.

您可能想要具有低高水位线的发布/订阅、服务器到客户端的推送/拉入之类的内容,以及将添加到响应中的请求中的某些内容(例如GUID或序列号),以便客户端可以确定从服务器返回的请求与哪些请求有关。


The PUB/SUB is useful because it will drop messages in the PUBlisher if there are no SUBscribers. Having a the high water mark set to a low value (1) means that it won't stash a load of old messages until the server can absorb them. The PUSH/PULL for replies from the server to the client won't drop anything, so the replies will certainly get through.

发布/订阅非常有用,因为如果没有订阅服务器,它将丢弃发布服务器中的消息。将高水位线设置为低值(1)意味着它不会隐藏大量旧消息,直到服务器能够吸收它们。从服务器到客户端的回复的推送/拉入不会丢弃任何内容,因此回复肯定会通过。


This way the server can take it's own sweet time receiving requests on its SUB socket, and get a reply back on the PUSH socket.

这样,服务器就可以从容不迫地在其子套接字上接收请求,并在推送套接字上得到回复。


Note that we're not really using the PUB/SUB or PUSH/PULL patterns here - we're just using them for point-to-point connections with differing policies on what to do if things start bottling up. PUB/SUB drops messages, PUSH/PULL does not.

请注意,我们在这里并没有真正使用发布/订阅或推送/拉入模式-我们只是将它们用于点对点连接,并使用不同的策略来处理事情开始堵塞时该如何做。发布/订阅丢弃消息,推送/拉入不会。


That may be what you're looking for!

这可能就是你要找的东西!


更多回答

For the server reply to client, is PUSH/PULL necessary? Because if the client side accidentally down for a short period, it will receive several stale responses when reconnect back.

对于服务器回复客户端,是否需要推送/拉取?因为如果客户端在短时间内意外停机,重新连接时会收到几个过时的响应。

@LQsLLDB I think that would depend on what happens to the state of the client, if it's accidentally down. If it's going to remember what it did, then the response is still going to make sense. If the client is going to be restarted with no knowledge of what had happened before, then the responses that make no sense could simply be discarded. That would be helped if the request response tag was a GUID / UUID, as that would cope with anything. If you used PUB/SUB instead of PUSH/PULL, that'd allow responses to be dropped. Either way, you'd have to write the client to be aware of stale responses

@LQsLLDB我认为这取决于客户端的状态会发生什么,如果它意外停机的话。如果它会记住它做了什么,那么它的反应仍然是有意义的。如果在不知道以前发生了什么的情况下重新启动客户端,则可以简单地丢弃没有意义的响应。如果请求响应标记是GUID/UUID,这将有所帮助,因为它可以处理任何事情。如果您使用发布/订阅而不是推/拉,那么将允许丢弃响应。无论采用哪种方式,您都必须编写客户端以了解过时的响应

27 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com