我們現在先來實現，跟一個人來來回回不停的講電話。
客戶端，通過循環來輸入多次命令：
client.recv(1024)每次只接收1K的內容
服務端來改成多次接收：如果你寫成如下的代碼：
那么造成的結果，就是很多人連上來，但是每次只能跟服務端說一句話，然后第二句話卡住。
第二個客戶端一樣，每次只能跟服務端說一句話，然后第二句話卡住。
也就是服務端寫成這種代碼是不行的，會造成代碼卡住。我們現在先來實現跟一個人可以來來往往的說話：暫時無法實現跟多個人
以上的服務端代碼已經可以跟客戶端實現完美的交換式通訊，但是產生一個新的問題，
當客戶端斷開的時候，服務端提示報錯，然后也斷開連接，結束代碼了。
這個是win上的一個BUG，其中一個連接斷開的時候，server也斷開了，這個是不對的。
但是在linux上是可以正常執行的，客戶端斷開，服務端不會停止代碼，也不會停止服務。
但是現在運行在linux依舊還是有BUG，我們發現當客戶端斷開的時候，服務端會進入一個死循環。
表示服務端不停的接收到了空字符的，造成了死循環。所以我們要修改服務端的代碼，當接收到空字符串的時候，不要進入死循環，而重新接收狀態：
修正后的服務端代碼如下：
這樣實現了，第一個人可以跟服務端不停的通訊，這個時候如果第二個人進來想通話，會卡住；直到第一個人跟服務端斷開以后，第二個人可以立即接入進行跟服務端進行通訊~！
這邊有個要注意的地方server.listen(5)，這里的5表示最多允許有5個client掛起，等待中，排隊中。。。不過這個必須在異步的情況下，才可以測試出來。
然后，我們又發現了一個bug，如果客戶端client發送一個空，會造成程序卡死。
client.send不能發送空~！不能發送空~！不能發送空~！不能發送空~！所以我們客戶端的代碼要改進下：
我們現在來模擬客戶端是ssh：
先來看看服務端的代碼的修改：
客戶端執行代碼，可以正常返回。
但是現在有幾個新問題：
不能執行top命令，因為top命令會一直執行刷新，不停變化：
但是我們可以執行top -bn 1，讓top執行一次。但是由於top -bn 1返回的結果超過了1024字節，你后面再輸入命令df依舊返回的是top -bn 1的命令結果，繼續執行新命令還是返回top -bn 1的返回值：如下圖
這個時候我們需要修改客戶端接收信息的大小，我們原來是1024字節，修改為102K，如下圖
這個時候，我們再執行top -bn 1，就 可以返回正常的所有值了。
如果我們這個時候發送一個超大文件，比如60M的文件：
我們來看看服務端的代碼：（注意這里是py2的代碼，到py3，必須先轉換為二進制）
來看看客戶端的代碼修改：
執行上訴代碼以后，我們發現服務端的conn.send也是有大小限制的，我們發現每次最多值發送32K大小的文件：
所以我們要修改服務端的代碼，進行循環send，發送文件直到把文件發送出去。 我們需要用到conn.sendall方法
雖然我們使用了sendall的方法，但是我們要注意服務端第一次只發送32K的文件（第2，第3次依次增加，但是最大不超過客戶端的recv(xxxx)，xxxx設置的數值，上訴例子設置的是10M），所以你客戶端需要多次send命令，讓服務端不停的往客戶端發送文件。
我們用f.flush的方法，來強制客戶端寫入文件，讓我們可以看到文件的增加的大小。
下面我們來看看文件的傳輸過程：
第一次：
第二次：
第三次：
。。。。。。。。。。。
文件的傳輸最大不超過10M/次，客戶端的recv的參數設置