有乙個情形我突然之間想明白了。
注意下面情形：
假設節點a與節點b已經 正常的建立了連線，並且進行了通訊。
假設 節點b收到了 節點a 的 "建立連線"命令
節點b上的連線定時器啟動，假設定時為10秒， 同時 節點b置位他的已連線標誌
linkedhard_flag=1 ; 同時，節點b給節點a上傳正常的響應幀， 告知節點a ，節點a與節點b 已經握手成功。
在接下來的10秒內，節點a可以向節點b傳送 寫資料命令的資料幀，節點b正常的接收的節點a的命令幀以後，就返回給節點a響應幀。
注意兩點：（1）在接下來的10秒內，節點b若收到了節點a的命令幀以後，又會將自己（節點b）的定時器的初值重新裝載，即重新開始10秒計時。
（2）節點b處於連線中狀態（即linkedhard_flag=1），在這個前提下，節點b才能接收 寫資料 或者 讀資料，或者 刪除連線的命令幀。
下面就是問題的表現形式了：
linkedhard_flag=1標誌 對於節點b來講，僅僅表示了他和網路上的某一節點正在連線，但是具體和哪個網路節點連線是不清楚的，（我目前寫的軟體，是區分不了b和網路上哪個節點連線的。如果在軟體中要體現連線關係，軟體會變複雜）。
假設某一時刻，在該時刻b節點處於連線中狀態（linkedhard_flag=1 ），假設此時c節點 要傳送寫資料命令幀，給b節點，b節點知道自己在連線狀態，固可以接受來自c節點的命令，（目前我軟體中是可以接受來自c節點傳送的寫資料 或者 讀資料命令的，我沒有區分,這個現象也在試驗中驗證了，但此時 我如果規定讓節點c先傳送連線命令，則我軟體是可以簡單處理的，並告知c節點不能正常連線），
所以：如果節點b處於和節點a的連線中的時候， 節點c突然不按照規則的傳送了乙個連續 寫 或者 連續 讀命令幀， （我目前的軟體 b可以接收c） ， 那麼 我現在該怎麼辦呢。
實際上： 你還是沒有理解這個具體的過程，
主機在不建立連線的情況下，命令幀根本就發不出去。
綜上，以前的困惑迎刃而解。 你也就理解了握手幀的意義。 這樣的規定也使軟體的設計簡化。
把上面的東西 最後用圖畫表示。
TCP協議 建立連線
上面第四步的ack報文不占用序列號 為了防止已失效的連線請求報文段突然又傳送到了服務端，因而產生錯誤 謝希仁版 計算機網路 中的例子是這樣的，已失效的連線請求報文段 的產生在這樣一種情況下 client發出的第乙個連線請求報文段並沒有丟失，而是在某個網路結點長時間的滯留了，以致延誤到連線釋放以後的某...
我今天的感悟
今天跟我同事周公 可以算是我的老朋友了,跟他聊了一天,收穫不少,對自己被公司開除的原因又多了一層認識,覺得自己再公司欠缺了一些東西.如跟師傅的溝通方面.周公說的對,有什麼工作方面的事情不懂不理解就去問師傅,因為大家都在為了解決問題再努力.不要怕去問他,找準時間,沒事情做可以找師傅要事情做,不管怎樣也...
我的工作感悟
自從2001年畢業後,到現在一晃的時間就過去了8年.夜裡靜靜的進行思考,反問我自己,在這8年當中,我得到了甚麼?是累還是辛苦?是有成就還是兩手空空.其實回頭想想,在出來其中4年當中因為工作沒有經驗和年輕,是沒有甚麼可收穫.接下來的4年當中有2年也是白白浪費的.因為沒有收穫.自從2006年開始,可以算...