UDP远程监控系统

你好！

因为不熟悉你们项目的具体运用环境，实际需求，所以我也就不好给你们讲开发过程中具体的技术细节等内容。权且写下这个文档，当做是自己对UDP远程监控系统开发的一个回顾和反思吧。

初衷

我的初衷是开发一个类似于腾讯QQ的远程协助、微软的远程求助、灰鸽子的远程控制的系统，两台机器间能通过网络实现互相，服务器端能向客户端传送自己的桌面图片。客户端能远程控制服务器端的机器。

最初实现方式

两台机器通过基于TCP的SOCKET建立链接，链接成功后，服务器端按20帧(每50MS)启动一个发送桌面图片的线程向客户端发送自己的桌面图片。客户端接收服务器端发送过来的信息，解析出图片，显示在相应组建上。客户端在相应组建上监听本地的鼠标、键盘事件，将监听到的操作命令封装后发给服务器端。服务器端接收客户端传送过来的信息，解析出对应的操作命令，通过ROBOT对象驱动该操作来实现对服务器端的控制。

至此，一个简单的远程监控系统已经完成。

拓展

基本的功能实现后，我发现在以下几种情况下，这个基于TCP协议的远程监控系统就显得有些力不从心了。

一．当需要连接到服务器的用户数很多时，比如一个简单的网络教室系统，这时候对建立了TCP连接的用户一个一个的发送数据的速度是不能容忍的，而如果用

UDP，只需要向一个组播地址中发一次消息，让路由器去广播即可。

二．在某些对通信实时性要求比较强，而能容许一定程度的失帧的条件下，比如网络会议，网络直播等等情况。TCP协议的三次握手，差错重组等等就显得太笨

拙了，而用UDP则能很好的实现。

三．在广域网运用的实际情况中，很多用户可能都是在内网中通过路由利用NAT 技术共享上网的，通过TCP协议是没办法实现互联的，而通过UDP则能很好

的“打洞”来穿透内网。

问题

关于网络协议的简单阐述已经完了，现在简单讲讲基于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解决等等细节，恕在此不再详述了。

因为只是自己关于项目的一个大致回顾和反思，也就只是框架性的想到什么说什么了，并没有很详细的技术，也没有项目的设计书、流程图等等详细内容。还望见谅。