最近在处理框架通讯方面的问题，通过积累的开发经验，其实在很多情况（尤其是实时大数据量），udp是占有很多优势的；不需要连接，只管发送，理论上要快很多;
另外在穿墙上占有很大优势；
但是最大的一个问题就是丢包；
很多时候我们会结合我们的业务来进行发送与回执，这样的方式应该的最好的；但是也意味着每次都得重来一次；因此花费了一些时间来写这个重发逻辑；当然目前仅是测试；
封装了一个udp重发；其实组播也可以直接使用，只是我还没有完成封装，原来一样，只不过组播封装重发，会浪费网络资源，只要一个节点（把一个接收位置看作一个节点）没有收到其中一个包，就需要发送端发送，所有节点都会接收（并不影响数据完整，在接收已经封装了接收发生，不会造成数据重复）；不说组播了，回到udp重发；
大体结构：
1.每一次发送都视为session；
1》judpclient为封装的发送端，发送数据时，会自动分包，按照udp65535大小（可以设置）；每次发送分配一个发送端session(同时产生id),每次发送分包时，都会依次产生
一个初始化序列号，按照初始序列号，每包设置一个id,按照此发送打包数据发送
2》同时会发送一个ack发送确认包，防止数据包只有一个被丢包；
3》发送后等待数据返回
4》judpclient关闭只是逻辑关闭
2.接收端
接收端按照来源IP,端口产生一个接收端session，然后接收数据，组织数据，检查丢包，发送丢包ack;
接收端设计了serversession及buffer,所以不用担心数据重发造成数据触发的问题，该结构读取方式已经直接避免了
3.辅助应用
因为是辅助，无法判断judpclient使用情况，所所以利用java特点，在回收对象时设置逻辑关闭；同时控制时间，来判断通讯真实关闭（因为发送端还要监听等待重发）
4.共享session
最开始的设计是不共享的，但是在测试时发现，在极端时候，因为发送端占有端口监听需要时间，重新初始化judpclient对象，会导致端口占用完，无法再分配；所以
最好采用了共用的方式，让多个judpclient实际使用一个真正的udp底层通讯；每个judpclient产生一个id,来判断数据接收时往哪里发送，触发哪个对象的方法；
5.缓存问题解决方式
数据重发就意味着发送的数据需要缓存下来，准备重新发送；这样如果发送大量数据，发送端就可能“爆满”，所以要减少内存使用；
处理方式：做一个简单的数据量统计（不精确，也不需要精确），当这个量达到一定值后，就把数据由内存转移到磁盘中；
我自己设计了一个文件保存方式（做了一个文件持久化层），来按照一定方式保存，也实现了文件删除，修改（修改没有必要）；
里面主要是有个索引维护；同时使用了内存数据库表（如果不实现文件修改是没有必要的，通过异步方式保证文件索引准确，又不影响使用效率）
最开始我没有使用文件，而是查找了数据库（paldb,fastdb,mapdb等等），但是效果不尽人意，通过磁盘，其实一般磁盘读取在30M/s,而数据库是做不到的；因此我直接采用了文件读取方式；我并不是要做一个文件数据库，所以在实现文件修改时，任然使用了第三方数据库h2,简单直接，索引使用足够了，而且是异步；在数据重发这里，文件修正是没有必要的，实现该功能只是想让模块更加完整而已；
文件保存，也是通过一个简单的计数，每次10M左右的数据一起写入文件；
当接收端数据接收完成后，会回复一个接收完成ack包，发送端解析信息后，会把接收完成的一次会话数据都删除掉；
使用数据库保存的最初代码我并没有删除，只是没有使用而已；
6.遗留问题（需要优化）
通过什么的构造，其实最大问题在于我无法控制judpclient的使用，这样会造成很多线程启动，在监听数据返回的信息（丢包，完成），这样造成大量线程存在，虽然应用了线程池
根据现在的测试，发送端cpu 15-35%都是有可能的；阻塞的线程也很多，一旦彻底完成发送，同时退出的线程同样多，但是感觉这样也没有影响测试使用（可能是我的java水平不过关，有的测试结果我感觉很怪）；所以需要缩减线程以及阻塞集合；
7.共享session分配
专门有个管理池分配，其实就是定一个最大个数，使用完了就再产生一个，同时监视是否共享session关闭情况
8.其它辅助实现
使用了guava的缓存及eventbus;
数据发送打包与解析配套（接收端也可以正常使用）
9.源码
eclipse编译；现在已经上传git;
地址：https://github.com/jinyuttt/jyudp.git
我也会上传到csdn,不过可能超过大小；