2

I'm developing a few applications for embedded devices; they should be compatible with both Windows CE 5.0 and XP embedded using C# 2.0. Applications should exchange small messages which usually represent events. I implemented a first prototype using TCP sockets and a separate server acting as dispatcher (with a pub/sub pattern). It works, but I'm wondering if using MSMQ would be a better solution. Persisting messages would help me in a few scenarios, but generally all events should be consumed immediately by target applications. I would like to know pros and cons for both solutions and some guidelines to help me with the decision.

Thank you

fra
  • 3,488
  • 5
  • 38
  • 61

2 Answers2

3

Well, message queuing is great for its guaranteed delivery over a transactional queue. Which helps making your system resilient to crashes and unexpected reboots. But that will typically only work out well when you can restart your app from such a mishap and be able to restore state before you start receiving messages again.

That's a non-trivial requirement. If you cannot meet it, any stateful messages tend to take the machine down again. There's almost always explicit state in messages, even if their content is not stateful, simply by the order in which they are received and mutate your program state. This has been the curse for middleware, software that assumes that networking is an implementation detail that can be abstracted away does not work well in practice.

I thought this answer at SO expressed this problem particularly well.

Community
  • 1
  • 1
Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536
2

I would be inclined to abstract out an interface and implement them both based on the interface and make the decision a configuration item. Let the users choose a protocol based on their potentially changing needs.

Kell
  • 3,252
  • 20
  • 19