1.寫了一個socket傳輸文件的程序，發現傳輸過去文件有問題。找了一下午終於似乎找到了原因，記錄下來警示一下：
接受文件的一端，向本地寫文件之前使用Thread.sleep(time)休息一下就解決了問題。
個人認為可能是傳輸過程中，接收端向磁盤寫速度有點慢，被后面的覆蓋導致錯誤。
//--------------------------------------------------------------------------------------------------------------------
12-29：最近看了本書<<Java Tcp/IP Socket 編程>>，似乎了解了如題這個問題的原因：
不能假設在連接的一端將數據寫入輸出流和在另一端從輸入流讀入的數據間有任何的一致性。雖然發送端都是1024bytes為單位發送的，但是由於網速問題接收端不一定是按照1024bytes為單位接受的，可能小於1024。所以buf[0]=5這種手段是行不通的，接受方收到的buff的第一個字符可不一定是5。
注：若以1024bytes為發送和接受緩沖區的話。
//---------------------------------------------------------------------------------------------------------------------
12-29晚：我徹底知道了原因。就是網絡傳輸的問題，發送端以1024byte為單位發送，接收端以1024byte為單位接受。但是由於網絡傳輸速度的限制，發送端發送出去的1024byte不能同時到達接收端，而接收端使用read獨到的可能少於1024byte。下次從上次讀到的下一個位置繼續讀，所以以1024byte數組的開頭設為標識位的做法是行不通的，是錯誤的。解決辦法是在接收端每次read之前，Thread.sleep(mileseconds);一會。這樣就有足夠的時間等待發送端發送的數據完全到達接受端后再接受，這樣的話buff[0]的值就可以最為標示位了。
但是還是不提倡這種設置buff[0]為表示位的做法。好的做法是，接收端收到發送文件的請求收，接受文件，不考慮標識，就沒有標識位，發送端發送完文件后調用close()，以發送結束標識，接收端會通過read（）收到-1。接收端關閉接受流。則，文件傳輸過程結束。
http://www.cnblogs.com/wangjiyuan/p/3493186.html