我們現在先來實現,跟一個人來來回回不停的講電話。
客戶端,通過循環來輸入多次命令:
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的參數設置