问题背景

NIO是面向缓冲区进行通信的,不是面向流的。我们都知道,既然是缓冲区,那它一定存在一个固定大小。这样一来通常会遇到两个问题:

  • 消息粘包:当缓冲区足够大,由于网络不稳定种种原因,可能会有多条消息从通道读入缓冲区,此时如果无法分清数据包之间的界限,就会导致粘包问题;
  • 消息不完整:若消息没有接收完,缓冲区就被填满了,会导致从缓冲区取出的消息不完整,即半包的现象。

介绍这个问题之前,务必要提一下我代码整体架构。

代码参见GitHub仓库

https://github.com/CuriousLei/smyl-im

在这个项目中,我的NIO核心库设计思路流程图如下所示

介绍:

  • 服务端为每一个连接上的客户端建立一个Connector对象,为其提供IO服务;
  • ioArgs对象内部实例域引用了缓冲区buffer,作为直接与channel进行数据交互的缓冲区;
  • 两个线程池,分别操控ioArgs进行读和写操作;
  • connector与ioArgs关系:(1)输入,线程池处理读事件,数据写入ioArgs,并回调给connector;(2)输出,connector将数据写入ioArgs,将ioArgs传入Runnable对象,供线程池处理;
  • 两个selector线程,分别监听channel的读和写事件。事件就绪,则触发线程池工作。

思路

光这样实现,必然会有粘包、半包问题。要重现这两个问题也很简单。

  • ioArgs中把缓冲区设置小一点,发送一条大于该长度的数据,服务端会当成两条消息读取,即消息不完整;
  • 在线程代码中,加一个Thread.sleep()延时等待,客户端连续发几条消息(总长度小于缓冲区大小),也可以重现粘包现象。

这个问题实质上是消息体与缓冲区数据不一一对应导致的。那么,如何解决呢?

固定头部方案

可以采用固定头部方案来解决,头部设置四个字节,存储一个int值,记录后面数据的长度。以此来标记一个消息体。

  • 读取数据时,根据头部的长度信息,按序读取ioArgs缓冲区中的数据,若没有达到长度要求,继续读下一个ioArgs。这样自然不会出现粘包、半包问题。
  • 输出数据时,也采用同样的机制封装数据,首部四个字节记录长度。

我的工程项目中,客户端和服务端共用一个nio核心包,即niohdl,可保证收发数据格式一致。

设计方案

要实现以上设想,必须在connector和ioArgs之间加一层Dispatcher类,用于处理消息体缓冲区之间的转化关系(消息体取个名字:Packet)。根据输入和输出的不同,分别叫ReceiveDispatcher和SendDispatcher。即通过它们来操作Packet与ioArgs之间的转化。

Packet

定义这个消息体,继承关系如下图所示:

Packet是基类,代码如下:

package cn.buptleida.niohdl.core;
import java.io.Closeable;
import java.io.IOException;
/**
* 公共的数据封装
* 提供了类型以及基本的长度的定义
*/
public class Packet implements Closeable {
protected byte type;
protected int length; public byte type(){
return type;
} public int length(){
return length;
} @Override
public void close() throws IOException { }
}

SendPacket和ReceivePacket分别代表发送消息体和接收消息体。StringReceivePacket和StringSendPacket代表字符串类的消息,因为本次实践只限于字符串消息的收发,今后可能有文件之类的,有待扩展。

代码中必然会涉及到字节数组的操作,所以,以StringSendPacket为例,需要提供将String转化为byte[]的方法。代码如下所示:

package cn.buptleida.niohdl.box;
import cn.buptleida.niohdl.core.SendPacket; public class StringSendPacket extends SendPacket { private final byte[] bytes; public StringSendPacket(String msg) {
this.bytes = msg.getBytes();
this.length = bytes.length;//父类中的实例域
} @Override
public byte[] bytes() {
return bytes;
}
}

SendDispatcher

在connector对象的实例域中会引用一个SendDispatcher对象。发送数据时,会通过SendDispatcher中的方法对数据进行封装和处理。其大致的关系图如下所示:

SendDispatcher中设置任务队列Queue queue,需要发送消息时,connector将消息写入sendPacket,并存入队列queue,执行出队。用packetTemp变量引用出队的元素,将四字节的长度信息和packetTemp写入ioArgs的缓冲区中,发送完毕之后,再判断packetTemp是否完整写出(使用position和total指针标记、判断),决定继续输出packetTemp的内容,还是开始下一轮出队。

这个过程的程序框图如下所示:

在代码中,SendDispatcher实际上是一个接口,我用AsyncSendDispatcher实现此接口,代码如下:

package cn.buptleida.niohdl.impl.async;

import cn.buptleida.niohdl.core.*;
import cn.buptleida.utils.CloseUtil; import java.io.IOException;
import java.util.Queue;
import java.util.concurrent.ConcurrentLinkedDeque;
import java.util.concurrent.atomic.AtomicBoolean; public class AsyncSendDispatcher implements SendDispatcher {
private final AtomicBoolean isClosed = new AtomicBoolean(false);
private Sender sender;
private Queue<SendPacket> queue = new ConcurrentLinkedDeque<>();
private AtomicBoolean isSending = new AtomicBoolean();
private ioArgs ioArgs = new ioArgs();
private SendPacket packetTemp;
//当前发送的packet大小以及进度
private int total;
private int position; public AsyncSendDispatcher(Sender sender) {
this.sender = sender;
} /**
* connector将数据封装进packet后,调用这个方法
* @param packet
*/
@Override
public void send(SendPacket packet) {
queue.offer(packet);//将数据放进队列中
if (isSending.compareAndSet(false, true)) {
sendNextPacket();
}
} @Override
public void cancel(SendPacket packet) { } /**
* 从队列中取数据
* @return
*/
private SendPacket takePacket() {
SendPacket packet = queue.poll();
if (packet != null && packet.isCanceled()) {
//已经取消不用发送
return takePacket();
}
return packet;
} private void sendNextPacket() {
SendPacket temp = packetTemp;
if (temp != null) {
CloseUtil.close(temp);
}
SendPacket packet = packetTemp = takePacket();
if (packet == null) {
//队列为空,取消发送状态
isSending.set(false);
return;
} total = packet.length();
position = 0; sendCurrentPacket();
} private void sendCurrentPacket() {
ioArgs args = ioArgs; args.startWriting();//将ioArgs缓冲区中的指针设置好 if (position >= total) {
sendNextPacket();
return;
} else if (position == 0) {
//首包,需要携带长度信息
args.writeLength(total);
} byte[] bytes = packetTemp.bytes();
//把bytes的数据写入到IoArgs中
int count = args.readFrom(bytes, position);
position += count; //完成封装
args.finishWriting();//flip()操作
//向通道注册OP_write,将Args附加到runnable中;selector线程监听到就绪即可触发线程池进行消息发送
try {
sender.sendAsync(args, ioArgsEventListener);
} catch (IOException e) {
closeAndNotify();
}
} private void closeAndNotify() {
CloseUtil.close(this);
} @Override
public void close(){
if (isClosed.compareAndSet(false, true)) {
isSending.set(false);
SendPacket packet = packetTemp;
if (packet != null) {
packetTemp = null;
CloseUtil.close(packet);
}
}
} /**
* 接收回调,来自writeHandler输出线程
*/
private ioArgs.IoArgsEventListener ioArgsEventListener = new ioArgs.IoArgsEventListener() {
@Override
public void onStarted(ioArgs args) { } @Override
public void onCompleted(ioArgs args) {
//继续发送当前包packetTemp,因为可能一个包没发完
sendCurrentPacket();
}
}; }

ReceiveDispatcher

同样,ReceiveDispatcher也是一个接口,代码中用AsyncReceiveDispatcher实现。在connector对象的实例域中会引用一个AsyncReceiveDispatcher对象。接收数据时,会通过ReceiveDispatcher中的方法对接收到的数据进行拆包处理。其大致的关系图如下所示:

每一个消息体的首部会有一个四字节的int字段,代表消息的长度值,按照这个长度来进行读取。如若一个ioArgs未满足这个长度,就读取下一个ioArgs,保证数据包的完整性。这个流程就不画程序框图了,偷个懒hhhh。其实看下面代码注释已经很清晰了,容易理解。

AsyncReceiveDispatcher的代码如下所示:

package cn.buptleida.niohdl.impl.async;

import cn.buptleida.niohdl.box.StringReceivePacket;
import cn.buptleida.niohdl.core.ReceiveDispatcher;
import cn.buptleida.niohdl.core.ReceivePacket;
import cn.buptleida.niohdl.core.Receiver;
import cn.buptleida.niohdl.core.ioArgs;
import cn.buptleida.utils.CloseUtil; import java.io.IOException;
import java.util.concurrent.atomic.AtomicBoolean; public class AsyncReceiveDispatcher implements ReceiveDispatcher {
private final AtomicBoolean isClosed = new AtomicBoolean(false);
private final Receiver receiver;
private final ReceivePacketCallback callback;
private ioArgs args = new ioArgs();
private ReceivePacket packetTemp;
private byte[] buffer;
private int total;
private int position; public AsyncReceiveDispatcher(Receiver receiver, ReceivePacketCallback callback) {
this.receiver = receiver;
this.receiver.setReceiveListener(ioArgsEventListener);
this.callback = callback;
} /**
* connector中调用该方法进行
*/
@Override
public void start() {
registerReceive();
} private void registerReceive() { try {
receiver.receiveAsync(args);
} catch (IOException e) {
closeAndNotify();
}
} private void closeAndNotify() {
CloseUtil.close(this);
} @Override
public void stop() { } @Override
public void close() throws IOException {
if(isClosed.compareAndSet(false,true)){
ReceivePacket packet = packetTemp;
if(packet!=null){
packetTemp = null;
CloseUtil.close(packet);
}
}
} /**
* 回调方法,从readHandler输入线程中回调
*/
private ioArgs.IoArgsEventListener ioArgsEventListener = new ioArgs.IoArgsEventListener() {
@Override
public void onStarted(ioArgs args) {
int receiveSize;
if (packetTemp == null) {
receiveSize = 4;
} else {
receiveSize = Math.min(total - position, args.capacity());
}
//设置接受数据大小
args.setLimit(receiveSize);
} @Override
public void onCompleted(ioArgs args) {
assemblePacket(args);
//继续接受下一条数据,因为可能同一个消息可能分隔在两份IoArgs中
registerReceive();
}
}; /**
* 解析数据到packet
* @param args
*/
private void assemblePacket(ioArgs args) {
if (packetTemp == null) {
int length = args.readLength();
packetTemp = new StringReceivePacket(length);
buffer = new byte[length];
total = length;
position = 0;
}
//将args中的数据写进外面buffer中
int count = args.writeTo(buffer,0);
if(count>0){
//将数据存进StringReceivePacket的buffer当中
packetTemp.save(buffer,count);
position+=count; if(position == total){
completePacket();
packetTemp = null;
}
} } private void completePacket() {
ReceivePacket packet = this.packetTemp;
CloseUtil.close(packet);
callback.onReceivePacketCompleted(packet);
} }

总结

其实粘包、半包的解决方案并没有什么奥秘,单纯地复杂而已。方法核心就是自定义一个消息体Packet,完成Packet中的byte数组与缓冲区数组之间的复制转化即可。当然,position、limit等等指针的辅助很重要。

总结这个博客,也是将目前为止的工作进行梳理和记录。我将通过smyl-im这个项目来持续学习+实践。因为之前学习过程中有很多零碎的知识点,都躺在我的有道云笔记里,感觉没必要总结成博客。本次博客讲的内容刚好是一个成体系的东西,正好可以将这个项目背景带出来,后续的博客就可以在这基础上衍生拓展了。

java nio消息半包、粘包解决方案的更多相关文章

  1. [转]java nio解决半包 粘包问题

    java nio解决半包 粘包问题 NIO socket是非阻塞的通讯模式,与IO阻塞式的通讯不同点在于NIO的数据要通过channel放到一个缓存池ByteBuffer中,然后再从这个缓存池中读出数 ...

  2. 网络编程3 网络编程之缓冲区&subprocess&粘包&粘包解决方案

    1.sub简单使用 2.粘包现象(1) 3.粘包现象(2) 4.粘包现象解决方案 5.struct学习 6.粘包现象升级版解决方案 7.打印进度条

  3. netty10---分包粘包

    客户端:根据 长度+数据 方式发送 package com.server; import java.net.Socket; import java.nio.ByteBuffer; public cla ...

  4. mina框架tcpt通讯接收数据断包粘包处理

    用mina做基于tcp,udp有通讯有段时间了,一直对编码解码不是很熟悉,这次做项目的时候碰到了断包情况,贴一下解决过程, 我接受数据格式如下图所示: unit32为c++中数据类型,代表4个字节,由 ...

  5. goim socket丢包粘包问题解决。

    -(NSInteger)bytesToInt:(unsigned char*) data { return (data[3]&255)|(data[2]&255)<<8|( ...

  6. socket编程 TCP 粘包和半包 的问题及解决办法

    一般在socket处理大数据量传输的时候会产生粘包和半包问题,有的时候tcp为了提高效率会缓冲N个包后再一起发出去,这个与缓存和网络有关系. 粘包 为x.5个包 半包 为0.5个包 由于网络原因 一次 ...

  7. TCP的粘包、半包和Netty的处理

    参考文献:极客时间傅健老师的<Netty源码剖析与实战>Talk is cheap.show me the code! 什么是粘包和半包 在客户端发送数据时,实际是把数据写入到了TCP发送 ...

  8. tcp的粘包现象与解决方案

    粘包现象: 粘包1:连续的小包,会被优化机制给合并 粘包2:服务端一次性无法完全就收完客户端发送的数据,第二再次接收的时候,会接收到第一次遗留的内容 模拟一个粘包现象 服务端 import socke ...

  9. NIO框架之MINA源码解析(四):粘包与断包处理及编码与解码

    1.粘包与段包 粘包:指TCP协议中,发送方发送的若干包数据到接收方接收时粘成一包,从接收缓冲区看,后一包数据的头紧接着前一包数据的尾.造成的可能原因: 发送端需要等缓冲区满才发送出去,造成粘包 接收 ...

随机推荐

  1. Linux---使用kill杀不掉进程解决方案

    今天打开Linux虚拟机,然后使用jps命令查看,莫名奇妙多了一个1889进程 然后使用kill杀掉后,再运行jps还是存在此进程.于是乎开始大量百度,最终找到了解决方案. 说的很清楚了,杀不掉的原因 ...

  2. FormData/Go分片/分块文件上传

    FormData 接口提供了一种表示表单数据的键值对的构造方式,经过它的数据可以使用 XMLHttpRequest.send() 方法送出,本接口和此方法都相当简单直接.如果送出时的编码类型被设为 & ...

  3. VScode配置CMD本地运行环境(2.0)

    VScode配置CMD本地运行环境(2.0) 官方Task.json说明 完整的Task.json配置信息 Task.json预定义变量 看了很多网上的教程都说需要下载VScode的python插件, ...

  4. selenium停止对PhantomJS的支持

    今天发现最新版本的selenium3.11.0停止对PhantomJS的支持,需要对selenium降级 卸载最新版本:pip3 uninstall selenium 安装历史版本:pip3 inst ...

  5. JWT签发token

    目录 一. 认证的发展历程简介 二. JWT签发Token源码分析 2.1 JWT工作原理及简介 2.2 JWT生成token源码分析 返回目录 一. 认证的发展历程简介 这里真的很简单的提一下认证的 ...

  6. POJ1270 toposort+DFS+回溯

    题目链接:http://poj.org/problem?id=1270 这道题其实就是求所有满足条件的topo序,我们考虑到给定的字符是确定的,也就是他们的长度都是一样的,所以为了得到所有的情况,我们 ...

  7. AQS机制

    一,Lock接口 锁是用来控制多个线程访问共享资源的方式,一般来说,一个锁能够防止多个线程同时访问共享资源(但是有些锁可以允许多个线程并发的访问共享资源,比如读写锁).在Lock接口出现之前,Java ...

  8. RDD的Cache、Persist、Checkpoint的区别和StorageLevel存储级别划分

    为了增强容错性和高可用,避免上游RDD被重复计算的大量时间开销,Spark RDD设计了包含多种存储级别的缓存和持久化机制,主要有三个概念:Cache.Persist.Checkout. 1.存储级别 ...

  9. 简述UDF/UDAF/UDTF是什么,各自解决问题及应用场景

    UDF User-Defined-Function 自定义函数 .一进一出: 背景 系统内置函数无法解决实际的业务问题,需要开发者自己编写函数实现自身的业务实现诉求. 应用场景非常多,面临的业务不同导 ...

  10. 记录一些服务端术语和搭建web服务器

    菜单快捷导航 服务端常用术语 搭建web服务器和配置虚拟主机 记录一些服务端方面的常用术语 1.CS架构和BS架构 1.1 CS架构 CS(Client/Server),基于安装包类型的桌面或手机软件 ...