Best technology to use for realtime messaging dynamic list of clients

I want to enhance the logging on a windows service. Logging is currently done to a database, but I'd like to write clients that can in some way connect to the service and get log messages in real time. The service should always output the log messages to its endpoint, and multiple clients can connect and disconnect from that as they wish. When they are connected they will receive the messages as they are sent. What's the best technology to use for this? The service is written in .Net 4.

EDIT: Would tcp/ip multicasting 开发者_如何学JAVAfit the bill here? I've written unicast stuff in the past, so I'm not afraid to work at that level, but is it appropriate for the job?

---

Edit: Added stuff to the end.

There are so many options depending on all sorts of things. Generally you need some sort of end point API, then something to go in the middle. The middle can take all sorts of forms, hub-spoke, multicast, persistent queue, transient, guarenteed delivery, Publish/Subscribe. etc.

For the bit in the middle

Paid for:

Tibco

MQSeries (IBM)

Microsoft MSMQ (included with MS OS's)

Free

Roll your own (actually quite easy even for high throughput) using Remoting/WCF/ASP.Net/Web Service.

Apache MQ and a handful of other open source frameworks. Too many to list.

For the end point, it rather depends on what's in the middle, but once you've got communications up and running it's just a case of wrapping it up and publishing messages to be consumed by what ever is listening/subscribing.

It's all rather fun. If you want an approach. Do this:

1) Define a couple of C# interfaces, say ISubscribe, IPublish and IMessage.

2) Add methods/Events. ISubscribe needs a new message event and some way to say subscribe to a certain type of message. IPublish needs a way to send a certain type of message. IMessage is that message.

3) ...

4) profit.

Ok, step 3 isn't very clear here, but this is where you do a reference implementation using what ever of the above you select. Try Microsoft MSMQ, it's built into Windows and easy to access from c#. Once you have that running you can think about alternatives.

Hope that helps.

Ian

Edit: A few slightly fleshed out options.

Here are a few options. They all have strengths and weaknesses.

So I'll stick with IPublish, ISubscribe and IMessage.

On IPublish I'll add one method:

void SendMessage(IMessage message);

On ISubscribe I'll add one method and one event

event EventHandler NewMessage; void Subscribe(string channel);

and IMessage will have: string Channel {get;} string Body {get;}

The idea here is simply that you subscribe to a channel, and we're using a string for the channel name because it's easy. A message contains the channel the message is for and a string for the body (again because it's easy, I'm not getting into serialising stuff here, lets just get messages moving). So when you sendmessage it is suppose to end up with anyone subscribing to the channel to which you've addressed the message.

So with that in mind, let's play with a few options:

1) a database. Publish writes the message to a database. Subscribers poll the table for any new rows addressed to the channel to which they are subscribed. 2) MSMQ There are a few ways to use MSMQ, but lets just say subscribe creates a channel for each client, and publish puts a message in each of the client's queues. The subscriber then decides to act on it if it's addressed to it. (Take a look on CodeProject for how to really use MSMQ) 3) an SMTP implementation (yes email :D) Subscribe adds itself to an Exchange group, publish sends an email to all users in the group. Ok, this is a bit of a silly example, but you get the idea. 4) Coherence. Coherence is an in memory database available from Oracle. It supports pretty much everything you want. Publish writes a new message to the Coherence cache, subscribers subscribe to events raised by the cache. 5) A windows Service which hosts a web service exposed by WCF. Microsoft actually provide a WCF sample which does a simple chat server/client. That's almost what you want.

I hope some of that helped. It's not concrete, just ideas. What you will notice though, is if you create the interfaces above, any of those five options could be coded to sit behind them (with varying amounts of effort).

---

You might consider writing to the Windows Event Log. See this project for an example of a real-time event log monitoring tool.

---

I've typically used Remoting for this kind of thing in the past. However, I'm told that WCF has replaced Remoting, and is the recommended standard for new projects.

You should look into WCF, as it should simplify this process greatly, so that you don't have to invent a whole new protocol and spend all day messing with that.

---

Okay, I gave tcp/ip multicasting a shot, and it seemed to work quite well, as in no real management required, anything could connect to a stream and listen to it. I was a bit concerned about the volume of traffic though.

Currently working on approach two, based on Ian's answer. I'm using WCF, exposing two primary interfaces. The first of these allows a log source to add log messages to the system. The second allows a third party to listen to a selected log. Additional interfaces allow log sources to register information about themselves, clients to list what logs are available, etc.

One nice feature is that I can specify filters and these filters are applied by the service, reducing the network traffic. When a log source registers itself it can specify information on fields it can be filtered on, etc

It's looking pretty good so far, just need to work on polishing some aspects.