0

クライアントサーバーシステムでは、サーバーメソッドが「クライアントに詳細を尋ねる」ための優れたアーキテクチャと見なされますか? もしそうなら、そのようなシナリオを設計する最善の方法は何ですか? これには「パターン」がありますか？

たとえば、エンド ユーザーがクライアント UI で削除するレコードのセットを選択すると、クライアントはレコードのセットをパラメーターとしてサーバーに「レコードの削除」呼び出しを行います。次に、サーバーは、何らかの形で「特別」であり、ユーザーが確認する必要があるレコードのサブセットを見つけます。クライアントからサーバーへの元の呼び出しを継続しながら、サーバーが何らかの方法でクライアントに「レコードの確認」と呼ばれるメソッドに「コールバック」することは適切ですか?

また、サーバーとクライアントの間で長い「対話」が必要になる可能性がある、より複雑なサーバー呼び出しについてはどうでしょうか?

4

4 に答える 4

1

クライアントは削除するファイルのリストを送信していますよね? サーバーに、削除されたファイル、削除されなかったファイル、および削除されなかった理由 (存在しない、権限がないなど) を示す成功ステータスのリストを返信させるだけです。

一般的なケースとして、すべてのファイルが正常に削除された場合は、すべてのファイルが削除されたかどうか、またはクライアントが実際にステータス コードを評価して操作がどのように行われたかを確認する必要があるかどうかを示すステータス フィールドから応答を開始します。

この応答により、クライアントは、少なくとも削除対象として選択されたファイルに関して、サーバーの状態に関するビューを更新できるはずです (つまり、正常に削除されたファイルだけでなく、それらのファイルも UI から削除します)。これはもはや存在しませんでした; また、パーミッションがないためにサーバーが削除できなかったファイルを示している可能性があります)。

于 2008-12-17T19:51:17.473 に答える
1

「レコード x、y、z は削除されませんでした。set を使用してもう一度I_RELLY_WANT_TO削除してください」というような返信は、私にとって合理的な解決策のように思えます。

一般的なパターン; 尋ねるのではなく、実行して報告し、次に何をすべきかをクライアントに決定させます。これは、ダイアログの形式として永続的な接続のコンテキストで実行できます。

本当に私の分野ではないので... 64mg NaClを追加します

于 2008-12-11T23:26:35.450 に答える
0

そのようなコールバックは、クライアントとサーバーの役割を逆にします。これらのタイプのアーキテクチャの多くでは、クライアントはリクエストをリッスンする能力がありません。もしそうなら、あなたはP2Pのようなシステムを見始めています. たぶん、このようなものがうまくいくかもしれません。

client code: 
  special_records = server.deleteRecords(records)
  server.deleteSpecialRecords(special_records)

server code:
  def deleteRecords(records):
    special_records = detectSpecialRecords(records)
    reply(special_records)
    actuallyDeleteRecords(records - special_records)

したがって、deleteRecords への最初の呼び出しは、明示的に削除する必要があるこれらの特別なレコードのリストを返します。お役に立てれば。

于 2008-12-12T01:41:41.620 に答える
0

そういうアレンジは全然いいと思います。サーバーがクライアントにクエリを返し、クライアントが詳細情報を提供することを妨げるものは何もありません。ソケット接続が開いている限り、自由にメッセージを送受信できます。

クライアントがサーバーにメッセージを送信し、その後、サーバーが制御するローカル マシン上の stdin/out とファイル システム上の小さなレイヤーになるだけの配置を見てきました。それはうまく機能し、非常に高速でした。

于 2008-12-12T04:40:56.033 に答える