用 .Net Remoting 技术实现“定向广播”

声明:由于本人刚刚接触 .Net Remoting 技术,对该技术的理解尚浅,文中难免有不准确甚至错误之处,欢迎大家指正。

相对于 WebService 来说,采用 .Net Remoting 技术的客户端能够订阅服务器端事件,这个功能简直太棒了。

如果想利用该技术作一个简单而又典型的应用,信息广播程序是一个不错的选择。以下代码是一个简单的广播程序,当然,它实在太简陋了。

服务端:
Code

客户端:
Code


远程对象、委托及事件重现器(需同时部署在服务端及客户端):
Code

OK,我的信息广播程序就这样完成了。

但是,我很快就发现了问题:如果我的确想让所有订阅我的广播事件的客户端都得到我要广播的信息,这个实现应该不会有问题。但是现在我有一个消息只想通知 Mike 或 John (正如以上代码),(注:可能这时不能再称为“广播”了),我的广播程序依然将这个消息通知到了每一个客户端。

可以想到的一个方法是,让事件重现器(SayEventReappear)接收到信息后先判断一下是不是发给自己的,只有发给自己的信息才激发本地事件(代码比较容易实现,不再贴出源码)。但是,这种处理只是在客户端将信息忽略而己,服务器端是照常广播了,如果你的信息非常机密,或者带宽非常有限,这显然不是好的解决办法。

考虑到 .Net Remoting 客户端订阅事件的实现原理:事件重现器在客户端实例化,并由服务器对按引用方式对其远程调用(个人理解,未经确认,欢迎指正)。如果将事件重现器订阅服务器端事件改为向服务器端“注册”事件重现器,逻辑上应该可行,这样就可以让每个客户端注册的事件重现器携带自己的客户标识,让服务端根据标识决定是否引发特定客户端的事件。修改后的代码如下:
远程对象:
Code

客户端程序:
sh.OnSay += new SayHandler(re.Say);
改为
sh.AddEventReappear(re);

OK,服务端分别检测每一个客户端的Id,然后只引发特定客户端的事件,真正的“定向广播”实现了。

但是检查一下以上代码,会发现依然存在问题:由于事件重现器的实例存在于客户端,服务端访问的是它的代理类,因此每次对 ClientId 的检查都是一次远程调用,这无疑是一种浪费。因此将程序改为在客户端注册事件重现器时提交 ClientId 或许更合理。修改后的代码如下:
远程对象:
Code
事件重现器:
Code
客户端:
sh.AddEventReappear(re);
改为:
sh.AddEventReappear("John", re);

如此一来,不仅避免了对客户端的频繁调用,而且代码也更加简洁了。

当然,同利用“事件订阅”方式实现时当订阅事件的客户端退出时应该取消订阅一样,该实现中的客户端在退出时同样应该取消在服务端的“注册”。由于只是示例程序,以上代码中并没有进行取消注册处理。

但是问题恰恰出在这儿了,如果有的客户端没有自觉的取消注册或者意外退出/断线了,服务器端该如何处理呢?当然使用事件订阅时这个问题同样存在,但我估计 .Net Remoting 会根据生命周期原则适时“清除”已订阅事件而不再响应的客户端(同样是个人猜测,没有证实)。如果服务器端将连接失败的客户端直接取消注册,显然是对客户端的一种不负责任(如果客户端因临时资源紧张或临时断线无法及时响应时将被永久取消注册),但除此之外我没有想出合适的办法进行处理,总不能让已经不存在的客户端一直处于注册状态吧?!当然还有一种折中的办法是对客户端连接失败进行计数或计时,达到一定程度后认为客户已经不存在而进行注销。

欢迎您提出宝贵建议或解决办法。
posted @ 2007-11-15 17:12  同一片海  阅读(3428)  评论(13编辑  收藏  举报