版权声明：本文为博主原创文章，转载请说明出处，谢谢。 https://blog.csdn.net/qq_27070443/article/details/61421258
前言：
虽然Mina框架很好的解决了粘包断包等问题，而且对于各种数据类型都很和蔼。但是对于一个热于研究原理的我来说，我更喜欢自己组织整体框架。
Socket
无论是Java还是C#，还是其他的语言。Receive(C#) 、 read(Java) 等这样的方法都是阻塞的，也就是说，如果没有数据，线程会一直等待，程序会在这暂停，直到有消息到来。
那什么是阻塞呢？
说句很和蔼的粗话：孙子骂了爷爷，爷爷等孙子来。孙子没来，爷爷还能走不成？
输入输出流
Java中最常见的InputStream和OutputStream,继而拓展出InputStreamBuffer和OutputStreamBuffer,当然还有DataInputStream和DataOutputStream，以及对象流ObjectInputStream和ObjectOutputStream.
IM即时通讯系统
即时也就是，“小王啊”---“在这呢”，类似人与人之间的对话形式。互联网给人类带来了物理层面的便捷，但是想要更为具体的信息主体，那么就要通过编程来实现这方面的需求了。
即时通讯真的可以做到实时同步么？
这个问题的答案是否。因为网络中存在如此庞大的数据流，每天的流量是不可计量的。所以数据的到达还是有一定的延迟性。就像微信抢红包，就算是自己发出去的红包，自己也不一定是第一个看见的人，等到自己看见红包之后，点开却提示已抢完。是不是内心有着千万种那个啥难以发泄？
粘包
那什么是粘包现象呢？当你发一个消息给你的小伙伴，你对他说“下午来我家”，然后又发了一句“什么游戏比较好玩”。但是你的小伙伴收到的消息却是"下午来我家什么游戏"，然后又收到“比较好玩”。可想而知粘包的严重性，小伙伴的内心一定的凌乱的，什么跟什么呀。
对于文本的粘包问题，从输出流写出的时候，每次记得flush，也就是刷新缓冲区。
但是如果单纯的是流的粘包问题，那么黏就让它粘吧，反正只是数据被分成了一块块的，每次读取的字节数不相同而已。
断包
数据被分成了好几块，接收不完整。传输“数据长度 + 数据”，然后flush，也就是刷新缓冲区，一般没有什么很大的问题。
最大上限
拿Java来说，Java数组的最大上限是2的31次幂，也就是2G，当要自定义一个通讯框架的时候，应该考虑好当超过2G的时候应该做些什么，是限制超过2G的数据，还是将超大的文件分割成若干份依次发送。
下一次开始实现一个最简单的文本即时通讯，主要的语言依然是Java。
为了更好的共同学习，我会很细心，代码也会很冗长。
当前的IM框架实现了即时文本通讯，文件传输，语音以及视频。当然bug依存，还有很多的问题需要解决。