Design and Architecture Discussion Boards

I need opinions on which offers a better deal for a distributed system.

The choices are WCF/MSMQ or Asynchronus TCP Sockets.

So far WCF/MSMQ is ahead - because of how they implement transactions.

Ger

Some considerations which might or might not matter.

I am rather certain that you can't use WCF, MSMQ and MSMQ Transactions. You can investigate yourself but I believe there is a fundamental problem in terms of receiving them. Basically they can be sent ok (with a transaction), but when receiving them there is no assurance that the transaction is preserved. (I can't remember how I came to this conclusion.)

MSMQ has a hard 4 meg byte limit per message. Between overhead and unicode (not optional) that can reduce the maximum message sized to less than 2 meg (bytes.) Microsoft technical docs state they have no intention of changing this limit.

Despite claims to the contrary WCF/MSMQ does not support a streaming operation. So the message must always be less than 2 meg.

MSMQ uses magic routing which is great when it works (when you get all the ports/permissions right) but is extremely difficult to figure out otherwise. And because of that messages can take a long time to arrive at the target, for example hours.

MSMQ at least on OSes before 2008 (and maybe that too) uses by default a single file with a 2 gig limit for persistence. MSMQ will crash if that file fills. And there is no way to monitor problems via the MSMQ API (maybe there is something in WMI.)

Most of the standard MSMQ 'queues' use Active Directory. If Active Directory has problems then MSMQ will have problems. If you use options to exclude Active Directory then you CANNOT insure transactions are in use. See next note.

If one queue uses transactions and the other end doesn't, messages just disappear.

MSMQ failures can result in MSMQ exceptions which have a enum which indicates the type of error. The problem however is that API can end up returning a value, via the enum api, which is not a enum. Basically violating the contract of the method.

MSMQ queue permissions and application permissions must match. Which would seem obvious. However if they don't match then it returns non-helpful errors. Such as telling you that the queue doesn't exist (even though it does.)

MSMQ is supposed to support multiple clients consuming from a single queue. However someone I know (but not me) ran a test that suggested performance was significantly degraded in such a scenario when transactions were in use. Developing around this is complicated.

I can state that I built message streaming using chunking to break a larger (bigger than 4 meg) into pieces. It was extremely difficult. Especially since I was attempting to support multiple clients (see above limitation)

MSMQ is tied to the OS. This of course means that if you want to upgrade from, say, MSMQ 3.0 to 4.0, then you must upgrade the OS.

I have gone a considerable way down the WCF/MSMQ route (see my articles/posts) but find its awkwardness exasperating. Transactions were presented as a 'done deal' both in the documetation I read and the resposes to my queries. See Mohamad Halabai's work in this site and elsewhere.

Yor response is a welcome counter balance.

Ger

You should use only WCF. I am using WCF (.NET 4.0) with net.tcp protocol because it provides both: security (SSL)and maximum speed!

Raul Iloc

The problem with MSMQ is that the payload size is limited to 4 MB

We created a actually a framework that can transport jobs to multiple machines using :

1. MSMQ (only as an event trigger)
2. WCF + MS SQL (for managing the job distribution transaction based )
3. and a TCP component for async transport of the payload.
4. A base class that you inherit in each (windows service) application you build to process a job. This class gets and returns the payload to the WCF which stores or retrieve the data from the Database.

On which server a job has to be processed and what process should handle the job is controlled by a simple xml flowlist. This flowlist can be requested from a WCF service.

A very interesting solution. I'm well under the four meg limit, but have a future proofing exposure.

Ger

I think this article will provide a solution:
Using MSMQ in mail relay[^]

Ger