当前位置：文档之家 › Java 远程通讯_MINA

Java 远程通讯_MINA

  • 格式：docx
  • 大小：4.19 MB
  • 文档页数：37

第一章MINA前述1.1线程模型MINA线程模型采用了Reactors in threads模型，即Main Reactor + Sub Reactors的模式。

由main reactor处理连接相关的任务：accept、connect等，当连接处理完毕并建立一个socket连接（称之为session）后，给每个session分配一个sub reactor，之后该session的所有IO、业务逻辑处理均交给了该sub reactor。

每个reactor均是一个线程，sub reactor中只靠内核调度，没有任何通信且互不打扰。

现在来讲讲我对线程模型演进的一些理解：Thread per Connection:在没有nio之前，这是传统的java网络编程方案所采用的线程模型。

即有一个主循环，socket.accept阻塞等待，当建立连接后，创建新的线程/从线程池中取一个，把该socket连接交由新线程全权处理。

这种方案优缺点都很明显，优点即实现简单，缺点则是方案的伸缩性受到线程数的限制。

Reactor in Single Thread:有了nio后，可以采用IO多路复用机制了。

我们抽取出一个单线程版的reactor模型，时序图见下文，该方案只有一个线程，所有的socket连接均注册在了该reactor上，由一个线程全权负责所有的任务。

它实现简单，且不受线程数的限制。

这种方案受限于使用场景，仅适合于IO密集的应用，不太适合CPU密集的应用，且适合于CPU资源紧张的应用上。

Reactor + Thread Pool:方案2由于受限于使用场景，但为了可以更充分的使用CPU资源，抽取出一个逻辑处理线程池。

reactor仅负责IO任务，线程池负责所有其它逻辑的处理。

虽然该方案可以充分利用CPU资源，但是这个方案多了进出thread pool的两次上下文切换。

Reactors in threads: 基于方案3缺点的考虑，将reactor分成两个部分。

main reactor负责连接任务（accept、connect等），sub reactor负责IO、逻辑任务，即mina与netty的线程模型。

该方案适应性十分强，可以调整sub reactor的数量适应CPU资源紧张的应用；同时CPU密集型任务时，又可以在业务处理逻辑中将任务交由线程池处理，如方案5。

该方案有一个不太明显的缺点，即session没有分优先级，所有session平等对待均分到所有的线程中，这样可能会导致优先级低耗资源的session堵塞高优先级的session，但似乎netty与mina并没有针对这个做优化。

Reactors in threads + Threads pool: 这也是我所在公司应用框架采用的模型，可以更为灵活的适应所有的应用场景：调整reactor数量、调整thread pool大小等。

1.2 任务粒度任务从逻辑上我给它分为成三种类型：连接相关的任务（bind、connect等）、写任务（write、flush）、调度任务（延迟、定时等），读任务则由selector加循环时间控制了。

mina任务调度的趋势是逐渐变小，从session级别的调度 -> 类型级别任务的调度 -> 任务的调度。

mina-1.1.7: SocketIoProcessor$Worker.runmina-2.0.4: AbstractPollingIoProcessor$Processor.runmina-3.0.0.M3-SNAPSHOT: AbstractNioSession.processWritemina1、2的任务调度粒度为session。

mina会将有IO任务的的session写入队列中，当循环执行任务时，则会轮询所有的session，并依次把session中的所有任务取出来运行。

这样粗粒度的调度是不公平调度，会导致某些请求的延迟很高。

mina3的模型改动比较大，代码相对就比较难看了，我仅是随便扫了一下，它仅提炼出writeQueue。

1.3 数据如何Read/writejava nio如果是non-blocking的话，在每次write(bytes[N])的时候，并不会将N字节全部write出去，每次write仅一部分（具体大小和tcp_write_buffer有关）。

那么，mina是怎么处理这种情况的呢？mina-1.1.7: SocketIoProcessor.doFlushmina-2.0.4: AbstractPollingIoProcessor.flushNowmina-3.0.0.M3-SNAPSHOT: AbstractNioSession.processWritemina1、2的方式基本一致。

在发送端每个session均有一个writeBufferQueue，有这样一个队列，可以保证写入与写出均有序。

在真正write时，大致逻辑均是一一将队列中的writeBuffer取出，写入socket，但有一些不同的是，mina1是每次peek一次，当该buffer全部写出之后再poll（mina3也是这种机制）；而mina2则是直接poll第一个，将其存为currentWriteRequest，直到currentWriteRequest全部写出之后，才会poll下一个。

这样的做法是为了省几次peek的时间么？同时mina在write时，有一种spin write的机制，即循环write多次。

mina1的spin write count为256，写死在代码里了，表示256有点大；mina2这个机制废除但代码保留；每次write只是输出了一部分数据，read同理，也有可能只会读入部分数据，这样就是导致读入的数据是残缺的。

而mina默认不会理会这种由于nio导致的数据分片，需要由业务层自己额外做配置或者处理。

nfs-rpc: ProtocolUtils.decodemina-1.1.7: SocketIoProcessor.read, CumulativeProtocolDecoder.decodemina-2.0.4: AbstractPollingIoProcessor.read,CumulativeProtocolDecoder.decodemina-3.0.0.M3-SNAPSHOT: NioSelectorLoop.readBuffernfs-rpc在协议反序列化的过程中，就会考虑这个的问题，依次读入每个字节，当发现当前字节或者剩余字节数不够时，会将buf的readerIndex设置为初始状态。

具体的实现，有兴趣的同学可以学习nfs-rpc：ProtocolUtils.decodenfs-rpc在decode时，出现错误就会将buf的readerIndex设为0，把readerIndex设置为0就必须要有个前提假设：每次decode时buf是同一个，即该buf是复用的。

那么，具体情况是怎样呢？mina1、2的读buffer创建方式比较土，在每次read之前，会重新allocate一个新的buf对象，该buf 对象的大小是根据读入数据大小动态调整。

当本次读入数据等于该buf大小，下一次allocate的buf对象大小会翻倍；当本次读入数据不足该buf大小的二分之一，下一次allocate的buf对象同样会缩小至一半。

需要注意的是，*2与/2的代码都可以用位运算，但是mina1竟没用位运算，有意思。

mina1、2处理数据分片可以继承CumulativeProtocolDecoder，该decoder会在session中存入(BUFFER, cumulativeBuffer)。

decode过程为：1）先将message追加至cumulativeBuffer；2）调用具体的decode逻辑；3）判断cumulativeBuffer.hasRemaining()，为true则压缩cumulativeBuffer，为false则直接删除(BUFFER, cumulativeBuffer)。

实现业务的decode逻辑可以参考nfs-rpc中MinaProtocolDecoder的代码。

mina3在处理读buffer的创建与数据分片比较巧妙，它所有的读buffer共用一个buffer对象（默认64kb），每次均会将读入的数据追加至该buffer中，这样即省去了buffer的创建与销毁事件，也省去了cumulativeDecoder的处理逻辑，让代码很清爽啊！ByteBuffer设计需要说明的是，只有mina1、2才有自己的buffer类，mina3内部只用nio的原生ByteBuffer类（提供了一个组合buffer的代理类-IoBuffer）。

mina1、2自建buffer的原因如下：It doesn’t provide useful getters and putters such as fill,get/putString, andget/putAsciiInt()enough.It is difficult to write variable-length data due to its fixed capacity第一条比较好理解，即提供了更为方便的方法用以操作buffer。

第二条则是觉得nio的ByteBuffer是定长的，无法自动扩容或者缩容，所以提供了自动扩/缩容的方法：IoBuffer.setAutoExpand,IoBuffer.setAutoShrink。

但是扩/缩容的实现，也是基于nio的ByteBuffer，重新ByteBuffer.allocate(capacity)，再把原有的数据拷贝过去。

第二章MINA框架与应用Apache Mina Server 是一个网络通信应用框架，也就是说，它主要是对基于 TCP/IP、UDP/IP协议栈的通信框架（当然，也可以提供 JAVA 对象的序列化服务、虚拟机管道通信服务等），Mina 可以帮助我们快速开发高性能、高扩展性的网络通信应用，Mina 提供了事件驱动、异步（Mina 的异步 IO默认使用的是 JAVA NIO 作为底层支持）操作的编程模型。

从官网文档“MINA based Application Architecture”中可以看到Mina作为一个通信层框架，在实际应用所处的位置，如图所示：Mina位于用户应用程序和底层Java网络API（和in-VM通信）之间，我们开发基于Mina的网络应用程序，就无需关心复杂的通信细节。

再看一下，Mina架构，如图所示：通信过程：1.通过SocketConnector同服务器端建立连接2.链接建立之后I/O的读写交给了I/O Processor线程，I/O Processor是多线程的3.通过I/O Processor读取的数据经过IoFilterChain里所有配置的IoFilter，IoFilter进行消息的过滤，格式的转换，在这个层面可以制定一些自定义的协议4.最后IoFilter将数据交给Handler进行业务处理，完成了整个读取的过程5.写入过程也是类似，只是刚好倒过来，通过IoSession.write写出数据，然后Handler进行写入的业务处理，处理完成后交给IoFilterChain，进行消息过滤和协议的转换，最后通过I/O Processor将数据写出到socket通道IoFilterChain作为消息过滤链1.读取的时候是从低级协议到高级协议的过程，一般来说从byte字节逐渐转换成业务对象的过程2.写入的时候一般是从业务对象到字节byte的过程IoSession贯穿整个通信过程的始终MINA2工作流程：一个Acceptor线程有一个自己的Selector，这个Selector专门监听端口上的connect事件。

合集下载

[VIP专享]手把手教你做java远程控制

[VIP专享]手把手教你做java远程控制

手把手教你做java远程控制一、认识类1,Socket ，ServerSocket:Socket 位于.包中，这是一个对于网络通信来说及其重要的类，无论是那种语言，都会有Socket类的定应用或许，存在的差异也仅仅是在表示和组织上有所不同，Socket中文称它为套接字，javaAPI中可以查看相应的介绍一个ServerSocket构造一对通信套接字方法如下ServerSocket sr=new ServerSocket(port);Socket sc=new Socket("ip",port);其中ServerSocket 的accpet方法十分重要，当一个服务套接字建立之后它一直阻塞等待一个套接字的请求，直到建立连接。

部分计算机网络的书籍对套接字有这样的定义套接字 =ip+port;一个套接字是由一个由一个ip地址和一个端口组成的，在网络通信中的底层实现也的确如此，要一个进程通信就必须为之制定工作端口，在连接端口之后才能在该端口上通信.2, InputStream , OutputStream当一个套接字连接成功后就可以获得基于这个套接字的输入输出流，一切数据的发送和接受都离不开输出输入流，我们可以通过流封装的方法选择你要输入或者输出的数据类型，请看如下例子：这是一个完整服务器端的例子请仔细阅读注释//Server.javaimport .*;import java.io.*;public class Server {public static void main(String args[]){ServerSocket server=null;//定义服务套接字Socket you=null;String s=null;DataOutputStream out=null;//定义流DataInputStream in=null;try{server=new ServerSocket(4331);/*在这里建立服务器套接字，服务套接字的构造方法只需要有服务端口就行，这个道理很简单*/}catch(Exception e){System.out.println(e.getMessage());}//捕捉异常try{System.out.println("wait.....");you=server.accept();//在这里阻塞等待客户的介入out=new DataOutputStream(you.getOutputStream());//取得输出流in=new DataInputStream(you.getInputStream());//取得输出流while(true)//循环读{s=in.readUTF();int m=Integer.parseInt(s);out.writeUTF("Hello i am server!");//发送信息out.writeUTF("X 2:"+s);System.out.println("Server receive :"+s);Thread.sleep(300);//f防止组赛，没有这一个语句或占用很多cpu和内存}}catch(Exception e){System.out.println("Client leave!");}}}//上面是一个简单的服务器端程序显示了如何实现套接字的服务器构建//下面是一个客户端import java.io.*;import .*;public class Client {public static void main(String args[]){String s=null;Socket mysocket;//创建客户端套接字DataInputStream in=null;DataOutputStream out=null;try{mysocket=new Socket("127.0.0.1",4331);/*注意实例化的构造方法与服务器有什么不同*/System.out.println("localport:"+mysocket.getLocalPort());System.out.println("localAddress:"+mysocket.getLocalAddress());System.out.println("localSocketAddress:"+mysocket.getLocalSocketAddre ss());System.out.println("Chanel:"+mysocket.getChannel());// 上面的代码显示具体的通信地址端口in=new DataInputStream(mysocket.getInputStream());out=new DataOutputStream(mysocket.getOutputStream());for(int k=1;k<100;k=k+2）//循环写入内容{out.writeUTF(""+k);s=in.readUTF();System.out.println("客户端接受的数据！："+s);Thread.sleep(500);}}catch(Exception e){System.out.println(e.getMessage());}}}上面两个文件保存后放在一个文件价下运行客户端服务器端就可以实现通信，建议读者使用集成开发环境进行测试二、认识RPCRPC 是英文远程方法调用的缩写,见名知意,就是在本地计算机上调用远程计算机上的方法或着过程。

java远程调用方法

java远程调用方法

java远程调用方法
Java远程调用方法是指在分布式系统中，通过网络连接调用远程主机上的Java方法。

这种方法使得应用程序能够在不同的计算机上分布式运行，从而实现分布式计算。

通常，Java远程调用方法使用Java RMI（Remote Method Invocation）技术来实现，在远程主机上运行的Java对象可以使用本地Java应用程序中的方法。

Java 远程调用方法适用于大型分布式系统中的数据交换、计算和资源共享等场景，具有高效、可伸缩、可靠性强等优点。

同时，Java远程调用方法也存在着安全性和性能等方面的挑战，需要进行相应的安全措施和优化处理。

- 1 -。

使用MINA构建NIO程序

使用MINA构建NIO程序

使用MINA构建NIO程序mina是非常好的C/S架构的java服务器，这里转了一篇关于它的使用感受。

前言MINA是Trustin Lee最新制作的Java通讯框架。

通讯框架的主要作用是封装底层IO操作，提供高级的操作API。

比较出名的通讯框架有C++的ACE、Python的Twisted，而Java的通讯框架还有QuickServer、Netty2、Cindy、Grizzly 等。

2004年6月，Trustin Lee发布了一个通讯框架Netty2，是Java界第一个事件模型架构的通讯框架，Cindy也从中借鉴了不少思想。

由于Netty2的架构不是很好，Trustin Lee在2004年底加入Apache Directory组之后，重写了整个框架，取名为MINA。

MINA是一个基于Java NIO的通讯框架，Java从1.4开始引入NIO，提供了一个非阻塞、高性能的IO底层。

目前使用MINA的产品并不是很多，比较出名的就有Apache Directory、Openfire （Jive出品的一个XMPP产品）、red5（研究flash流媒体flv技术的朋友应该很清楚这个东西，adobe fms的竞争者，国内也有视频网站在使用）等等。

笔者在07年初的时候，公司新项目需要用Java实现一个Socket Server，对比了Netty2、Cindy、QuickServer和MINA。

当时Netty2已经停止开发，也找不到官方网站和代码，比较了另外三个框架之后，毅然选择了当时文档比较缺乏和使用群较少的MINA，一年以来的使用经验来看，感觉还是很不错的，MINA有着清晰的架构，很方便做自定义的扩充。

在1.0发布之后，官方网站充实了很多，增加了不少文档，也听到越来越多的朋友开始使用MINA。

后来专门针对JDK 1.5发布了1.1的版本，使用JDK内置的concurrent代替backport-util-concurrent。

Apache Mina典型例子分析

Apache Mina典型例子分析

Apache Mina ，一个高性能Java 异步并发网络通讯框架。

利用Mina 可以高效地完成以下任务：TCP/IP 和UDP/IP通讯串口通讯VM 间的管道通讯SSL/TLSJXM 集成IoC 容器集成（Spring 、Pico 等）状态机Mina 的API 当前主要有三个分支，分别是：2.0.x 目前处于SVN trunk 上的版本，Mina 社区对该版本的API 进行了全新的设计1.1.x 为当前用于产品开发的版本，适用于5.0 以上的JDK ，最新版本为1.1.51.0.x 是1.1.x 的JDK 1.4 的兼容版本，最新版本为1.0.8这里将要介绍的是 2.0.x 版。

虽然当前的稳定版本还是 1.1.x ，但是按照Mina 团队之前的开发计划， 2.0.x 即将在08 年夏季正式发布，并且在 2.0.x 中对Spring 等IoC 的集成进行了简化，添加了基于OGNL 的JMX 远程管理支持，使用基于Java Annotation 的全新API 大大简化了状态机编程，新的基于Apache APR 的基础I/O 组件促进了进一步的效率提升（据官方评测，APR 的效率较之Sun NIO 要高出约10%）。

由于这一系列的重大改进，使得 2.0.x 成为十分令人期待的一个版本，无论是Mina 新手还是老用户，如果你对这个项目抱有兴趣，便很有必要提前对这个版本进行一些了解。

首先让我们对异步I/O 做一些基本的了解。

异步I/O 模型大体上可以分为两种，反应式（Reactive ）模型和前摄式（Proactive ）模型：传统的select / epoll / kqueue 模型，以及Java NIO 模型，都是典型的反应式模型，即应用代码对I/O 描述符进行注册，然后等待I/O 事件。

当某个或某些I/O 描述符所对应的I/O 设备上产生I/O 事件（可读、可写、异常等）时，系统将发出通知，于是应用便有机会进行I/O 操作并避免阻塞。