旭++

      從上周三，我才真正了解到我要做的東西（FTPserver）是一個涉及知識極其廣泛的復雜程序。而并非之前以為的，單純的C\S模式文件傳輸程序。

      首先按照老師的提示，配了ftp服務器和web服務器，熟悉了一些ftp命令和配置方法。但是對ftp的通信方式和具體過程還是一無所知。

      接下來找來RFC-FTP協(xié)議來看，同時參考了telnet協(xié)議和http協(xié)議。結果還是一頭霧水，搞不清楚協(xié)議中規(guī)定的東西到底應該怎樣去實現(xiàn)。

      我打算轉變思路，動手做試驗。模擬了一個服務器端程序，這個程序只能send一條信息和recv一條信息并且打印，然后用linux自帶的ftp客戶端程序去連接模擬服務器。我想他們之間肯定是有通信來往的，這樣做可以觀察客戶端到底傳給服務器怎樣形式的信息。經過反復測試。終于搞明白了客戶端和服務器之間嚴格按照RFC-959協(xié)議的規(guī)定一問一答的通訊方式。

      接下來，我就沒有著急動手繼續(xù)寫程序，而是去網(wǎng)上搜索了不少關于ftp協(xié)議的文檔和討論。了解了雙socket-（控制通道，數(shù)據(jù)通道）。了解了主動傳輸和被動傳輸?shù)膮^(qū)別。

      看了這些材料以后，我已經大概對整個ftp整個傳輸過程有一個了解。接下來繼續(xù)完善了模擬服務器，能夠用ftp客戶端軟件登陸和退出（只做肯定回應）。這樣控制通道的通信已經可以正常對話了。剩下的一大問題就是數(shù)據(jù)通道的通信方式了。

      做到這里，我遇到了兩個棘手的問題。

      Listen（）監(jiān)聽函數(shù)是如何作用的？按我的理解，listen函數(shù)是這道題目中“控制最大同時訪問數(shù)”的關鍵。我在編碼過程中對這個地方做了試驗：當我在while（1）中執(zhí)行accept時，當接收到客戶端connect請求時，fork（）建立子進程去處理，父進程繼續(xù)循環(huán)等待accept（），之前l(fā)isten函數(shù)backlog為2。但結果是我仍然可以使用三個以上的ftp客戶端進程去同時訪問服務器，并保持連接不斷開或者阻塞。

      兩臺電腦相互通信，如何取得適合對方訪問的自己IP地址？在客戶端要求使用被動傳輸模式的時候，服務器要建立臨時的數(shù)據(jù)傳輸通道，并把建好的本機地址+新端口，以“msg…. (xxx,xxx,xxx,xxx,xxx,xxx) \r\n”的形式發(fā)送給客戶端，客戶端根據(jù)所給的地址和端口號和服務器的數(shù)據(jù)傳輸通道建立連接。在C/C++里，可以使用gethostname函數(shù)獲取本機名稱，根據(jù)獲取的名稱，使用gethostbyname函數(shù)可以獲取本機的IP地址。但是這個IP地址永遠是127.0.0.1（至少我的程序中是這樣的）。但是這個地址傳給對方，對方并不能按照這個地址找到服務器（除非客戶端和服務器在同一臺電腦上）。如果客戶端和服務器在同一局域網(wǎng)中的不同電腦上，那服務器應該傳給客戶端類似192.168.x.x的地址。如果在internet范圍內則需要傳送互聯(lián)網(wǎng)上的IP地址。而真正的ftp服務器和客戶端之間的通信，是可以發(fā)送適合對方訪問自己的IP地址給對方的。而目前所了解到的函數(shù)，gethostname和gethostbyname函數(shù)并不能完成這項要求。