1

I want to send information from one .Net application to multiple other .Net applications. I want the applications to be loosely coupled. The number of applications receiving the information could change at run time. What is the simplest way to do this?

I thought about using MSMQ, but from what I can tell, there the broadcasting application has to know how many receivers there are or each message only gets processed by one of the receiving applications. Neither options is acceptable.

  • 3
    Sounds like a case for WCF or a self-hosted web server. However, you should be more specific. Here are some points to start with: How often will there be updates/messages? How many listeners are there? How large is the amount of data transferred? Is this on the same machine, or distributed? How far distributed? Will there be firewalls? – Marcel Oct 29 '14 at 13:27
  • 1
    I imagine there will be a message 1 every 5 minutes. There could be up to five listeners. It will be a fairly small amount of data, under 1K. Initially, all of the listeners will be on the same machine, but if possible, I'd like to have it open to multiple machines later. – epotter Oct 29 '14 at 13:32
5

One solution would be to publish the information via UDP. Open a specific port for broadcasting, send your data. There is nothing else to do on the provider/server side.

On the client side, open the same port for receiving.

The only downside that I am aware of with this method is that if you miss the broadcast message, you will never see it again. There is no guaranteed delivery.

One upside is that you can have unlimited clients with no additional overhead for the server.

Microsoft has a working example using the UDPClient class.

If you need guaranteed delivery, you can use (among other options) the TCPListener class for your server. You will have to use the TCPClient class for the client. This technique will (more or less) recreate a web server and clients. Writing a RESTful interface would be easier.

One downside is that every client opens a connection (more overhead) to your server.

  • Using UDP seems like the right solution. However, it my test, I could only receive the UDP message with one client. Whichever client received the message first would be the only one to get it. Am I missing something? – epotter Oct 29 '14 at 16:42
  • If the applications are all on the same machine, it is possible you can only get one message. For multiple machines it shouldn't be an issue. – Adam Zuckerman Oct 29 '14 at 17:04
  • 3
    Upon further research, it can work with multiple receivers on the same machine if you join a multicast group. Here is an example: jarloo.com/c-udp-multicasting-tutorial – epotter Oct 29 '14 at 17:18
  • I was not aware of using the multicast setting. Interesting.... – Adam Zuckerman Oct 29 '14 at 18:38
6

You might be best served by letting the apps pull the information rather than pushing it out -- that is a much simpler model as all you need to do is expose an API. The default choice in 2014 is probably an RESTful ASP.NET web api but there are tons of options depending on what you are doing.

As for the push model, MSMQ is a pretty raw tool but it is usable. You might want to look at something like rabbit MQ which is a bit more feature-complete and has a pretty handy pub/sub model.

The bottom line is that there are lots of ways to solve this problem -- the best way really depends in specific requirements here.

  • 1
    A RESTful API seems to be a good choice: see asp.net/web-api to get started. Don't be scared; Exposing data, small or big, is very simple, once you get the basics. – Marcel Oct 29 '14 at 13:50
4

SignalR might be a good candidate if you don't need guaranteed delivery, and you're simply looking to periodically send relatively small amounts of data to/from N* clients and servers (e.g. real-time dashboard, instant messaging, multiplayer game, etc...). It can also scale quite well using backplanes (currently supports Redis, Azure Service Bus, SQL Server, or writing your own).

While SignalR is focused towards ASP.NET development (it abstracts the implementation of WebSockets), you can also use it in non-web applications (i.e. WinForms, WPF, Windows services, etc...).

Plus, SignalR operates over standard HTTP/S ports (80, 443), so you typically don't need to create firewall exceptions to get things talking correctly.

Another bonus is that you can have two way communication between clients and/or server(s).

Here's a few links you might find useful:

1

I've been using Rebus which makes it pretty simple to push messages between applications. It is a .NET library that sits as a layer on top of an underlying transport layer, which could be MSMQ, RabbitMq, or something else.

It does support publish/subscribe. In the case of MSMQ, this is simply implemented that Rebus handles publishing the message to multiple queues. Rebus just needs somewhere it can store a configuration about which subscribes have subscribes to which types of messages.

If you want to step up, you can use NServiceBus, which is a paid product. But I have no experience with that. But it should be easy to migrate an app from Rebus to NServiceBus.

0

Whether it's applicable to your specific scenario is a different question entirely, but writing to a text file and reading it from the other applications is probably the 'simplest' way to transfer data.

  • 4
    Simple until you get into details like file locking . . . – Wyatt Barnett Oct 29 '14 at 13:36
  • That entirely depends on your setup, hence why I said it may not be suitable. There are several ways to deal with locking though - one-writer, multiple-reader access for example – Jon Story Oct 29 '14 at 13:41
-2

For windows .net processes to pipe data between themselves they can do so in different ways using WCF using transport layers such as http or named pipes.

Good tutorial for this: http://tech.pro/tutorial/855/wcf-tutorial-basic-interprocess-communication

Another question you may find helpful: https://stackoverflow.com/questions/7353670/wcf-named-pipe-minimal-example

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.