对等网络图像传输软件设计

软件客户端部分主要完成对传输来的图像数据进行解压，并重新组合屏幕在本地计算机上显示；传输本机的鼠标和键盘信息给服务器端，并且具有信息提示和远程关机的功能。解决屏幕图像数据远程传输的关键在于对屏幕图像的数据的压缩与解压缩及屏幕图像的获取上。目前，主要追求在屏幕图像数据的压缩率及解压速度的提高，但这一方面的提高余地已非常有限。实际上屏幕图像的抓取与数据的压缩与解压缩一样重要，都将对屏幕图像的实时传输过程产生极其重要的影响。对计算机屏幕进行抓取也有许多种不同的方案：
第一种方案，传统的屏幕图像截取压缩传输，具体实现的思路如下:首先利用屏幕拷贝捕捉到当前整个屏幕的图像，然后在内存中保存为 BMP文件格式。在服务端进行压缩时，使用压缩算法对原始图像进行压缩、保存并且传输；在客户端解压缩时,使用压缩算法对被压缩的图像进行解压缩,还原为 BMP 格式的图像文件并随即显示出来。这是最原始的截取屏幕的方法，存在着许多局限性。传统的屏幕图像传输方法是定时截取整幅图像后压缩传输，这会消耗大量的主机资源和网络带宽，尤其在窄带环境下，该方法无法实现流畅的屏幕图像传输。
第二种方案，对屏幕图像的分块压缩传输，思路如下：事实上在计算机使用的大多数时间中，任一微小时间内屏幕图像仅发生局部改变，如果只对发生改变的图像进行传输，将能大大减少屏幕数据传输的流量。因此，借鉴MPEG 影像动态压缩的思路，对屏幕图像采用分块传输的方法，将屏幕图像划分为8×4 共32格，定时同前一时刻比较判断每块图像是否发生改变，仅仅对发生改变的屏幕图像块进行压缩和传输。由于只需要传输发生改变的图像数据，在进行远程控制或者监控时，控制端所显示的远端屏幕就能够得到较好的刷新速率，从而实现更好的交互。
4.3 服务器端模块设计
4.3.1 通信模块设计
软件在设计阶段考虑到图片的远程传输，且数据量大的特点，考虑采用效率较高的UDP协议传输图片数据。但在远程监控的要求下，需要准确传输鼠标键盘的消息，如传输命令和控制信息。这些消息对数据的要求较高的。为了获得对计算机的远程访问控制功能，不得不放弃UDP协议，而改用TCP协议传输数据。虽然这样可以保证传输命令和控制信息的准确性，但是确是以牺牲数据传输的高效性为代价。
服务器端程序运行时，需要完成一系列的任务。首先服务器创建一个Socket套接字，建立Socket之前，必须先对Socket进行初始化工作，使用WSAStartup()函数来初始化底层的Windows Sockets DLL。应用程序或DLL只能在一次成功的WSAStartup()之后才能进一步调用Windows Sockets API函数。程序在成功创建了套接字后,需要绑定（Bind）到约定端口上，然后侦听并等待连接。客户方也建立Socket，连接到服务器约定端口。当服务器侦听到有连接并判断允许时另外建立一个Socket，通过Accept函数与客户机连接起来。自此双方成功建立了连接，可以正常地发送（Send）和接收（Receive）消息。等待对话结束关闭Socket。整个过程如图4.3所示。
图 4.2 流式套接字系统调用时序图
服务器端采用多线程编程技术,对每一个连接到该服务器的客户机，以阻塞方式接受连接请求。因而服务器端可以同时接收多个客户端的连接，并且同时向它们传输屏幕图像数据并接受客户端的控制。客户端的连接虽然是以阻塞的方式，但因为是使一个线程函数处理每一个连接，所以用户在使用过程中并不会感到阻塞。
4.3.2 屏幕图像获取模块设计
在服务端可以将屏幕分格为一定数量的大小相等的矩形区域，根据矩形在屏幕上的位置参数，分别对每个区域的图像进行获取与压缩，然后将压缩后的数据添加到一个待发送的数据队列中去，添加完毕后传输。服务器端的执行步骤为:1) 抓取一个个矩形区域的屏幕图像;2)判断矩形区域图像是否改变;3) 对发生改变的矩形区域图像进行压缩，并放入发送队列;4) 跳转到第1 步。

图4.3 屏幕数据获取流程图
编程过程中，用下列的数据结构来存储每个网格区域图像的数据：
struct GdiDS //网格信息结构
{
int iGridX; // 网格X横坐标
int  iGridY; // 网格Y纵坐标
int  iWidth1; // 网格矩形区域左上角坐标
int  iWidth2; // 网格矩形区域右上角坐标
int  iHeight1;// 网格矩形区域左下角坐标
int  iHeight2;// 网格矩形区域右下角坐标
int  nColors;         // 设备无关位图(DIB)颜色表中的色彩的数目
DWORD dwBitMapHeader; // DIB信息头的字节数
DWORD dwLen;           // DIB 长度和起始坐标
DWORD dwCompress;      // 数据压缩类型
DWORD iStartPos;       // DIB数据的起始位
BITMAP DIBitmap;        // DIB结构
BITMAPINFOHEADER BMIH; // DIB 信息头
LPBITMAPINFOHEADER lpBMIH; // DIB信息头的指针
HDC  hMemDC;           // 区域的设备句柄HDC
HBITMAP hDIBitmap;    // 区域的位图句柄
char *pDIB;      // 无压缩的DIB区域指针
char *pDIBCompress;   // 指向压缩区域的DIB指针
char *pDIBitmap;     // 指向全局区域的DIB指针
char *pDIBChange;    // 指向区域DIB的变化的指针
char *pDIBChangeStart;   // DIB变化区域开始位置指针
BOOL fDIBitmap;     // DIB标志是否存在
BOOL fChange;      // 区域位图数据变化标志
};
struct GdiList //网格区域信息结构链表
{
struct GdiDS Gdi; //网格区域信息结构
struct GdiList *pNext; //指向下一个链表结点指针
};
初始化网格信息，在这过程中，结点链表存储了屏幕网格区域的属性信息，通过网格的结构成员信息，为每个网格区域创建设备描述表，并根据设备描述表获取相关位图数据信息，通过struct GdiList *Add_Gdi(struct GdiList *pNode,struct GdiDS Gdi)函数，将位图数据信息存入一个结构链表中，直到把整个屏幕的位图数据全部存入。
4.3.3 图像数据更新的判断
要对发生改变的屏幕图像进行压缩传输，前提是需对图像是否发生改变进行判断。截取的图像实际上是一块内存数据，所以只需要对前后2 块图像的数据进行比较，如果相同，则表示图像没有改变，反之亦然。对于数据的比较有两种办法可供选择：
1) 调用C++语言的memcmp() 函数进行比较。对前后2 幅屏幕的内存数据逐个字节进行比较。此方法需保存两份屏幕数据拷贝，当分辨率为1024×768，24 位色时，一幅图像所需内存空间为2.25Mb。对于每一个网格区域，需要频繁的调用该函数，实现数据比较。
2）使用汇编程序对内存中数据每4个字节进行比较。比较时需要跳过位图的头部，因为位图头部的数据在通行进行时，已经进行了定义，所有的位图头部数据是一样的。显然，使用汇编程序直接操作内存，效率要比调用高级函数要高。另外在数据判断和压缩的顺序选择方面，考虑到屏幕数据在没有发生改变的情况下，先进行压缩再判断，虽然可以提高判断的效率，但是进行压缩将占用主机资源。综合考虑，采取先对图像原始数据先进行比较，再对改变的图像数据进行压缩的方式。实现代码如下：
// 比较区域DIB之前和之后的变化
if (pGdiNode->Gdi.fDIBitmap)
{
  dwLen1 = pGdiNode->Gdi.dwLen;
  dwBitMapHeader1 = pGdiNode->Gdi.dwBitMapHeader;
  pDIBitmap1 = pGdiNode->Gdi.pDIBitmap;
  pDIB1 = pGdiNode->Gdi.pDIB;
  fChange1 = pGdiNode->Gdi.fChange;
  // 每次4个字节的比较两副位图,跳过位图的头部

首页上一页 1 2 3 4 5 下一页尾页 3/5/5

对等网络图像传输软件设计(三)