简述用于windowsclient的一个异步http模块的实现

1.须要实现的feature

1.1 非常easy地发起异步http请求,然后回调。

1.2 可以管理http并发数。

1.3 可以支持http超时:不依赖于curl中实现的连接超时及其他超时。

1.4 请求能够取消。



2.參与者和简要分析:

Manager:接收http请求,调用curl。

Request:封装http请求。

Response:封装http回应。



线程模型:

这里实现异步通常会开线程,假定有一个UI(主)线程,可能有这些模式:

Manager在UI线程中管理若干个工作线程,curl_easy接口。

Manager在自己新起的http线程中管理若干个工作线程,curl_easy接口。

Manager在自己新起的http线程中调用curl_multi接口。



Manager在UI线程中调用curl_multi接口不合适,由于须要占用UI线程时间去select。

开多个work线程浪费资源,线程管理难度大,线程并发度的降低不会造成性能瓶颈,

由于主要耗时在网络IO上。



所以选定模型是:开一个http线程,在上面调用curl_multi接口。



解决回调问题:

这里会遇到两个问题,一个是回调的线程问题:在http中检測到IO完毕,

假设直接在http中进行回调,会使得使用者要考虑多线程使用问题,回调中可能的崩溃,

耗时操作会影响异步http模块性能。还有一个是回调对象的生命周期问题:假设回调

到对象的成员函数,在回调时有可能该对象已经析构。



考虑到这些,使用了chromium的线程模型:chromium中的base模块提供了几个抽象

层次的线程调度接口。当中一个层次是:知道对方线程的标识符,即能够向相应的线程

派发任务。



于是设计要求调用者是在某个被管理的线程上,那么在发起请求后,在Manager的SendRequest

方法中能够检測到主调线程的MessageLoopProxy,将该代理作为请求的一部分放到请求

队列中。在请求完毕后,将response和SendRequest中的callback对象绑定到一起作为

一个任务由MessageLoopProxy派发,这样就回到调用者所在线程上了。



在此同一时候,对象的生命周期问题也解决,base中有弱指针。



回调接口被设计为void XXX::CallBack(WeakPtr<XXX> ptr, scoped_refptr<Response> ptr);

在绑定到当前对象的弱引用时得到一个签名为 void (scoped_refptr<Response>) 的Runnable Object。

这个签名的对象才干够交给Manager。

在IO完毕时,再将这个Runnable Object的參数绑定到相应的Response上,就得到签名为 void (void)的

Runnable Object,同一时候也是线程池能派发的对象。



在这里引入chromium的线程池,加上了调用者的约束,解决回调问题。



3.參与者设计

Request设计:

包括一堆參数,比方url,HTTP_VERB,HTTP头操作,HTTP的BODY操作,超时设置。

为了简化使用,能够提供一个MakeGetRequest的函数,用于生成一个不须要那么多复杂设置的Request。



Reponse设计:

包括自定义的错误码,curl的http错误码,http状态码,response body buffer,

response header,原来的url,甚至一个void* user的不透明指针。



Manager设计:

作为单件存在,拥有初始化和反初始化接口。这样,Manager得和所在模块的生命周期

绑定在一起,在合适的地方初始化和反初始化。



在初始化时内部创建http工作线程,整个模块处于就绪状态。



请求队列是少不了的,在訪问时注意相互排斥。

为每一个请求分配一个handle,交给调用者。

维护一个当前工作队列,即:加到CURLM中的全部请求。



能够预见http就是不断循环地处理一些事件。



怎样及时响应加入的请求。

怎样及时退出。

怎样处理超时。

怎样避免轮询。



假设每次循环都须要主动检測请求队列,可能比較低效。由于一方面肯定要从

curl的select中退出,然后去检測请求队列,而检測时可能发现没有请求。另外一方面

訪问队列得加锁。



一般而言,这个问题的解决方式是用个Event。

假设这里用Event,那么退出,删除操作是不是也得有个Event。另外Event的自己主动切换状态

或手动切换状态会不会切出问题。Event的信息量是1,处理多个请求足够吗。

事实上Event的信息量处理多个请求是够的,仅仅要加入请求就触发一次事件能保证work的。



然而在这里不使用Event解决问题,使用windows消息,为加入,删除,结束分别定义消息。

用一个状态变量记录上次处理请求队列时是否有未处理的请求,否则须要加锁地读请求队列状态。

当状态变量为true时,请求队列一定非空。当状态变量为false时,请求队列可能是空,也能够有

请求,这说明在上一次读请求队列后请求队列中又加了请求,会通过消息来唤起当前线程。



先来看IO循环,在这些条件下应该退出IO循环:

1.still running的handle数为0,不须要进入IO循环。

2.still running的handle数目发生变化时应该退出IO循环,这样,外部就有可能处理IO完毕。

3.still running数没有达到最大,且有未处理请求时。

4.有消息时应该退出IO循环,这个不用说。



这里select是在socket上等待,而其他4个退出条件须要轮询,所以在实现上有点违背curl_multi

的设计初衷。假设每次都额外select一个socket,在发线程消息时,往这个socket发点数据,

就能够将对线程消息的检測放到select中来。前三个退出条件和当前的still running的handle数

相关,能够在select前检測一次。select退出前still running的handle数不会发生变化,所以

能够放心select同一时候保持敏感。只是这里没有再创建socket了,还是用轮询吧。



在IO循环外是http线程的主循环,主循环可能干这些事:

A.处理IO完毕。

B.处理消息。

C.在没有任务时放弃自己的线程运行,通过GetMessage进入休眠。

D.请求队列非空,且当前运行的handle没有达到最大时,须要处理请求队列。

E.设置TIMER(须要建立一个消息窗体),用于检測超时。消息时间是最先可能造时的请求超时的时间。



这些事怎样安排?

最開始两个是事件派发类:B和C是同一类逻辑,一量地B或C须要处理,即使进入了IO循环也会

立即退出。

接着是D,检測一下能否进入GetMessage的调用状态,假设能,则一直等待有消息,又一次进入BC的逻辑。

然后是A,表示没有外部的事要处理,专心做IO吧。

而E,在不论什么可能影响超时时间的后面都加一个。


for (;;)
{
	if (m_UnHandleRequest > 0 && m_RunningRequest < MAX_RUNNING_REQUEST)
	{
		HandleQueueingRequest();
		ModifyTimer();
	}
	while (::PeekMessage())
	{
		ProcessMessage();
		if (m_QuitFlag)
		{
			ClearResource();
			break;
		}
	}
	if (m_QuitFlag)
	{
		break;
	}
	ModifyTimer();
	
	if (!HaveRequestAndIO())
	{
		GetMessage();
		ProcessMessage();
		if (m_QuitFlag)
		{
			ClearResource();
			break;
		}
	}
	if (m_QuitFlag)
	{
		break;
	}
	ModifyTimer();
	
	IOLoop();
	IOComplete();
	ModifyTimer();
}

void ProcessMessage()
{
	case 退出:m_QuitFlag = 1; break;
	case 取消Request:HandleCanceledRequest(); break;
	case 加入Request:HandleQueueingRequest();break;
}

void HandleCanceledRequest()
{
	在请求队列中,直接remove掉。
	在running中,相应的remove操作。
	// bad case,在处理请求时,完毕的task已经进入调用者线程的task队列
}

void HandleQueueingRequest()
{
	将请求队列中的请求放到Running队列中。
	调用curl相应接口開始处理相应的请求。
	更新m_UnHandleRequest。
}

void ModifyTimer()
{
	计算近期超时,假设存在则更新timer。
}

void IOLoop()
{
	int m_OldRunningRequest = m_RunningRequest;
	while (m_RunningRequest)
	{
		if (m_UnHandleRequest > 0 && m_RunningRequest < MAX_RUNNING_REQUEST)
		{
			break;
		}
		if (PeekMessage())
		{
			break;
		}
		if (m_OldRunningRequest != m_RunningRequest)
		{
			break;
		}
		
		curl_multi_timeout();
		改动超时时间,假设超时时间超过100毫秒。
		
		假设超时时间是0,须要curl_multi_perform一次。
		curl_multi_fdset();
		select();
	}
}