Ayende @ Rahien

My name is Oren Eini
Founder of Hibernating Rhinos LTD and RavenDB.
You can reach me by phone or email:


+972 52-548-6969

, @ Q c

Posts: 6,128 | Comments: 45,550

filter by tags archive

Silverlight Queues: Design

time to read 4 min | 619 words

I got a question about the feasibility of porting Rhino Queues to Silverlight, but that isn’t really something that can fit in that scenario. So I set down to write the design for a Silverlight queuing system. Just to be clear, I have no intention currently to actually build this at this time (well, not unless someone is willing to pay for it or I get a project that requires it). This is merely a way to get the design problem off my head.

Why can’t we just port Rhino Queues to Silverlight?

There are two reasons, one is technical, the second relates to the different way that Silverlight applications are used. The first problem is that Rhino Queues requires a way to listen to incoming messages, but Silverlight offers no way of doing such (reasonably so, FWIW, since that would turn the Silverlight app to a server, and there are probably security issues with that).

The second problem is simply that the way most Silverlight solutions are structured, there is going to be a WAN between the Silverlight app and the server, and WAN between each client. Direct connections between the Server & Silverlight client is likely to be possible only when using HTTP, and there isn’t going to be any direct communication between different clients.

This usually looks something like this:


Rhino Queues is built on the notion of independent agents, each of them containing a full queuing stack. That model will not work for Silverlight. In Silverlight, we need to support all the usual queuing features, but each agent (Silverlight application) is no longer independent.

The Silverlight Queues model will be slightly different. We introduce a Queues server component which will hold the queues & messages internally.


On the client side, the process of sending messages is:

  • Queues.Send(“server”, “Orders”, new Buy{ … });
  • Message is saved to isolated storage
  • A background thread send the messages from isolated storage to the Queues server.

The process of receiving messages is:

  • A background thread periodically pools (an alternative is a Comet using something like WebSync) the server for new messages.
  • Messages are written to isolated storage
  • The Silverlight acknowledge the receipt of the messages.

There are some twists here, though.

In a Silverlight application, there are going to be several possible use cases:

  • Each Silverlight application has its own “queue” in the Queues server. That allows a one-way messaging platform with point to point notification. That is likely to be common in Silverlight applications that handle business transactions.
  • Topics, in addition to a queue per client, we might also want to allow subscription to topics, for example, I may be interested in getting notifications when the system settings have changed. That is something that is shared among all (or a lot) of clients. The Queues server should support this as well.

An interesting approach to make the Queues server even more stateless is to remove the process of acknowledgement and change it to “give me all messages after…”

Yes, I know that this is a very high level design, but there really isn’t much here that I can call very complex.

How much interest is there in Queuing system in Silverlight?


Howard van Rooijen

Could WebSockets offer an alternative mechanism for broadcast / polling?

Frans Bouma

"How much interest is there in Queuing system in Silverlight?"

Isn't the question: "what problem would this solve?", and the answers to that should be analyzed and if the best answer involves queueing, then one should look at a queueing system but IMHO it now looks like you're looking for a problem which fits a solution which was written without knowing the problem.

Ayende Rahien


Probably, that is highly dependant on the requirements that you have for ttl for messages, I think.

Frank Quednau

Just looked through Alexandria. Interesting! I am just wondering - what protocol does rhino.bus use? can it be hosted in IIS much like a WCF service?

Just questioning myself whether message request/response + batching could be put on top/into WCF...

Websync looks quite elegant, as opposed to ye old' polling. The other day, a colleague of mine explored a Comet approach based on this article: www.codeproject.com/KB/aspnet/CometGrid.aspx

First things first ;) Do we have an open implementation of Comet for the .NET stack?

Tuna Toksoz

Silverlight Polling Duplex might make things a bit easier.

Ayende Rahien

Alexandria uses Rhino Queues, which can't be hosted in IIS, but you can use MSMQ (or any other queuing tech) as well


I agree polling duplex is the right way to go here for silverlight. I do think there's a need. It would be very nice for those trying to achieve a CQRS solution in Silverlight. Could also be something that sets RSB apart from other solutions if there is an easy bridge between the two.

Robert Vukovic


in what program do you make those nice diagrams and where do you find such nice pictures of server, computer, firewall ... ?

Tom Allard

We are currently developing a Silverlight app that communicates with a webserver that is using rhino servicebus to orchestrate messaging with different services. Currently we are using httppollingduplexbinding to forward incoming messages server side over wcf to caliburn.reactive where messages are pushed to the relevant components client side.

What we think would be nice is simply to retain the rsb api client side. Unfortunately we have had no time to investigate in how to do that ourselves. Offline availability is not a requirement for us, so we don't really have a need for having persistent messages client side.


I would love to see some framework/toolkit for that!!

Now i'm thinking on using rhino bus or some other bus framework, and polling duplex services for Silverlight. Then, on silverlight side, another messaging pub/sub system (mvvmlight) for internal SL needs. Unified system would make this much easier.

Chris Chilvers

I think this solves more than just Silverlight, such as MSMQ isn't that great if the client's end point keeps changing, such as if you have a laptop out in the field connected using 3G. The client won't have a constant connection (perfect reason for using queues), but also won't have a consistent IP or DNS name.

I'd name the server side per-client holding area mailboxes, since they work similar to say POP3 email (or using Comet, IMAP with push).

The main points I saw is the mailboxes need to be cheap, as you'll probably need to create a large number of them as you'll need one per client, which might translate to one per session. From what I've seen a queue per client for MSMQ wouldn't be pretty, not sure about Rhino.Queues or ActiveMQ. RabbitMQ seems to eat memory when it has a large number of queues from what I've read.

I was thinking something as simple as serialize each message to the file system server side, perfect if the message order doesn't matter as you can use the message's guid as the file name. If the serialized format matches the wire format then it's ready to go, which can also work well with systems like AtomPub.


Spending some time reading up on WebSockets I think that could give some interesting options over PollingDuplex.

Comment preview

Comments have been closed on this topic.


  1. The worker pattern - about one day from now

There are posts all the way to May 30, 2016


  1. The design of RavenDB 4.0 (14):
    26 May 2016 - The client side
  2. RavenDB 3.5 whirl wind tour (14):
    25 May 2016 - Got anything to declare, ya smuggler?
  3. Tasks for the new comer (2):
    15 Apr 2016 - Quartz.NET with RavenDB
  4. Code through the looking glass (5):
    18 Mar 2016 - And a linear search to rule them
  5. Find the bug (8):
    29 Feb 2016 - When you can't rely on your own identity
View all series


Main feed Feed Stats
Comments feed   Comments Feed Stats