發送系統調用文件服務器

Question

我正在設計一個文件服務器使用套接字編程C.我發送類似open（），write（）等調用使用流套接字的普通字符串和破譯它在服務器端。如果這是一個公開的電話，然後我們提取路徑，模式，標誌。是好的，或者我應該使用某種結構來存儲文件系統調用，並將其發送到服務器只訪問字段的服務器。

有沒有一些標準的方式我不知道？

謝謝

Answer 1

你基本上開始定義你自己的協議。如果您發送描述操作的數字而不是字符串，這將會容易得多。

如果你是認真的，你可能想看看RPC - （？你是問一個標準方式吧）RFC707。

Answer 2

是的，有一個標準的方法。看看NFS,AFP,CIFS和WebDAV，然後選擇一個。

Answer 3

你已經有了標準方法的答案，所以我會給你一些注意事項，你應該注意。

如果您打算在不受信任的環境（例如Internet）中部署文件服務器，請考慮立即對其進行保護。保護它是而不是只是一個關於加密的問題 - 你需要知道你打算如何驗證你的用戶，你想如何授權不同類型的訪問服務器的不同部分，你將如何保證真實性和數據的完整性以及您打算如何保護數據的機密性。

您還需要考慮服務器的可用性。這意味着你應該具有容錯能力 - 即連接可以（並且將會）中斷（不管它們是否被故意破壞），所以你需要檢測到這種情況，要麼會保持活躍狀態​​（這將會如果客戶離開，則失敗）或者某種活動超時（如果客戶離開，將會過期）。您還需要考慮您願意同時支持多少客戶端 - 這可以徹底改變服務器的體系結構。

至於打開，關閉，讀取，寫入等命令，大多數文件傳輸協議沒有詳細說明，但根據您的具體情況可能會有所幫助。如果你的文件非常龐大，你只需要一些文件，或者你想要鎖定文件來專門處理這些文件等等，你可能想要詳細說明一下。如果你沒有這些要求，比較簡單的事務命令，比如get &（而不是打開，讀取，讀取，讀取，關閉和打開，寫入，寫入更多，關閉）可能更容易實現，並且更容易實現與...合作。

如果您希望人類與您的服務器進行交互併爲其提供命令，那麼文本是一種很好的方法：當嗅探和人類理解文本並且可以輕鬆打字時，很容易進行調試。如果沒有人蔘與，使用整數作爲命令可能是一種更好的方法：您可以將命令的結構設置爲以整數開頭，後面跟着許多參數，並且始終只需要在服務器端指定相同的東西（並執行switch您收到的命令）。即使在這種情況下，在整數中使用人類可讀的值也許是個好主意。例如，將'READ'置於整數中，因爲讀命令使用的字節數與0x00000001一樣多，但在使用WireShark進行嗅探時更易於閱讀。

最後，你真的看看標準方法，並試圖瞭解在每種情況下作出的權衡。例如，問問你自己，爲什麼HTTP有如此詳細的標題以及爲什麼WebDAV使用它。爲什麼FTP使用兩個連接（一個用於命令，另一個用於數據），而其他許多協議只使用一個？ NFS如何演進到現在的位置，爲什麼？理解這些問題的答案將幫助你開發自己的協議 - 如果在你理解了這些答案之後，你仍然覺得你需要自己的協議。