基于代理(中介)的通信的现成可用实现

发布于 2024-10-03 20:09:45 字数 663 浏览 3 评论 0原文

我不确定如何正确地提出问题,所以如果有更好的想法 - 请继续提出建议。

问题很简单。我有 2 个对等点 A 和 B,都位于防火墙后面。我希望他们使用公共经纪人或调解员来相互沟通,无论哪个名字更适合。

通信是异步的,过程如下:

  1. A 和 B 定期轮询代理,询问是否有给他们的消息。
  2. 当 A 希望与 B 通信时,它会向代理发送一条消息,表明该消息是发给 B 的。
  3. 当 B 轮询代理时,代理发现确实有一条消息,并做出相应响应。
  4. B 处理消息并将响应发送回代理,表明这是对来自 A 的特定消息的响应。
  5. 在某个时刻,A 轮询代理并接收来自 B 的响应。

现在,在我冲进去实施此操作之前我自己进行了某种通信,我想知道是否有现成的软件包可以允许这种开箱即用的通信。

有人吗?

谢谢。

EDIT1

我想强调一点,对等方可能没有安装消息服务器。这意味着,用两个单向连接模拟请求-响应是不可能的。我确实需要能够得到对等方响应的答复,因此它不能是单向通信。

EDIT2

另一个限制是只有 HTTP(S) 端口可以打开用于通信,因此代理 A 和 B 可能处于仅使用 HTTP(S) 与代理进行通信的情况。

I am not sure how to formulate the question correctly, so if there are better ideas - go ahead and suggest them.

The problem is simple. I have 2 peers A and B, both behind firewalls. I wish them to communicate with each other using a public broker or mediator, whichever name suits better.

The communication is asynchronous and goes something like this:

  1. Both A and B periodically poll the broker asking whether there are messages for them.
  2. When A wishes to communicate with B it sends a message to the broker, indicating that the message is for B.
  3. When B polls the broker, the broker sees that there is indeed a message for it and responds accordingly.
  4. B processes the messages and sends the response back to the broker, indicating that this is a response to the particular message from A.
  5. At some point A polls the broker and receives back the response from B.

Now, before I rush in and implement this sort of communication myself, I am wondering whether there are ready to use packages that allow for this sort of communication out of the box.

Anyone?

Thanks.

EDIT1

I wish to emphasize that a peer may not have a message server installed on it. Meaning, simulating request-response with two one-way connections is not possible. I really need to be able to get a reply to peer's response, so it cannot be one-way communication.

EDIT2

One more constraint is that only HTTP(S) ports may be open for the communication, so the agents A and B may be in a situation where they communicate to the broker using HTTP(S) only.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

美煞众生 2024-10-10 20:09:45

有 ESB 吗?例如 http://www.nservicebus.com/,或更轻量级:http://www.zeromq.org/

any esb wold do? For instance http://www.nservicebus.com/, or more lightweight: http://www.zeromq.org/

赢得她心 2024-10-10 20:09:45

您可以使用任何 HTTPS 堆栈轻松完成此操作(IMO)。您的代理的架构取决于您需要处理的数量和并发性。创建一个资源模型,以便您的应用程序可以 PUT 和 GET 消息(其中 URI 包含目标节点),并添加回复地址的参数。您应该花费大约 1 天的时间来弄清楚工作资源模型,并花费 4 个小时来对其进行编码。如果您需要容量,请使用像 mongrel2 这样具有 Zeromq 后端的服务器。或者node.js,它应该可以很好地做到这一点。

ZeroMQ 非常适合构建并发应用程序,但它不是 HTTP/S 服务,最好由 mongrel2 等专用前端来处理。

You can make this trivially (IMO) using any HTTPS stack. The architecture of your broker depends on the volume and concurrency you need to handle. Create a resource model such that your applications can PUT and GET messages, where the URI contains the destination node, and add a parameter for a reply address. It should take you about 1 day to figure out a working resource model, 4 hours to code it up. If you need volume, take a server like mongrel2 which has a zeromq backend. Or node.js, which should do this admirably.

ZeroMQ is ideal for building concurrent apps but it's not a HTTP/S service, that's better handed by dedicated front-ends like mongrel2.

天气好吗我好吗 2024-10-10 20:09:45

此类代理作为 Azure 平台中 AppFabric 的一部分存在。在AppFabric中,您可以使用服务总线,它允许这样的中继通信。但使用时需要付费。

Such broker exists as part of AppFabric in Azure platform. In AppFabric you can use Service bus which allows such relayed communication. But you have to pay fees when using it.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文