Multiple instances of the same subscriber on different machines

Question

I am trying to implement the publisher subscriber pattern using Nservice bus , what i am trying to do is as follow :

I have web application , user can write news and add documents to that Application using his account .

I have a Windows forms desktop application that running on users machines , they can login this desktop app using the same credentials they are using to access the web application.

what i need to to is when users on web applications add news or documnets , the installed desktop app should receive notifications to informing it about this added news .....

i imagin that my desktop application will be the subscriber that will subscribe on events that will be published from the server what i need to know is

when multiple users for example 1000 user , install this desktop app on different machines to start using it , in this case Nservice bus will consider them as multiple subscribers and will send a copy of message to each one of them or what ???

Answer 1

As described in the documentation , it works like this:

• If you use Send(ICommand command) , you get message sent directly to the matching target. In this case, if you have multiple consumers, they will compete to get this message and only one gets it. This is usually used to scale applications.
• If you do Publish(IEvent @event) , your message will get delivered to all subscribers.

Answer 2

When Pub/Sub happens in NServiceBus, there is one logical publisher that sends an event to multiple logical subscribers. Each logical subscriber will only receive one copy of each event that is published.

If many subscribers represent the same logical entity then each event will be processed by only one of the subscribers within that logical entity. Two subscribers are considered to represent the same logical entity if they share an Endpoint Name .

In this case, if every instance of the desktop application have the same endpoint name then they are considered to represent the same logical entity. When an event is published, then only one of those desktop application instances will get a copy of the event. That is probably not what you want.

If you give each instance of the desktop application a different endpoint name then they each represent their own logical entity. When an event is published, all of the desktop instances will get a copy of the event. That is also probably not what you want.

Another thing to consider is pub/sub in NSB is persistent and reliable. If you start a desktop application and it sets up a subscription, that subscription is in effect even if the desktop application is offline. Messages may be queued up waiting for the Desktop Application to come back online to be processed, even if you never run the desktop application again. Does your desktop application need these or do you only care about events that occur while you are connected?

If you want to notify a specific subscriber or subset of subscribers that are online when an event occurs on the server then I would use SignalR before using NSB.

Additional Info

---

MSMQ and SQL Server do not support pub-sub out of the box and so they use a feature called message driven-subscription. Message driven subscriptions work by having the subscriber send a message to the publisher when it starts up (or calls Subscribe() ). This message contains a Reply To header which the publisher stores and uses to send copies of each message that is published.

For SQL Server transport, the Reply To address will be the name of the Endpoint. This in turn is mapped to a table in the database that represents the queue of messages. If multiple subscribers share the same Endpoint name (and hence the same table) then they will get one copy of the event between them and will be competing to see which subscriber pulls it from the queue.

For MSMQ, the Reply To address will be the name of the Endpoint and the name of the machine separated by an @ symbol. This means that each subscription will be for a different address. When the event is published, each subscriber will get it's own copy of it. If multiple subscribers represent the same logical entity (ie share an Endpoint name), then you should have a distributor in front of them . When you do this then the Reply To header on outgoing subscribe messages will be the address of the Distributor. When an event is published, it will always go to the Distributor which will hand it off to one (and only one) of it's workers for processing.

Rabbit MQ and Azure Service Bus have built-in mechanisms for pub/sub but they will behave in a manner similar to SQL Transport. One instance of the logical subscriber will get a copy of the event.