今天由于架构方案的需要,再来仔细思考连接保持方案,以及参考gmail的请求行为,总结了一下,应该是这样的:客户端一直保持一个与服务器的连接,这个连接一直保持着对服务器的请求动作,直到服务器发现有数据后给它返回后,才结束返回这一次请求。客户端在接收到请求返回后,在处理这些返回之前,又向服务器发送了一次连接请求,直到下一次有数据返回。不可避免的有一种情况,就是如果服务器长时间没有需要给客户端发送数据的话,那么可以就会造成请求失败(超时或其它原因)。对于这种情况的处理也是一样的,在错误的回调事件中重新发送一次请求连接。这样就可以模拟保持连接状态了。
用伪代码来描述一下思路吧:
客户端脚本:
1: function Request()
2: {
3: Ajax.Request(url,OnSuccessed,OnFailed);
4: }
5: function OnSuccessed(response)
6: {
7: //重新发送一次请求
8: Request();
9: //处理返回数据
10: }
11: function OnFailed()
12: {
13: //错误(超时)重新请求
14: Request();
15: }
Web服务:
1: public class IMService : IHttpHandler
2: {
3: public bool IsReusable{return false;}
4: public void ProcessRequest(HttpContext context)
5: {
6: //读取最新数据
7: while(true)
8: {
9: string message = GetMessage();
10: if(!string.IsNullOrEmpty(message))
11: {
12: context.Response.Write(message);
13: break;
14: }
15: Thread.Sleep(500);//等待一段时间再重新读取。
16: }
17: }
18: private string GetMessage()
19: {
20: //取得最新数据
21: }
22: }
这种方案的好处有:客户端可以第一时间得到服务器需要给客户端发送的数据(而至于Web服务怎么知道要给客户端发送数据,也就是服务器的轮循设计,则是另一个需要考虑的方案
相信在此之前,已经有很多人在使用这种方案了。欢迎大家就此方案发表自己的见解。
补充:服务器部分的设计,除了使用轮循外,也可以考虑使用资源互斥访问的方式来设计,这样做可以获得更佳性能,更高实时性,具体的方案应当根据实际情况来考虑。