NIO框架之MINA源码解析（转）

http://blog.csdn.net/column/details/nio-mina-source.html

http://blog.csdn.net/chaofanwei/article/details/38848085

http://blog.csdn.net/chaofanwei/article/details/38871115

http://blog.csdn.net/chaofanwei/article/details/38920963

http://blog.csdn.net/chaofanwei/article/details/38928409

时间： 2024-10-26 20:07:37

NIO框架之MINA源码解析（转）的相关文章

NIO框架之MINA源码解析（五）：NIO超级陷阱和使用同步IO与MINA通信

1.NIO超级陷阱之所以说NIO超级陷阱,就是因为我在本系列开头的那句话,因为使用缺陷导致客户业务系统瘫痪.当然,我对这个问题进行了很深的追踪,包括对MINA源码的深入了解,但其实之所以会出现这个问题,它的根不是MINA的原因,而是JDK底层的问题. JDK底层在实现nio时,为了能够唤醒等待在io上的线程,在windows平台使用了两个端口建立连接发消息实现.看如下代码: [java] view plain copy print? public class NIOTest { @Test p

NIO框架之MINA源码解析（一）：背景

?? "你们的agent占了好多系统的端口,把我们的很多业务系统都给整死了,给我们造成了很大的损失,要求你们的相关领导下周过来道歉" -- 来自我们的一个客户. 怎么可能呢,我们都不相信,我们的agent只占一个端口啊! 事实胜过雄辩,经过查证,确实是由于我们的agent占了好多系统的端口,我看了一下日志,基本把系统可用的端口占完了! 为什么呢?MINA框架私自开的! 由于我们的agent端使用了NIO通信框架MINA,但并没有使用好,造成了这一几乎毁灭行的灾难. 还是先看代码

NIO框架之MINA源码解析（二）：mina核心引擎

MINA的底层还是利用了jdk提供了nio功能,mina只是对nio进行封装,包括MINA用的线程池都是jdk直接提供的. MINA的server端主要有accept.processor.session三部分组成的.其中accept主要负责在指定的端口监听,若有新连接则建立一个新的session:processor则负责处理session对应的发送数据和接收数据并调用上层处理:session则缓存当前连接数据. MINA采用了线程懒启动的技术,即最少启动线程,在MINA server启动的时候,

NIO框架之MINA源码解析（三）：底层通信与责任链模式应用

本文主要介绍下在mina中责任链模式的应用以及mina对于数据读写的处理. 在mina中,对数据的读操作是在processor类里面触发的,收到新消息后就触发读数据链去处理新消息直到自己的业务逻辑代码(IoHandler). 在mina中,数据的写(write)和发(send)差别相对较大,mina中的写消息最终的结果只是把要写的消息经过写数据链处理后的最终结果放在了一个缓存中,并把当前session标记为可发. 数据的发送就是传统中我们所说的发消息,就是把写消息最终处理的结果发送到客户端,待发

NIO框架之MINA源码解析（四）：粘包与断包处理及编码与解码

1.粘包与段包粘包:指TCP协议中,发送方发送的若干包数据到接收方接收时粘成一包,从接收缓冲区看,后一包数据的头紧接着前一包数据的尾.造成的可能原因: 发送端需要等缓冲区满才发送出去,造成粘包接收方不及时接收缓冲区的包,造成多个包接收断包:也就是数据不全,比如包太大,就把包分解成多个小包,多次发送,导致每次接收数据都不全. 2.消息传输的格式消息长度+消息头+消息体即前N个字节用于存储消息的长度,用于判断当前消息什么时候结束. 消息头+消息体即固定长度的消息,前几个字节为消息

（三）Mina源码解析之IoFilter

本篇文章主要剖析Mina中的过滤器是如何实现的首先还是引入一个简单的完整的server端的例子,代码如下 public class Server { public static void main(String[] args) { IoAcceptor acceptor = new NioSocketAcceptor(); acceptor.getSessionConfig().setReadBufferSize(2048); acceptor.getSessionConfig().setId

Volley框架使用及源码解析

1. Volley特点 (1) 特别适合数据量小,通信频繁的网络操作. (2) 扩展性强.Volley 中大多是基于接口的设计,可根据需要自行定制. (3) 一定程度符合 Http 规范,包括返回 ResponseCode(2xx.3xx.4xx.5xx)的处理,请求头的处理, 缓存机制的支持等.并支持重试及优先级定义. (4) 提供简便的图片加载工具 GitHub地址:https//github.com/mcxiaoke/android-volley 2. 概念介绍 Request:表示一个请

rpc框架yar之源码解析- 协议和传输

Yar 协议头和传输源码分析这篇博客主要学习rpc框架yar的协议头和传输的实现, 能力有限,有些语句没有看懂,所以猜测了一部分. yar_header_t的实现 _yar_header的定义主要在yar_protocol.h和yar_protocol.c里面,下面介绍这两个文件里的源码.借用网上的一幅图片,请求体包括 yar_header + packager_name + yar_request_t 这三个部分,返回类似.下面主要介绍yar_header的部分. ? yar_protoco

NIO byteBUffer 讲解及Mina 源码分析

1.传统的socket: 阻塞式通信模式 tcp连接: 与服务器连接时 .必须等到连接成功后才返回 . udp连接: 客户端发送数据 ,必须等到发送成功后返回 . 每建立一个 Scoket连接时, 同事创建一个新线程对该 Socket进行单独通信(采用阻塞式通信 ) 这种方式具有很高的响应速度,并且控制起来也很简单,在连接数较少的时候非常有效,但是如果对每一个连接都产生一个线程的无疑是对系统资源的一种浪费,如果连接数较多将会出现资源不足的情况 2．1NIO 设计背后的基石:反应器模式,用于事