【目录】
远程桌面控制的产品已经有很多很多，我做此项目的初衷并不是要开发出一个商用的产品，只是出于兴趣爱好，做一个开源的项目，之前也没有阅读过任何远程桌面控制的项目源码，只是根据自己已有的经验设计开发，肯定有许多不足，有兴趣的朋友可以留言讨论与支持。
初现端倪一般需要远程控制的场景发生在公司和家之间，由于公司和家里的电脑一般都在局域网内，所以不能直接相连，需要第三方中转，所以至少有三方,如下图。
负责中转的第三方是服务器，控制端和傀儡端(被控制端)相对于服务器来说都是客户端，都和服务器直接相连，也就是说控制端不和傀儡端相连。
款款深入约定:
控制端M(Master)
服务器S(Server)
傀儡端P(Puppet)
为了叙述方便,以下如不做特别说明,M表示控制端,S表示服务端,P表示傀儡端。
如果要达到控制傀儡的目的，应该怎么做呢？三方之间至少要发生什么交互呢？
控制端、傀儡端的接收器和服务器中的转发器都是一个，为便于流程的清晰，分开画了。
责任细分
可以看出三者交互主要通过命令形式(命令可以带数据也可以不带数据)，发送、转发、接收命令，然后做出相应的动作。
从上图中看到，服务端不仅需要转数据，还需要记录存活的傀儡以及维护控制端和傀儡之间的关系，其实还得处理一些异常情况，比如远程过程中，傀儡断开，过一会又连接上，傀儡是否需要继续给控制端发送屏幕截图。
粗粒度分一下，可以分为三层：Desktop层负责UI处理，CommandHandler层负责命令处理,Netty网络层负责数据的网络传输。
具体来看一下commandHandler层：
CommandHandlerLoader工具类会根据Netty或Desktop层传入的Command到配置文件commandhandlers中查找对应的处理类，动态加载，然后进行逻辑处理，这样对于后期命令添加是非常方便的，命令与命令之间，以及命令与Netty/Deskto之间解耦。
项目结构
这个项目一共有四个子模块:
server: 服务端
puppet: 傀儡端
master 控制端
common: 前面三者共用的一些类或接口。
各个子模块的包结构类似，我们看其中的一个子模块puppet即可。
commandhandler 命令处理器
constants 常量类，包括配置参数常量、异常消息常量、和消息常量
exception 自定义的一些业务异常类
netty Netty网络通信的相关类
ui 界面操作的相关类
PuppetStarter 启动器类
Resources/commandhandlers 命令对应的处理器配置文件
关键类设计
下面来看一下关键几个类的设计:
请求/响应类 Invocation public class Invocation implements Serializable { /** * ID(客户端标识(控制端为'M',傀儡端为'P')+MAC地址+序列号) */ private String id; /** * 傀儡名 */ private String puppetName; /** * 命令 */ private Enum<Commands> command; /** * 值 */ private Object value; //省略getter、setter方法 @Override public String toString() { return "Response{" + "requestId='" + requestId + '\'' + ", puppetName='" + puppetName + '\'' + ", command=" + command + ", value=" + value + '}'; } }其中id的作用有两点：
用于标识是来自M的请求，还是P的请求。
用于标识一次请求或响应，可以将M和P串联起来，用于请求追踪。