通訊階段總結（2）

以下是在通訊階段遇到的問題的部分總結，或者說是需要注意的地方。

1．

埠被占用：在測試程式時，有時會發現telnet

不上伺服器，這時應該首先懷疑是埠出了問題。一般來說埠數1024

以下的埠會被系統占用，系統開放的埠從0~65535

，這時我們就應該選擇1024

之後的埠才不會出問題。

2．

死迴圈：我們在寫伺服器時，會讓伺服器不斷迴圈等待客戶端的接入，所以我們用到了while

的迴圈語句，但是這就會用個問題：在客戶端異常關閉時，伺服器端容易出現死迴圈。要理解這個，就必須了解到當客戶端直接關閉時，會向伺服器返回乙個-1

，我們將出現-1

作為while

的結束條件，這樣死迴圈的問題就解決了。

3．

方法宣告的準確性：作為程式設計師，我們寫**時一定要將方法的宣告寫清楚，但更重要的是要寫得有意義。如果是問牛答馬的話，那顯然是沒有意義的。

4．

流的提前關閉：我們寫傳檔案程式時，還常常犯這樣的乙個錯誤：客戶端這邊剛把檔案傳走完，就立即關閉客戶端，這就使得還處在「路上」（流的管道裡）的資料傳不到伺服器，我理解就好像飛彈雖然發**出去，預定的彈道上飛行，可惜突然失去了動力，必然飛彈不會命中目標。

5．

try catch

與throws

的區別：try catch就是用catch捕獲try中的異常，並處理其中的異常，用於函式內部。throws就是不處理異常，直接丟擲異常，向上丟擲，讓上一層來處理，用於函式。

6．

違反協議：當然協議事先是怎麼定的就應該不怎麼用，如果違反協議那麼通訊自然會出現錯誤，無法解析。所以協議定成什麼樣，寫客戶端與寫伺服器的程式設計師就應該照著來。

7．

協議缺陷：不過即使是雙方都按照制定好的協議來執行，那也無法保證就能通訊無阻。如協議本身就有問題！有歧義！最明顯的乙個例子在制定檔案傳輸協議時，檔案的大小需要乙個int

來制定，這個int

的資料是只含檔案大小，還是包含了傳輸檔案時所攜帶的附加的一些bytes

？！當然這一點必須要制定清楚。