車站車票管理系統(tǒng)

摘 要隨著當今社會信息技術的高速發(fā)展，計算機技術在交通方面的應用更加明顯，尤其是在車站的管理系統(tǒng)的應用。通過不同地點的客戶端訪問票務中心的服務器，實現(xiàn)全國車票的統(tǒng)一管理。本文根據(jù)具體的車站管理以及票務管理，運用基于IOCP（完成端口）模型實現(xiàn)的模擬車站管理系統(tǒng)，通過VC+ 6.0編譯器和SQL Server 2000數(shù)據(jù)庫管理系統(tǒng)，模擬車站管理系統(tǒng)的功能特點、程序的編寫和編譯過程，給出了系統(tǒng)的需求分析、設計與實現(xiàn)，從售票、訂票，退票，查詢票信息、車輛調(diào)度、設置等多方面對系統(tǒng)做了設計與分析。售票員管理售票，訂票等票務服務，車輛調(diào)度員實現(xiàn)對車輛的調(diào)度管理，普通客戶對票的查詢。經(jīng)測試，系統(tǒng)運行穩(wěn)定，能基本滿足車站對系統(tǒng)在功能和性能上的需求。關鍵字：車站管理系統(tǒng)，數(shù)據(jù)庫管理系統(tǒng)，套接字，完成端口模型，多線程AbstractAlong with the rapid development of modern information technology, the computer technology is more obvious in the transportation aspects application，especially in management system management systems application。Visits the ticket clerk center through the different places client side server，realizes the national ticket global administration。Manage according to the concrete station management as well as the ticket clerk ，utilization simulation station management system management system which (Complete Port) the model realizes based on IOCP , through the VC+ 6.0 compilers and SQL Server 2000 database management system , simulates the station management system management systems function characteristic , procedure compilation and compilation process, has given systems demand analysis, the design with realizes, from the booking, the order form, return a ticket, the inquiry ticket information, the vehicles dispatch, the establishment and so on multi-aspects have made the design and the analysis to the system. The ticket seller manages the booking, orders ticket and so on ticket clerks to serve, the dispatcher realizes to vehicles dispatch management, ordinary customer to ticket inquiry. After the test, the systems operation is stable, can satisfy the station basically to the system in the function and the performance demand.Keywords：Station management system management system, DBMS, Socket, Complete port，Multithreading44摘 要IAbstractII1 緒 論1.1 課題背景31.2課題研究目的和意義31.3 開發(fā)目標42 可行性研究2.1經(jīng)濟可行性52.2技術可行性52.3操作可行性53需求分析3.1任務概述63.2功能需求分析63.2.1系統(tǒng)管理63.2.2調(diào)度管理63.2.3票務管理73.3 數(shù)據(jù)流圖84概要設計4.1 系統(tǒng)整體框架設計104.2系統(tǒng)流程圖104.3 系統(tǒng)用例114.4售票訂票流程圖124.5活動圖134.6序列圖155詳細設計5.1服務器設計165.1.1線程模型。165.1.2 SOCK模型175.1.3通信數(shù)據(jù)幀格式和粘連包處理215.2客戶端程序設計285.3客戶端未來展望29六 數(shù)據(jù)庫設計6.1數(shù)據(jù)庫概念設計316.2 數(shù)據(jù)庫的邏輯設計336.3 數(shù)據(jù)庫的實現(xiàn)336.4數(shù)據(jù)庫訪問356.4.1數(shù)據(jù)庫訪問技術簡介356.4.2數(shù)據(jù)庫訪問技術比較36七 系統(tǒng)結(jié)果分析7.1 服務器啟動界面397.2 登陸窗口397.3 售票397.4車票查詢407.5退票查詢418總結(jié)與展望429致 謝43參考文獻44 1 緒 論1.1 課題背景在當今社會，計算機占據(jù)了非常重要的位置，這些大部分都是通過使用軟件而提高生產(chǎn)、管理效率來體現(xiàn)的。本文研究的火車站售票系統(tǒng)正好就是這樣性質(zhì)的一個軟件。鐵路運輸一直都是我國重要的經(jīng)濟命脈，而且由于我國是內(nèi)陸國家，這鐵路運輸?shù)囊饬x就顯得更加突出了，對于這樣重要的一件事，當然需要良好的管理了。經(jīng)過幾十年的發(fā)展，事實早就證明了使用計算機軟件來輔助自己比單純的人工處理手段高明的多，在這樣的背景下，研究這樣的課題的意義也就不言而喻了。在以前，像售票這樣的事，都是人工處理的，人工處理的缺點是顯而易見的，成本大、處理的速度慢、出錯的幾率比較大，效率是很低的?，F(xiàn)在，在世界各國，火車售票使用的基本上都是員工操作計算機的模式，在這里，計算機主要是借助軟件用來存儲、更新數(shù)據(jù)的，并有統(tǒng)計帳目的功能。嚴格的說，這并不是智能化，但是，這樣的處理模式比已往的人工處理的好處顯然還是很明顯的，所有的數(shù)據(jù)都由數(shù)據(jù)庫管理，可以隨時動態(tài)的提取、存儲數(shù)據(jù)，并可以將修改后的數(shù)據(jù)覆蓋掉原有的數(shù)據(jù)。所以，開發(fā)火車站售票系統(tǒng)軟件是很有意義、有必要的。1.2課題研究目的和意義(1)研究目的為了應對交通運輸行業(yè)的迅猛發(fā)展，尤其是火車運輸業(yè)的發(fā)展和適應實名制后顧客買票的問題，針對不同類型不同規(guī)模的售票點，開發(fā)實時，高效，智能的火車票售票系統(tǒng)顯得尤為重要。本次系統(tǒng)就是在實際考察火車站售票過程在實踐調(diào)查情況下提出的，旨在模擬現(xiàn)有的火車站工作流程并且加入新的功能，做到實時，安全，廣泛。目前全國火車售票系統(tǒng)已日趨完善，并且已經(jīng)對實名制進行了改進，但是客戶自主購買車票和預訂車票問題并不理想，由于網(wǎng)頁響應速度慢，所以我想將此系統(tǒng)做成C/S工作模式，運用visual C +開發(fā)工具開發(fā)出實時的售票系統(tǒng)，以滿足客戶自主買票的需求。(2)研究意義火車站市場的管理和規(guī)范問題，是困擾我們多年的一個老問題，也是政府管理中的一個難點，訂票是客運業(yè)務中的一個最基本的業(yè)務，表面上看，它只是火車站業(yè)務的一個簡單的部分，但是它涉及到管理與客戶服務等多方面，因此，過去傳統(tǒng)的售票方式已經(jīng)不能滿足現(xiàn)代客運業(yè)務流量劇增的客觀要求，這就要求一種全新的訂票方式網(wǎng)上訂票，來緩解訂票高峰時期的客運壓力，并為用戶提供方便快捷的訂票服務。本次設計便是利用開發(fā)工具Visual c+ 6.0和SQL Server同開發(fā)的一個火車站網(wǎng)上訂票系統(tǒng)，它能方便快捷地運用在火車站訂票業(yè)務的營運之中。1.3 開發(fā)目標本系統(tǒng)開發(fā)意在實現(xiàn)售票員快速、準確、方便地的完成查詢、售票、改簽、退票等操作，使得顧客短時間內(nèi)獲取所需的準確信息、節(jié)約時間，最終提高顧客滿意程度。另外，本系統(tǒng)還可對運價、車次、終點進行調(diào)整，對各類報表進行維護和統(tǒng)計，有利于鐵道部門分析報表結(jié)果適時作出路線、車次、票價的調(diào)度，最終實現(xiàn)鐵路線路保持暢通運行，為旅客提供優(yōu)質(zhì)滿意的服務。其次，本系統(tǒng)可減少一定人力資源，一名售票員或一個窗口可以“同步”完成查詢、售票、改簽以及退票等所有基本功能；本系統(tǒng)界面操作簡單，功能全面，能夠很好滿足火車站售票需求。這樣，可以有效的利用適當?shù)娜肆ν瓿苫疖囌镜母鞣N服務。最后，本系統(tǒng)還提供功能強大的管理功能，即實現(xiàn)人員、車次、運價、終點站的修改以及各類報表的維護和打印，方便鐵道部門信息管理。2 可行性研究該階段通過對系統(tǒng)目標的初步調(diào)研和分析，提出可行性方案并進行論證。我們在這里主要從技術可行性、經(jīng)濟可行性和操作可行性三方面進行分析。2.1經(jīng)濟可行性開發(fā)該系統(tǒng)所需的相關資料可以通過已存在的網(wǎng)上訂票系統(tǒng)進行調(diào)查采集,所需的其他應用軟件、硬件系統(tǒng)也易于獲得.因此,開發(fā)成本較低。而引進使用本系統(tǒng)后，與傳統(tǒng)方式相比，具有高效率、低成本、高質(zhì)量的特點，可以節(jié)省不少人力、物力及財力。所以，從經(jīng)濟的角度來看，該系統(tǒng)可行。2.2技術可行性開發(fā)工具：Visual C+ 6.0數(shù)據(jù)庫環(huán)境：SQL Server 2000系統(tǒng)環(huán)境：Microsoft Windows XP系統(tǒng)實現(xiàn)依靠相對熟悉的C+語言和SQL Server2000數(shù)據(jù)庫系統(tǒng)，其基本操作實質(zhì)還是對數(shù)據(jù)庫進行添加、刪除、查找等操作,具體技術問題后面討論。2.3操作可行性系統(tǒng)采用菜單式，實現(xiàn)用戶與數(shù)據(jù)庫的交互，界面簡潔友好，操作方便。用戶只需對訂票流程和業(yè)務調(diào)查了解即可，不需掌握數(shù)據(jù)庫等相關知識。3需求分析3.1任務概述車站是發(fā)行車票、提供車輛從而方便旅客出行的單位。車站售票系統(tǒng)在正常運行中需要使用的主要是售票員、調(diào)度人員、車站管理人員和系統(tǒng)維護人員。其主要業(yè)務包括訂票、售票、退票和補票等?；诎踩院推渌鞣矫娴脑蚩紤]，本售票系統(tǒng)設計成C/S模式。車站客運系統(tǒng)的主要流程是：根據(jù)客流的分布情況制定票額分配計劃和車輛的調(diào)度信息，通過預定、發(fā)票等方式售出車票，并就車票出售情況做出關于售票的財務統(tǒng)計報表、客運統(tǒng)計報表。而由統(tǒng)計產(chǎn)生的數(shù)據(jù)將成為客流分析的基本數(shù)據(jù)。對于旅客來說，想要買票先到車站的售票大廳向售票員查詢相關的車次信息，若有票則出示身份證件可以現(xiàn)場購買，若旅客不方便出行則可以打電話到車站訂票，此時需要身份證號碼和聯(lián)系電話。對于售票員來說根據(jù)旅客的訂票信息在規(guī)定的時間內(nèi)提醒旅客持身份證前來買票。3.2功能需求分析3.2.1系統(tǒng)管理（1）用戶權限：本售票系統(tǒng)的用戶包括售票員、調(diào)度員、車站內(nèi)部的高級管理人員和系統(tǒng)維護人員。不同的人員登錄系統(tǒng)時選擇不同的用戶角色，不同的角色具有不同的權限。售票員的權限是進入車票數(shù)據(jù)庫查看車票信息并修改車票的狀態(tài)；調(diào)度員登錄系統(tǒng)主要是安排車輛及車次的調(diào)度信息；管理人員包括車站領導及財務管理人員，財務管理人員主要是看每個售票員的售票信息和車票狀態(tài)；系統(tǒng)維護人員主要是檢查系統(tǒng)對數(shù)據(jù)庫進行備份工作。（2）站點管理主要是考慮每條線路上車輛的其起始站點及?？空军c。3.2.2調(diào)度管理（1）車次調(diào)度：車次調(diào)度包括車次的增加、刪除和調(diào)整。車站根據(jù)客流的分布情況制定每條線路上的車次信息，當某段時間某條線路上客流過多或過少時車站就需要增加或刪除一些車次，調(diào)整是指根據(jù)特殊情況延遲或提前某次車的發(fā)車時間。（2）線路管理：包括增加線路、修改線路、刪除線路和調(diào)整線路，車站調(diào)研人員根據(jù)客流的分布情況做出開辟某些新線路、刪除原有線路或修改某些線路。（3）票價管理：包括審定票價、修改票價和線路票價浮動。3.2.3票務管理 （1）訂票：旅客訂票有兩張方式：一是電話預定，旅客將車票信息告知售票員，售票員登錄系統(tǒng)查詢車票信息，若有票旅客需要留下身份證號碼和聯(lián)系電話方便旅客買票；二是到車站訂票，步驟同上。（2）退票：旅客因特殊原因需要退票，則需要在規(guī)定的時間內(nèi)攜帶原車票和身份證到車站去退票并繳納退票手續(xù)費。（3）售票：售票員根據(jù)訂票信息通過旅客留下的電話號碼聯(lián)系快到時間而未來買票的旅客來買票，同時為直接買票的旅客打印車票。（4）補票：客戶因某種原因車票丟失了，應先持身份證到制定地點掛失車票，經(jīng)過掛失的車票在檢票的時候不能通過，然后根據(jù)原有車票信息打印新的車票，旅客需要繳納一定的手續(xù)費。圖3.1 系統(tǒng)功能圖3.3 數(shù)據(jù)流圖圖3.2 頂層圖圖3.3 售票0層圖圖3.4 訂票1層圖圖3.5 售票1層圖圖3.6 退票1層圖4概要設計4.1 系統(tǒng)整體框架設計本系統(tǒng)將采取C/S三層架構模式實現(xiàn)對車站的管理，服務器主用完成端口模型實現(xiàn)，客戶端用基于對話框的框架進行設計。只有服務器能直接訪問數(shù)據(jù)庫，保證了數(shù)據(jù)庫的安全性。圖4.1 系統(tǒng)框架圖4.2系統(tǒng)流程圖本系統(tǒng)具體的操作流程是用戶輸入自己的登陸信息，登陸成功后，售票員進入票務操作界面，車站管理員進入管理界面，普通用戶不需登陸，這樣可以理解為自助機。在售票界面，售票員、車站管理員和普通用戶都可以進行車票查詢，但是只有售票員才能進行售票，車票預訂在售票員和普通用戶權限下都可以進行操作。車站管理員可以對車次，車票，車站，路線進行相應管理。具體流程見圖：不同人員售票系統(tǒng)數(shù)據(jù)庫提供所需信息查詢數(shù)據(jù)庫顯示查詢結(jié)果反饋給購票者圖4.2 流程圖4.3 系統(tǒng)用例用例圖用于顯示若干角色以及這些角色與系統(tǒng)提供的用例之間的連接關系。用例模型是把應滿足用戶需求的基本功能聚合起來表示的強大工具，對于正在構造的新系統(tǒng)，用例描述系統(tǒng)應該作什么，對于已構造完畢的系統(tǒng)，用例則反映了系統(tǒng)能夠完成什么樣的功能。用例模型的基本組成部件是用例、角色和系統(tǒng)。用例用于描述胸膛那個的功能，也就是從外部用戶的角度觀察，系統(tǒng)應支持哪些功能，幫助分析人員理解系統(tǒng)的行為，他是對系統(tǒng)功能的宏觀描述。一個完整的系統(tǒng)中通常包含若干個用例，每個用例具體說明應完成的功能，代表系統(tǒng)的所有基本功能。角色是與系統(tǒng)進行交互的外部實體，它可以是系統(tǒng)用戶，也可以是其他系統(tǒng)或硬件設備，總之，凡是需要與系統(tǒng)進行交互的任何東西都可以稱作角色。系統(tǒng)的邊界線以內(nèi)的區(qū)域則抽象表示系統(tǒng)能夠?qū)崿F(xiàn)的所有基本功能。在用例模型中，系統(tǒng)仿佛是實現(xiàn)各種用例的“黑盒子”，我們只關心該系統(tǒng)實現(xiàn)了哪些功能，并不關心內(nèi)部的具體實現(xiàn)細節(jié)。根據(jù)本系統(tǒng)的需求分析，本系統(tǒng)中存在的角色：售票員，車站管理員，普通客戶，打印機。所以可得到系統(tǒng)的用例圖。如圖圖4.3 用例圖對于本系統(tǒng)而言，具體功能是非常多的，此處只列舉售票操作的圖。4.4售票訂票流程圖售票訂票是本系統(tǒng)最基本的功能，售票功能的流程是：售票員登陸，根據(jù)客戶提供的車次或者是車站信息對車票進行查詢，有票時向客戶進行售票，系統(tǒng)修改數(shù)據(jù)庫，打印機打印車票。訂票可以客戶在自助機上進行，也可以由售票員進行。訂票功能的流程是：客戶在自助機上根據(jù)車次或車站信息對車票進行查詢，有票時展現(xiàn)車票信息和余票信息，客戶自助訂票，系統(tǒng)修改數(shù)據(jù)庫，產(chǎn)生訂單。圖4.4 售票訂票流程圖4.5活動圖活動圖顯示動作及其結(jié)果?；顒訄D著重描述操作實現(xiàn)中所完成的工作以及用例實例或?qū)ο笾械幕顒?。活動圖是狀態(tài)圖的一個變種，與狀態(tài)圖的目的有一些小的差別，活動圖的主要目的是描述動作及對象狀態(tài)改變的結(jié)果。當狀態(tài)中的動作被執(zhí)行時，活動圖中的狀態(tài)直接轉(zhuǎn)移到下一個階段?；顒訄D和狀態(tài)圖的另一個區(qū)別是活動圖中的動作可以放在泳道中。泳道聚合一組活動，并指定負責人和所屬組織?；顒咏M是另一種描述交互的方式，描述采取何種動作，做什么，何時發(fā)生，以及在何處發(fā)生?；顒訄D可以用作下述目的：（1）描述一個操作執(zhí)行過程中（操作實現(xiàn)的實例化）所完成的工作（動作）。這是活動圖最常見的用途。（2）描述對象內(nèi)部的工作。（3）顯示如何執(zhí)行一組相關的動作，以及這些動作如何影響他們周圍的對象。（4）顯示用例的實例是如何執(zhí)行動作以及如何改變對象狀態(tài)。（5）說明一次活動中的角色、工作流、組織和對象是如何工作的。圖4.5 活動圖4.6序列圖序列圖描述對象是如何交互的，并且將重點放在消息序列上，也就是說，描述消息是如何在對象間發(fā)送和接收德爾。序列圖有兩個坐標軸：縱坐標軸顯示時間，橫坐標軸顯示對象。序列圖也顯示特殊情況下的對象交互：在系統(tǒng)執(zhí)行期間的某一時間點發(fā)生在對象間的特殊交互。在序列圖的橫坐標軸上是與序列有關的對象。每一個對象的表示方法是：矩形框中寫有對象和/或類名，且名字下面有下劃線。同時，有一條縱向的虛線表示對象在序列中的執(zhí)行情況（即：發(fā)送和接收的消息，對象的活動），這條虛線稱為對象的“生命線”。對象間的通信用對象的生命線之間的水平的消息線來表示。消息線的箭頭說明消息的類型，如同步，異步或簡單。瀏覽序列圖的方法是：從上到下查看對象交換的消息。圖4.6 序列圖5詳細設計5.1服務器設計服務器是本系統(tǒng)的核心模塊，其一端連接中心數(shù)據(jù)庫，另一端連接各客戶端節(jié)點，是系統(tǒng)的業(yè)務處理和信息交互的中心節(jié)點。其模型圖為：圖5.1 系統(tǒng)模型圖其穩(wěn)定性要求和響應時間有較高要求。設計思想從以下幾個方面進行描述：5.1.1線程模型。主線程為界面線程，當啟動服務時，系統(tǒng)創(chuàng)建監(jiān)聽線程，用于監(jiān)聽到達的客戶端連接，當客戶端到達時，將客戶端信息等級到服務器的列表框中。監(jiān)聽線程創(chuàng)建服務服務線程，此服務線程用于接收客戶端傳來的消息，對消息進行分析，并將消息投遞到不同的業(yè)務線程中。根據(jù)不同的業(yè)務類型，服務線程創(chuàng)建三條業(yè)務線程，即時業(yè)務線程，非即時業(yè)務線程，查詢線程。具體的線程模型見圖：圖5.2 線程模型/創(chuàng)建三條業(yè)務線程m_pDoPacketThreadForSearch=new CDoPacketThreadForSearch;m_pDoPacketThreadForSearch-CreatThread();m_pDoPacketThreadForJiShi=new CDoPacketThreadForJiShi;m_pDoPacketThreadForJiShi-CreatThread();m_pDoPacketThreadForNotJiShi=new CDoPacketThreadForNotJiShi;m_pDoPacketThreadForNotJiShi-CreatThread();5.1.2 SOCK模型Windows平臺常用的模型有阻塞模型、select模型、WSAAsyncSelect模型、WSAEventSelect模型、Overlap模型、完成端口（IOCP）模型?？紤]到服務點的規(guī)模和采用多線程的特點，選用IOCP模型。根據(jù)業(yè)務類別分別基于TCP或UDP協(xié)議開發(fā)。完成端口簡介完成端口模型 (I/O completion ports)是迄今為止為復雜的一種I/O模型，假如一個程序需要管理為數(shù)多的套接字，那么采用這種模型往往可以達到最佳的系統(tǒng)性能,因其設計的復雜性,只有應用程序需要同時管理數(shù)百乃至上千個套接字的時候,而且希望隨著系統(tǒng)內(nèi)安裝CPU 數(shù)量的增多,應用程序的性能呈線性提升時,才考慮采用完成端口模型。完成端口模型是唯一適用于高負載服務器的一種技術。我們可以把完成端口看成系統(tǒng)維護的一個隊列，操作系統(tǒng)把重疊IO操作完成的事件通知放到該隊列里。一個socket被創(chuàng)建后，可以在任何時刻和一個完成端口聯(lián)系起來，當與完成端口相關聯(lián)的socket上的異步I/O 完成時，操作系統(tǒng)會向完成端口發(fā)送一個完成通知包。通過GetQueuedCompletionStatus()函數(shù)可以獲取I/O操作結(jié)果。由于一個完成端口能夠管理為數(shù)眾多的套接字，所以用完成端口編寫的服務器程序能夠達到最佳的系統(tǒng)性能。而且隨著服務器CPU數(shù)量的增加，應用程序的性能也會得到線形的提高。線程的數(shù)量一般來說，一個應用程序可以創(chuàng)建多個工作器線程來處理完成端口上的通知事件。但是在理想的情況下，應該對應一個CPU創(chuàng)建一個線程。因為在完成端口理想模型中，每個線程都可以從系統(tǒng)獲得一定的時間片，輪番運行并檢查完成端口。但是在實際開發(fā)的時候，還要考慮這些線程是否牽涉到其他堵塞操作的情況。如果某線程進行堵塞操作，系統(tǒng)則將其掛起，讓別的線程獲得運行時間。因此，如果有這樣的情況，可以多創(chuàng)建幾個線程來盡量利用時間。重疊I/O 用完成端口編寫的服務器程序有如此高的系統(tǒng)性能，重疊I/O功不可沒。比起阻塞的I/O操作，重疊I/O最大的優(yōu)勢是應用程序投遞了一個發(fā)送或接受請求以后直接就返回。對于那種需要很長時間才能完成的操作來說，重疊I/O機制尤其有用，因為發(fā)起重疊操作的線程在重疊請求發(fā)出后就可以自由的做別的事情了。Windows Sockets 2引入了重疊I/O的概念并且要求所有的傳輸協(xié)議提供者都支持這一功能。重疊I/O僅能在由WSASocket()函數(shù)打開的套接口上使用（使用WSA_FLAG_OVERLAPPED標記）。對于接收數(shù)據(jù)，應用程序使用WSARecv()函數(shù)來提供存放接收數(shù)據(jù)的緩沖區(qū)。如果數(shù)據(jù)在WSARecv()函數(shù)接收以前已經(jīng)到達套接字的接受緩沖區(qū)，那么調(diào)用WSARecv()函數(shù)，接收的數(shù)據(jù)就可以立即被存放進用戶緩沖區(qū)，函數(shù)返回值是0，如果數(shù)據(jù)在WSARecv()函數(shù)接收之前沒有到達套接字的接受緩沖區(qū)，那么調(diào)用WSARecv()返回SOCKET_ERROR，并且錯誤代碼是WSA_IO_PENDING，當數(shù)據(jù)到來的時候，操作系統(tǒng)直接把數(shù)據(jù)拷貝進應用程序的緩沖區(qū)。發(fā)送函數(shù)WSASend()發(fā)送數(shù)據(jù)的時候，如果套接字的發(fā)送緩沖區(qū)有足夠的空間，那么將數(shù)據(jù)拷貝到套接字的發(fā)送緩沖區(qū)，函數(shù)返回值是0。如果套接字的發(fā)送緩沖區(qū)沒有空間，那么WSASend()返回SOCKET_ERROR，并且錯誤代碼是WSA_IO_PENDING，在系統(tǒng)處理完套接字的發(fā)送緩沖區(qū)后，系統(tǒng)直接把數(shù)據(jù)交給了TCP，繞過了套接字的發(fā)送緩沖區(qū)。Overlapped的用法在重疊IO的過程中，Overlapped的使用非常重要，當一個重疊IO被發(fā)起，一個Overlapped結(jié)構體的指針就要作為參數(shù)傳遞給系統(tǒng)。當操作完成，GetQueueCompletionStatus可以返回指向同一個Overlapped結(jié)構的指針。為了辨認和定位這個已完成的操作，開發(fā)人員最好定義自己的Overlapped結(jié)構，以包含一些自己定義的關于操作本身的額外信息。使用AcceptEx由于高性能的服務器在很短的時間內(nèi)要響應大量的連接，所以采用AcceptEx函數(shù)。AcceptEx函數(shù)是微軟的Winsosk 擴展函數(shù)，這個函數(shù)與accept的區(qū)別就是：accept是阻塞的，一直要到有客戶端連接上來后accept才返回，所以同時面對大量的連接，accept顯然難以滿足要求。而AcceptEx是異步的，直接就返回了，而且我們可以利用AcceptEx可以發(fā)出多個AcceptEx調(diào)用等待客戶端連接。另外，如果我們可以預見到客戶端一連接上來后就會發(fā)送數(shù)據(jù)，那么可以隨著AcceptEx投遞一個BUFFER進去，這樣如果連接建立成功，就可以接收客戶端發(fā)出的數(shù)據(jù)到BUFFER里，這樣的話，一次AcceptEx調(diào)用相當于accpet和recv的一次連續(xù)調(diào)用。IOCP工作流程：主線程工作流程1、創(chuàng)建一個I/O 完成端口；2、創(chuàng)建一個listen_socket并listen_socket添加到完成端口；3、將套接字綁定到一個已知的地址4、創(chuàng)建一個socket，調(diào)用AcceptEx（）函數(shù)，將socket作為AccpetEx的一個參數(shù)，用于下一個客戶機的連接。重復此步驟若干次。5、在listen_socket上用WSAEventSelect（）注冊FD_ACCEPT事件6、主線程進入循環(huán)，等待listen_socket上的FD_ACCEPT事件7、如果發(fā)生FD_ACCEPT事件，則說明已經(jīng)投遞的套接字已經(jīng)用完，則調(diào)用步驟5，再投遞一定數(shù)量的AcceptEx（），如果發(fā)生了WAIT_TIMEOUT時間，則調(diào)用CheckConnection()函數(shù)，刪除已經(jīng)連接但是沒有發(fā)送數(shù)據(jù)的socket。圖5.3 主線程圖工作者線程的步驟如下1、創(chuàng)建擴展重疊結(jié)構2、工作者線程循環(huán)調(diào)用GetQueuedCompletionStatus函數(shù)以獲取I/O操作結(jié)果；3、GetQueuedCompletionStatus()中WSAOVERLAPPED的結(jié)果來判斷完成端口上是接受到了新的連接、有數(shù)據(jù)接受，還是要發(fā)送數(shù)據(jù)。4、如果接受到了新的連接，將新套接字句柄用CreateIoCompletionPort函數(shù)關聯(lián)到完成端口，如果要接受數(shù)據(jù)則調(diào)用WSARecv（），如果要發(fā)送數(shù)據(jù)，調(diào)用WSASend（）。因為是異步函數(shù)，WSASend和WSARecv會直接返回，實際的發(fā)送或接收數(shù)據(jù)的操作由Windows 系統(tǒng)完成。圖5.4 工作線程圖5.1.3通信數(shù)據(jù)幀格式和粘連包處理TCP通信是基于數(shù)據(jù)流的，不區(qū)分邊界，可能出現(xiàn)粘連包，數(shù)據(jù)在傳輸過程中可能被竊取或篡改，數(shù)據(jù)幀的種類繁多等等，在設計數(shù)據(jù)幀時必須考慮到上述問題。所以，在通信時的數(shù)據(jù)包中都包含了包長、協(xié)議類型、校驗和，數(shù)據(jù)通過相應的加密算法加密。（1）數(shù)據(jù)幀格式如表5.1表5.1 數(shù)據(jù)幀格式表包長（4字節(jié)）業(yè)務代碼（4字節(jié)）用戶數(shù)據(jù)段（K字節(jié)）校驗和（8字節(jié)）數(shù)據(jù)幀包括4字節(jié)的包長字段，4字節(jié)的業(yè)務字段，K字節(jié)的用戶數(shù)據(jù)字段，8字節(jié)的校驗和。（2）粘連包處理方法由于車票管理的數(shù)據(jù)量是非常大的，多以出現(xiàn)粘連包是在所難免的，粘連包出現(xiàn)的問題主要是半包問題，所以必須解決這個問題，在此方案中，處理粘連包的方法是，在服務器中存在4個包隊列：即時業(yè)務包隊列，非即時業(yè)務包隊列，查詢業(yè)務包隊列，半包隊列，首先取得包的前4個字節(jié)得到包應該的長度a，計算獲得包的總長度b，如果a = b則是正常包，進行正常處理，如果如果a b，則根據(jù)a的值在包中取得相應長度的數(shù)據(jù)，并將b的長度減去a，然后循環(huán)如此，直到包結(jié)束或者是出現(xiàn)半包停止，若果a s=g_BaseObj.m_iter-s)/如果有就半包添加到收到的數(shù)據(jù)的開始部位，并且報的長度進行改編char temp1024;memset(temp,0,1024);memcpy(temp,g_BaseObj.m_iter-msg,sizeof(g_BaseObj.m_iter-msg);strncpy(temp+sizeof(g_BaseObj.m_iter-msg),pPerIO-buf,nLen);strncpy(pPerIO-buf,temp,sizeof(temp);nLen=atoi(pPerIO-buf);/構造消息節(jié)點if（nLenLen）MESSAGE MsgNode;MsgNode.s=pPerHandle-s;char tempbuf1024;ZeroMemory(tempbuf,0,1024);strncpy(tempbuf,pPerIO-buf+4,Len-4);MsgNode.msg.Format(%s,tempbuf); /去掉包長字段（4字節(jié)）nLen-=Len;if (nLen!=0)strncpy(pPerIO-buf,pPerIO-buf+Len,nLen);pPerIO-bufnLen=0;memcpy(intLen,pPerIO-buf,4);Len=atoi(intLen);elsebreak;if (nLens;char tempbuf1024;ZeroMemory(tempbuf,0,1024);strncpy(tempbuf,pPerIO-buf,Len);MsgNode.msg.Format(%s,tempbuf); /去掉包長字段（4字節(jié)）EnterCriticalSection(&g_BaseObj.m_cs_HalfPacket);g_BaseObj.m_MessageList_HalfPacket.push_front(MsgNode);LeaveCriticalSection(&g_BaseObj.m_cs_HalfPacket);g_BaseObj.m_HalfPacket+;break;（3）數(shù)據(jù)安全保障算法。中心數(shù)據(jù)庫由業(yè)務中間件定時維護，如果存放中心數(shù)據(jù)庫的硬盤損毀或出現(xiàn)無法訪問的故障時，沒有備份的數(shù)據(jù)就會丟失。因此，在中間件執(zhí)行更改數(shù)據(jù)庫數(shù)據(jù)的指令時，相應的SQL指令被存儲到一個按日期命名的文本文件中，且該文本文件與數(shù)據(jù)庫文件不在同一個硬盤上，這樣，一旦硬盤出現(xiàn)故障，數(shù)據(jù)庫無法訪問時，執(zhí)行文本文件中的相應SQL語句就可以恢復數(shù)據(jù)。這一塊具體沒有實現(xiàn)。（4）線程之間同步和互斥訪問數(shù)據(jù)庫問題由于數(shù)據(jù)量大且信息種類多樣，為了同時滿足對數(shù)據(jù)的讀取、存放和顯示，必須在軟件運行期間開啟多條線程進行應對。由于服務器中存在3條業(yè)務線程，服務線程需要向業(yè)務隊列中投遞業(yè)務，業(yè)務線程需要從業(yè)務隊列中取業(yè)務代碼，由于3條業(yè)務線程是異步執(zhí)行的，所以業(yè)務線程需要從而對數(shù)據(jù)庫的訪問就存在互斥訪問問題，以免出現(xiàn)數(shù)據(jù)混亂的局面。在window環(huán)境下，一個進程等同于一個容器，而線程則是容器內(nèi)的實體，線程才是程序的最小執(zhí)行單元。對于進程中，若多條線程在任意時刻都有可能訪問到某個全局資源，那么這個全局資源被稱為是臨界資源。在這種情況下，必須保護臨界資源，多線程必須互斥的對其訪問。在本監(jiān)控系統(tǒng)中，將多條線程做成類似生產(chǎn)者消費者模型，滿足了系統(tǒng)對數(shù)據(jù)并發(fā)控制的需要。此模型的原理即是：一條線程負責生產(chǎn)數(shù)據(jù)，其他線程負責讀取由該線程生產(chǎn)的數(shù)據(jù)。只需對數(shù)據(jù)訪問部分做到同步即可。為了解決線程同步問題，win32 API提供了多種同步控制對象。包括：互斥對象、信號對象、事件對象、排斥區(qū)對象(關鍵代碼段)在介紹這些對象之前，必須先介紹等待函數(shù)，因為他們都要使用等待函數(shù)。Win32 API提供了一組能使線程阻塞其自身執(zhí)行的等待函數(shù)。等待函數(shù)未返回時，線程處于等待狀態(tài)，此時線程只是消耗很少的CPU時間。使用等待函數(shù)既可以保證線程的同步，又可以提高程序的運行效率。最常用的等待函數(shù)為：WaitForSingleObject, WaitForMultipleObjects。1）.Mutex對象的狀態(tài)在它不被任何線程擁有時才有信號。Mutex對象很適合用來協(xié)調(diào)多個線程對共享資源的互斥訪問。可以按照下列步驟使用該對象：.建立互斥對象，得到句柄:HANDLE CreateMutex()。.在線程可能產(chǎn)生沖突的區(qū)域前（即訪問共享資源前）調(diào)用WaitForSingleObject()將句柄傳給函數(shù)，請求占用Mutex對象。.共享資源訪問結(jié)束，釋放對Mutex對象的占用：ReleaseMutex(hMutex)。Mutex對象在同一時刻只能被一個線程占用，當Mutex對象被一個線程占用時，若另一個線程想占用它，則必須等到前一個線程釋放。2）.信號對象允許同時對多個線程共享資源進行訪問，在創(chuàng)建對象時指定最大可同時訪問的線程數(shù)。當一個線程申請訪問成功后，信號對象中的計數(shù)器減一，調(diào)用ReleaseSemaphore函數(shù)后，信號對象中的計數(shù)器加一。其中，計數(shù)器值大于或等于0，但小于或等于創(chuàng)建時指定的最大值。如果一個應用在創(chuàng)建一個信號對象時，將其計數(shù)器的初始值設為0，就阻塞了其他線程，保護了資源。等初始化完成后，調(diào)用ReleaseSemaphore函數(shù)將其計數(shù)器增加至最大值，則可進行正常的存取訪問。 其使用步驟與Mutex對象類似，這里不再贅述。3）.事件對象(Event)是最簡單的對象，它包括有信號和無信號兩種狀態(tài)。.創(chuàng)建事件對象HANDLE CreateEvent(NULL,FALSE,TRUE,NULL)/自動重置事件HANDLE CreateEvent(NULL,TRUE,FALSE,NULL)/手工重置事件.在線程訪問共享資源之前調(diào)用 WaitForSingleObject()。.重新設置成有信號狀態(tài) SetEvent(EVENT_HANDLE )。4）.排斥區(qū)對象 在排斥區(qū)中異步執(zhí)行時，它只能在同一進程的線程之間共享資源處理。使用排斥區(qū)的方法則使同步管理的效率更高。.使用時先定義一個CRITICAL_SECTION結(jié)構的排斥區(qū)對象: VOID InitializeCriticalSection(LPCRITICAL_SECTION)。.當一個線程使用排斥區(qū)時，調(diào)用函數(shù)：EnterCriticalSection( ); .當要求退出排斥區(qū)時，調(diào)用函數(shù)：LeaveCriticalSection( ); /釋放對排斥區(qū)對象的占用在這四種多線程同步的方法中，優(yōu)先選用關鍵代碼段（排斥區(qū)對象）方法。其使用簡單且速度較快，而Mutex對象與事件對象等屬于內(nèi)核對象，運行速度較慢。故本系統(tǒng)中采用第四種同步方法?？紤]到本系統(tǒng)里需要用到的線程存在于一個進程之中和5個臨界區(qū)，即即時業(yè)務隊列，非即時業(yè)務隊列，查詢業(yè)務隊列，半包隊列，數(shù)據(jù)庫訪問這些對象對應的關鍵區(qū)，所以采用關鍵代碼段來實現(xiàn)線程同步和互斥。在服務器開啟服務的時候?qū)﹃P鍵區(qū)進行初始化：InitializeCriticalSection(&g_BaseObj.m_cs_noJiShiTX);InitializeCriticalSection(&g_BaseObj.m_cs_jiShiTX);InitializeCriticalSection(&g_BaseObj.m_cs_search);InitializeCriticalSection(&g_BaseObj.m_cs_HalfPacket);InitializeCriticalSection(&g_BaseObj.m_cs_datebase);在停止服務時刪除關鍵區(qū)：DeleteCriticalSection(&g_BaseObj.m_cs_jiShiTX);DeleteCriticalSection(&g_BaseObj.m_cs_noJiShiTX);DeleteCriticalSection(&g_BaseObj.m_cs_search);DeleteCriticalSection(&g_BaseObj.m_cs_HalfPacket);DeleteCriticalSection(&g_BaseObj.m_cs_datebase);在需要訪問臨界區(qū)的時候：業(yè)務線程從隊列中取走業(yè)務代碼：EnterCriticalSection(&g_BaseObj.m_cs_jiShiTX);if(!g_BaseObj.m_MessageList_jiShiTx.empty()/list操作，新元素插入list頭，取元素從list尾部msg_node=g_BaseObj.m_MessageList_jiShiTx.back(); g_BaseObj.m_MessageList_jiShiTx.pop_back();g_BaseObj.m_Jishi_Packet-; /即時交易包未處理數(shù)目elseLeaveCriticalSection(&g_BaseObj.m_cs_jiShiTX); Sleep(10);continue;LeaveCriticalSection(&g_BaseObj.m_cs_jiShiTX);服務線程向隊列中投遞業(yè)務：if(iBusinessType=0)/插入g_MessageList_jiShiTxEnterCriticalSection(&g_BaseObj.m_cs_jiShiTX);g_BaseObj.m_MessageList_jiShiTx.push_front(MsgNode);/list操作，新元素插入list頭，取元素從list尾部g_BaseObj.m_Jishi_Packet+; /即時交易包未處理數(shù)目LeaveCriticalSection(&g_BaseObj.m_cs_jiShiTX);else if(iBusinessType=1)/插入g_MessageList_noJiShiTxEnterCriticalSection(&g_BaseObj.m_cs_noJiShiTX);g_BaseObj.m_MessageList_noJiShiTx.push_front(MsgNode);/list操作，新元素插入list頭，取元素從list尾部g_BaseObj.m_NoJishi_Packet+;/非即時交易包未處理數(shù)目LeaveCriticalSection(&g_BaseObj.m_cs_noJiShiTX);else if (iBusinessType=2)/插入g_MessageList_SearchEnterCriticalSection(&g_BaseObj.m_cs_search);g_BaseObj.m_MessageList_Search.push_front(MsgNode);/list操作，新元素插入list頭，取元素從list尾部g_BaseObj.m_Search_Packet+;/查詢包未處理數(shù)目LeaveCriticalSection(&g_BaseObj.m_cs_search);（5）全局隊列和全局結(jié)構的設計本系統(tǒng)中由于處理數(shù)據(jù)內(nèi)容是龐大的，所以應該有相應的結(jié)構來存儲以便統(tǒng)一管理數(shù)據(jù)。并且由于本系統(tǒng)中幾乎所有的線程都需要用到一些數(shù)據(jù)結(jié)構，所以將這些數(shù)據(jù)結(jié)構存放在統(tǒng)一的類里，此類是一個全局類。類中包括的結(jié)構有消息節(jié)點結(jié)構：套接字信息，消息數(shù)據(jù)。套接字信息提供客戶端套接字，以便于服務器進行操作之后向客戶端發(fā)送數(shù)據(jù)和粘連包的處理，消息數(shù)據(jù)即為客戶端發(fā)送的請求，包括4字節(jié)的包長，8字節(jié)的校驗和字段，K個字段的數(shù)據(jù)。/消息節(jié)點類typedef struct _messageSOCKET s;CString msg;MESSAGE,*PMESSAGE;業(yè)務節(jié)點結(jié)構：業(yè)務代碼，業(yè)務類別。業(yè)務代碼是服務器與客戶端協(xié)定的業(yè)務協(xié)議，不同的代號代表不同業(yè)務，是面向開發(fā)人員的。業(yè)務類別有3類，即時業(yè)務，非即時業(yè)務和查詢業(yè)務。/業(yè)務代碼節(jié)點類typedef struct _BusinessTypechar BusinessId5; /業(yè)務id，如“0001”，“0002”byte bBusinessType; /業(yè)務類別，0-即時業(yè)務，1-非即時業(yè)務，2-查詢BUSINESS_TYPE;車輛信息結(jié)構：車次，始發(fā)站，終點站，開車時間，到站時間。由于本系統(tǒng)初衷是實現(xiàn)全國任意車站（必須在路線之內(nèi)）的售票工作，所以用此結(jié)構體來查詢車票。/車輛信息結(jié)構體typedef struct _carmessage CString carID;CString Startstation;CString Endstation;CString Starttime;CString Endtime;CARMESSAGE,*PCARMESSAGE;typedef struct _carPrice CString length;CString price;CARPRICE,*PCARPRICE;/per_handle數(shù)據(jù)typedef struct _PER_HANDLE_DATA SOCKET s;sockaddr_in clientaddr;PER_HANDLE_DATA,*PPER_HANDLE_DATA;/per_I/O數(shù)據(jù)typedef struct _PER_IO_DATA OVERLAPPED ol;char bufBUFFER_SIZE;int nOperationType;PER_IO_DATA,*PPER_IO_DATA;本系統(tǒng)中使用的關鍵代碼段和鏈表CRITICAL_SECTION m_cs_search; /查詢隊列操作關鍵區(qū)CRITICAL_SECTION m_cs_jiShiTX; /即時交易隊列操作關鍵區(qū)CRITICAL_SECTION m_cs_noJiShiTX;