基于C远程控制系统的设计毕业论文.docx
- 文档编号:27344302
- 上传时间:2023-06-29
- 格式:DOCX
- 页数:54
- 大小:782.03KB
基于C远程控制系统的设计毕业论文.docx
《基于C远程控制系统的设计毕业论文.docx》由会员分享,可在线阅读,更多相关《基于C远程控制系统的设计毕业论文.docx(54页珍藏版)》请在冰豆网上搜索。
基于C远程控制系统的设计毕业论文
基于C++远程控制系统的设计毕业论文
第一章绪论1
1.1课题背景1
1.2目的以及意义1
第二章开发平台的理论基础2
2.1MicrosoftVisualC++及编程模式简介2
2.2系统架构的模式5
2.3APIHOOK技术简介6
2.4CAsyncSocket类的简单介绍7
第三章需求分析9
3.1系统基本情况描述9
3.2系统可行性分析9
3.3功能需求分析10
3.4系统流程图12
第四章总体设计13
4.1使用工具13
4.2系统模块的设计13
第五章系统详细设计17
5.1客户端与服务器连接设计17
5.2系统各模块界面设计及其实现18
第六章系统测试32
6.1软件测试基础32
6.2本系统采用的测试方法32
第七章总结35
参考文献36
附录37
致谢44
第一章绪论
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操作,以接受客户端的连接。
此时连接创建成功,则进行数据传输,待数据传输完毕,服务端和客户端就断开连接。
图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.服务端对客户端的高级操作。
对于维护和修复一个系统,难免要与系统注册表、系统服务、进程打交道,在桌面监控功能中虽然能实现对这些功能的操作,但是毕竟受到网络带宽的限制,远程桌面图片传输较慢,实时性较低。
服务端向客户端发送一条命令,客户端针对该命令分别枚举出客户端的注册表、系统服务、进程等,再以文本方式发送给服务端,服务端获取到信息后,则可以对注册表、系统服务、进程做删除、添加、结束等操作。
4.消息广播。
服务端可以同时被多个客户端连接,消息广播则合适企业或学校的管理。
在该功能中,服务端有权限阻止客户端发送的广播消息,也有权限向某一客户端发送消息。
5.自动上线。
自动上线其实就是一种反弹式连接,该功能只需应用在服务端IP是动态的情况下。
服务端首先要拥有一个动态域名,假设为:
myweb.,然后将此时服务端的IP更新到一个页面中,如:
myweb./ip.html,客户端则不断去访问该页面,以便获取服务端最新的IP,然后连接到服务端。
6.进程守护。
对于企业或学校的多客户端连接,为了能使得管理顺利进行,则需对客户端进程进行保护,防止被恶意结束。
3.4系统流程图
安装好客户端后,客户端则会不断的尝试连接服务器,连接成功了就会根据服务端发送的操作命令执行不同的操作,再将结果返回给服务端,本系统流程图如图3-3所示:
图3-3系统流程图
第四章总体设计
经过需求分析阶段,在软件需求分析阶段已经弄清楚了各种需求,较好地解决了所开发的系统“做什么”的问题,并已在软件需求说明书和数据要求说明书中详尽和充分地阐明了这些需求以后,下一步就要着手对软件系统的结构、数据结构、用户界面等进行设计。
4.1使用工具
本系统采用VisualC++6.0作为开发工具,客户端调试使用VMwarePlayer虚拟机。
4.2系统模块的设计
4.2.1模块设计
本系统面向的对象有两种,一种是服务端,一种是客户端。
服务端只要是向客户端发送操作命令,客户端解析命令后执行相应操作,然后将结果返回给服务端,服务端再将结果显示出来。
4.2.2屏幕监控模块设计
屏幕监控,也就是将客户端的屏幕截图,然后发送给服务端。
由于截图图片格式为BMP,一帧图像数据量很大,因此在此模块中引用第三方开源类库CxImage,和压缩库zlib,将截图在存中压缩成JPEG格式,然后再调用zlib的压缩函数进一步对JPEG压缩,最后再发送给服务端。
鼠标和键盘的操作则是通过模拟来实现,在服务端捕获鼠标键盘操作后,服务端的命令连接就会将捕获的结果发送到客户端,客户端再通过调用mouse_event和keybd_event这两个API函数进行模拟鼠标键盘操作。
该模块大致流程图如图4-1所示:
图4-1屏幕监控大致流程图
4.2.3文件操作模块设计
文件操作,包括文件上传、文件下载、删除文件、修改文件名、执行远程程序。
在文件传输过程中,服务端能显示传输进度,也可以终止传输。
该模块大致流程图如图4-2所示:
图4-2文件操作大致流程图
4.2.4命令操作模块设计
命令操作,包括系统注册表、服务、进程、消息广播、执行CMD、重启或关闭远程计算机等操作,命令操作传输的数据量小,响应快。
为了客户端程序能正常对进程、服务等操作,还必须对客户端进程进行提升权限操作。
该模块的功能模块图如图4-3所示:
图4-3命令操作功能模块图
4.2.5HTTP/FTP服务器模块设计
对于使用自动上线的用户来说,如果系统包含HTTP/FTP服务器的话就会比较方便,因此在该远程协助系统中,嵌入了简单的HTTP和FTP服务器,用户可以借助这两个服务器,将服务端的IP更新到动态域名的某个文件中,使得客户端能够自动上线。
4.2.6APIHOOK模块设计
本系统采用APIHOOK技术对客户端进程进行守护,达到防止客户端进程被恶意结束的目的。
该功能采用了微软的开源类库detours,对OpenProcess和TerminateProcess这两个系统API进行HOOK,从而实现对客户端进程进行守护的目的。
第五章系统详细设计
根据系统的主要功能及上一章的总体设计,系统进入详细设计阶段。
详细设计阶段的根本目标是确定应该怎样具体地实现所要求的系统,经过这个阶段的设计工作,得出对目标系统的精确描述。
由于代码较多,本章在说明部分功能时,只介绍了相关的函数和某些关键的代码语句。
5.1客户端与服务器连接设计
CAsyncSocket重载了SOCKET连接和断开的消息事件,用户可以在这些事件中判断SOCKET的连接情况,但是断开消息事件在一种情况下无法触发,也就是网线被拔掉或其中一方断电时,为了解决这种情况,可以在服务端和客户端中都添加一个连接时钟,周期性的给对方发送一个心跳包,如果发送失败则表示对方已
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 基于 远程 控制系统 设计 毕业论文