关于JMS体系结构
我正在编写一个服务器/客户端游戏，一个典型的场景是这样的：一个客户端（clientA）向服务器发送一条消息，服务器中有一个 MessageDrivenBean 来处理此类消息。 MDB 完成其工作后，会将结果消息发送回另一个客户端（clientB）。
在我看来，我只需要两个队列来进行这种通信，一个用于输入，另一个用于输出。为每个连接创建新队列不是一个好主意，对吗？ 输入队列相对清晰，如果有更多客户端同时发送消息，消息只是在队列中等待，而服务器中有更多MDB实例，这应该不会是一个大的性能问题。
但另一方面我对输出队列不太清楚，我应该使用主题而不是队列吗？每个客户端都在监听输出队列，其中一个客户端获取新消息并检查属性以确定该消息是否发送给它，如果不是，则回滚事务，消息返回到队列并为其他客户端做好准备……应该可以工作，但速度一定很慢。如果我使用主题，每个客户端都会收到消息的副本，如果不是，则忽略该消息。应该会更好吧？
我对消息系统很陌生。对我的实施有什么建议吗？谢谢！
I’m writing a server/client game, a typical scenario looks like this: one client (clientA) send a message to the server, there is a MessageDrivenBean in server to handle such messages. After the MDB finished its job, it sends the result message back to another client (clientB).
In my opinion I only need two queues for such communication, one for input the other for output. Creating new queue for each connection is not a good idea, right?
The Input queue is relative clear, if more clients are sending message at the same time, the messages are just waiting in the queue, while there are more MDB instances in server, that should not a big performance issue.
But on the other side I am not quite clear about the output queue, should I use a topic instead of a queue? Every client is listening the output queue, one of them gets the new message and checks the property to determine if the message is to it, if not, it rollback the transaction, the message goes back to queue and be ready for other client … It should work but must be very slow. If I use topic instead, every client gets a copy of the message, if it’s not to it, just ignores the message. It should be better, right?
I’m new about message system. Is there any suggestion about my implementation? Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
首先，选择 JMS 作为游戏平台是很不寻常的——企业使用 JMS 代理来实现交付可靠性和事务支持。您真的需要在游戏中进行如此繁重的提升吗？例如，您难道不应该诉诸您自己的基于 HTTP 的协议吗？
也就是说，两个队列是点对点通信的标准模式。为新连接创建队列绝对是不行的 — 消息驱动 bean 在部署时附加到队列，因此您将无法响应队列创建事件。此外，队列并不意味着在短周期内创建和销毁，而是被设计为长期存在的实体。如果您需要将消息传递给一个特定的客户端，请让客户端侦听服务器响应队列，并将消息选择器设置为仅过滤针对此客户端的消息（请参阅
javax.jms.MessageAPI ）。对于主题，正如您所指出的那样 - 每个连接的客户端都会获得消息的副本 - 因此，向 n 个客户端发送一条必须被 丢弃的消息并不是一个好的模式n-1 个客户端。
To begin with, choosing JMS as a gaming platform is, well, unusual — businesses use JMS brokers for delivery reliability and transaction support. Do you really need this heavy lifiting in a game? Shouldn't you resort to your own HTTP-based protocol, for example?
That said, two queues are a standard pattern for point-to-point communication. Creating a queue for a new connection is definitely not OK — message-driven beans are attached to queues at deployment time, so you won't be able to respond to queue creation events. Besides, queues are not meant to be created and destroyed in short cycles, they're rather designed to be long-living entities. If you need to deliver a message to one precise client, have the client listen on the server response queue with a message selector set to filter only the messages intended for this client (see
javax.jms.MessageAPI).With topics it's exactly as you noted — each connected client will get a copy of the message — so again, it's not a good pattern to send to n clients a message that has to be discarded by n-1 clients.
马达；
您可以保留一个输出队列（或主题），并简单地使用标识预期客户端的标头来标记消息。然后，客户端可以使用选择器监听队列/主题。希望您的 JMS 实现具有高效的服务器端侦听器评估。
MaDa;
You could stick one output queue (or topic) and simply tag the message with a header that identifies the intended client. Then, clients can listen on the queue/topic using a selector. Hopefully your JMS implementation has efficient server-side listener evaluation.