UDP远程监控系统

你好！ 因为不熟悉你们项目的具体运用环境，实际需求，所以我也就不好给你们讲开发过程中具体的技术细节等内容。权且写下这个文档，当做是自己对UDP远程监控系统开发的一个回顾和反思吧。 初衷 我的初衷是开发一个类似于腾讯QQ的远程协助、微软的远程求助、灰鸽子的远程控制的系统，两台机器间能通过网络实现互相，服务器端能向客户端传送自己的桌面图片。客户端能远程控制服务器端的机器。 最初实现方式 两台机器通过基于TCP的SOCKET建立链接，链接成功后，服务器端按20帧(每50MS)启动一个发送桌面图片的线程向客户端发送自己的桌面图片。客户端接收服务器端发送过来的信息，解析出图片，显示在相应组建上。客户端在相应组建上监听本地的鼠标、键盘事件，将监听到的操作命令封装后发给服务器端。服务器端接收客户端传送过来的信息，解析出对应的操作命令，通过ROBOT对象驱动该操作来实现对服务器端的控制。 至此，一个简单的远程监控系统已经完成。 拓展 基本的功能实现后，我发现在以下几种情况下，这个基于TCP的远程监控系统就显得有些力不从心了。 一． 当需要连接到服务器的用户数很多时，比如一个简单的网络教室系统，这时候对建立了TCP连接的用户一个一个的发送数据的速度是不能容忍的，而如果用UDP，只需要向一个组播地址中发一次消息，让路由器去广播即可。 二． 在某些对通信实时性要求比较强，而能容许一定程度的失帧的条件下，比如网络会议，网络直播等等情况。TCP协议的三次握手，差错重组等等就显得太笨拙了，而用UDP则能很好的实现。 三． 在广域网运用的实际情况中，很多用户可能都是在内网中通过路由利用NAT技术共享上网的，通过TCP协议是没办法实现互联的，而通过UDP则能很好的“打洞”来穿透内网。   综上，我们可以简单的小结下在这个远程监控系统中，利用TCP协议和UDP协议的优劣 模式 TCP UDP TCP+UDP 适用场景及特点 1.可靠的连接，能确保消息接收的完整性 2.少数用户连接时，保证传输图片质量 3.广域网中使用非常方便  1.连入用户很多时，通过组播大大减少服务器负担 2.实时性要求不高时，减轻网络负担 3．广域网中使用时可以穿透内网 1.UDP传输可靠性要求不高的数据，比如桌面图片，TCP传说可靠性要求高的数组，比如操作指令 问 关于网络协议的简单阐述已经完了，现在简单讲讲基于UDP协议相对TCP来说会遇到的一些问题。 首先，UDP协议不再像TCP协议那样在发送大块数据时能够自己把数据打包，到了客户端接收后再重组，而是统一用一个IP数据包来发送，而一个IP数据报最大长度为16位，也就是64KB,即用UDP传播时，一个数据包最大的长度只能小于等于64KB。 而在我的这个远程监控系统中，一张屏幕截图图片大小大概在200KB左右，通过GIF压缩得到的图片大小在95KB上下，即使使用有损压缩成JPG，在能接受的清晰度的情况下，大小一般都还是大于90KB。 要想利用UDP来传送数据，只能把数据大小压缩成小于64KB。因此，很有必要对图片进行压缩。本人不才，研究了半个月，还是没有很好的解决办法。感觉比较靠谱的方法是利用JPG压缩算法，只是压缩时使用的量化根据人眼的视觉特性、再结合屏幕图像特性，自己写一个量化表，看有没有可能在比较好的清晰度下达到64KB，不过研究半个月后觉得不合适，最后放弃了。 另外一个解决办法，把普通的通过GIF压缩后的图片数据，分割为小于64KB的几个数据包后再发送，客户端则对接收到的数据进行重组，还原原数据，生成图片。 又因为UDP是不可靠的链接，每个包都有丢失的风险，因此，一个数据组分的包越多，最后组合成功的可能性就越小。如果在UDP中模拟引入类似TCP的差错控制机制的，虽然能较好的解决丢包问题，但是重发和等待的时间将大大降低系统的实时性，因此放弃这种考虑。 同样基于实时性的考虑，在客户端用一个缓冲区来接收数据，如果一个数据的一个包到了，后面的几个包在固定时间（比如5秒）还未到，则丢弃则数据组分出的所有包。 经过如此处理后，基于UDP的远程监控系统已经能实现了，后面涉及到的关于多线程中CPU时钟分配导致实时性不强的,应用NIO解决等等细节，恕在此不再详述了。 因为只是自己关于项目的一个大致回顾和反思，也就只是框架性的想到什么说什么了，并没有很详细的技术，也没有项目的、流程图等等详细内容。还望见谅。