muduo源码分析--连接的断开
2014-03-31 17:02
288 查看
在Tcp中断开连接比创建连接更加困难
真正执行断开连接的时候是从在channel中的handleEvent函数,在Channel中并没有handleRead、handleWrite、handleClose函数出里的实现,都是借助注册的回调来进行的。
在某一个channel上有事件到达时,执行相应的操作,更具事件类型执行相应的操作这个步骤是在handleEvent函数中进行的。在channel中有closecallback_的回调,这个函数是在什么时候被初始化的呢?肯定是它的拥有者在创建的时候赋值的。这么一来,就是在新建TcpConnection的时候,channel中的closeCallback是TcpConnection初始化的,在初始化TcpConnection的时候将TcpConnection中的handleClose赋值个Channel宏的closeCallback。那么在TcpConnection中的handleClose都是什么工作呢?
handleClose的在TcpConnection::handleRead()函数中如果read为0的时候也被调用,同时也被注册到Channel的closecallback.
在handleClose函数中,首先保证执行这个函数实在IO线程。然后调用用户的connectionCallback_,为什么要调用用户的connectionCallback_呢?因为读取数据已经发现是0了,那么就需要通知用户,看用户怎么调用。最用调用它的成员函数closeCallback_。
所以到目前为止出现了两个closeCallback,Channel中是给TcpConnection使使用的,TcpConnection中的是个TcpServer使用的,用于通知他们移除所持有的TcpConnectionPtr.不是给普通用户用的,普通用户继续使用ConnectionCallback.
接下来看看,TcpServer给TcpConnection注册的是什么closeCallback_
注册的是removeConnection函数
这个函数保证是在主IO线程中执行removeConnectionInLoop函数。后者又执行了connectDestory函数.
TcpConnection::handleClose()的主要功能是调用closeCallback_,这个回调绑定到TcpServer::removeConnection()函数。
TcpServer中的removeConnection函数被非为了两个部分,因为TcpConnection会在自己的ioLoop线程调用removeConnection(原因是新建TcpConnection的时候将他分为某一个ioLoop),为了避免这样情况发生,所以需要把它移到TcpServer的loop_线程。但是为了保证TcpConnection的ConnectionCallback始终在其ioLoop回调,在removeInLoop函数中需要将connectDestoryed放发哦ioLoop中执行!!!
真正执行断开连接的时候是从在channel中的handleEvent函数,在Channel中并没有handleRead、handleWrite、handleClose函数出里的实现,都是借助注册的回调来进行的。
在某一个channel上有事件到达时,执行相应的操作,更具事件类型执行相应的操作这个步骤是在handleEvent函数中进行的。在channel中有closecallback_的回调,这个函数是在什么时候被初始化的呢?肯定是它的拥有者在创建的时候赋值的。这么一来,就是在新建TcpConnection的时候,channel中的closeCallback是TcpConnection初始化的,在初始化TcpConnection的时候将TcpConnection中的handleClose赋值个Channel宏的closeCallback。那么在TcpConnection中的handleClose都是什么工作呢?
handleClose的在TcpConnection::handleRead()函数中如果read为0的时候也被调用,同时也被注册到Channel的closecallback.
在handleClose函数中,首先保证执行这个函数实在IO线程。然后调用用户的connectionCallback_,为什么要调用用户的connectionCallback_呢?因为读取数据已经发现是0了,那么就需要通知用户,看用户怎么调用。最用调用它的成员函数closeCallback_。
所以到目前为止出现了两个closeCallback,Channel中是给TcpConnection使使用的,TcpConnection中的是个TcpServer使用的,用于通知他们移除所持有的TcpConnectionPtr.不是给普通用户用的,普通用户继续使用ConnectionCallback.
接下来看看,TcpServer给TcpConnection注册的是什么closeCallback_
注册的是removeConnection函数
这个函数保证是在主IO线程中执行removeConnectionInLoop函数。后者又执行了connectDestory函数.
TcpConnection::handleClose()的主要功能是调用closeCallback_,这个回调绑定到TcpServer::removeConnection()函数。
TcpServer中的removeConnection函数被非为了两个部分,因为TcpConnection会在自己的ioLoop线程调用removeConnection(原因是新建TcpConnection的时候将他分为某一个ioLoop),为了避免这样情况发生,所以需要把它移到TcpServer的loop_线程。但是为了保证TcpConnection的ConnectionCallback始终在其ioLoop回调,在removeInLoop函数中需要将connectDestoryed放发哦ioLoop中执行!!!
相关文章推荐
- muduo-源码分析2:注册监听socket和建立连接
- muduo源码分析之实现TCP网络库(连接的接收和关闭)
- C# 连接自动拨号与断开分析
- libstreaming 源码分析一之RTSP连接
- 基于TCP网络通信的自动升级程序源码分析-客户端连接服务器
- Android-vold源码分析之连接电脑OTG(11)
- muduo源码分析之使用封装的Buffer读取数据
- 针对TCP连接异常断开的分析
- TCP连接三次握手和四次断开分析
- 高并发服务器架构笔记(3)——muduo_base 源码分析
- 利用asio实现了一个服务器,多个客户端连接,并异常断开连接,发现后面再也连接不上服务器了,不能建立新连接了。原因分析
- Mina源码分析博客连接汇总
- [置顶] Mybatis技术(四) 从配置读取到打开连接的源码分析
- 【OVS2.5.0源码分析】openflow连接实现分析(3)
- srs 服务器在客户端断开连接后,服务器代码跟踪分析
- Lighttpd1.4.20源码分析 笔记 状态机之错误处理和连接关闭
- muduo源码分析:异常类封装
- srs 推流者、观看者在连接、断开的代码跟踪分析
- smack 源码分析一(android上实现长连接)
- rt-thread通过TCP连接(网络+shell)方式调用list_if()导致网络断开的问题分析