Linux下CS模式数据查询的UDP实现.docVIP

Linux下C/S模式数据查询的UDP实现 摘要 伴随着VOD视频点播技术的在KTV等娱乐场所的广泛应用，与之配套的管理系统也被推上了快速发展的轨道，通过这些系统人们可以对这些场所进行统一的管理，在方便顾客的同时也提高其自身的管理水平。目前视频点播系统主要以专用局域网络为主，在这样的网络结构中，要实现若干点播端与服务器之间大量数据的实时交互，C/S模式无疑为一种非常合适的实现模式，本文将详细阐述Linux下C/S模式数据查询的一种UDP实现方式。 关键词 Linux C/S模式 数据查询 UDP 三层模型 正文 一、概述 在早期的KTV系统中，我们在机顶盒端仅可以做一些比如点播歌曲、调节歌曲和麦克风音量、切歌、重唱等这些最基本的点歌操作，应该说在功能上比较单一。而随着KTV娱乐场所运营模式的改变和KTV相关技术的进步，在原来机顶盒点播系统的基础上，许多与之配套的管理系统也快速的发展了起来，正是这些配套管理系统的出现，才使得我们今天的机顶盒在功能上变得越来越强大，而酒水管理系统就是在这些配套管理系统中的一个典型代表。在KTV娱乐场所，通过机顶盒我们不仅可以直接对所在消费场所提供的酒水分类、酒水明细、消费账单等进行实时的查询，还可以进行酒水的点单、呼叫服务员等操作，而在场的场所管理人员则可以通过机顶盒直接进行退单、账单打折等操作，这在方便客户的同时也极大提高了场所的管理水平。而所有的这些操作都是通过机顶盒与后台的酒水管理系统的配合工作来实现的，两个系统之间采用了客户端与服务端的实现模式（即C/S模式），其中酒水管理系统为服务端，机顶盒为客户端，所有操作均由客户端发起，由服务端回应，这种工作方式就是我们在本文中要讲述的C/S模式数据查询。 二、传输协议选择 在KTV系统中应该说歌曲点播功能是其最主要的一项功能，当然音视频流的网络传输优先级也就最高，所以如果要进行音视频流之外的其他数据流的传输，则必须在保证不影响音视频网络传输的前提下进行，才能保证歌曲的点播功能不受影响。而目前在机顶盒端实现的酒水分类、酒水明细、消费账单等信息的实时查询操作由于传输数据量大、查询频繁，如果使用TCP协议进行传输的话，由于TCP协议本身是一种有连接的协议，相对于UDP协议而言系统开销大、传输速度慢，而TCP协议本身也存在有数据粘连等问题，从最大可能的减小查询数据流网络传输对音视频流网络传输的影响和降低软件的开发设计难度两方面考虑，这里我们将选择了系统开销小、传输速度快的UDP协议作为我们C/S模式数据查询的通信协议，并在使用中加入了适当的传输控制。 三、通信模型结构图 图1 模型结构图 在本文中我们将采用如上图所示的模型结构图所描述的模型来实现C/S模式数据查询的UDP实现，该模型共分为三层，从内向外依次为UDP套接字层（CUdpSocket）、UDP客户端层（CUdpClient）、UDP代理层（CUdpProxy），下面将对这三层的功能做一下大致说明： 1、UDP套接字层：该层在套接字的基础上实现了对数据发送接口的封装，并创建了独立接受线程负责对数据的实时接受。 2、UDP客户端层：该层以UDP套接字层为基础，实现了对单次查询数据发送和接受过程的封装以及对收包数据的分析。 3、UDP代理层：该层以UDP客户端层为基础，实现了对整个查询过程即若干单次查询的进一步封装。 四、对应类实现结构图 图2 对应类实现结构图 在该类实现结构图中，分别对三层模型所对应的CUdpSocket、CUdpClient、CUdpProxy类的主要成员变量、接口以及各个类之间的调用关系等进行了说明，在后面的程序具体实现中上述模型结构图及该类实现结构图，对整个模型的工作原理和调用流程做详细说明。 五、具体程序实现 1、启动服务 在模型启动之前首先要启动服务，也就是调用CUdpProxy类的StartService()接口，下面我们来看一下CudpProxy类StartService()接口的具体实现： int CUdpProxy::StartService() { //初始化收发包对pthread_cond_t数组 if (this-InitPackThreadCondArray() = 0) { return -1; } //创建CudpClient实例 m_pUdpClient = new CUdpClient(); if (NULL == m_pUdpClient) { return -2; } //Udp客户端启动服务 if (0 != m_pUdpClient-StartService (192.168.0.100, 5600, 8400, CUdpProxy::PackCondCallba