最近在做乙個c/s檔案管理系統，想要把客戶端命令跟檔案的傳輸分開進行，這就要求我們重新在客戶端與伺服器之間建立乙個新的套接字連線。
首先我們知道c/s伺服器每接到乙個客戶的鏈結請求後，都將建立乙個新的執行緒用於為客戶服務，在高併發的情況下，伺服器可能會同時開啟相當多的執行緒，在這些服務執行緒中，如果有相當一部分客戶要求進行檔案傳輸，那我們就不得不在每乙個執行緒中開啟乙個新的埠用於供客戶連線，但是每個執行緒中的埠又不能重複，這就造成了大量埠的浪費，甚至造成埠不夠用的情況。
最後的解決方案其實挺簡單，即我們的serversocket由客戶端建立，並將所使用的新埠號通知伺服器，而後伺服器向客戶端發起連線。這樣，需求就從本來需要伺服器開啟大量埠號變為每個客戶端自行開啟一新的埠號並由伺服器發起連線。豈不美哉？
在解決完這個問題之後，突然發現，首先呢就是我的伺服器是在內網中的。。於是乙個檔案管理系統，最後變成了乙個區域網檔案管理系統。具體原因見 你的寬頻ip位址被100.64了嗎？
其次，看完ftp協議後，我發現自己想了半天得到的解決方案原來在ftp協議裡早就給出了解決方法。
流式套接字客戶端 伺服器程式設計
1 客戶端向伺服器發出日期請求字串，如 d y a t等 2 伺服器從網路接收到日期時間請求字串後，根據字串格式生成對應的日期時間值返回給客戶端 為了簡化程式美圖出套接字變成的關鍵內容，該例項略去了對請求字串進行合法的校驗的處理。伺服器端程式 include include include incl...
客戶端和伺服器套接字的區別
同樣為套接字socket，但是客戶端和伺服器的是不同的 1 介面api不同 服務端 bind 繫結乙個固定埠 listen 監聽 accept 接收到乙個客戶端連線 客戶端 connect 根據指定的伺服器host ip去連線 2 伺服器應對的是多個客戶端，可能會多個客戶端同時與伺服器通訊，多路io...
伺服器端的返回的套接字是不是客戶端的套接字？？？
對於伺服器端 socket s ss.accept 對於客戶端程式 socket s new socketj 我認為，伺服器端的s即 ss.accept 的返回值，因為，這個返回值，是在客戶端傳送請求後，accept 方法被啟用，從而返回乙個套接字物件。我認為，對於客戶端的 socket s new...