xsocket分析三,补充说明

xsocket作为一个知名的开源框架(看代码作者好像就一个人。。),有很多地方值得借鉴。

1.内存管理

默认采用了预分配的方式,每个Dispatcher拥有一个MemoryManager对象,MemoryManager管理一大块ByteBuffer默认是16KB,在第一次请求内存时分配。有新的连接时Dispatcher将MemoryManager的引用传给IoSocketHandler,有新的读事件时,IoSocketHandler将数据读在大的ByteBuffer,然后从大的ByteBuffer里分离出读的大小,剩余的部分回收,下次继续使用,如果剩余部分小于最小大小则再分配一个16KB。这里ByteBuffer是由该Dispatcher所管理的所以连接所共享的,由于请求内存、写、回收等操作都是在Dispatcher线程里,所以这里不需要同步。

2.连接管理

主要是对连接最大时长超时、连接空闲时长超时进行管理,由Server的ConnectionManager成员进行管理其维护了一个connection的链表,Server初始化时即实例化connectionManager ,并启动了一个定时任务,定期对链表里的connection进行检查,超时调用connection的函数进行处理。

3.tcp分包

摘自官方手册

As discussed above, data will be segmented on the network level. If the onData() method is called, it is not predictable how many bytes will be received. By calling a read method such as readInt() or readStringByDelimiter() a BufferUnderflowException can occur. To handle this, the read mark support can be used.

即先标记读的起始地方,在读的过程中比如readint不够4byte,则抛出异常重置到标记的地方,ondata方法退出,等有新的数据来时再次调用。

4.多线程,线程池

主要是一个Acceptor线程,一个管理连接的Timer,一个Dispatcher线程池(默认是两个Dispatcher),底层读写操作由Dispatcher完成,每个连接会新建一个ondataevent事件队列和Runnabe对象(注意不是线程),Runnable run方法从队列取事件执行ondataevent也就是我们定义的handler的函数。Runnable对象提交给一个全局的workpool线程池执行,core size为2,max size 为100。

通常情况下就是有六个线程。

时间: 2024-08-08 13:56:03

xsocket分析三,补充说明的相关文章

baksmali和smali源码分析(三)

baksmali 的源码分析 在baksmali进行源码分析之前,需要读者掌握一条主线,因为本身笔者只是由于项目需要用到这套源码,在工作之余的时间里面来进行学习也没有时间和精力熟读源码的每个文件每个方法,但是依据这条主线,至少能够猜出并且猜对baksmali里面的源码的文件大概的作用是什么,这样在修改问题和移植的时候才能做到游刃有余. 这条主线是,baksmali其实只是利用了dexlib2提供的接口,将dex文件读入到一块内存中,这块内存或者说数据结构开辟的大小是跟输入的dex文件相关的,而这

传奇源码分析-客户端(游戏逻辑处理源分析三)

6. 接收怪物,商人,其它玩家的消息:ProcessUserHuman:(其它玩家-服务器处理)CPlayerObject->SearchViewRange();CPlayerObject->Operate();遍历UserInfoList列表,依次调用每个UserInfo的Operate来处理命令队列中的所有操作; pUserInfo->Operate()调用m_pxPlayerObject->Operate()调用.根据分发消息(RM_TURN)向客户端发送SM_TURN消息.

Nouveau源码分析(三):NVIDIA设备初始化之nouveau_drm_probe

Nouveau源码分析(三) 向DRM注册了Nouveau驱动之后,内核中的PCI模块就会扫描所有没有对应驱动的设备,然后和nouveau_drm_pci_table对照. 对于匹配的设备,PCI模块就调用对应的probe函数,也就是nouveau_drm_probe. // /drivers/gpu/drm/nouveau/nouveau_drm.c 281 static int nouveau_drm_probe(struct pci_dev *pdev, 282 const struct

[Android]Fragment源码分析(三) 事务

Fragment管理中,不得不谈到的就是它的事务管理,它的事务管理写的非常的出彩.我们先引入一个简单常用的Fragment事务管理代码片段: FragmentTransaction ft = this.getSupportFragmentManager().beginTransaction(); ft.add(R.id.fragmentContainer, fragment, "tag"); ft.addToBackStack("<span style="fo

横屏小游戏--萝莉快跑源码分析三

主角出场: 初始化主角 hero = new GameObjHero(); hero->setScale(0.5); hero->setPosition(ccp(100,160)); hero->setVisible(false); addChild(hero,1); 进入GameObjHero类ccp文件 创建主角及动作 this->setContentSize(CCSizeMake(85,90)); //接收触摸事件 CCDirector* pDirector = CCDire

转:u-boot分析 三 (u-boot.lds脚本)

u-boot分析 三 (u-boot.lds脚本) 转自:http://blog.csdn.net/itxiebo/article/details/50938753 目的, 了解链接器用到的脚本文件u-boot.lds. 在开始这篇博文之前,需要先了解一些GNU linker script的基本知识,可以参考博主的另外一篇分享<GNU linker script,ld script,GNU链接脚本> 在<u-boot分析 二>中,我们分析u-boot的目录结构,提及到了程序入口st

需求用例分析之补充规约

补充规约在RUP中是记录那些在用例模型的用例中不容易体现出来的系统需求.这些需求包括: § 法律法规方面的需求和应用标准. § 要建立的系统质量属性,包括可用性需求.可靠性需求.性能需求和可支持性需求. § 其他需求,诸如操作系统和操作环境.兼容性需求以及设计约束. 补充规约是对用例模型的重要补充.补充规约和用例模型应该一起获取对系统的一整套需求. 通过以上文字可以知道,补充规约是全局性的要求,与上述c文中的"全局规则"极为接近.而中文中"补充规约"的说法让不少人以

一些有用的javascript实例分析(三)

原文:一些有用的javascript实例分析(三) 1 10 输入两个数字,比较大小 2 window.onload = function () 3 { 4 var aInput = document.getElementsByTagName("input"); 5 var aSpan = document.getElementsByTagName("span")[0]; 6 for(var i=0;i<aInput.length-1;i++){ 7 aInp

Nouveau源代码分析(三):NVIDIA设备初始化之nouveau_drm_probe

Nouveau源代码分析(三) 向DRM注冊了Nouveau驱动之后,内核中的PCI模块就会扫描全部没有相应驱动的设备,然后和nouveau_drm_pci_table对比. 对于匹配的设备,PCI模块就调用相应的probe函数,也就是nouveau_drm_probe. // /drivers/gpu/drm/nouveau/nouveau_drm.c 281 static int nouveau_drm_probe(struct pci_dev *pdev, 282 const struct