Queue alternatives to MSMQ on Windows?

Question

I'm building a WCF Service that uses Custom Username/Password validation on netTcpBinding with message level security. I've been researching MaxReceivedMessageSize settings and I've got a query of a rather technical nature. I've noticed that when you specify a custom username validator that it gets called deep inside the plumbing of WCF (during handshaking I suppose).

If I have a relatively large MaxReceivedMessageSize of 1MB, will WCF read the entire message off the line and then do authentication, or will it first do the authentication and somehow discard the rest of the message?

The reason for my query is DoS attacks. I am hoping that due to the authentication the service would be immune to large message DoS attacks.

Solution 1

I can't begin to say enough good things about Tibco EMS - an implementation of the Java JMS messaging spec. Tibco EMS has superb support for .NET clients - including Compact Framework .NET on WinCE. (They also have C client libraries too.)

So if you're building a heterogeneous distributed application involving messaging code running on Windows, Unix (AIX/Solaris), Linux, or Mac OS X, then Tibco EMS is the ticket.

Check out my article here:

Using JMS For Distributed Software Development

I used to work at Microsoft and did some implementation with MSMQ while there. But you know, Microsoft just concerns itself with Windows. They depended on 3rd parties to provide MSMQ clients to other platforms. My encounter with Tibco EMS was a much better experience. It was very evident that Tibco understood messaging much more so than Microsoft. And Tibco put the effort into supporting diverse client bindings themselves. That is why they eventually changed the product name from Tibco JMS to Tibco EMS (Enterprise Messaging Service).

And I did build heterogeneous software systems around Tibco EMS. Rolled C# .NET Winform clients interacting with Java/JBoss middle-tier via Tibco EMS messaging. (And also have WinCE industrial embedded computers that use the Compact Framework .NET Tibco client.)

Links To My JMS Writings

Solution 2

May not be "best practice" advice here... but based on real life needs and experience: we have distributed system, 60 boxes running each 10 clients all do task X, and they need to take the next task from a queue. The queue is being fed from one other "client"...

We had used inter process communication, we used MSMQ, we tried service broker... It just doesn't work in the long term because you are giving away the control of your application to Microsoft. It works great as long as your needs are satisfied. it becomes hell when you need something not supported.

The best solution for us was: Use a SQL Database table as the queue. Don't reinvent the wheel there, since you will make mistakes (locks). There is info out there on how to do it, it is very easy and we handled over 200K messages per 24H (with 60x10 = 600 concurrent reads and writes to the queue). That is in addition to the same SQL server handling the rest of the application stuff...

Some reasons why MSMQ doesn't work:

1. When you need to change the logic of the queue to not FIFO, but something like "the oldest RED message" or "the oldest BLUE message" you can't do it. (I know what people will say, you can do it by having a red queue and a blue queue.. .But what if the number/types of queues is dynamic based on the way the application is administrated and changes daily?)

2. It adds a point of failure and deployment nightmare (the queue is a point of failure and you need to deal with setting the right permissions on all boxes to read/write messages etc' in Enterprise software you pay in blood for these type of things). SQL server... all clients are writing/reading already from the DB, it is just one more table..

Solution 3

The RabbitMQ framework seems to have been overlooked here. If folks still care, it does have a .NET 2.0 code base and it comes with a WCF binding similar to netMsmqBinding. The binding naturally requires at least .NET 3.0 and it has more features than the built-in netMsmqBinding. On top of it all, it is Mono friendly. Its worth a look.

Solution 4

What about SQL 2005's service broker?

Solution 5

Why not use ActiveMQ? :)

View more solutions

Comments

[Andre Luus]

Damn :)! Thanks for that clarification. What would you reckon would happen if I had transport level security enabled then?