WCF后续之旅(9):通过WCF的双向通信实现Session管理[上篇]
我们都知道,WCF支持Duplex的消息交换模式,它允许在service的执行过程中实现对client的回调。WCF这种双向通信的方式是我们可以以Event Broker或者订阅/发布的方式来定义和调用WCF Service。今天我们就给大家一个具体的例子:通过WCF的duplex communication方式现在Session管理。
一、Session 管理提供的具体功能
我们的例子实现了下面一些Session Management相关的功能:
- Start/End Session:可以调用service开始一个新的Session或者结束掉一个现有的Session。当开始一个Session的时候,service根据client端传入的client相关的信息(ClientInfo),创建一个SessionInfo对象,该对象由一个GUID类型的SessionID唯一标识,代表一个具体的Client和Service的Session。在service端,通过一个dictionary维护者一个当前所有的active session列表,key为SessionID,value是SessionInfo对象。当client调用相应的service,传入对应的SessionID,该SessionID对应的SessionInfo从该session列表中移除。
- Session Timeout:如同ASP.NET具有一个Timeout的时间一样,我们的例子也具有timeout的机制。在client可以注册timeout事件,某个session timeout,service会通过在start session中指定的callback回调相应的操作(OnTimeout)并处罚client注册的timeout事件。session timeout后,SessionInfo对象从active session列表中移除。 比如在本例中,我们通过注册事件使得timeout后,程序在显示timeout message之后,自动退出。
- Session Renew:session timeout判断的依据是client最后活动的时间(last activity time),而该事件反映的是最后一次鼠标操作的时间(假设我们的client是一个GUI应用)。所以从session的生命管理来讲,用户的每次鼠标操作实际上将session的时间延长到session timeout的时间。
- Session Listing Viewing:Administrator或者某个具有相应权限的用户,可以查看当前活动的session列表和session相关的信息,比如IP地址、主机名称、用户名、session开始的时间和最后一次活动的时间,见下图。
- Session Killing:如何发现某个用户正在做一些不该做的事情,或者发现当前的并发量太大,管理员可以强行杀掉某个正在活动的Session。同session timeout一样,client端可以注册session killed事件。当session被强行中止后,service回调client相应的方法(OnSessionKilled),触发该事件。比如在本例中,我们通过注册事件使得某个client对应的session被杀掉后,该client程序在显示message之后,自动退出。
二、Session Timeout的实现原理
在该例子中,最重要的是如何实现timeout的功能,而该功能的核心在于如何探测session的状态(Active、Timeout、Killed)。一般地我们有两种截然不同的方式来实现这样的功能:
1、客户端驱动
这是大多数人会想得到的方式,通过这样的方式实现session status的检测功能:如下图所示,client端调用相应的service开始一个session,并获得SessionID。client端每隔一定的时间调用相应的操作(CheckSessionStatus),并将自己的SessionID传入,进行session status的检测(步骤1),根据返回的状态进行相应的处理;用户的鼠标操作将会调用相应的操作(RenewSession)将session的last active time修正为service端的当前时间(不应该是client的时间)(步骤2)。然而,不可能每次鼠标操作都进行service的调用,这样会频繁的调用service调用肯定会使程序不堪重负。所以会一般会设置一个service调用的时间间隔,也就是在一定的时间端内,只有一次鼠标操作会触发service的调用。由于CheckSessionStatus和RenewSession的调用都是基于某个时间间隔的,所以实时性是怎么也解决不了的。此外,这种形如轮询方式的机制在高并发的情况下也会让service端的压力正大。
2、服务端驱动
设计服务端驱动模型是从.NET Remoting的remote instance生命周期管理机制得到的灵感。我们知道和WCF3种InstanceContext Mode(PerCall、PerSession和Single)相对应,Remoting也具有3种不同的对象激活方式(Object Activation):SingleCall、CAO(client activated object)和Singleton。SingleCall和Singleton是两个极端,不需要特殊的对象回收机制,而CAO模式下,Remoting采用了一种基于“租约”(lease)的service instance 生命周期管理机制:remote object被一个租约一个“租约”(lease:实现了System.Runtime.Remoting.Lifetime.ILease inte易做图ce)对象引用。client端通过一个Sponsor( System.Runtime.Remoting.Lifetime.ISponsor)引用lease对象. 当Lease Manager检测到某个remote object的lease超时,Remoting不会马上对其进行垃圾回收,而是找到该lease的Sponsor对象,通过Sponsor对象回调Renewal方法(Sponsor处于client端),返回一个Timespan对象,表明需要将remote object的lifetime延长的时间,如何该值小于或者等于零,则不需要延长,该对象将会被回收掉;否则将lifetime延长至相应的时间。同时,client的每次远程调用,都会自动实现对lifetime的Renew功能
我们实现与此相似的Session Management的功能,具体的流程如下图所示:
步骤一
client端调用Guid StartSession(SessionClientInfo clientInfo, out TimeSpan timeout)方法,其中SessionClientInfo 表述client的一些基本的信息,比如IP地址、主机名称、用户名等等。service端接收到请求后,创建一个SessionInfo对象,该对象代表一个具体基于某个client的session,并同通过一GUID形式的SessionID唯一标识。同时将此SessionClientInfo 对象加入到表示当前所有活动的Session列表中,该列表通过一个dictionary表示(IDictionary<Guid, SessionInfo> CurrentSessionList),其中key是SessionID。最后service将SessionID和session timeout的时间返回到client端。
此外,client调用StartSession,除了指定SessionClientInfo 之外,还提供了一个Callback对象,Callback用在service在相应的时机(session轮询、session timeout,kill session)实现对client的回调,下面是3个主要的callback操作:
- TimeSpan Renew():对Session生命周期的延长。
- void OnSessionKilled(SessionInfo sessionInfo):当client对应的session被杀掉之后,调用该方法实现实时通知。
- void OnSessionTimeout(SessionInfo sessionInfo):当client对应的session timeout后,调用该方法实现实时通知。
除了维护一个当前活动session的列表之外,service还维护一个Callback列表(IDictionary<Guid, ISessionCallback> CurrentCallbackList),key仍然是SessionID。当StartSession被调用后,callback被加入到CurrentCallbackList中。
步骤二
service以一定的时间间隔对session列表进行轮询(polling),根据SessionClientInfo的最后活动时间(LastActivityTime)和session timeout的时间判断是否需要renew session(DateTime.Now - sessionInfo.LastActivityTime 〉 Timeout)。考虑到对实时性的要求
补充:综合编程 , 其他综合 ,