对Java nio socket与as3 socket连接的简单应用 <ignore_js_op>Java nio socket与as3 socket连接的应用实例.rar (9.61 KB, 下载次数: 1691) 这个从基本的弄起太复杂了,我弄个了mina与flash通信的,通信数据模式是dataLength+data(数据长度+数据内容),对于socket字节流通信,我习惯用这种方式,方便粘包解码处理.其中已包含所需的jar包,客户端代码须另自写,不可沿用.flash socket发送的

java nio解决半包 粘包问题 NIO socket是非阻塞的通讯模式,与IO阻塞式的通讯不同点在于NIO的数据要通过channel放到一个缓存池ByteBuffer中,然后再从这个缓存池中读出数据,由于服务端缓存池大小限制以及网速不均匀等原因,会造成服务端读取到缓冲池中的数据不完整,就形成了断包问题,当缓存池大小够大的情况下又会发生一次读取到缓存池中的数据多于一个完整的数据包,这种情况因为无法分清数据包之间的界限,就形成了粘包问题.对于NIO的SocketChannel每次触发OP_REA

问题背景 NIO是面向缓冲区进行通信的,不是面向流的.我们都知道,既然是缓冲区,那它一定存在一个固定大小.这样一来通常会遇到两个问题: 消息粘包:当缓冲区足够大,由于网络不稳定种种原因,可能会有多条消息从通道读入缓冲区,此时如果无法分清数据包之间的界限,就会导致粘包问题: 消息不完整:若消息没有接收完,缓冲区就被填满了,会导致从缓冲区取出的消息不完整,即半包的现象. 介绍这个问题之前,务必要提一下我代码整体架构. 代码参见GitHub仓库 https://github.com/CuriousLe

java.nio:NIO-2: NIO 面向流的IO体系一次只能处理一个或多个字节/字符,直至读取所有字节/符,且流中的数据不能前后移动.效率低,当数据源中没有数据时会阻塞线程.Java-4提供的新API,Non-blocking IO(New IO,面向块的IO体系)为所有的原始类型提供Buffer缓存支持,缓冲区中数据可前后移动.灵活性好,非阻塞式允许一个单独的线程可以管理多个输入/出Channel,但是处理和解析数据相对复杂. 采用内存映射文件的方式处理输入输出,将文件或文件的一段区域映射

相关学习资料 http://www.molotang.com/articles/903.html http://www.ibm.com/developerworks/cn/education/java/j-nio/j-nio.html 目录 . NIO.NIO.2简介 . NIO中的关键技术 1. NIO.NIO.2简介 Java中的输入流.输出流都是阻塞式的输入.输出.不仅如此,传统的输入流.输出流都是通过字节的移动来处理的(即使是字符流,在底层也是通过字节流来进行处理的),也就是说,面向流的

在JDK 1.4以前,Java的IO操作集中在java.io这个包中,是基于流的同步(blocking)API.对于大多数应用来说,这样的API使用很方便,然而,一些对性能要求较高的应用,尤其是服务端应用,往往需要一个更为有效的方式来处理IO.从JDK 1.4起,NIO API作为一个基于缓冲区,并能提供异步(non-blocking)IO操作的API被引入.本文对其进行深入的介绍. NIO API主要集中在java.nio和它的subpackages中: java.nio 定义了Buffer及

目录 零.NIO包 一.Java NIO Channel通道 Channel的实现(Channel Implementations) Channel的基础示例(Basic Channel Example) 二.Java NIO Buffer缓冲区 Buffer基本用法(Basic Buffer Usage) Buffer的容量,位置,上限(Buffer Capacity, Position and Limit) 容量(Capacity) 位置(Position) 上限(Limit) Buffer

Java NIO 的核心组成部分: 1.Channels 2.Buffers 3.Selectors 我们首先来学习Channels(java.nio.channels): 通道 1)通道基础 通道(Channel)是java.nio的第二个主要创新.它们既不是一个扩展也不是一项增强,而是全新.极好的Java I/O示例,提供与I/O服务的直接连接.Channel用于在字节缓冲区和位于通道另一侧的实体(通常是一个文件或套接字)之间有效地传输数据. channel的jdk源码: package j

目录: <Java NIO系列教程(二) Channel> <Java NIO系列教程(三) Channel之Socket通道> 在<Java NIO系列教程(二) Channel>介绍了FileChannel,本章节介绍socket通道类. 一.Socket通道 新的socket通道类可以运行非阻塞模式并且是可选择的.这两个性能可以激活大程序(如网络服务器和中间件组件)巨大的可伸缩性和灵活性.本节中我们会看到,再也没有为每个socket连接使用一个线程的必要了,也避免

原文连接: http://www.blogjava.net/19851985lili/articles/93524.html 感谢原作者 NIO API 主要集中在 java.nio 和它的 subpackages 中: java.nio 定义了 Buffer 及其数据类型相关的子类.其中被 java.nio.channels 中的类用来进行 IO 操作的 ByteBuffer 的作用非常重要. java.nio.channels 定义了一系列处理 IO 的 Channel 接口以及这些接口在文

Java NIO的出现 Java语言发展至今,优点大家有目共睹:面向对象的语言.简洁有效.高移植性等等.但是同样也存在很多缺点,C语言程序员口中Java太慢了,.net程序员口中Java太开放了,php程序员说Java太复杂了. Java为了“一次编写,到处运行”的最大优势,也付出了相应的代价: Java需要运行于虚拟机(即JVM)之上,为了保证Java字节码在各种JVM部署平台上运行效果一致,作些妥协是必须的.既然需要通用于不同的操作系统平台,那么,某种程度上就必须选择各种平台都接受的处理方案

文章目录 问题 消息如何在管道中流转 源码解析 AbstractNioSelector.java AbstractNioWorker.java NioWorker.java DefaultChannelHandlerContext.java DefualtChannelPipeline.java SimpleChannelUpstreamHandler.java 验证 Server.java Handler1.java Handler2.java Client.java 输出 观察粘包.分包现象

Java NIO API详解 NIO API 主要集中在 java.nio 和它的 subpackages 中: java.nio 定义了 Buffer 及其数据类型相关的子类.其中被 java.nio.channels 中的类用来进行 IO 操作的 ByteBuffer 的作用非常重要. java.nio.channels 定义了一系列处理 IO 的 Channel 接口以及这些接口在文件系统和网络通讯上的实现.通过 Selector 这个类,还提供了进行非阻塞 IO 操作的办法.这个包可以说

疯狂创客圈 Java 聊天程序[ 亿级流量]实战系列之13 [博客园 总入口 ] 本文的源码工程:Netty 粘包/半包原理与拆包实战 源码 本实例是<Netty 粘包/半包原理与拆包实战> 一文的源代码工程. 写在前面 大家好,我是作者尼恩. 为了完成了一个高性能的 Java 聊天程序,在前面的文章中,尼恩已经再一次的进行了通讯协议的重新选择. 这就是:放弃了大家非常熟悉的json 格式,选择了性能更佳的 Protobuf协议. 在上一篇文章中,并且完成了Netty 和 Protobuf协议

上次回归: 上次博客我们主要说了netty的基本使用,都是一些固定的模式去写的,我们只需要关注我们的拦截器怎么去写就可以了,然后我们用我们的基础示例,改造了一个简单的聊天室程序,可以看到内部加了一个StringEncoder和StringDecoder,这个就是用来编解码我们字符串的,这次我们就来说说这个编解码. 编码&解码: 上次我们写的那个简单的聊天室程序大家还记得吧,内部加了两个类似拦截器的玩意. ch.pipeline().addLast(new StringEncoder()); ch

本文是Netty系列第4篇 上一篇文章我们深入了解了I/O多路复用的三种实现形式,select/poll/epoll. 那Netty是使用哪种实现的I/O多路复用呢?这个问题,得从Java NIO包说起. Netty实际上也是一个封装好的框架,它的网络I/O本质上还是使用了Java的NIO包(New IO,不是网络I/O模型的NIO,Nonblocking IO)包.所以,从网络I/O模型到Netty,我们还需要了解下Java NIO包. 本文预计阅读时间 5 分钟,将重点回答以下几个问题: 如

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

TCP是个"流"协议,所谓流,就是没有界限的一串数据.大家可以想象河里的流水,他们是连成一片的,其间并没有分界线.TCP底层并不了解上层业务数据的具体含义,他会根据TCP缓冲区的实际情况进行包的划分,所以在业务上认为,一个完整的包可能会被TCP拆分成多个包进行发送,也有可能把多个小的包封装成一个大的数据包发送.这就是TCP所谓的拆包和粘包的问题. 一.TCP粘包/拆包问题说明 我们可以通过图解对TCP粘包和拆包问题进行说明,粘包问题如图. 假设客户端分别发送了两个数据包D1和D2给服务

tcp是一个“流”的协议,一个完整的包可能会被TCP拆分成多个包进行发送,也可能把小的封装成一个大的数据包发送,这就是所谓的TCP粘包和拆包问题. 粘包.拆包问题说明 假设客户端分别发送数据包D1和D2给服务端,由于服务端一次性读取到的字节数是不确定的,所以可能存在以下4种情况. 1.服务端分2次读取到了两个独立的包,分别是D1,D2,没有粘包和拆包: 2.服务端一次性接收了两个包,D1和D2粘在一起了,被成为TCP粘包; 3.服务端分2次读取到了两个数据包,第一次读取到了完整的D1和D2包的部

TCP以流的方式进行数据传输,上层应用协议为了对消息的区分,采用了以下几种方法. 1.消息固定长度 2.第一篇讲的回车换行符形式 3.以特殊字符作为消息结束符的形式 4.通过消息头中定义长度字段来标识消息的总长度 一.采用指定分割符解决粘包与拆包问题 服务端 package com.ming.netty.nio.stickpack; import java.net.InetSocketAddress; import io.netty.bootstrap.ServerBootstrap; impo