MassTransit: How to acheive 'Competing Consumers'

How can multiple services subscribe to the same message but only have it delivered once? I am thinking of redundancy and load balancing scenarios where I have multiple clients processing messages.

I think that you are referring to a competing consumer pattern. Assuming this is correct this is how I would go about solving it in MT.

In masstransit, we have the concept of a control bus as being different from the 'data bus'. You can see this in the XML below

    <facility id="masstransit">
      <bus id="server"
              endpoint="msmq://localhost/mt_server">
        <subscriptionCache name="subscriptioncache.shared"/>
        <managementService heartbeatInterval="3" />
      </bus>
      <bus id="control"
              endpoint="msmq://localhost/mt_server_control">
          <subscriptionCache name="subscriptioncache.shared"/>
          <subscriptionService endpoint="msmq://localhost/mt_pubsub">
            <localEndpoint>msmq://localhost/mt_server</localEndpoint>
          </subscriptionService>
      </bus>
      <transports>
        <transport>MassTransit.ServiceBus.MSMQ.MsmqEndpoint, MassTransit.ServiceBus.MSMQ</transport>
      </transports>
    </facility>

Here you can see a snippet of the windsor masstransit facility where one 'autonomous component' is listening for data at 'msmq://localhost/mt_server' and is listening for control messages (things like subscription updates) at 'msmq://localhost/mt_server_control'. This setup will allow multiple consumers to happily exist. :) Each one listening for application messages at 'msmq://localhost/mt_server' and receiving at there own control endpoint 'msmq://localhost/mt_server1_control', 'msmq://localhost/mt_server2_control', etc.

I would also recommend that from an application development standpoint that your software be able to handle any given message more than once. As we move into a more distributed environment, the statement 'You will get this message at least once' becomes a helpful mantra, as it helps to avoid the pitfalls of the network.

Hope that helps