




版權(quán)說(shuō)明:本文檔由用戶(hù)提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請(qǐng)進(jìn)行舉報(bào)或認(rèn)領(lǐng)
文檔簡(jiǎn)介
1、基于UDP協(xié)議的可靠通訊系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)UDP是OSI參考模型中一種無(wú)連接的傳輸層協(xié)議,它提供了簡(jiǎn)單不可靠的信息傳送服務(wù)。由于UDP的包頭包含很少的字節(jié),它在網(wǎng)絡(luò)傳輸方面有很大的速度優(yōu)勢(shì)。由于UDP存在傳輸可靠性差的問(wèn)題,無(wú)法實(shí)現(xiàn)聊天系統(tǒng)在好友互相聊天時(shí)的可靠性傳輸。文章在細(xì)致分析UDP和TCP協(xié)議特點(diǎn)的基礎(chǔ)上,通過(guò)對(duì)TCP協(xié)議的模擬,設(shè)計(jì)出了一種新的可靠UDP協(xié)議(UDT),大大提高了數(shù)據(jù)傳榆的可靠性。本文結(jié)合Java面向?qū)ο笳Z(yǔ)言特性和系統(tǒng)的功能需要,對(duì)本系統(tǒng)進(jìn)行了設(shè)計(jì)與實(shí)現(xiàn)。該系統(tǒng)在用戶(hù)與服務(wù)器之間采用C/S架構(gòu)。使用分層設(shè)計(jì)的思想分離出視圖層、商務(wù)邏輯層、hibernate數(shù)據(jù)庫(kù)連接層、
2、hibernate數(shù)據(jù)庫(kù)存儲(chǔ)層。UDT;套接字;Java;多線(xiàn)程;Hibernate Design and Implementation of the Reliable Communication System Based on UDPUDP is the OSI connectionless transport protocol,it provides simple unreliable transport servicesUDP has a transmission speed advantage in the network that is caused by UDP header co
3、nsists of a few fields. UDP has disadvantage of poor reliable, so it cant support the reliable transmission to this project when friends chat with each other. This paper extracts the features of UDP and TCP and proposes a new Reliable UDP(UDT)An object-oriented programming language Java, support man
4、y API , provides a great help for the realization of this chat program .In this thesis, combined with the JAVA object-oriented language feature and the actual need of this program , this Instant Message has been designed and implemented. C/S architecture is used between server and client .Using the
5、idea of the hierarchical design, this system can be separated view layer, business logic layer, Hibernate database access layer and Hibernate database storage layer.UDT; Socket ;Java; Multithread ; Hibernate目 錄 TOC o 1-3 h z u HYPERLINK l _Toc325922637 1 緒論 PAGEREF _Toc325922637 h 1 HYPERLINK l _Toc
6、325922638 1.1 課題選擇的背景 PAGEREF _Toc325922638 h 1 HYPERLINK l _Toc325922639 1.2 國(guó)內(nèi)外現(xiàn)狀及發(fā)展趨勢(shì) PAGEREF _Toc325922639 h 1 HYPERLINK l _Toc325922640 1.3 本文的主要工作 PAGEREF _Toc325922640 h 2 HYPERLINK l _Toc325922641 1.4 本章小結(jié) PAGEREF _Toc325922641 h 2 HYPERLINK l _Toc325922642 2 涉及的相關(guān)技術(shù)與協(xié)議 PAGEREF _Toc325922642
7、 h 2 HYPERLINK l _Toc325922643 2.1 Java語(yǔ)言技術(shù)基礎(chǔ) PAGEREF _Toc325922643 h 3 HYPERLINK l _Toc325922644 2.1.1 Java語(yǔ)言在開(kāi)發(fā)和執(zhí)行過(guò)程中的特點(diǎn) PAGEREF _Toc325922644 h 3 HYPERLINK l _Toc325922645 2.1.2 Java語(yǔ)言本身的特點(diǎn) PAGEREF _Toc325922645 h 3 HYPERLINK l _Toc325922646 2.1.3 Java與Hibernate整合使用訪(fǎng)問(wèn)數(shù)據(jù)庫(kù) PAGEREF _Toc325922646 h 6
8、 HYPERLINK l _Toc325922647 2.2 相關(guān)的協(xié)議介紹 PAGEREF _Toc325922647 h 7 HYPERLINK l _Toc325922648 2.2.1 TCP/IP協(xié)議 PAGEREF _Toc325922648 h 7 HYPERLINK l _Toc325922649 2.2.2 UDP協(xié)議(用戶(hù)數(shù)據(jù)報(bào)協(xié)議) PAGEREF _Toc325922649 h 8 HYPERLINK l _Toc325922650 2.2.3 TCP協(xié)議與UDP協(xié)議的比較 PAGEREF _Toc325922650 h 10 HYPERLINK l _Toc32592
9、2651 2.3 基于Socket的編程 PAGEREF _Toc325922651 h 11 HYPERLINK l _Toc325922652 2.4 本章小結(jié) PAGEREF _Toc325922652 h 12 HYPERLINK l _Toc325922653 3 聊天系統(tǒng)的需求分析 PAGEREF _Toc325922653 h 12 HYPERLINK l _Toc325922654 3.1 即時(shí)消息的一般需求 PAGEREF _Toc325922654 h 12 HYPERLINK l _Toc325922655 3.1.1 一般即時(shí)消息格式需求 PAGEREF _Toc325
10、922655 h 12 HYPERLINK l _Toc325922656 3.1.2 可靠性需求 PAGEREF _Toc325922656 h 12 HYPERLINK l _Toc325922657 3.1.3 性能需求 PAGEREF _Toc325922657 h 12 HYPERLINK l _Toc325922658 3.2 即時(shí)消息的協(xié)議需求 PAGEREF _Toc325922658 h 13 HYPERLINK l _Toc325922659 3.3 即時(shí)消息的安全需求 PAGEREF _Toc325922659 h 13 HYPERLINK l _Toc325922660
11、 3.4 即時(shí)通訊系統(tǒng)需求 PAGEREF _Toc325922660 h 13 HYPERLINK l _Toc325922661 3.4.1 注冊(cè)需求 PAGEREF _Toc325922661 h 13 HYPERLINK l _Toc325922662 3.4.2 通訊需求 PAGEREF _Toc325922662 h 13 HYPERLINK l _Toc325922663 3.5 系統(tǒng)的用例分析 PAGEREF _Toc325922663 h 13 HYPERLINK l _Toc325922664 3.5.1 服務(wù)器端用例圖 PAGEREF _Toc325922664 h 14
12、 HYPERLINK l _Toc325922665 3.5.2 客戶(hù)端用例圖 PAGEREF _Toc325922665 h 14 HYPERLINK l _Toc325922666 3.6 本章小結(jié) PAGEREF _Toc325922666 h 15 HYPERLINK l _Toc325922667 4 系統(tǒng)總體設(shè)計(jì) PAGEREF _Toc325922667 h 15 HYPERLINK l _Toc325922668 4.1 功能模塊劃分 PAGEREF _Toc325922668 h 16 HYPERLINK l _Toc325922669 4.1.1 服務(wù)器端 PAGEREF
13、_Toc325922669 h 16 HYPERLINK l _Toc325922670 4.1.2 客戶(hù)端 PAGEREF _Toc325922670 h 16 HYPERLINK l _Toc325922671 4.2 系統(tǒng)的多線(xiàn)程設(shè)計(jì) PAGEREF _Toc325922671 h 17 HYPERLINK l _Toc325922672 4.2.1 服務(wù)器端的多線(xiàn)程設(shè)計(jì) PAGEREF _Toc325922672 h 17 HYPERLINK l _Toc325922673 4.2.2 客戶(hù)端的多線(xiàn)程設(shè)計(jì) PAGEREF _Toc325922673 h 18 HYPERLINK l _
14、Toc325922674 4.3 本章小結(jié) PAGEREF _Toc325922674 h 18 HYPERLINK l _Toc325922675 5 系統(tǒng)關(guān)鍵技術(shù)及實(shí)現(xiàn) PAGEREF _Toc325922675 h 18 HYPERLINK l _Toc325922676 5.1 消息格式的設(shè)計(jì)與實(shí)現(xiàn) PAGEREF _Toc325922676 h 18 HYPERLINK l _Toc325922677 5.1.1 客戶(hù)端消息格式的設(shè)計(jì) PAGEREF _Toc325922677 h 18 HYPERLINK l _Toc325922678 5.1.2 服務(wù)器端的消息格式 PAGERE
15、F _Toc325922678 h 19 HYPERLINK l _Toc325922679 5.2 Hibernate數(shù)據(jù)庫(kù)設(shè)計(jì) PAGEREF _Toc325922679 h 20 HYPERLINK l _Toc325922680 5.2.1 數(shù)據(jù)庫(kù)的選擇 PAGEREF _Toc325922680 h 21 HYPERLINK l _Toc325922681 5.2.2 數(shù)據(jù)庫(kù)表設(shè)計(jì) PAGEREF _Toc325922681 h 21 HYPERLINK l _Toc325922682 5.2.3 Hibernate偽面向?qū)ο髷?shù)據(jù)庫(kù)的設(shè)計(jì)與實(shí)現(xiàn) PAGEREF _Toc3259226
16、82 h 22 HYPERLINK l _Toc325922683 5.3 客戶(hù)端好友聊天時(shí)的可靠傳輸 PAGEREF _Toc325922683 h 25 HYPERLINK l _Toc325922684 5.3.1 雙方的連接建立與關(guān)閉 PAGEREF _Toc325922684 h 25 HYPERLINK l _Toc325922685 5.3.2 發(fā)送方和接收方的設(shè)計(jì) PAGEREF _Toc325922685 h 25 HYPERLINK l _Toc325922686 5.3.3 發(fā)送方的流量控制 PAGEREF _Toc325922686 h 26 HYPERLINK l _
17、Toc325922687 5.3.4 接收方的確認(rèn)技術(shù) PAGEREF _Toc325922687 h 26 HYPERLINK l _Toc325922688 5.4 本章小結(jié) PAGEREF _Toc325922688 h 27 HYPERLINK l _Toc325922689 6 系統(tǒng)測(cè)試 PAGEREF _Toc325922689 h 27 HYPERLINK l _Toc325922690 6.1 測(cè)試方法 PAGEREF _Toc325922690 h 27 HYPERLINK l _Toc325922691 6.1.1 靜態(tài)測(cè)試與動(dòng)態(tài)測(cè)試相結(jié)合 PAGEREF _Toc3259
18、22691 h 27 HYPERLINK l _Toc325922692 6.1.2 壓力測(cè)試 PAGEREF _Toc325922692 h 27 HYPERLINK l _Toc325922693 6.2 測(cè)試結(jié)果 PAGEREF _Toc325922693 h 27 HYPERLINK l _Toc325922694 7 總結(jié)與展望 PAGEREF _Toc325922694 h 28 HYPERLINK l _Toc325922695 7.1 總結(jié) PAGEREF _Toc325922695 h 28 HYPERLINK l _Toc325922696 7.2 展望 PAGEREF _
19、Toc325922696 h 28 HYPERLINK l _Toc325922697 結(jié)束語(yǔ) PAGEREF _Toc325922697 h 30 HYPERLINK l _Toc325922698 參考文獻(xiàn) PAGEREF _Toc325922698 h 31 HYPERLINK l _Toc325922699 致謝 PAGEREF _Toc325922699 h 32 PAGE 33緒論自從人類(lèi)有了語(yǔ)言之后,人與人之間的交流更為方便。二次大戰(zhàn)以后科學(xué)技術(shù)的迅猛發(fā)展,給我們的生活帶來(lái)了巨大的變化。人與人之間的交流不在局限于面對(duì)面或紙上的書(shū)信交流,而是更加多元化。當(dāng)今世界即時(shí)聊天越來(lái)越受到人
20、們的青睞。本課題研究的是一種基于Internet網(wǎng)絡(luò)以及其他有線(xiàn)、無(wú)線(xiàn)網(wǎng)絡(luò)的實(shí)時(shí)通信方式即時(shí)聊天系統(tǒng)。即時(shí)通信(Instant Message)是互聯(lián)網(wǎng)應(yīng)用的一大熱點(diǎn),通過(guò)通信系統(tǒng)建立網(wǎng)絡(luò)虛擬社區(qū),為用戶(hù)提供實(shí)時(shí)有效的溝通手段。本課題在實(shí)施的過(guò)程使用的Java語(yǔ)言。課題選擇的背景計(jì)算機(jī)、電信網(wǎng)絡(luò)快速發(fā)展的今天,即時(shí)通訊方式日益受到人們的青睞。即時(shí)通訊工具不僅解放了人們交流的距離,而且使得交流的方式更加的多元化。即時(shí)聊天工具發(fā)展的歷史并不久遠(yuǎn),但憑借計(jì)算機(jī)和網(wǎng)絡(luò)之間的相互結(jié)合。人們可以通過(guò)計(jì)算機(jī)的電信網(wǎng)絡(luò)實(shí)現(xiàn)視頻、音頻同步的交流。豐富了人們的聯(lián)系方式。1996年11月,四位以色列籍年輕人成立的一
21、家名為Mirabilis的小公司推出了第一個(gè)即時(shí)通信軟件ICQ,取意為“I seek you”,這是當(dāng)時(shí)出現(xiàn)一款較為流行的網(wǎng)絡(luò)IM聊天工具。在接下來(lái)的幾年里,IM憑借一種更直接、更簡(jiǎn)單、更便捷的方式改變了整個(gè)網(wǎng)絡(luò)的交流方式,在編碼、字符、圖片堆積Internet中構(gòu)建了一條充滿(mǎn)溫情的溝通渠道。隨后的幾年伴隨著互聯(lián)網(wǎng)的飛速發(fā)展,國(guó)內(nèi)外即時(shí)聊天系統(tǒng)也在不斷的發(fā)展。相繼有許多的聊天系統(tǒng)被人們所接受和認(rèn)可。比如中國(guó)騰訊的QQ,微軟的MSN,新浪的UC,搜狐的搜Q,但還是QQ最為成功。目前互聯(lián)網(wǎng)上即時(shí)聊天系統(tǒng)種類(lèi)眾多,功能也較為齊全。如果企業(yè)或者單位內(nèi)部使用這些比較成熟的即時(shí)聊天系統(tǒng),由于聊天對(duì)象與內(nèi)容
22、部可控性,這樣企業(yè)可能會(huì)降低工作效率。該即時(shí)聊天通訊系統(tǒng)將自己的服務(wù)器端安裝在企業(yè)內(nèi),并且由企業(yè)內(nèi)部的人員來(lái)進(jìn)行管理,可以很好的解決這個(gè)問(wèn)題。并且該系統(tǒng)是定位于企業(yè)內(nèi)部網(wǎng)絡(luò),解決企業(yè)或單位的溝通與系統(tǒng)問(wèn)題,提高工作效率。企業(yè)內(nèi)部的工作人員可利用該通訊系統(tǒng)隨時(shí)隨地發(fā)送文字消息、進(jìn)行群聊、消息群發(fā)等。系統(tǒng)包括客戶(hù)端程序和服務(wù)器端程序,支持局域網(wǎng)和Intent。企業(yè)內(nèi)部員工之間可以在內(nèi)部網(wǎng)覆蓋的任何地方、時(shí)間即時(shí)交流,真正的實(shí)現(xiàn)企業(yè)內(nèi)部協(xié)同工作。大大提高企業(yè)的辦公效率。國(guó)內(nèi)外現(xiàn)狀及發(fā)展趨勢(shì)目前,即時(shí)聊天系統(tǒng)收到人們的普遍歡迎,互聯(lián)網(wǎng)上也推出不少相關(guān)的應(yīng)用程序。目前在互聯(lián)網(wǎng)上受歡迎的即時(shí)通訊軟件包括Q
23、Q、MSN、AOL Instant Messenger、Yahoo! Messenger、NET Messenger Service、Jabber、ICQ等。通常IM服務(wù)會(huì)在使用者通話(huà)清單(類(lèi)似電話(huà)簿)上的某人連上IM時(shí)發(fā)出信息通知使用者,使用者便可據(jù)此與此人透過(guò)Internet或網(wǎng)絡(luò)開(kāi)始進(jìn)行實(shí)時(shí)的IM文字通訊。除了文字外,在頻寬充足的前提下,大部份IM服務(wù)事實(shí)上也提供了視訊通訊的能力。實(shí)時(shí)傳訊與電子郵件最大的不同在于不用等候,不需要每隔兩分鐘就按一次“傳送與接收”,只要兩個(gè)人都在在線(xiàn),就能像多媒體電話(huà)一樣,傳送文字、檔案、聲音、影像給對(duì)方,只要有網(wǎng)絡(luò),無(wú)論對(duì)方在天涯海角或是雙方隔得多遠(yuǎn)都沒(méi)有
24、距離?!爸袊?guó)即時(shí)通訊市場(chǎng)將發(fā)生翻天覆地的變化,當(dāng)然并不是說(shuō)誰(shuí)可以把QQ干掉,QQ依然會(huì)占領(lǐng)很大的市場(chǎng)份額,但是絕對(duì)不是像現(xiàn)在這樣的一家獨(dú)大的壟斷性份額。我認(rèn)為這個(gè)時(shí)間很快就會(huì)來(lái)臨,或許就在今年底或明年?!鼻把呕⒅袊?guó)總裁周鴻祎曾如此充滿(mǎn)期望。2005年Ebay以數(shù)億美金的代價(jià)收購(gòu)了做語(yǔ)音即時(shí)通訊軟件的Skype,此時(shí)Skype并沒(méi)有實(shí)現(xiàn)盈利。之前,搜索引擎巨Google也開(kāi)發(fā)了自己的語(yǔ)音即時(shí)通訊聊天工具Google Talk。國(guó)際巨頭的動(dòng)作預(yù)示著,即時(shí)通訊公司正在向多元化經(jīng)營(yíng)和通訊語(yǔ)音的方向發(fā)展。同樣的變化也發(fā)生在中國(guó),只不過(guò)故事的版本有了變化。2004年微軟的MSN進(jìn)中國(guó)時(shí),簽下了數(shù)家做內(nèi)容的
25、網(wǎng)站進(jìn)行門(mén)戶(hù)式的擴(kuò)張;而騰訊則公開(kāi)宣布要靠即時(shí)通訊多年積攢的用戶(hù)數(shù)做基礎(chǔ),向門(mén)戶(hù)和C2C電子商務(wù)方向進(jìn)軍。新浪的UC則在向視頻增值服務(wù)的方向向前發(fā)展。即時(shí)通訊產(chǎn)業(yè)的明天同樣充滿(mǎn)了變數(shù)。隨著互聯(lián)網(wǎng)的普及和帶寬技術(shù)的發(fā)展,即時(shí)聊天領(lǐng)域競(jìng)爭(zhēng)依然十分激烈。雖然互聯(lián)網(wǎng)的應(yīng)用不斷的推陳出新,像微博、社交網(wǎng)站的出現(xiàn),在一定程度上對(duì)即時(shí)聊天有一些沖擊,但是完全替代即時(shí)聊天是不可能的。人們渴望在現(xiàn)在即時(shí)聊天的基礎(chǔ)上,即時(shí)聊天能不斷的完善與滿(mǎn)足用戶(hù)的需要,使之更為出色和富有競(jìng)爭(zhēng)力。本文的主要工作本文在充分了解時(shí)下流行的即時(shí)聊天系統(tǒng)的基礎(chǔ)上,針對(duì)企業(yè)對(duì)聊天的可控性的要求,在設(shè)計(jì)上采用的是面向?qū)ο蟮慕M建式設(shè)計(jì)方法,詳
26、細(xì)介紹系統(tǒng)的分析與設(shè)計(jì)。本文則主要介紹,用戶(hù)之間的信息同步,用戶(hù)之間可以進(jìn)行信息交互、溝通。使用即時(shí)通訊時(shí),要保證當(dāng)前客戶(hù)端計(jì)算機(jī)登陸指定服務(wù)器,在這里可以進(jìn)行好友的添加,并與對(duì)方進(jìn)行溝通,發(fā)送信息、文件等。本章小結(jié)本章簡(jiǎn)要描述該課題的選題背景、即時(shí)通訊系統(tǒng)的國(guó)內(nèi)外發(fā)展?fàn)顩r與趨勢(shì)、論文的主要內(nèi)容。涉及的相關(guān)技術(shù)與協(xié)議為了保證課題能正常實(shí)施,先來(lái)分析一下課題所需要的相關(guān)技術(shù)和協(xié)議。Java語(yǔ)言技術(shù)基礎(chǔ)經(jīng)過(guò)認(rèn)真的討論分析,綜合各種計(jì)算機(jī)高級(jí)語(yǔ)言的特征和適應(yīng)范圍,最終決定選擇純面向?qū)ο蟮腏ava語(yǔ)言來(lái)完成畢業(yè)論文的設(shè)計(jì),下面就技術(shù)可行性方面,對(duì)Java語(yǔ)言作簡(jiǎn)要介紹。Java的歷史要追溯到1991年
27、,由Patrick Naughton及其伙伴James Gosling 帶領(lǐng)SUN公司的工程師小組想要設(shè)計(jì)一種小型的計(jì)算機(jī)語(yǔ)言,主要用于像有線(xiàn)電視轉(zhuǎn)換盒這類(lèi)的消費(fèi)設(shè)備。由于這些消費(fèi)設(shè)備的處理能力和內(nèi)存都很有限,所以語(yǔ)言必須非常小且能夠生成非常緊湊的代碼。另外,由于不同的廠商會(huì)選擇不同的中央處理器,因此這種語(yǔ)言的關(guān)鍵是不能與任何特定的體系結(jié)構(gòu)捆綁在一起。這種要求代碼小、緊湊、且平臺(tái)無(wú)關(guān),是Java語(yǔ)言設(shè)計(jì)的初衷。1996年初,SUN公司發(fā)布了Java第一版本,就引起了人們的極大興趣。雖然在在前兩個(gè)版本中有很大的局限性,在隨后的幾個(gè)版本的不斷完善后,現(xiàn)在Java語(yǔ)言在業(yè)界起著舉足輕重的作用。Jav
28、a是它以C+為基礎(chǔ),但是卻是一個(gè)全新的軟件開(kāi)發(fā)語(yǔ)言。Java語(yǔ)言具有的簡(jiǎn)單、面向?qū)ο蟮?1大特色 REF _Ref323757239 r 1。Java語(yǔ)言在開(kāi)發(fā)和執(zhí)行過(guò)程中的特點(diǎn)Java是解釋型的高級(jí)編程語(yǔ)言 REF _Ref323758230 r 2,所以Java程序的開(kāi)發(fā)通常需要經(jīng)過(guò)編寫(xiě)源程序、編譯生成字節(jié)碼和運(yùn)行三個(gè)過(guò)程。這里要提到,Java應(yīng)用程序的開(kāi)發(fā)周期包括編譯、下載、解釋和執(zhí)行幾個(gè)部分。Java編譯程序?qū)ava源程序翻譯為JVM可執(zhí)行代碼字節(jié)碼。這一編譯過(guò)程同C/C+的編譯有些不同。當(dāng)C編譯器編譯生成一個(gè)對(duì)象的代碼時(shí),該代碼是為在某一特定硬件平臺(tái)運(yùn)行而產(chǎn)生的。因此,在編譯過(guò)程中
29、,編譯程序通過(guò)查表將所有對(duì)符號(hào)的引用轉(zhuǎn)換為特定的內(nèi)存偏移量,以保證程序運(yùn)行。Java編譯器卻不將對(duì)變量和方法的引用編譯為數(shù)值引用,也不確定程序執(zhí)行過(guò)程中的內(nèi)存布局,而是將這些符號(hào)引用信息保留在字節(jié)碼中,由解釋器在運(yùn)行過(guò)程中創(chuàng)立內(nèi)存布局,然后再通過(guò)查表來(lái)確定一個(gè)方法所在的地址。這樣就有效的保證了Java的可移植性和安全性。Java的另外一個(gè)比較重要的概念就是Java虛擬機(jī):Java虛擬機(jī)(JVM)是可運(yùn)行Java代碼的假想計(jì)算機(jī)。只要根據(jù)JVM規(guī)格描述將解釋器移植到特定的計(jì)算機(jī)上,就能保證經(jīng)過(guò)編譯的任何Java代碼能夠在該系統(tǒng)上運(yùn)行。運(yùn)行JVM字節(jié)碼的工作是由解釋器來(lái)完成的。解釋執(zhí)行過(guò)程分代碼的
30、裝入、代碼的校驗(yàn)和代碼的執(zhí)行三部進(jìn)行。JVM的設(shè)計(jì)目標(biāo)是提供一個(gè)基于抽象規(guī)格描述的計(jì)算機(jī)模型,為解釋程序開(kāi)發(fā)人員提很好的靈活性,同時(shí)也確保Java代碼可在符合該規(guī)范的任何系統(tǒng)上運(yùn)行。JVM對(duì)其實(shí)現(xiàn)的某些方面給出了具體的定義,特別是對(duì)Java可執(zhí)行代碼,即字節(jié)碼(Bytecode)的格式給出了明確的規(guī)格。Java語(yǔ)言本身的特點(diǎn)Java是一種跨平臺(tái),適合于分布式計(jì)算環(huán)境的面向?qū)ο缶幊陶Z(yǔ)言 REF _Ref323757239 r 1。具體來(lái)說(shuō),它具有如下特性:簡(jiǎn)單性、面向?qū)ο?、網(wǎng)絡(luò)性、解釋型、健壯性、安全性、體系結(jié)構(gòu)獨(dú)立、可移植性、高性能、多線(xiàn)程、動(dòng)態(tài)性等。下面將重點(diǎn)介紹Java語(yǔ)言的簡(jiǎn)單性、面向?qū)?/p>
31、象、體結(jié)構(gòu)中立性、可移植性、多線(xiàn)程、可靠和安全等特性。簡(jiǎn)單性Java語(yǔ)法就是C+語(yǔ)法的一個(gè)“純凈”版本。Java剔除了C+中許多很少使用、難以理解、易混淆的特性。這里沒(méi)有頭文件、指針運(yùn)算(甚至指針語(yǔ)法)、結(jié)構(gòu)、聯(lián)合、操作重載符、虛基類(lèi)等等。簡(jiǎn)單的另外一個(gè)方面是小,可支持開(kāi)發(fā)能夠在小型機(jī)器上獨(dú)立運(yùn)行的軟件?;镜慕忉屍饕约邦?lèi)支持大約僅為40kb,再加上基礎(chǔ)的標(biāo)準(zhǔn)類(lèi)庫(kù)和對(duì)線(xiàn)程的支持大約需要增加175kb。面向?qū)ο笮悦嫦驅(qū)ο蟪绦蛟O(shè)計(jì)是當(dāng)今主流的程序設(shè)計(jì)范型。面向?qū)ο蟮某绦蛟O(shè)計(jì)是由對(duì)象組成的,每個(gè)對(duì)象包含對(duì)用戶(hù)公開(kāi)的特定功能部分和隱藏的實(shí)現(xiàn)部分。其實(shí)現(xiàn)實(shí)世界模型的自然延伸?,F(xiàn)實(shí)世界中任何實(shí)體都可以看作
32、是對(duì)象。對(duì)象之間通過(guò)消息相互作用。另外,現(xiàn)實(shí)世界中任何實(shí)體都可歸屬于某類(lèi)事物,任何對(duì)象都是某一類(lèi)事物的實(shí)例。如果說(shuō)傳統(tǒng)的過(guò)程式編程語(yǔ)言是以過(guò)程為中心以算法為驅(qū)動(dòng)的話(huà),面向?qū)ο蟮木幊陶Z(yǔ)言則是以對(duì)象為中心以消息為驅(qū)動(dòng)。它將重點(diǎn)放在數(shù)據(jù)(即對(duì)象)和對(duì)象的接口上。面向?qū)ο笫冀K關(guān)注的是所要抽象的對(duì)象,然后才是實(shí)現(xiàn)的方法。在過(guò)去的30年里,面向?qū)ο笠呀?jīng)證明了自身的價(jià)值,一種現(xiàn)代的程序設(shè)計(jì)技術(shù)簡(jiǎn)直讓人難以置信。Java的面向?qū)ο筇匦耘cC+旗鼓相當(dāng)。Java與C+的主要不同在于多繼承,在Java中,取而代之是簡(jiǎn)單的接口概念,以及Java的元類(lèi)(metaclass)模型。封裝、繼承、多態(tài)是面向?qū)ο笳Z(yǔ)言的三大特性
33、。Java作為面向?qū)ο缶幊陶Z(yǔ)言很好的支持這三種特性?,F(xiàn)實(shí)世界的對(duì)象均有屬性和行為,可以映射到計(jì)算機(jī)程序上,屬性表示對(duì)象的數(shù)據(jù),行為表示對(duì)象的方法。封裝形式看只不過(guò)是將數(shù)據(jù)和行為組合在一個(gè)包中,并對(duì)對(duì)象的使用者隱藏了數(shù)據(jù)的實(shí)現(xiàn)方式。對(duì)象的數(shù)據(jù)稱(chēng)為實(shí)例域(instance fields),操縱數(shù)據(jù)的過(guò)程稱(chēng)為方(method)。繼承讓人們可以在已存在類(lèi)的基礎(chǔ)上構(gòu)造一個(gè)新類(lèi)。繼承已存在的類(lèi)就是復(fù)用這些類(lèi)的方法和域。在此基礎(chǔ)上,可以添加一些新的方法和域,以滿(mǎn)足新的需求。這是Java程序設(shè)計(jì)中的一項(xiàng)核心技術(shù)。多態(tài)是一種運(yùn)行期行為,不是編譯期的行為,是指一個(gè)對(duì)象變量可以引用多種實(shí)際類(lèi)型的現(xiàn)象。在運(yùn)行時(shí)能自動(dòng)
34、地選擇調(diào)用哪個(gè)方法的現(xiàn)象。體系機(jī)構(gòu)中立性編譯器會(huì)為Java代碼生成一個(gè)體系結(jié)構(gòu)中立的目標(biāo)文件格式,這是一種編譯過(guò)的代碼,只要有Java運(yùn)行時(shí)系統(tǒng),就可以在許多處理器上運(yùn)行。Java編譯器通過(guò)生成與特定平臺(tái)計(jì)算機(jī)無(wú)關(guān)的字節(jié)碼指令來(lái)實(shí)現(xiàn)這一特性。精心設(shè)計(jì)的字節(jié)碼不僅可以很容易地在任何機(jī)器上解釋執(zhí)行,而且還可以迅速地翻譯成本地機(jī)器的代碼。解釋字節(jié)碼是依賴(lài)于虛擬機(jī)的,虛擬機(jī)可以檢測(cè)指令序列,以增強(qiáng)期安全性。有些程序還以快速地生成字節(jié)碼,并動(dòng)態(tài)增強(qiáng)所運(yùn)行程序的處理能力。可移植性與C和C+不同,Java規(guī)范沒(méi)有“依賴(lài)具體實(shí)現(xiàn)”的地方?;镜臄?shù)據(jù)類(lèi)型的大小以及有關(guān)的算法都做了明確的說(shuō)明。例如,Java中的i
35、nt永遠(yuǎn)為32位的整數(shù),而在C/C+中,int可能是16位整數(shù)、32位整數(shù),也可能是編譯器提供商指定的其他大小。惟一的限制只是int類(lèi)型的大小不能低于short int,并且不能高于long int。在Java中,數(shù)據(jù)類(lèi)型具有固定的大小,這消除了代碼移植時(shí)令人頭痛的主要問(wèn)題。二進(jìn)制數(shù)據(jù)以固定的格式進(jìn)行的存儲(chǔ)和傳輸,消除了字節(jié)順序的困擾。字符串是用標(biāo)準(zhǔn)的Unicode格式存儲(chǔ)的。多線(xiàn)程通常,一個(gè)程序可以同時(shí)執(zhí)行多個(gè)任務(wù)時(shí),每個(gè)任務(wù)稱(chēng)為一個(gè)線(xiàn)程。線(xiàn)程可以帶來(lái)更好的交互響應(yīng)和實(shí)時(shí)行為。與進(jìn)程相比較線(xiàn)程是輕量級(jí)的進(jìn)程,創(chuàng)建、撤銷(xiāo)一個(gè)線(xiàn)程比啟動(dòng)新進(jìn)程的開(kāi)銷(xiāo)要小的多。Java處理多線(xiàn)程非常便捷。只要操作系
36、統(tǒng)支持,Java中的線(xiàn)程就可以利用多個(gè)處理器。Java在兩方面支持多線(xiàn)程。一方面,Java環(huán)境本身就是多線(xiàn)程的。若干個(gè)系統(tǒng)線(xiàn)程運(yùn)行負(fù)責(zé)必要的無(wú)用單元回收,系統(tǒng)維護(hù)等系統(tǒng)級(jí)操作;另一方面,Java語(yǔ)言?xún)?nèi)置多線(xiàn)程控制,可以大大簡(jiǎn)化多線(xiàn)程應(yīng)用程序開(kāi)發(fā)。Java提供了一個(gè)類(lèi)Thread,由它負(fù)責(zé)啟動(dòng)運(yùn)行,終止線(xiàn)程,并可檢查線(xiàn)程狀態(tài)。Java的線(xiàn)程還包括一組同步原語(yǔ)。這些原語(yǔ)負(fù)責(zé)對(duì)線(xiàn)程實(shí)行并發(fā)控制。利用Java的多線(xiàn)程編程接口,開(kāi)發(fā)人員可以方便得寫(xiě)出支持多線(xiàn)程的應(yīng)用程序,提高程序執(zhí)行效率。必須注意地是,Java的多線(xiàn)程支持在一定程度上受運(yùn)行時(shí)支持平臺(tái)的限制。例如,如果操作系統(tǒng)本身不支持多線(xiàn)程,Java的
37、多線(xiàn)程特性可能就表現(xiàn)不出來(lái)??煽啃耘c安全性Java的設(shè)計(jì)目標(biāo)之一在于使得Java編寫(xiě)的程序具有多方面的可靠性。Java投入了大量的精力進(jìn)行早期的問(wèn)題檢測(cè)、后期動(dòng)態(tài)的檢測(cè),并消除了有出錯(cuò)傾向的狀態(tài)。Java和C+最大的不同在于Java采用指針模型可以消除重寫(xiě)內(nèi)存和損壞數(shù)據(jù)的可能性。Java編譯器能夠檢測(cè)許多在其他語(yǔ)言中僅在運(yùn)行時(shí)刻才能夠檢測(cè)出來(lái)的問(wèn)題。Java是一種沒(méi)有顯式指針的語(yǔ)言,但具備指針的能力,如鏈表。Java是絕對(duì)安全的,它能夠永遠(yuǎn)存取一個(gè)“壞的”指針,造成內(nèi)存分配的錯(cuò)誤,也不必防范內(nèi)存泄露。Java適用于網(wǎng)絡(luò)/分布式環(huán)境。為了達(dá)到這個(gè)目的,在安全方面投入了很大的精力。使用Java可以
38、構(gòu)建防病毒、防纂改的系統(tǒng)。Java能夠防范各種襲擊,其中包括:運(yùn)行時(shí)的堆棧溢出。如蠕蟲(chóng)等病毒常用的襲擊手段;在自己的內(nèi)存空間之外破壞內(nèi)存;未經(jīng)授權(quán)的讀寫(xiě)文件。Java還有數(shù)字簽名類(lèi)的概念。通過(guò)數(shù)字簽名類(lèi),可以確定類(lèi)的作者。如果信任這個(gè)類(lèi)的作者,這個(gè)類(lèi)就可以在機(jī)器上擁有更多的權(quán)限。Java與Hibernate整合使用訪(fǎng)問(wèn)數(shù)據(jù)庫(kù)ORM數(shù)據(jù)庫(kù)操作技術(shù)ORM是一種在關(guān)系型數(shù)據(jù)庫(kù)上構(gòu)造面向?qū)ο髷?shù)據(jù)存儲(chǔ)的技術(shù),這種技術(shù)又被稱(chēng)為偽面向?qū)ο髷?shù)據(jù)庫(kù)技術(shù)。該技術(shù)提供一個(gè)軟件框架,透明的實(shí)現(xiàn)對(duì)象保存與維護(hù)。在底層上,對(duì)象保存時(shí),對(duì)象能拆分成不同的數(shù)據(jù)記錄,并規(guī)則地保存在關(guān)系型數(shù)據(jù)庫(kù)中;而數(shù)據(jù)的檢索式,再實(shí)現(xiàn)由關(guān)系型
39、數(shù)據(jù)庫(kù)中的記錄到特定對(duì)象的裝配工作。ORM模塊作用示意圖如2-1所示。圖21偽面向?qū)ο髷?shù)據(jù)庫(kù)系統(tǒng)結(jié)構(gòu)示意圖RDB為關(guān)系型數(shù)據(jù)庫(kù),DBMS是關(guān)系型數(shù)據(jù)庫(kù)管理系統(tǒng),兩者整體上構(gòu)成傳統(tǒng)上的關(guān)系數(shù)據(jù)庫(kù)系統(tǒng) REF _Ref325900592 r 3。ORM是對(duì)關(guān)系映射模塊,該模塊和傳統(tǒng)的關(guān)系型數(shù)據(jù)庫(kù)系統(tǒng)作為整體形成偽面向?qū)ο髷?shù)據(jù)庫(kù)系統(tǒng)。Hibernate簡(jiǎn)介本系統(tǒng)采用了Hibernate的ORM模塊,通過(guò)該模塊可以為多數(shù)主流關(guān)系型數(shù)據(jù)庫(kù),如Oracle、MySQL、SQL Server等,提供方便的面向?qū)ο蟛僮鞣椒?。此模塊只需要打包開(kāi)發(fā)的應(yīng)用軟件中,不需要在數(shù)據(jù)庫(kù)上安裝,應(yīng)用軟件在運(yùn)行過(guò)程中會(huì)使用該模
40、塊操作數(shù)據(jù)庫(kù)。 Hibernate本質(zhì)上也是一種基于JDBC的數(shù)據(jù)庫(kù)操作技術(shù)。它通過(guò)JDBC的封裝,屏蔽了JDBC API 的操作細(xì)節(jié),提供一種方便的面向?qū)ο髷?shù)據(jù)庫(kù)操作接口。它實(shí)現(xiàn)了面向?qū)ο蟛僮髋c面向關(guān)系操作的轉(zhuǎn)變,將應(yīng)用軟件提出的面向?qū)ο髷?shù)據(jù)庫(kù)操作請(qǐng)求,轉(zhuǎn)變?yōu)殛P(guān)系型的SQL語(yǔ)句,然后對(duì)數(shù)據(jù)庫(kù)進(jìn)行操作,并將數(shù)據(jù)庫(kù)返回結(jié)果封裝成適當(dāng)?shù)膶?duì)象,返回作為數(shù)據(jù)使用者的應(yīng)用軟件。圖2-2演示了Hibernate的操作原理。圖22 Hibernate核心作用示意圖Hibernate的核心作用有兩個(gè)方面:首先將面向?qū)ο蟮南鄳?yīng)概念對(duì)應(yīng)翻譯成關(guān)系型數(shù)據(jù)庫(kù)中的概念,例如將對(duì)象翻譯成表的記錄:將類(lèi)翻譯成數(shù)據(jù)庫(kù)中的表;
41、將類(lèi)和類(lèi)間的關(guān)聯(lián)關(guān)系翻譯成為表和表間的關(guān)系。其次Hibernate承擔(dān)著將面向?qū)ο蟛僮鞣g成SQL語(yǔ)句為標(biāo)準(zhǔn)的關(guān)系型操作。XMLXML是可擴(kuò)展標(biāo)記語(yǔ)言,一種非常有用的描述結(jié)構(gòu)化信息的技術(shù) REF _Ref325901157 r 4。XML工具使處理和轉(zhuǎn)化信息十分容易。只需要在特定的領(lǐng)域標(biāo)準(zhǔn)和代碼庫(kù)就能有效地使用XML。XML與Java配合的相當(dāng)好。從20世紀(jì)90年代末以來(lái),IBM ,Apache和其他許多公司一直在幫助開(kāi)發(fā)用于XML處理的高質(zhì)量Java庫(kù)。Sun公司從JDK SE 1.4 開(kāi)始將大部分重要的代碼庫(kù)都整合到了Java平臺(tái)的標(biāo)準(zhǔn)版中。此外也有一些組織或個(gè)人開(kāi)發(fā)出了一些第三方類(lèi)庫(kù),使
42、XML的解析和創(chuàng)建都十分的簡(jiǎn)單易行。比如Jdom、dom4j等,都是非常實(shí)用的類(lèi)庫(kù),給處理XML帶來(lái)了很大的幫助。XML文件的格式非常直觀,它與HTML文件非常相似。XML和HTML是標(biāo)準(zhǔn)通用語(yǔ)言的衍生語(yǔ)言。只不過(guò)XML語(yǔ)言對(duì)語(yǔ)法的要求給位嚴(yán)格,并且其中的元素可以自己定義非常的靈活與方便。要處理XML文檔,就要先解析(parse)它。解析器一種程序,它讀入一個(gè)文件,確認(rèn)這個(gè)文件具有正確的格式,然后將其分解稱(chēng)為各種元素,是的程序員能夠得到這些元素。Java庫(kù)提供了兩種XML解析器:像文檔對(duì)象模型(DOM)解析器這樣的樹(shù)形解析器(tree parser),它們將讀入的XML文檔轉(zhuǎn)換成為樹(shù)結(jié)構(gòu)。像用
43、于XML的簡(jiǎn)單API(Simple API for XML,SAX)解析器這樣的流機(jī)制解析器,它們?cè)谧x入XML文檔時(shí)生成相應(yīng)的事件。除了Java庫(kù)中提供的解析器,還有現(xiàn)在比較流行的第三方解析器,如jdom、dom4j等,這些類(lèi)庫(kù)能讓程序員以更加面向?qū)ο蟮姆绞饺ソ馕鯴ML文檔,程序員只要知道XML中相應(yīng)的格式,就可以解析出文檔的內(nèi)容,同樣也是程序員創(chuàng)建XML中的元素更加的方便與快捷,大大提高了開(kāi)發(fā)效率。相關(guān)的協(xié)議介紹TCP/IP協(xié)議TCP:Transmission Control Protocol 傳輸控制協(xié)議TCP是一種面向連接(連接導(dǎo)向)的、可靠的、基于字節(jié)流的運(yùn)輸層(Transport l
44、ayer)通信協(xié)議 REF _Ref325901325 r 5。在簡(jiǎn)化的計(jì)算機(jī)網(wǎng)絡(luò)OSI模型中,它完成第四層傳輸層所指定的功能。TCP作用在因特網(wǎng)協(xié)議族(Internet protocol suite)中,TCP層是位于IP層之上,應(yīng)用層之下的運(yùn)輸層。不同主機(jī)的應(yīng)用層之間經(jīng)常需要可靠的、像管道一樣的連接,但是IP層不提供這樣的流機(jī)制,而是提供不可靠的包交換。應(yīng)用層向TCP層發(fā)送用于網(wǎng)間傳輸?shù)?、?位字節(jié)表示的數(shù)據(jù)流,然后TCP把數(shù)據(jù)流分割成適當(dāng)長(zhǎng)度的報(bào)文段(通常受該計(jì)算機(jī)連接的網(wǎng)絡(luò)的數(shù)據(jù)鏈路層的最大傳送單元(MTU)的限制)。之后TCP把結(jié)果包傳給IP層,由它來(lái)通過(guò)網(wǎng)絡(luò)將包傳送給接收端實(shí)體的T
45、CP層。TCP為了保證不發(fā)生丟包,就給每個(gè)字節(jié)一個(gè)序號(hào),同時(shí)序號(hào)也保證了傳送到接收端實(shí)體的包的按序接收。然后接收端實(shí)體對(duì)已成功收到的字節(jié)發(fā)回一個(gè)相應(yīng)的確認(rèn)(ACK);如果發(fā)送端實(shí)體在合理的往返時(shí)延(RTT)內(nèi)未收到確認(rèn),那么對(duì)應(yīng)的數(shù)據(jù)(假設(shè)丟失了)將會(huì)被重傳。TCP用一個(gè)校驗(yàn)和函數(shù)來(lái)檢驗(yàn)數(shù)據(jù)是否有錯(cuò)誤;在發(fā)送和接收時(shí)都要計(jì)算和校驗(yàn)。首先,TCP建立連接之后,通信雙方都同時(shí)可以進(jìn)行數(shù)據(jù)的傳輸,其次,它是全雙工的;在保證可靠性上,采用超時(shí)重傳和捎帶確認(rèn)機(jī)制。在流量控制上,采用滑動(dòng)窗口協(xié)議,協(xié)議中規(guī)定,對(duì)于窗口內(nèi)未經(jīng)確認(rèn)的分組需要重傳。在擁塞控制上,采用廣受好評(píng)的TCP擁塞控制算法(也稱(chēng)AIMD算法
46、),該算法主要包括三個(gè)主要部分:加性增、乘性減、慢啟動(dòng)對(duì)超時(shí)事件做出反應(yīng)。UDP協(xié)議(用戶(hù)數(shù)據(jù)報(bào)協(xié)議)UDP協(xié)議簡(jiǎn)介UDP 是User Datagram Protocol的簡(jiǎn)稱(chēng), 中文名是用戶(hù)數(shù)據(jù)包協(xié)議,是 OSI 參考模型中一種無(wú)連接的傳輸層協(xié)議,提供面向事務(wù)的簡(jiǎn)單不可靠信息傳送服務(wù) REF _Ref325901325 r 5。它是IETF RFC 768是UDP的正式規(guī)范。用戶(hù)數(shù)據(jù)包協(xié)議UDP是OSI參考模型中一種無(wú)連接的傳輸層協(xié)議,提供面向事務(wù)的簡(jiǎn)單不可靠信息傳送服務(wù)。UDP 協(xié)議基本上是IP協(xié)議與上層協(xié)議的接口。UDP協(xié)議適用端口分別運(yùn)行在同一臺(tái)設(shè)備上的多個(gè)應(yīng)用程序。簡(jiǎn)介UDP協(xié)議的全
47、稱(chēng)是用戶(hù)數(shù)據(jù)包協(xié)議,在網(wǎng)絡(luò)中它與TCP協(xié)議一樣用于處理數(shù)據(jù)包,是一種無(wú)連接的協(xié)議。在OSI模型中,在第四層傳輸層,處于IP協(xié)議的上一層。UDP有不提供數(shù)據(jù)包分組、組裝和不能對(duì)數(shù)據(jù)包進(jìn)行排序的缺點(diǎn),也就是說(shuō),當(dāng)報(bào)文發(fā)送之后,是無(wú)法得知其是否安全完整到達(dá)的。UDP用來(lái)支持那些需要在計(jì)算機(jī)之間傳輸數(shù)據(jù)的網(wǎng)絡(luò)應(yīng)用。包括網(wǎng)絡(luò)視頻會(huì)議系統(tǒng)在內(nèi)的眾多的客戶(hù)/服務(wù)器模式的網(wǎng)絡(luò)應(yīng)用都需要使用UDP協(xié)議。UDP協(xié)議從問(wèn)世至今已經(jīng)被使用了很多年,雖然其最初的光彩已經(jīng)被一些類(lèi)似協(xié)議所掩蓋,但是即使是在今天,UDP仍然不失為一項(xiàng)非常實(shí)用和可行的網(wǎng)絡(luò)傳輸層協(xié)議。與所熟知的TCP(傳輸控制協(xié)議)協(xié)議一樣,UDP協(xié)議直接位于
48、IP(網(wǎng)際協(xié)議)協(xié)議的頂層。根據(jù)OSI(開(kāi)放系統(tǒng)互連)參考模型,UDP和TCP都屬于傳輸層協(xié)議。UDP協(xié)議的主要作用是將網(wǎng)絡(luò)數(shù)據(jù)流量壓縮成數(shù)據(jù)包的形式。一個(gè)典型的數(shù)據(jù)包就是一個(gè)二進(jìn)制數(shù)據(jù)的傳輸單位。每一個(gè)數(shù)據(jù)包的前8個(gè)字節(jié)用來(lái)包含報(bào)頭信息,剩余字節(jié)則用來(lái)包含具體的傳輸數(shù)據(jù)。使用UDP在選擇使用協(xié)議的時(shí)候,選擇UDP必須要謹(jǐn)慎。在網(wǎng)絡(luò)質(zhì)量令人不十分滿(mǎn)意的環(huán)境下,UDP協(xié)議數(shù)據(jù)包丟失會(huì)比較嚴(yán)重。但是由于UDP的特性:它不屬于連接型協(xié)議,因而具有資源消耗小,處理速度快的優(yōu)點(diǎn),所以通常音頻、視頻和普通數(shù)據(jù)在傳送時(shí)使用UDP較多,因?yàn)樗鼈兗词古紶杹G失一兩個(gè)數(shù)據(jù)包,也不會(huì)對(duì)接收結(jié)果產(chǎn)生太大影響。比如我們聊
49、天用的ICQ和QQ就是使用的UDP協(xié)議。UDP報(bào)頭UDP報(bào)頭由4個(gè)域組成,其中每個(gè)域各占用2個(gè)字節(jié),具體如下:源端口號(hào)目標(biāo)端口號(hào)數(shù)據(jù)報(bào)長(zhǎng)度校驗(yàn)值UDP協(xié)議使用端口號(hào)為不同的應(yīng)用保留其各自的數(shù)據(jù)傳輸通道。UDP和TCP協(xié)議正是采用這一機(jī)制實(shí)現(xiàn)對(duì)同一時(shí)刻內(nèi)多項(xiàng)應(yīng)用同時(shí)發(fā)送和接收數(shù)據(jù)的支持。因?yàn)榱奶炱陂g一般對(duì)數(shù)據(jù)的可靠性要求不高,所以在這里用UDP協(xié)議。UDP協(xié)議在Java編程中的應(yīng)用Java中用于無(wú)連接的數(shù)據(jù)報(bào)通信的類(lèi)有兩個(gè):DatagramPacket類(lèi)和DatagramSocket類(lèi) REF _Ref325901485 r 6。其中DatagramPacket類(lèi)用于讀取數(shù)據(jù)等信息,Datagr
50、amSocket類(lèi)用于實(shí)現(xiàn)數(shù)據(jù)報(bào)的發(fā)送和接受過(guò)程?,F(xiàn)在主要介紹一下DatagramPacket類(lèi)與DatagramSocket類(lèi)。DatagramPacket類(lèi)的構(gòu)造函數(shù)有兩個(gè):public DatagramPacket(byte buf,int length);public DatagramPacket(byte buf,int length,InetAddress addr,int port);第一個(gè)是用來(lái)創(chuàng)建接收數(shù)據(jù)報(bào)的對(duì)象,它的兩個(gè)參數(shù)分別代表接收數(shù)據(jù)報(bào)的數(shù)據(jù)部分的字節(jié)數(shù)組和所要接收的數(shù)據(jù)報(bào)的長(zhǎng)度;DatagramPacket類(lèi)的第二個(gè)構(gòu)造函數(shù)用來(lái)創(chuàng)建發(fā)送給遠(yuǎn)程系統(tǒng)的數(shù)據(jù)報(bào),它的第一個(gè)
51、參數(shù)buf是存放欲發(fā)送的編碼后的報(bào)文的字節(jié)數(shù)組,第二個(gè)參數(shù)length指明字節(jié)數(shù)組的長(zhǎng)度,即數(shù)據(jù)報(bào)的18大小,第三個(gè)參數(shù)指定所發(fā)送的數(shù)據(jù)報(bào)的目的地,其接收者的IP地址,最后一個(gè)參數(shù)port標(biāo)志本數(shù)據(jù)報(bào)發(fā)送到目標(biāo)主機(jī)的哪個(gè)端口。DatagramSocket類(lèi)有三個(gè)構(gòu)造函數(shù):public DatagramSocket ();public DatagramSocket(int port);public DatagramSocket(int port ,InetAddress localAddr);DatagramSocket類(lèi)有三個(gè)構(gòu)造函數(shù),第一個(gè)用于創(chuàng)建一個(gè)數(shù)據(jù)報(bào)Socket并將它連接在本地主機(jī)的
52、任何一個(gè)可用的端口上;第二個(gè)構(gòu)造函數(shù)在指定的端口處創(chuàng)建一個(gè)數(shù)據(jù)報(bào)Socket對(duì)象;第三個(gè)構(gòu)造函數(shù)用于在多IP地址主機(jī)上創(chuàng)建數(shù)據(jù)報(bào)Socket,它的第二個(gè)參數(shù)具體指明使用哪個(gè)IP地址。這三個(gè)構(gòu)造函數(shù)都拋出IOException異常,用來(lái)控制在創(chuàng)建DatagramSocket類(lèi)對(duì)象時(shí)可能產(chǎn)生的異常情況,如下:public synchronized void receive(DatagramPacket p)throws IOException;public void send(DatagramPacket p)throws IOException。receive()和send()是Datagram
53、Socket類(lèi)中數(shù)據(jù)報(bào)套接字用來(lái)實(shí)現(xiàn)數(shù)據(jù)報(bào)傳送和接收的兩個(gè)重要方法。其中receive()方法將使程序的線(xiàn)程一直處于阻塞狀態(tài),直至從當(dāng)前Socket中接收到數(shù)據(jù)報(bào)文、發(fā)送者等信息,這些接收到的信息將存儲(chǔ)在receive()方法的參數(shù)DatagramPacket對(duì)象p的存儲(chǔ)機(jī)構(gòu)中。需要注意的是由于數(shù)據(jù)報(bào)是不可靠的數(shù)據(jù)通信方式,receive()方法不一定能讀到數(shù)據(jù),為防止線(xiàn)程死掉,應(yīng)該設(shè)置超時(shí)參數(shù)(timeout)。Send()方法將其參數(shù)DatagramPacket對(duì)象p中包含的數(shù)據(jù)報(bào)文發(fā)送到所指定的IP地址主機(jī)的指定端口。這兩個(gè)方法都可能產(chǎn)生輸入/輸出異常,所以都拋出IOException異
54、常。然后,再介紹一下UDP的編程實(shí)現(xiàn)數(shù)據(jù)報(bào)的發(fā)送過(guò)程可簡(jiǎn)單描述為如下的步驟:創(chuàng)建DatagramPacket對(duì)象,使其中包含如下的信息:要發(fā)送的數(shù)據(jù);數(shù)據(jù)報(bào)分組長(zhǎng)度;發(fā)送目的地的主機(jī)IP地址和目的端口號(hào);在指定的或可用的本機(jī)端口創(chuàng)建DatagramSocket對(duì)象;調(diào)用該DatagramSocket的send()方法,以DatagramPacket對(duì)象為參數(shù)發(fā)送數(shù)據(jù)報(bào)。數(shù)據(jù)報(bào)的發(fā)送過(guò)程可簡(jiǎn)單表述為如下的步驟:創(chuàng)建一個(gè)用于接收數(shù)據(jù)報(bào)的DatagramPacket對(duì)象,其中包含空白數(shù)據(jù)緩沖區(qū)和指定數(shù)據(jù)報(bào)分組長(zhǎng)度;在指定的或可用的本機(jī)端口創(chuàng)建DatagramSocket對(duì)象;調(diào)用DatagramSo
55、cket對(duì)象的receive()方法,以DatagramPacket對(duì)象為參數(shù)接收數(shù)據(jù)報(bào),接收到的信息有:收到的數(shù)據(jù)報(bào)文內(nèi)容;發(fā)送端的主機(jī)IP址;發(fā)送端主機(jī)的發(fā)送端口號(hào)。TCP協(xié)議與UDP協(xié)議的比較分析可知,TCP協(xié)議比UDP協(xié)議復(fù)雜得多,現(xiàn)在從協(xié)議的應(yīng)用范圍說(shuō)明他們的使用范圍。TCP協(xié)議與UDP協(xié)議特點(diǎn)比較TCP協(xié)議是一種面向連接的協(xié)議,而UDP協(xié)議是無(wú)連接的協(xié)議。這其中的區(qū)別在于:第一,TCP協(xié)議是以連接作為協(xié)議數(shù)據(jù)的最終目標(biāo)的。UDP協(xié)議則是以目標(biāo)端口作為協(xié)議數(shù)據(jù)的最終目標(biāo)。因此,TCP的協(xié)議端口是可以復(fù)用的,UDP協(xié)議的端口在同一時(shí)間則只能為一個(gè)應(yīng)用程序所用。第二,一個(gè)連接是由兩個(gè)端點(diǎn)
56、構(gòu)成的。要使用TCP進(jìn)行通信必須先在通信雙方之間建立連接,連接的兩端必須就連接的一些問(wèn)題進(jìn)行協(xié)商(如最大數(shù)據(jù)段長(zhǎng)度、窗口大小、初始序列號(hào)等),并為該連接分配一定的資源(緩沖區(qū))。UDP協(xié)議則不需要這個(gè)過(guò)程,可以直接發(fā)送和接受數(shù)據(jù)。TCP協(xié)議提供的是可靠的傳輸服務(wù),而UDP協(xié)議提供的是不可靠的服務(wù)。使用不可靠的服務(wù)進(jìn)行數(shù)據(jù)傳輸時(shí),數(shù)據(jù)可能會(huì)丟失、失序、重復(fù)等。而可靠的服務(wù)服務(wù)能保證發(fā)送方發(fā)送數(shù)據(jù)能原樣到達(dá)接收方。TCP協(xié)議提供的是面向字節(jié)流的服務(wù)。應(yīng)用程序只需要將要傳輸?shù)臄?shù)據(jù)以字節(jié)流的形式提交給TCP協(xié)議,在連接的另一端,數(shù)據(jù)以同樣的字節(jié)流順序出現(xiàn)在接收程序中,而UDP協(xié)議的傳輸單位是數(shù)據(jù)塊,一
57、個(gè)數(shù)據(jù)塊只能封裝在一個(gè)UDP數(shù)據(jù)包中。TCP協(xié)議與UDP協(xié)議應(yīng)用的比較根據(jù)上面的分析,現(xiàn)在來(lái)看看兩種協(xié)議適合于哪些場(chǎng)合。因?yàn)門(mén)CP協(xié)議提供了可靠的面向字節(jié)流的服務(wù),而且有一套的高效的機(jī)制保證數(shù)據(jù)的高效傳輸,所以對(duì)于有大量數(shù)據(jù)需要進(jìn)行可靠傳輸?shù)膽?yīng)用是很適合的,因?yàn)閼?yīng)用程序不需要關(guān)心如何保證數(shù)據(jù)傳輸?shù)目煽啃?,如何進(jìn)行超時(shí)重發(fā)等。這種應(yīng)用的典型例子就是文件傳輸協(xié)議(FTP)。由于TCP協(xié)議要先建立連接之后才能進(jìn)行通信,而連接的建立過(guò)程需要一定的時(shí)間。所以如果應(yīng)用程序只有少量數(shù)據(jù)需要傳輸則不適合使用TCP協(xié)議,因?yàn)檫B接建立的開(kāi)銷(xiāo)大于其方便性的優(yōu)點(diǎn)。但對(duì)于雖然數(shù)據(jù)量少但需要時(shí)間較長(zhǎng)且可靠性要求高的應(yīng)用T
58、CP也是比較適合的。Telnet就是這種應(yīng)用的一個(gè)例子。實(shí)時(shí)應(yīng)用不管數(shù)據(jù)量大小,不管對(duì)可靠性要求高低都不適合使用TCP協(xié)議,因?yàn)門(mén)CP協(xié)議對(duì)數(shù)據(jù)的傳輸有相應(yīng)的程序,只有前面的傳輸成功才會(huì)開(kāi)始后面的數(shù)據(jù)傳送傳送。另外,由于TCP協(xié)議是面向連接的,一個(gè)連接必須且只能有兩個(gè)端點(diǎn)。所以對(duì)于多個(gè)實(shí)體間的多播式的應(yīng)用無(wú)法使用TCP協(xié)議進(jìn)行通信,因?yàn)閷?duì)于n個(gè)實(shí)體間的通信需要n(n-1)/2個(gè)連接。對(duì)于不適合使用TCP協(xié)議的應(yīng)用就只能使用UDP協(xié)議了,使用UDP協(xié)議進(jìn)行通信時(shí)應(yīng)用程序必須自己處理下列問(wèn)題。應(yīng)用程序必須自己提供機(jī)制來(lái)保證可靠性。應(yīng)用程序必須有自己的超時(shí)重發(fā)機(jī)制、數(shù)據(jù)失序的處理、流量控制等。當(dāng)然對(duì)
59、于一些可靠性要求不高的應(yīng)用可以不用這些機(jī)制,但通常都需要區(qū)分?jǐn)?shù)據(jù)的先后關(guān)系。應(yīng)用程序必須機(jī)自己處理大塊數(shù)據(jù)的分割,以讓其能封裝在一個(gè)UDP數(shù)據(jù)包中。在接收方還必須再將再次將分割的數(shù)據(jù)進(jìn)行重組。綜上,可以知道,在設(shè)計(jì)基于網(wǎng)絡(luò)的即時(shí)通訊系統(tǒng)時(shí),比較適合使用UDP協(xié)議。基于Socket的編程現(xiàn)在來(lái)介紹一下Socket編程。從概念上理解,Socket是網(wǎng)絡(luò)編程中最常見(jiàn)的C/S模式,也是即時(shí)通訊工作的基礎(chǔ)。以該模式編程時(shí),服務(wù)器端有一個(gè)進(jìn)程或多個(gè)進(jìn)程在指定的端口等待客戶(hù)來(lái)連接,如果一旦連接成功,就按照設(shè)計(jì)的數(shù)據(jù)交換方法和格式進(jìn)行數(shù)據(jù)傳輸??蛻?hù)端向服務(wù)器端提出連接請(qǐng)求,連接之后進(jìn)行通信。Socket是一種
60、用于表達(dá)兩臺(tái)機(jī)器之間連接終端的軟件抽象。對(duì)于一個(gè)給定的連接,在每臺(tái)計(jì)算機(jī)上都有一個(gè)Socket,可以想象一條虛擬的電纜工作在兩臺(tái)機(jī)器之間,電纜插在兩臺(tái)機(jī)器的Socket上。當(dāng)然,物理硬件和兩臺(tái)機(jī)器之間的“電纜”這些連接裝置都是未知的、抽象的,所有目的就是為了不必了解更多的細(xì)節(jié)。簡(jiǎn)單說(shuō),一臺(tái)計(jì)算機(jī)上的Socket同另外一臺(tái)計(jì)算機(jī)通話(huà)創(chuàng)建一個(gè)通信信道,程序員可以用這個(gè)信道在兩臺(tái)計(jì)算機(jī)之間發(fā)送數(shù)據(jù)。Java Socket的類(lèi)型有兩種,在編寫(xiě)通訊工具時(shí)均有它們的用處。TCP Socket:由Socket類(lèi)實(shí)現(xiàn)。UDP Socket:由DatagramSocket類(lèi)實(shí)現(xiàn)。TCP和UDP扮演著同樣的角色,
溫馨提示
- 1. 本站所有資源如無(wú)特殊說(shuō)明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請(qǐng)下載最新的WinRAR軟件解壓。
- 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請(qǐng)聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶(hù)所有。
- 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁(yè)內(nèi)容里面會(huì)有圖紙預(yù)覽,若沒(méi)有圖紙預(yù)覽就沒(méi)有圖紙。
- 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
- 5. 人人文庫(kù)網(wǎng)僅提供信息存儲(chǔ)空間,僅對(duì)用戶(hù)上傳內(nèi)容的表現(xiàn)方式做保護(hù)處理,對(duì)用戶(hù)上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對(duì)任何下載內(nèi)容負(fù)責(zé)。
- 6. 下載文件中如有侵權(quán)或不適當(dāng)內(nèi)容,請(qǐng)與我們聯(lián)系,我們立即糾正。
- 7. 本站不保證下載資源的準(zhǔn)確性、安全性和完整性, 同時(shí)也不承擔(dān)用戶(hù)因使用這些下載資源對(duì)自己和他人造成任何形式的傷害或損失。
最新文檔
- 2025年醬瓶項(xiàng)目市場(chǎng)調(diào)查研究報(bào)告
- 2025年速凍木梳筍尖項(xiàng)目市場(chǎng)調(diào)查研究報(bào)告
- 2025年迥轉(zhuǎn)式電鍍機(jī)項(xiàng)目市場(chǎng)調(diào)查研究報(bào)告
- 在線(xiàn)教育對(duì)職場(chǎng)知識(shí)更新的影響
- 2025年煎炸爐項(xiàng)目市場(chǎng)調(diào)查研究報(bào)告
- 2025年有機(jī)硒粉項(xiàng)目市場(chǎng)調(diào)查研究報(bào)告
- 2025年中軟丙烯酸樹(shù)脂乳液項(xiàng)目市場(chǎng)調(diào)查研究報(bào)告
- 基于云計(jì)算的數(shù)字化支付系統(tǒng)架構(gòu)研究
- 我國(guó)糖尿病患者眼科就診狀況的深度剖析與優(yōu)化策略研究
- 心理語(yǔ)言學(xué)視角下俄語(yǔ)政治演講言語(yǔ)理解的多維度解析
- 《教育心理學(xué)(第3版)》全套教學(xué)課件
- 【年產(chǎn)2000噸色氨酸發(fā)酵工廠的計(jì)算與設(shè)計(jì)(附布置圖流程圖)15000字(論文)】
- 2024年倉(cāng)儲(chǔ)、物流等貨物管理員資格知識(shí)考試題庫(kù)(附含答案)
- 提高病人吸氧的依從性品管圈
- DL∕T 1917-2018 電力用戶(hù)業(yè)擴(kuò)報(bào)裝技術(shù)規(guī)范
- 邊溝施工技術(shù)交底滑模
- 向最高檢察院提起申訴書(shū)范文
- 網(wǎng)孔電流法 (1)講解
- 遼寧省沈陽(yáng)皇姑區(qū)2023-2024學(xué)年七年級(jí)下學(xué)期期末考試語(yǔ)文試題
- 九宮數(shù)獨(dú)200題(附答案全)
- 江西省宜春市袁州區(qū)2023-2024學(xué)年六年級(jí)下學(xué)期期末考試語(yǔ)文試卷
評(píng)論
0/150
提交評(píng)論