Using Rhino ESB to publish events to many clients

[Nathan Palmer]

I'm not sure if I'm going the right direction here so I thought I'd
see what other people thought. I have a server that is running jobs at
different intervals. I would like to allow clients to connect to the
server and receive events back when jobs are triggered. There will be
an unknown # of clients and could be multiple clients started under
the same machine / same user. I initially set this up with Rhino ESB
using MSMQ and it works with 1 client. If it start up a second client
then it seems the messages start to distribute between the two
clients. The message will go to either one or the other but not both.
Which probably makes sense on how I have it configured. So then I have
a couple of questions.

Is there an example configuration somewhere that has 1 server -> X
clients where ALL messages from the server get to ALL clients?
(bus.Notify())

Secondly.. does each client require it's own queue? If so.. How do I
handle a situation where multiple clients are connecting from the same
machine (in the scenario of many users connected to one terminal
server.)? If each client is using the same queue name then I believe
this would be a conflict.

Then of course I may also be thinking of the wrong technology here and
could possibly switch to something more like WCF.

Thanks,

Nathan Palmer

[Ayende Rahien]

bus.Publish / bus.Notify are what you are looking for.

Yes, it requires each client to have its own queue.

On the same machine you can create a queue per instance.

A better approach might be to use a different transport, like Rhino Queues, which doesn't require installation.

--
You received this message because you are subscribed to the Google Groups "Rhino Tools Dev" group.
To post to this group, send email to rhino-t...@googlegroups.com.
To unsubscribe from this group, send email to rhino-tools-d...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/rhino-tools-dev?hl=en.

[Corey Kaylor]

With multiple clients started at the same time under the same machine when using rhino queues you would need the ports to be a bit more dynamic than they are currently. Also, depending on the estimated number of clients you may want to manage your subscriptions carefully. In other words, if there are over 1000 and at any given time 500 are not running, this could create a bottleneck on the publishers sending queue. If a client goes offline, is it important to receive prior notifications? 

[Nathan Palmer]

It's not important to receive prior notifications. In fact it would be
confusing to the end user to receive those notifications. That is one
reason why I had wondered if an ESB is the right technology here.

I currently have it working using Rhino Queues with a random queue
name and a randomly available port within a range. But with this i
need to put in some code to cleanup the esent directories for the
clients and manage the subscriptions.

Nathan Palmer

[Ayende Rahien]

Nathan,

If that is the case, you might want to consider using an unreliable technology instead.

UDP, for example.

[Nathan Palmer]

Agreed. UDP would be fine in my scenario. In fact since I do not need
durable storage some type of queue that was all in memory would work
just fine too. That is why I had questioned whether or not I'm using
the right technology. Since it was so easy to setup the queue and the
communication with Rhino ESB I haven't looked for something else.

Nathan

[jgilkey]

Jist my $0.02 but a WCF peer channel might work.

On Jun 16, 8:17 pm, Nathan Palmer <snowpal...@gmail.com> wrote:
> Agreed. UDP would be fine in my scenario. In fact since I do not need
> durable storage some type of queue that was all in memory would work
> just fine too. That is why I had questioned whether or not I'm using
> the right technology. Since it was so easy to setup the queue and the
> communication with Rhino ESB I haven't looked for something else.
>
> Nathan
>
>
>
> On Wed, Jun 16, 2010 at 12:16 AM, Ayende Rahien <aye...@ayende.com> wrote:
> > Nathan,
> > If that is the case, you might want to consider using an unreliable
> > technology instead.
> > UDP, for example.
>

> >http://groups.google.com/group/rhino-tools-dev?hl=en.- Hide quoted text -
>
> - Show quoted text -

[Nathan Palmer]

I had considered this approach but I wasn't quite sure where to start.
If you have some links I could look through I'll weight it against my
current solution.

Nathan