C でソケット プログラミングを使用してファイル サーバーを設計していました。open()、write() などの呼び出しをストリーム ソケットを使用してプレーンな文字列として送信し、サーバー側で解読します。つまり、open 呼び出しの場合は、パスを抽出します。 、モード、フラグ。ファイルシステム呼び出しを保存し、サーバーがフィールドにアクセスするだけのサーバーに送信するために、ある種の構造体を使用する必要がありますか。
私が知らない標準的な方法はありますか?
ありがとう
C でソケット プログラミングを使用してファイル サーバーを設計していました。open()、write() などの呼び出しをストリーム ソケットを使用してプレーンな文字列として送信し、サーバー側で解読します。つまり、open 呼び出しの場合は、パスを抽出します。 、モード、フラグ。ファイルシステム呼び出しを保存し、サーバーがフィールドにアクセスするだけのサーバーに送信するために、ある種の構造体を使用する必要がありますか。
私が知らない標準的な方法はありますか?
ありがとう
基本的に、独自のプロトコルを定義し始めています。文字列の代わりに操作を説明する数値を送信すると、はるかに簡単になります。
これについて真剣に考えている場合は、 RFC707 (標準的なRPC
方法を求めましたよね?) を調べてみてください。
はい、標準的な方法があります。NFS 、AFP、CIFS、およびWebDAVを調べて、いずれかを選択します。
標準的な方法についてはすでに回答があるので、注意すべきいくつかの注意事項を示します。
ファイル サーバーを信頼されていない環境 (インターネットなど) に配置する場合は、すぐにセキュリティを確保することを検討してください。セキュリティを確保することは、暗号化を平手打ちするだけの問題ではありません。ユーザーを認証する方法、サーバーのさまざまな部分へのさまざまな種類のアクセスを許可する方法、信頼性と完全性をどのように保証するかを知る必要があります。データおよびデータの機密保持方法。
また、サーバーの可用性についても考慮する必要があります。つまり、フォールト トレラントである必要があります。つまり、接続は (意図的に切断されているかどうかに関係なく) 切断される可能性があり、切断されるため、それを検出する必要があります。クライアントが離れた場合に失敗する) または何らかのアクティビティ タイムアウト (クライアントが離れると有効期限が切れる) で発生します。また、同時にサポートするクライアントの数についても考慮する必要があります。これにより、サーバーのアーキテクチャが根本的に変わる可能性があります。
オープン、クローズ、読み取り、書き込みなどのコマンドに関しては、ほとんどのファイル転送プロトコルはそれほど詳細には入りませんが、状況によってはそうできると興味深いかもしれません。ファイルが巨大で、その一部のみが必要な場合、またはファイルをロックして排他的に作業できるようにしたい場合などは、そのような詳細に進みたいと思うかもしれません。これらの要件がない場合は、get & put などの単純なトランザクション コマンド (open、read、read、read、close and open、write、write some more、close ではなく) のほうが実装が簡単で、簡単に実行できる可能性があります。と連携。
人間がサーバーと対話してコマンドを与えるようにしたい場合は、テキストが良いアプローチです。スニッフィング時にデバッグが容易であり、人間がテキストを理解し、入力するのは簡単です。人間が関与していない場合は、コマンドとして整数を使用する方がおそらく優れたアプローチです。コマンドを整数で開始し、その後にいくつかのパラメーターを続けて、サーバー側で同じことを常に期待するように構成できます (そして、サーバー側で aswitch
を実行します)。受信したコマンド)。ただし、その場合でも、人間が読み取れる値を整数に含めることをお勧めします。たとえば'READ'
、読み取りコマンドとして整数を入力すると、 と同じバイト数が使用されますが0x00000001
、WireShark でスニッフィングすると読みやすくなります。
最後に、標準的なアプローチを実際に見て、それぞれの場合のトレードオフを理解しようとします。たとえば、なぜ HTTP にこのような詳細なヘッダーがあるのか、WebDAV がそれを使用するのかを自問してみてください。他の多くのプロトコルは 1 つしか使用しないのに、FTP は 2 つの接続 (コマンド用とデータ用に 1 つ) を使用するのはなぜですか? NFS はどのようにして現在の場所に進化したのですか? またその理由は? これらの質問に対する答えを理解することは、独自のプロトコルを開発するのに役立ちます。これらの答えを理解した後でも、独自のプロトコルが必要だと感じる場合.