views:

794

answers:

2

I'm tasked with implementing a messaging system for a real-time simulation. There are several different kinds of messaging objects that need to exist in this system, and more might be added in the future. These objects represent the primary means of communication between the players in the sim. Assuming I fully understand my requirements, the messaging objects can be defined by the following attributes:

  • Send protocol (what messages a player can send and when)
  • Receive protocol (what messages a player can receive and how often)
  • Message format (structure of the data being sent)

The simulation code currently only supports one send and receive protocol and one message format. My job is to make the code more extensible so it can support future changes/additions to protocols and message structure. A first-cut approach to this would be to define abstract base classes for each of the attributes and have each messaging object be composed of handles to them. Every messaging object can then be written as different combinations of protocol and format objects. My concern is that this design can quickly become over-generalized and thus a maintenance nightmare. I cringe at the thought of sifting through a dozen files just to figure out how the heck a FooMessaging really works.

I'll be writing this in C++, but I think this is really more a general design question. Are there any "standard" patterns or best practices I can apply here?

+4  A: 
Charlie Martin
I've reworded my question to hopefully make it clearer. I am *not* designing the messaging system itself. Rather, I am looking for a good way to make it easy to add new send/receive protocols and message formats in the future. And yes, in our case, the message format does vary independently from the protocol being used. Sorry for being vague, but I'm not allowed to provide specific details.
Kristo
The question is still very vague. I've worked on a number of projects that included something that could fit your description, and they were all very different. That tells me that your description of the problem is still not specific enough to let anyone give you a useful answer. Things that would change your design radically but you haven't talked about are whether the messages are sent between processes running on the same machine, on a network, between threads, or in a single thread. Whether any object can message any other object, or do objects are expected to do something specific
Ori Pessach
in order to receive messages. Will a message loop be acceptable design? Will the messaging layer be expected to call methods on the objects in response to messages? Would that even be acceptable? Are messages synchronous or asynchronous? Is there guaranteed delivery? Is the messaging layer expected to store and forward messages to objects that aren't there yet, aren't listening or unreachable?The fact that someone proposed Apache ActiveMQ as an answer should tell you how bad your question was.
Ori Pessach
The transport layer is already fixed in stone for this project and can effectively be treated as a black box from my point of view. Also, a player can attempt to send messages at any time, but the send protocol will hold them until they're allowed to go. Likewise, players will physically receive messages every frame, but the receive protocol won't let them be processed until the right time.
Kristo
+1  A: 

I believe you should take a look on Apache ActiveMQ. Actually, it is written on Java, but has option to use C++ clients and well documented also.

Cheers.

Artyom Sokolov
I can't see this without warning people NOT to use ActiveMQ.
Ori Pessach
Why not? Please, comment. Thanks.
Artyom Sokolov
I've seen it used in a project. It failed to scale to a moderate number of clients and had severe stability issues that were never resolved. To add insult to injury, its performance was rather poor. In my opinion, it is a ridiculously over engineered solution to a problem that doesn't need a solution that suffers from overgeneralization to this degree.
Ori Pessach