.Net Remoting实现定向广播(2)

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

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

　　远程对象：

　　客户端程序：

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

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

　　远程对象：

　　事件重现器：

　　客户端：

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

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

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