CAsyncSocket ,CSocket多线程环境

CAsyncSocket ,CSocket多线程环境
我接触Windows网络编程有一段时间了,对Windows网络编程,Windows网络编程模型和Linux网络编程模型有一个很不一样的地方,这就是异步选择模型。异步选择模型和普通的选择模型有着本质的区别,这个模型利用了Windows的窗口消息机制 。
在Linux网络编程里,最常用的是select模型,调用select函数后,线程进入阻塞状态,直到超时或socket的相关操作有可用性,比如可以网络对端发来数据,这时系统内核会告知现在SOCKET现在可读,此时select函数返回,线程继续执行。
WINDOWS网络里也提供这样的select调用,但是为了更好的利用WINDOWS消息机制,WINDOWS在传统Beckly socket的基础上进行了高度扩展,称为WINSOCK。WINSOCK里提供了异步选择机制,它的原理是将一个网络通知事件作为消息传递到一个接收窗口,利用WINDOWS的消息处理机制,将网络事件转给一个窗口过程来处理,程序员通过写这个窗口过程(实际上是个大的SWITCH-CASE语句)来实现对网络事件的处理。
MFC类是对WINDOWS API的封装,当然也少不了对WINSOCK API 的封装。
MFC对WINSOCK API的第一层封装类是 CAsyncSocket,他不仅封状了API,而且还让程序员省去了建立窗口、注册窗口消息和写窗口过程的麻烦,提供了回调接口,程序员只需要重写感兴趣的虚函数,就可以实现异步调用,这听起来似乎很方便,但是MSDN却说:使用CAysncSocket需要自己管理阻塞,自己处理网络字节顺序等。因为我们执行CAysncSocket的每一次异步调用,都不能保证程序已按照我们的意愿正确执行了。比如你调用Send来发送网络数据,你得到的返回值是WSAEWOULDBLOCK,表示你的操作是异步的,不能立刻返回,告诉你不用担心,但是以后是不是真正执行了,你是不知道的。要管理这样的过程,就需要你在每次调用后再进行检查(具体方法不详)。
CSocket是由CAysncSocket派生而来的,MSDN说CSocke提供的是同步阻塞模式的操作,我觉得严格意义上讲,从源代码上看,也是异步选择模式,不过他重写了操作函数,使得每次调用基类的异步操作后,都进行了阻塞管理,实际上自己就变得阻塞了。
提到网络编程,就不得不提在实际项目中,如何与多线程进行配合。对于在多线程中直接操作API,方法比较多,具体的做法要看项目需求。这里我针对CSocket在多线程环境中可能出现的问题进行分析和讨论。
由于CSocket的网络调用是阻塞的,在复杂的网络环境中,一个网络操作函数返回的时间可能让用户无法接受,大家都能想到,需要用多线程来处理,你的想法很好,可是尝试过后,才知道不易啊。多线程中使用CSocket的主要现象是,你在一个线程里调用了CSocket的成员函数,之后启动一个线程,在另一线程中对CSocket对象调用成员函数会失败!通过DEBUG,可以发现一般是在下面这句发送诊断错误:
    _AFX_SOCK_THREAD_STATE* pState = _afxSockThreadState;
    ASSERT(pState->m_hSocketWindow != NULL);
_AFX_SOCK_THREAD_STATE我们不用太深入的了解它,先从感性上认识,这应该是个和线程状态相关的一个类。诊断时发生错误说明和SOCKET相关的窗口不存在。
MSDN里这样有这样的一句:CSocket /CAsyncSocket is not thread-safety ,为什么不是线程安全的呢?我主要考虑到的是消息循环是和窗口相关的,而这个窗口又是线程相关的。我的理解很肤浅,要深入理解的话,应该要看看MFC线程、模块切换的原理。
今天先写到这里。
 

你可能感兴趣的:(职场,休闲,CAsyncSocket,CSocket多线程环境)