用于实时消息动态客户端列表的最佳技术

时间:2011-01-14 14:31:40

标签: .net logging tcp network-programming network-protocols

我想增强Windows服务的日志记录。目前正在对数据库进行日志记录,但我想编写可以某种方式连接到服务并实时获取日志消息的客户端。该服务应始终将日志消息输出到其端点,并且多个客户端可以根据需要连接和断开连接。当它们连接时,它们将在发送时收到消息。什么是最好的技术用于此?该服务是用.Net 4编写的。

编辑: tcp / ip多播是否适合这里的账单?我过去曾写过单播的东西,所以我不怕在那个级别上工作,但这适合这份工作吗?

4 个答案:

答案 0 :(得分:2)

编辑:添加内容到最后。

根据各种各样的事情,有很多选择。 通常,您需要某种端点API,然后在中间进行某些操作。中间可以采取各种形式,中心辐射,多播,持久队列,瞬态,保证传递,发布/订阅。等等

对于中间的位

支付:

TIBCO

MQSeries(IBM)

Microsoft MSMQ(包含在MS OS中)

使用Remoting / WCF / ASP.Net / Web服务滚动您自己(实际上非​​常容易,即使是高吞吐量)。

Apache MQ和一些其他开源框架。要列出的内容太多了。

最后,它取决于中间的内容,但是一旦你进行了通信并且正在运行它就只是将它包装起来并发布消息以供正在听取/订阅的内容消耗。

< / p>

这一切都很有趣。如果你想要一个方法。这样做:

1)定义几个C#接口,比如ISubscribe,IPublish和IMessage。

2)添加方法/事件。 ISubscribe需要一个新的消息事件和某种方式来说明订阅某种类型的消息。 IPublish需要一种发送特定类型消息的方法。 IMessage就是那条消息。

3)...

4)利润。

好的,这里的步骤3不是很清楚,但是这是你使用上面选择的参考实现的地方。尝试Microsoft MSMQ,它内置于Windows中,易于从c#访问。一旦你开始运行,你就可以考虑其他选择。

希望有所帮助。

伊恩

编辑:一些稍微充实的选项。

以下是一些选项。他们都有优点和缺点。

所以我会坚持使用IPublish,ISubscribe和IMessage。

在IPublish上我将添加一个方法:

void SendMessage(IMessage message);

在ISubscribe上,我将添加一个方法和一个事件

event EventHandler NewMessage; void订阅(字符串频道);

和IMessage将: string Channel {get;} string Body {get;}

这里的想法只是您订阅了一个频道,我们正在使用字符串作为频道名称,因为它很容易。一条消息包含消息所针对的频道和正文的字符串(再次因为它很简单,我不会在这里进行序列化,只是让消息移动)。因此,当您发送消息时,最终会有订阅您已对其发送消息的频道的任何人。

因此,考虑到这一点,让我们玩几个选项:

1)数据库。 发布将消息写入数据库。订阅者在表中查询发往他们订阅的频道的任何新行。 2)MSMQ 有几种方法可以使用MSMQ,但只是说subscribe为每个客户端创建一个通道,并且publish在每个客户端的队列中放置一条消息。然后,如果订户发送给订户,则订户决定对其采取行动。 (看看CodeProject如何真正使用MSMQ) 3)SMTP实现(是电子邮件:D) 订阅会将自身添加到Exchange组,发布会向该组中的所有用户发送电子邮件。好吧,这是一个愚蠢的例子,但你明白了。 4)连贯性。 Coherence是Oracle提供的内存数据库。它几乎支持您想要的一切。发布将新消息写入Coherence缓存,订阅者订阅缓存引发的事件。 5)承载WCF公开的Web服务的Windows服务。 Microsoft实际上提供了一个简单的聊天服务器/客户端的WCF示例。这几乎就是你想要的。

我希望其中一些有所帮助。这不是具体的,只是想法。你会注意到的是,如果你创建了上面的接口,那么这五个选项中的任何一个都可以被编码为坐在它们后面(不同的努力量)。

答案 1 :(得分:1)

您可以考虑写入Windows事件日志。有关实时事件日志监控工具的示例,请参阅this project

答案 2 :(得分:1)

我过去通常会使用Remoting来做这类事情。但是,我被告知WCF取代了Remoting,并且是新项目的推荐标准。

你应该研究一下WCF,因为它应该大大简化这个过程,这样你就不必发明一个全新的协议,而是花一整天时间搞乱它。

答案 3 :(得分:0)

好吧,我给了tcp / ip多播一个镜头,它似乎工作得很好,因为没有真正的管理要求,任何东西都可以连接到流并听取它。我对交通量有点担心。

根据Ian的回答,目前正在研究方法二。我正在使用WCF,暴露两个主要接口。第一个允许日志源将日志消息添加到系统。第二方允许第三方收听选定的日志。其他接口允许日志源注册有关自身的信息,客户端列出可用的日志等等。

一个很好的功能是我可以指定过滤器,这些过滤器由服务应用,从而减少网络流量。当日志源自身注册时,它可以指定可以过滤的字段等信息

到目前为止看起来相当不错,只需要对某些方面进行研究。