• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>
            隨筆 - 96  文章 - 255  trackbacks - 0
            <2025年5月>
            27282930123
            45678910
            11121314151617
            18192021222324
            25262728293031
            1234567

            E-mail:zbln426@163.com QQ:85132383 長(zhǎng)期尋找對(duì)戰(zhàn)略游戲感興趣的合作伙伴。

            常用鏈接

            留言簿(21)

            隨筆分類

            隨筆檔案

            SDL相關(guān)網(wǎng)站

            我的個(gè)人網(wǎng)頁(yè)

            我的小游戲

            資源下載

            搜索

            •  

            積分與排名

            • 積分 - 492198
            • 排名 - 38

            最新評(píng)論

            閱讀排行榜

            評(píng)論排行榜

                 摘要: 雖然UDP是無(wú)連接的,但是也可以通過調(diào)用connect()將本地的UDP socket FD與一個(gè)遠(yuǎn)程的UDP socket FD連接起來。  閱讀全文
            posted @ 2010-06-11 11:51 lf426 閱讀(2190) | 評(píng)論 (0)編輯 收藏
                 摘要: UDP的系統(tǒng)緩存隊(duì)列與TCP的相比,有兩點(diǎn)顯著的不同:
            1、UDP沒有SendQ。UDP的數(shù)據(jù)包不會(huì)被處理,通過調(diào)用sendto()(或者在connect()之后也可以調(diào)用send())將數(shù)據(jù)直接發(fā)送。
            2、UDP的數(shù)據(jù)在緩存隊(duì)列中是有邊緣保證的。  閱讀全文
            posted @ 2010-06-11 11:18 lf426 閱讀(3038) | 評(píng)論 (0)編輯 收藏
                 摘要: TCP之所以有個(gè)服務(wù)器,是因?yàn)門CP的客戶端只能和自己的服務(wù)器端通訊。而UDP的客戶端可以與任何一個(gè)UDP端口通訊——只要知道對(duì)方的地址(IP地址和UDP端口)就可以發(fā)送數(shù)據(jù)包。  閱讀全文
            posted @ 2010-06-10 19:37 lf426 閱讀(1724) | 評(píng)論 (0)編輯 收藏
                 摘要: 人們通常用電話連線來說明TCP協(xié)議,而UDP協(xié)議,則常常用郵遞來做比喻。與TCP有連接的信息傳輸方式不同,UDP協(xié)議被認(rèn)為是對(duì)底層IP協(xié)議簡(jiǎn)單的擴(kuò)展:協(xié)議并不保證每個(gè)數(shù)據(jù)包都會(huì)到達(dá)目的地,也不保證到達(dá)的順序,而僅僅就是“盡力”的發(fā)送每一個(gè)數(shù)據(jù)包。  閱讀全文
            posted @ 2010-06-10 12:16 lf426 閱讀(2905) | 評(píng)論 (0)編輯 收藏
                 摘要: 在我們遍歷查找對(duì)等值的循環(huán)中,一開始v.end()指向第10個(gè)元素(數(shù)值為9)的后面一個(gè)位置(不存在的第11個(gè)元素的位置)。當(dāng)?shù)髦赶虻?0個(gè)元素(數(shù)值為9)的時(shí)候,v.erase()生效運(yùn)行;下一輪循環(huán)中,迭代器本來應(yīng)該指向第11個(gè)元素的位置,并且等于v.end()并結(jié)束循環(huán)。但是,因?yàn)槲覀儾恋袅藇ector中的一個(gè)元素,v.end()指向的是現(xiàn)在的最后一個(gè)元素——第9個(gè)元素的后面,也就是第10個(gè)元素的位置。這樣,迭代器到了11,而判斷確是其是否到10,這將永遠(yuǎn)無(wú)法實(shí)現(xiàn),形成了一個(gè)邏輯bug,所以系統(tǒng)拋出錯(cuò)誤了。  閱讀全文
            posted @ 2010-06-10 11:03 lf426 閱讀(1673) | 評(píng)論 (1)編輯 收藏
                 摘要: echo客戶端的工作原理也很簡(jiǎn)單:
            1、向服務(wù)器端發(fā)送一個(gè)字符串;
            2、接收服務(wù)器的返回信息(如果是echo服務(wù)器就會(huì)返回發(fā)送出去的字符串本身)。
            3、在標(biāo)準(zhǔn)輸出中回顯服務(wù)器返回的信息。  閱讀全文
            posted @ 2010-06-08 11:49 lf426 閱讀(2277) | 評(píng)論 (1)編輯 收藏
                 摘要: echo服務(wù)器的工作原理很簡(jiǎn)單:
            1、接收客戶端傳來的信息;
            2、將接收到的信息原封不動(dòng)的返回給客戶端。  閱讀全文
            posted @ 2010-06-08 10:56 lf426 閱讀(3194) | 評(píng)論 (3)編輯 收藏
                 摘要: TCP的連接建立需要3次握手,而正常關(guān)閉則需要4次握手。  閱讀全文
            posted @ 2010-06-07 20:58 lf426 閱讀(2943) | 評(píng)論 (0)編輯 收藏
                 摘要: 在socket機(jī)制中,應(yīng)用層的程序以send()函數(shù)將數(shù)據(jù)首先發(fā)送到本機(jī)系統(tǒng)的發(fā)送緩存中,我們稱之為SendQ,意指這是一個(gè)FIFO(先進(jìn)先出)的隊(duì)列。這個(gè)緩存是系統(tǒng)決定的,并不是在我們的程序中指定的。然后socket機(jī)制負(fù)責(zé)將SendQ中的數(shù)據(jù)以字節(jié)為單位,按照順序發(fā)送給對(duì)方的接收緩存RecvQ中。RecvQ也是一個(gè)屬于系統(tǒng)的FIFO緩存隊(duì)列。在收信息的另外一邊,當(dāng)RecvQ沒有數(shù)據(jù)時(shí),recv()就會(huì)阻塞(默認(rèn)情況下),每當(dāng)有數(shù)據(jù)可接收,recv()就會(huì)返回實(shí)際接收到的數(shù)據(jù)長(zhǎng)度。  閱讀全文
            posted @ 2010-06-07 20:09 lf426 閱讀(4023) | 評(píng)論 (1)編輯 收藏
                 摘要: TCP的三次握手過程如下:
            1、第一個(gè)SYN連接請(qǐng)求由客戶端發(fā)起,這個(gè)數(shù)據(jù)報(bào)將SYN設(shè)置為1表示是一個(gè)連接請(qǐng)求,并且包含著這次連接的ISN,我們假設(shè)其值為n。
            2、服務(wù)器端收到第一次握手請(qǐng)求的數(shù)據(jù)報(bào)后開始構(gòu)建反饋的數(shù)據(jù)報(bào)。反饋數(shù)據(jù)報(bào)包括兩個(gè)部分:第一部分是將連接請(qǐng)求的序號(hào)反饋回去,因?yàn)镾YN本身占了一個(gè)字節(jié),所以反饋回去的序號(hào)就是n+1;第二部分是自己也向客戶端發(fā)起SYN連接請(qǐng)求,也將SYN設(shè)置為1,并包含這個(gè)新連接的ISN,我們?cè)O(shè)其值為m。
            3、客戶端回應(yīng)服務(wù)器端的SYN連接請(qǐng)求,將服務(wù)器端到客戶端連接的序號(hào)反饋回去,因?yàn)镾YN占了一個(gè)字節(jié),所以反饋給服務(wù)器端的序號(hào)是m+1。  閱讀全文
            posted @ 2010-06-07 13:16 lf426 閱讀(3028) | 評(píng)論 (0)編輯 收藏
            列出全部?jī)?nèi)容
            共10頁(yè): 1 2 3 4 5 6 7 8 9 Last 
            精品熟女少妇a∨免费久久| 一本久久a久久精品综合香蕉| 亚洲伊人久久大香线蕉综合图片 | 狠狠久久综合伊人不卡| 国产精品热久久毛片| 精品久久久中文字幕人妻| 国产精品久久网| 97视频久久久| 久久免费精品一区二区| 97精品依人久久久大香线蕉97| 狠狠狠色丁香婷婷综合久久五月| 久久人妻少妇嫩草AV无码蜜桃| 性欧美大战久久久久久久久| 久久激情五月丁香伊人| 久久发布国产伦子伦精品| 亚洲欧美国产精品专区久久| 国产精品久久久久影视不卡| 亚洲国产另类久久久精品| 久久精品国产清自在天天线| 少妇内射兰兰久久| 国产成人综合久久精品红| 国产精品永久久久久久久久久 | 蜜桃麻豆www久久国产精品| 久久青青草原亚洲av无码app| 四虎影视久久久免费观看| 久久最近最新中文字幕大全| 亚洲va中文字幕无码久久不卡| 色欲综合久久躁天天躁| 91久久九九无码成人网站 | 一级a性色生活片久久无少妇一级婬片免费放 | 久久精品国产亚洲av瑜伽| 2021少妇久久久久久久久久| 一本色道久久综合亚洲精品| 蜜桃麻豆WWW久久囤产精品| 亚洲AV伊人久久青青草原| 日日狠狠久久偷偷色综合96蜜桃 | 久久免费精品视频| 国产精品欧美久久久久无广告| 青青草原综合久久大伊人精品| 久久r热这里有精品视频| 国内精品久久久人妻中文字幕|