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。接收端关闭接受流。则，文件传输过程结束。