mina

最近刚刚在做 Java 通信方面，初次接触mina，边根据网上查找的资料，结合自身的实际问题，作出了如下整理，希望能给类似问题的朋友帮助。 我的实际情况： 1，传递的业务数据种类很多，这就决定了我们要用多路解码器，MINA的中文手册提供的是DemuxingProtocolCodecFactory; 2,,有的数据长度达到8K，网上有资料说Mina在传输数据超过2K的情况下，会分片传输，因此要考虑如何来接收； 3，若数据发送很快，或者网络状况不佳，很容易出现粘包的情况，这也是要解决的问题。 1）针对多路解码： 编码器： 将编码器继承MessageEncoder<T>,T是你编码的对象的类，此中我是要编码Requstwork类；其中GetBytes()是我自己定义的将对象的数据组成字节数组的函数； public class RequstNetworkEncoder implements MessageEncoder<RequstNetwork>{ @Override public void encode(IoSession ioSession, RequstNetwork requstNetwork, ProtocolEncoderOutput out) throws Exception { if (requstNetwork != null) { byte[] bytes1 =

解Bug之路-TCP粘包Bug 前言 关于TCP流 TCP是流的概念，解释如下 TCP窗口的大小取决于当前的网络状况、对端的缓冲大小等等因素， TCP将这些都从底层屏蔽。开发者无法从应用层获取这些信息。 这就意味着，当你在接收TCP数据流的时候无法知道当前接收了 有多少数据流，数据可能在任意一个比特位（seq）上。 详情见笔者另一篇博客 https://my.oschina.net/alchemystar/blog/833937 关于"粘包" 由于TCP流的特性，经常发生一个收到多于(长连接)或者小于当前包字节数的情况，看起来像一个包后面"粘着"后面包的一点内容，所以被应用层的人形象的称为"粘包",这个概念不是笔者发明的，老早就这么叫了。 关于流和"粘包" TCP流本身就是操作系统在屏蔽了mac帧、ip包这些底层概念与细节后抽象出来的概念。如果较真，TCP流在网络层也是由ip包一个一个传输组装而来。 TCP本身把底层的各种细节屏蔽抽象成"流"。 应用层的人把TCP导致的收多了(长连接）收不满的现象抽象成"粘包"。 笔者觉得无可厚非，无高下之分。 关于喷子 喷子有个特点，就是不看文章内容，只要和他所想不合，就开始喷。 笔者搞过协议栈，完整分析过三个协议栈(从ARP到TCP,分别是lwip、BsdTcp,xinu)的源码，给某实时操作系统解决ARP协议的Bug,用C写过滑动窗口协议。

SOCKET 协议 支持 java serial 与 AMF3 的混合协议 , 目前没有基于 xml 与 json 的实现。 协议说明： * 9个字节协议头+协议体. * * 协议头1-4字节表示协议长度 =协议体长度+9-4（去掉长度占的4字节） * * 协议头第5字节为标志字节： *------------------------ * 该字节的最低位为压缩位：0=协议体未压缩 1=协议体已经压缩， * 该字节的低2-4位为协议位： * 000=基于AMF3的协议， * 001=基于java serial协议 * 010=基于protobuf协议 * 5-8位未用，作为以后扩展 * ------------------------ * * 6-9字节表示命令号 * * 采用网络字节序的整数(高位在前，低位在后) 1-4协议长度 6-9cmd 1 2 3 4 5 标志位 6 7 8 9 数据（ AMF3 或者 java serial ） 目前支持3种序列化协议。protobuf没有做额外的压缩，也没有做加密，但是将来都可以用标志位来做，这里另外两种不做解释，主要说protobuf 准备工作 protobuf-java-2.5.0.jar 自定义的proto文件ChatMsg.proto protoc.exe编译工具 编译命令proto.bat #ChatMsg.proto

嘉宾介绍：叶倍宏，加拿大 UBC 计算机本科。 毕业后在加拿大支付公司 Versapay 任职。 回国多次创业，先在深圳小象网任合伙人 CTO，之后在大理远程自由职业。2016 在广州创立思客教学，专注于前端培训。 项目源码地址： https://git.oschina.net/hayeah/tongxing 一、小程序的价值观 张小龙是以小程序的价值观为出发点解释产品开发的思路的，他认为应用号的形态大致为：“一种新的公众号形态，这种形态下面用户关注了一个公众号，就像安装了一个 APP 一样。他要找这个公众号的时候就像找一个 APP，在平时这个号不会向用户发东西的，所以 APP 就会很安静的存在那里，等用户需要的时候找到它就好了，这样的话我们可以尝试做到让更多的 APP 有一种更轻量的形态，但是又更好使用的一种形态来存在，这是我们在探讨的一种新的公众号形态，叫应用号。” 开发者应该从应用号的价值观出发去思考产品的可能性。比如商城就太复杂而且不符合“用完即走”的价值观，而比较成功的案例有摩拜单车、冷气机的应用、微信支付等一些轻量级的应用。通过在微信里设计一个界面（页面）或添加一个按钮就可以去满足用户需求。 二、MINA 框架概述 小程序融合了很多前端开发界的概念，但是并没有采用任何一个框架，包括流行的REACT、VUE，还有CORDOVA 。 它不是三者中的任意一个

https://svn.apache.org/repos/asf/mina/mina/branches/2.0/mina-example/src/main/java/org/apache/mina/example/tcp/perf/TcpServer.java 全部mina查看网址： https://svn.apache.org/repos/asf/mina 关于mina和netty的好文章和代码： NIO框架入门(四)：Android与MINA2、Netty4的跨平台UDP双向通信实战 https://cloud.tencent.com/developer/article/1194019 http://www.52im.net/thread-373-1-1.html 来源： oschina 链接： https://my.oschina.net/u/2963604/blog/3161105

今天在调试springboot mina 串口时出现：java.lang.AbstractMethodError 参考： https://blog.csdn.net/blomule/article/details/43058111 才发现可能我的mina-transport-serial-2.0.2.jar与RXTXcomm.jar可能版本不同 https://blog.csdn.net/concisefreedom/article/details/67085946 中说：comm2.0.jar，后来测试时后报错，报错内容是它并不支持64位系统 mina-transport-serial 官方maven: https://mvnrepository.com/artifact/org.apache.mina/mina-transport-serial 来源： oschina 链接： https://my.oschina.net/u/2963604/blog/3158019

还有相关的帖子： https://blog.csdn.net/m0_37619559/article/details/79504710 https://www.iteye.com/blog/wandejun1012-2065941 （有代码） https://blog.csdn.net/kkk0526/article/details/51732437 https://blog.csdn.net/hannuotayouxi/article/details/78685334 (服务端和客户端代码都有) 服务端代码 public class MyServer { /** 30秒后超时 */ private static final int IDELTIMEOUT = 30; /** 15秒发送一次心跳包 */ private static final int HEARTBEATRATE = 15; /** 心跳包内容 */ private static final String HEARTBEATREQUEST = "xixixi";//预设请求内容 private static final String HEARTBEATRESPONSE = "hahaha";//预设应答内容（记得客户端在接收到预设请求内容回复给服务端一定也是这个内容哦） public static void

mina的粘包拆包其实是蛮简单的，只是一开始没搞清楚原理。 我们要约定数据包的格式，我这里的是(4个字节长度+json的string字符串） 1：写一个 ProtocolCodecFactory类，用来拦截数据包处理 内容如下 public class MessageCodecFactory implements ProtocolCodecFactory { private final DataEncoderEx encoder; private final DataDecoderEx decoder; public MessageCodecFactory() { encoder = new DataEncoderEx(); decoder = new DataDecoderEx(); } /* (non-Javadoc) * @see org.apache.mina.filter.codec.ProtocolCodecFactory#getDecoder(org.apache.mina.core.session.IoSession) */ @Override public ProtocolDecoder getDecoder(IoSession session) throws Exception { return decoder; } /* (non-Javadoc) *

1) https://www.cnblogs.com/juepei/p/3940396.html 2)spring集成mina，包含心跳检测，实现服务端主动推送 https://blog.csdn.net/smile326/article/details/51912141 3) http://www.bieryun.com/1800.html?spm=a2c4e.10696291.0.0.623919a4LjmCBH 4) https://www.cnblogs.com/codeydt/p/5126220.html 5) https://www.iteye.com/blog/sillycat-563765 祥细(博主还有一篇 SAMBA的JAVA客户端JCIFS https://www.iteye.com/blog/sillycat-563766 ） 来源： oschina 链接： https://my.oschina.net/u/2963604/blog/3161392

Dubbo（2） 第一层：service 层，接口层，给服务提供者和消费者来实现的 该层是与实际业务逻辑相关的，根据服务提供方和服务消费方的业务设计对应的接口和实现。 第二层：config 层，配置层，主要是对 dubbo 进行各种配置的 配置层（Config）：对外配置接口，以ServiceConfig和ReferenceConfig为中心，可以直接new配置类，也可以通过spring解析配置生成配置类。 第三层：proxy 层，服务代理层，无论是 consumer 还是 provider，dubbo 都会给你生成代理，代理之间进行网络通信 服务代理层（Proxy）：服务接口透明代理，生成服务的客户端Stub和服务器端Skeleton，以ServiceProxy为中心，扩展接口为ProxyFactory。 第四层：registry 层，服务注册层，负责服务的注册与发现 服务注册层（Registry）：封装服务地址的注册与发现，以服务URL为中心，扩展接口为RegistryFactory、Registry和RegistryService。可能没有服务注册中心，此时服务提供方直接暴露服务。 第五层：cluster 层，集群层，封装多个服务提供者的路由以及负载均衡，将多个实例组合成一个服务 集群层（Cluster）：封装多个提供者的路由及负载均衡，并桥接注册中心，以Invoker为中心