基于VC++远程控制系统的设计含源文件.docx
《基于VC++远程控制系统的设计含源文件.docx》由会员分享，可在线阅读，更多相关《基于VC++远程控制系统的设计含源文件.docx（44页珍藏版）》请在冰豆网上搜索。
基于VC++远程控制系统的设计含源文件
毕业论文
论文题目基于C++远程控制系统的设计
系别信息工程学院
专业计算机科学与技术
班级
学号
学生姓名
指导教师（签名）
完成时间年月
摘要
随着计算机信息现代工业的发展，计算机远程控制管理系统越来越受到各方面的重视。
本文主要分析了远程控制系统的一些基本功能和组成情况，包括系统的需求分析、系统结构、功能模块划分分析等，重点对应用程序的实际开发实现作了介绍。
达到了实时性和安全性，且应用程序功能完备。
同时简单介绍了VisualC++6.0编程环境和WINSOCKET的功能特点。
本课题设计是为适应远程控制及协助的要求，使远程控制提高到计算机的实时水平而设计的。
远程控制包括多项内容，本课题设计只是承建了其中的一部分即：
实时控制。
本课题设计为一个通信应用程序，用到了多项技术，诸如：
异步模式socket、面向对象编程、软件工程思想、APIHOOK等。
本系统采用VisualC++6.0作为开发工具,整个系统操作简洁、界面友好、功能灵活、实用，实现了包括客户端屏幕监控、文件监控及传输、进程监控、系统服务和注册表监控等基本功能，基本完成了远程控制中所需要到的主要功能。
关键词：
套接字面向对象软件工程远程监控
TheresearchingandimplementoftheRemoteControlSystembasedonbyC++
Abstract
Alongwiththedevelopmentofthecalculatorinformationmodernindustry,theremotecontrolsystemismoreandmorevaluebybusinessenterpriseandschool.Thistextmainlyanalyzedsomebasicfunctionsoftheremotecontrolsystemandconstitutethecircumstance,includingtherequirementsanalysis,thestructureofthesystem,thefunctionmoldpiecedividethelineanalyzeetc,thepointmaketheintroductiontowardsapplyingtheactualdevelopmentoftheprocedurerealization.Cometotheconsistencyandsafetiesofthedata,andapplytheprocedurefunctioncomplete.ItwillintroducetheVisualC++6.0programmingenvironmentandthefeaturesoftheWINSOCKETatthesametime.
Thistopicdesignisinordertoadapttheremotecontrolrequest,maketheremoteassistancecarryonthelevelbydesignthatthemanagementraisesthecalculatorof.Remotecontrolincludesseveralcontents,thistopicdesignjustacceptedtosetupamongthemofonepartnamely:
Thereal-timecontrol.Thistopicusedanumberoftechniques,forexample:
Thesocketofasynchronousmode,Object-Oriented,SoftwareEngineering,APIHOOKetc.
ThissystemusesVisualC++6.0asadevelopmenttool,theoperationoftheentiresystemissimple,interfaceisuser-friendly,functionisflexibleandpractical,achievedthebasicfunctionsincludingscreenmonitoring,controlandtransferfiles,processmonitoring,systemservicesandregistrymonitoring,completethemainfunctionsofwhattheRemoteAssistancesystemneedtogo.
Keyword:
SocketObject-OrientedSoftware-EngineeringHookRemoteControl
第一章绪论
1.1课题背景
通常企业内部或者IT公司的客户技术支持部门都有技术支持业务，其任务是通过电话解答疑难问题，努力减少技术人员到现场服务或者让用户把设备送到支持中心进行维护。
这种技术支持方式尽管被普遍采用，但效率不高而且大大增加了技术支持成本。
通常，技术支持必须依赖技术人员和用户之间的口头交流来进行，这种交流既耗时又容易出错。
许多商业用户对计算机知之甚少，然而当遇到问题时，他们必须向技术人员提供故障情报及相关操作。
在尝试解决问题时，技术人员可能指导用户执行一系列复杂的过程，而这些过程对用户来说或许完全不熟悉；如果用户不能正确的按要求操作，反而使问题恶化。
此外，如果通过电话不能解决问题，那么在技术人员亲自到用户现场解决问题之前，计算机将无法继续使用，导致工作延误。
1.2目的以及意义
本文正是在上文提到的背景下提出的，目的就是为了解决计算机的远程操作，降低企业对软件的后期维护成本，设计出一款远程控制系统。
远程控制系统能使技术人员直接操作远程计算机，就像操作本地机器一样，无须用户介入，技术人员技能得到该机器的问题的第一手材料，从而加快了问题的解决。
实际上，使用远程控制工具的技术人员能够做到解答疑难问题，安装和配置软件，把软件下载到用户计算机上，配置应用程序和系统软件设置并可通过实际操作培训用户。
总之，本课题的设计与实现具有很大的现实意义。
第二章开发平台的理论基础
2.1MicrosoftVisualC++及编程模式简介
2.1.1VisualC++的简介
VisualC++的资源编辑器能以所见即所得（Whatyouseeiswhatyouget）的形式直接编辑程序的用户界面，为所有资源分配ID标识号。
ClassWizard能把对话框模板与生成的类定义或与已有的类代码连接起来，为菜单项、控制等资源生成空的处理函数模板，创建消息映射条目，并将资源ID与处理函数连接起来。
通过使用AppWizard，程序员的编程工作便简化为用资源编辑器直观的设计界面，完善对话框类代码，在空的处理函数模板处填写响应用户操作的代码，这是一种比较完善的可视化编程方法。
但产品名“VisualC++”也容易误导人，让人认为自己使用的是一个与MicrosoftVisualBasic类似的完全可视化的系统。
然而，使用VisualC++，开发人员必须真正地阅读和编写C++代码。
VisualC++向导可以节省时间和提高精度，但是，程序员也必须理解向导产生的代码，并且，最重要的是，还必须理解MFC库的结构和Windows操作系统的内部工作方式[7]。
2.1.2MFC（MicrosoftFoundationClasses）应用程序框架
应用程序框架的一种定义是：
提供一般应用程序需要的全部面向对象软件组件的集成集合。
C++流行的一个原因是它可以用类库扩充。
类库是可在应用程序中使用的有关C++类的集合。
应用程序框架是类库的超集。
一般的类库只是一种孤立的类的集合，用来嵌入在任何程序中，但是，应用程序框架却定义了程序的结构。
自从MFC库发布以来，MFC已经成为主要的Windows类库。
使用MFC类库构建应用程序具有以下优点：
1.MFC库是C++的MicrosoftWindowsAPI。
2.应用程序框架生成的应用程序使用了标准的结构，具有标准化的用户接口，这对具有标准用户界面的Win32程序来说，可以极大的减轻程序员的负担，使程序员不必过多地考虑界面，可把主要精力放在程序设计上，以提高程序设计的效率。
3.使用应用程序框架的应用程序不仅小，而且运行速度快，具有很大的灵活性。
MFC封装了Win32SDK中的几乎所有函数，能实现Win32系统的任何功能。
4.MFC框架降低了编码的复杂性。
5.MFC库应用程序框架有丰富的特性，如：
WindowsAPI的C++接口、通用的（非Windows所特有的）类、“共用根对象”类层次结构、流线式多文档界面（MDI）应用程序支持等。
6.强大的功能。
除封装了大部分的Win32SDK函数外，MFC还提供了应用程序本身的数据和操作及ActiveX、OLE、Internet、WinSock、DAO（DataAccessObjects）、ODBC（OpenDataBaseConnectivity）等操作类。
MFC框架的核心是文档/视图结构（Document-ViewArchitecture），这是一个很好用、但又往往较难以入门的功能。
简单的说，文档/视图结构就是将数据和对数据的观察或数据的表现（显示）相分离。
文档仅处理数据的实际读、写操作，视图则是显示和处理数据的窗口，视图可以操作文档中的数据[7]。
2.1.2MFC的消息映射
在使用VisualC++进行Win32程序设计时，消息映射是一个非常重要的概念。
Windows应用程序是消息驱动的，应用程序不能直接得到用户所做的操作，如鼠标按键、键盘输入和窗口移动等。
这些操作由操作系统管理，操作系统检测到操作事件后，便向相关的应用程序发送消息，应用程序响应这些消息来完成用户的操作。
1．消息
Windows中的消息是操作系统与应用程序之间、应用程序与应用程序之间、应用程序各对象之间相互控制与传递信息的方式。
消息的基本格式如下：
MessagewParamlParam
Message是消息名称；wParam是与消息相关的Word型参数；lParam是与消息相关的Long型参数。
消息主要有以下3类。
Windows系统消息：
Windows系统向窗口发送的消息，由窗口（Window）或视图（View）进行响应处理。
这类消息包括除WM_COMMAND消息之外的名称以WM_开始的其他消息。
控制通知消息：
控制或子窗口传给父窗口的WM_COMMAND通知的消息。
命令消息：
在响应用户接口操作时，将产生WM_COMMAND命令消息。
其参数指定了用户接口的标识号，如菜单项和按钮等ID号。
2．消息映射过程
在使用AppWizard创建应用程序时，MFC应用程序框架设置了相应的消息处理函数来响应消息，以完成相应的操作。
消息处理函数是某些类（通常是窗口类）的成员函数和程序员在其中编写响应消息时应进行操作的代码。
框架将消息和它们的处理函数连接起来就是消息映射。
消息映射使应用程序在接收到消息时调用对应的消息处理函数来响应和处理消息。
ClassWizard在创建新类时将为其创建一个消息映射，并为每个类能响应的消息和命令增加对应的处理函数。
在源代码中，消息映射开始于BEGIN_MESSAGE_MAP宏，结束于END_MESSAGE_MAP宏，中间由一系列预定义的被称为“条目宏”的宏组成。
其基本格式如下：
BEGIN_MESSAGE_MAP（classname,parentclassname）
//{{AFX_MSG_MAP（classname）
条目宏1
条目宏2
条目宏3
…………
//}}AFX_MSG_MAP
END_MESSAGE_MAP（）
其中classname为拥有消息映射的当前类名，parentclassname为当前类的父类名。
条目宏定义了类所处理的消息与其对应的函数。
常用的条目宏类型如表2.1所示。
表2.1消息映射条目宏
消息类型
宏格式
说明
Windows消息
ON_WM_XXXX
WM_XXXX为Windows消息名
命令
ON_COMMAND（ID,Function）
ID为命令标识号，Function为处理函数名
更新命令
ON_UPDATE_COMMAND_UI（ID,Function）
ID为命令标识号，Function为处理函数名
控制通知
ON_XXXX（ID,Function）
ID为控制标识号，Function为处理函数名
用户定义消息
ON_MESSAGE（ID,Function）
ID为消息标识号，Function为处理函数名
用户注册消息
ON_REGISTERED_MESSAGE（ID,Function）
ID为消息标识号，Function为处理函数名
Windows消息的处理函数在CWnd类中进行了预定义，类库以消息名为基础定义这些处理函数的名称，且MFC要求所有消息处理函数声明为afx_msg类型。
例如，消息WM_PAINT的处理函数在CWnd类中的声明如下：
afx_msgvoidOnPaint（）;
通过ClassWizard在派生类中用同样的原型定义处理函数并为该函数生成消息映射条目，然后由程序员编写处理函数代码，并在派生类中覆盖了其父类的消息处理函数。
在有些情况下，必须在派生类的消息处理函数中调用其父类的消息处理函数，使Windows和基类能对消息进行处理。
ClassWizard将在生成的处理函数中建议是否应调用父类的消息处理函数及调用的次序。
除此之外，用户定义和注册的消息、命令和控制通知都没有默认的处理函数，需要在定义时声明，一般根据其ID名称来为函数命名[7]。
2.2系统架构的模式
C/S结构，即Client/Server（客户机/服务器）结构，软件系统体系结构，通过将任务合理分配到Client端和Server端，降低了系统的通讯开销，可以充分利用两端硬件环境的优势。
2.2.1C/S模式即Client/Server结构模式
Client/Server结构，它的发展经历了两个阶段：
从两层结构到三层结构。
1.两层结构：
它由两部分构成：
前端是客户机，通常是PC，主要完成用户界面显示，接受数据输入，校验数据有效性，向后台数据库发请求，接受返回结果，处理应用逻辑；后端是服务器，运行DBMS，提供数据库的查询和管理。
应用逻辑主要在前端，如在后端则是存储过程的形式。
2.三层结构：
利用中间件将应用分为表示层、业务逻辑层和数据存储层三个不同的处理层次。
三个层次的划分是从逻辑上来分的，具体的物理分法可以有多种组合。
基于三层结构的应用系统不但具备了大型机系统稳定、安全和处理能力高等特性，同时拥有开放系统成本低、可扩展性强、开发周期短等优点。
而中间件作为构造三层结构应用系统的基础平台，提供了以下主要功能：
负责客户机与服务器间、服务器间与服务器间的联接和通讯；实现应用与数据库的高效连接；提供一个三层结构应用的开发、运行、部署和管理的平台。
2.2.2TCPC/S模式的通信原理
TCPClient/Server的通信原理如图2-1所示，服务器端首先监听一个固定端口，客户端再连接到服务端，此时服务端执行Accept操作，以接受客户端的连接。
此时连接创建成功，则进行数据传输，待数据传输完毕，服务端和客户端就断开连接。
断开Close（）
图2-1Client/Server的通信流程
2.2.3C/S结构的优点
Client/Server技术在目前程序开发中得到了广泛的应用，这种技术的优点在于它将处理工作按照一定的比例分配到客户端和服务器上去执行，这样减少了网络传输的工作量，从而合理地利用了资源，提高了应用程序开发的效率。
由于客户端实现与服务器的直接相连，没有中间环节，因此响应速度快。
2.3APIHOOK技术简介
Windows系统下的编程，消息Message的传递是贯穿其始终的。
这个消息可以简单理解为一个有特定意义的整数，正如老故事片中的“长江长江，我是黄河”一个含义。
Windows中定义的消息给初学者的印象似乎是“不计其数”的，常见的一部分消息在winuser.h头文件中定义。
Hook与消息有着非常密切的联系，它的中文含义是“钩子”，这样理解起来不难得出“Hook是消息处理中的一个环节，用于监控消息在系统中的传递，并在这些消息到达最终的消息处理过程前，处理某些特定的消息”。
这也是Hook分为不同种类的原因。
在Windows系统下编程，经常接触到API函数的使用，常用的API函数大概有2000个左右。
今天随着控件，STL等高效编程技术的出现，API的使用概率在普通的用户程序上就变得越来越小了。
当诸如控件这些现成的手段不能实现的功能时，因此还需要借助API。
最初有些人对某些API函数的功能不太满意，就产生了如何修改这些API，使之更好的服务于程序的想法，这样APIHook就自然而然的出现了。
通过APIHook，改变一个系统API的原有功能。
基本的方法就是通过Hook“接触”到需要修改的API函数入口点，改变它的地址指向新的自定义的函数。
APIHook并不属于MSDN上介绍的13类Hook中的任何一种。
所以说，APIHook并不是什么特别不同的Hook，它也需要通过基本的Hook提高自己的权限，跨越不同进程间访问的限制，达到修改API函数地址的目的。
2.4CAsyncSocket类的简单介绍
CAsyncSocket类是MFC对WINSOCKAPI的较底层封装，通过类名就知道这是一个异步非阻塞SOCKET类。
什么是异步非阻塞呢？
举个例子：
一位体育老师，需要测验100位同学的400米成绩。
老师每隔10秒让一位同学起跑，直到所有同学出发完毕；另一边每有一个同学回到终点就记录成绩，直到所有同学都跑完。
老师设计了两个函数，其中一个函数记录起跑时间和学生号，该函数会主动调用100次；另一个函数记录到达时间和学生号，该函数是一个事件驱动的callback函数，当有同学到达终点时，callback函数会被动调用。
老师主动调用的函数是异步的，因为调用它时，它并不会立刻返回；这个函数也是非阻塞的，因为一旦调用它，它就马上返回，不用等待就可以再次调用它。
这就是异步非阻塞模式。
然而，最不容易被初学Socket编程的人理解的，也是本课题最要提醒的一点是，客户方在使用CAsyncSocket:
:
Connect（）时，往往返回一个WSAEWOULDBLOCK的错误（其它的某些函数调用也如此，如：
Send（）,Receive（）等），实际上这不应该算作一个错误，它是Socket在提醒用户，由于使用了非阻塞Socket方式，所以（连接）操作需要时间，不能瞬间建立。
因此可以在程序中等待，等它连接成功为止，于是许多程序员就在调用Connect（）之后，Sleep（0），然后不停地用WSAGetLastError（）或者CAsyncSocket:
:
GetLastError（）查看Socket返回的错误，直到返回成功为止。
这是一种错误的做法，不能达到预期目的。
事实上，可以在Connect（）调用之后等待CAsyncSocket:
:
OnConnect（）事件被触发，CAsyncSocket:
:
OnConnect（）是要表明Socket要么连接成功了，要么连接彻底失败了。
第三章需求分析
3.1系统基本情况描述
随着计算机技术的不断发展，人们要处理的任务也越来越多，工作地点也有可能是多个，在计算机使用的过程中就会遇到这样那样的问题，从而使得工作变得更加繁重。
如果将计算机系统进行还原或重装，一些重要资料有可能将会丢失。
寻求一种方便、高效的方法对出现故障的系统进行修复已经成为人们的迫切需要。
本课题设计的使用，能帮助技术人员方便、高效的修复远程系统软件，提高人们的工作效率，降低系统维护的成本。
3.2系统可行性分析
可行性研究的任务不是具体解决问题，而是研究问题的范围，探索这个问题是否值得去解，是否有可行的方法。
可行性分析实质上是要进行一次大大压缩简化了的系统分析和设计的过程，也就是在较高层次上以较抽象的方式进行的系统分析和设计的过程。
要研究每一种解法的可行性，一般说来，应从经济可行性、技术可行性、操作可行性等方面研究可行性[12]。
3.2.1经济可行性
本课题设计成本低廉，要的只是两个ISP分发的IP地址，而且这也多用于局域网或企业网等内网，就更谈不上成本上的问题。
但是如果需要对程序的质量提高可以购买加密算法，对传输数据进行加密。
3.2.2技术可行性
本课题设计所用到的一系列的技术已是累积了几十年的技术，这些技术在这么多年的发展中并没有被淘汰，反而是越来越来热门。
当初远程协助这门技术在DOS时代就已经存在，只是受网络的制约，但是此时这门技术还是受网络技术制约着。
网络流量的问题是造成所有通信程序的不稳定性的罪魁祸首。
但是本课题设计在局域网中是完全能够实现的，而且也是专门为企业网内部所设计，因为数据信息没被加密，如果想走Internet，则需建立VPN。
3.2.3操作可行性
根据系统的操作是否简单易懂，是否为用户所接受，从操作的角度研究系统的可行性。
本课题设计操作简单，客户端安装后无需其它操作，服务端待客户端自动连接后，则可以对其屏幕、文件、注册表等进行操作，完全像操作本地机器一样简单。
综合以上三方面的可行性分析，本课题设计的操作是可行的。
3.3功能需求分析
功能需求是对软件系统的一项基本需求，这方面的需求指定系统必须提供的服务。
根据对一般的远程协助的调查了解，该系统应该至少包含以下几个功能：
1.服务端对客户端的屏幕监控。
远程协助系统就是要解决那些难以用语言描述的软件问题，协助端（服务端）如果能实时的看见被协助端（客户端）的系统桌面，那将大大提高解决问题的效率。
当然，为了更方便的操作，协助端还必须能控制被协助端的鼠标和键盘。
系统服务端桌面监控的用例图如图3-1所示：
远程协助系统
图3-1桌面监控用例图
2.服务端对客户端文件操作。
服务端如果仅仅能监控客户端桌面，那帮助也许没那么大，比如客户端要修复一些文件，而在客户端本地硬盘中又没有相应的修复工具，此时服务端也是无能为力的。
当然，可以通过QQ、MSN等通讯工具传输，这样做毕竟也是很麻烦的，因此服务端能实现对客户端的文件远程操作则是不可或缺的。
文件操作包括：
上传文件、下载文件、修改文件名、创建文件夹、执行远程程序等等。
该功能模块的用例图如图3-2所示：
执行远程程序
图3-2文件操作用例图
3.服务端对客户端的高级操作。
对于维护和修复一个系统，难免要与系统注册表、系统服务、进程打交道，在桌面监控功能中虽然能实现对这些功能的操作，但是毕竟受到网络带宽的限制，远程桌面图片传输较慢，实时性较低。
服务端向客户端发送一条命令，客户端针对该命令分别枚举出客户端的注册表、系统服务、进
升级会员 