問題タブ [client-server]

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

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

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

私はいくつかのクライアント サーバー コードをリファクタリングしていますが、同じこと (サーバーからの応答) に対して応答、結果、応答という用語を使用しています。それほど重要ではありませんが、新しいコードを書くときにどの単語を使用するかを推測するのが難しくなってきているので、3 つの用語を 1 つに統合して適切なリファクタリングを行いたいのですが、どの単語が "最高」、そんなことがあれば。

この場合の命名に向けた優先順位と基準に基づく提案はありますか?

次の問題に対処しようとしています。

1. PONO のディクショナリを保持するサーバー側の .net アプリケーションがあります: キャッシュです。

2. 私は、キーを使用するか、サーバーに特定の属性値を持つ PONO のみをフィルタリングするように要求することによって、これらの PONO のいくつかを照会できる多くのクライアント側 .net ユーザー インターフェイスを持っています: クライアント

編集:クライアントは C# シック クライアントであり、Web アプリではありません。したがって、クライアントとサーバーの間で任意のチャネル タイプを使用しても問題ありません。

3. そしてもちろん、一部のクライアントは PONO を更新してサーバーに送り返すことができます。次に、この PONO を既に保持しているすべてのクライアントに新しい値を通知し、新しい PONO 値に一致するフィルターを持つすべてのクライアントに PONO を送信できるように、サーバーを十分に賢くしたいと考えています。

4. 私はトランザクションの側面についてはあまり気にしません。私の場合、最後に話す人は常に正しいです。

そのような機能は非常に汎用的に見えるので、すでにどこかに存在しているに違いないと思います。何かアドバイス ？

ありがとう

サイド プロジェクトとして、私は現在、昔からプレイしていたゲームのサーバーを作成しています。サーバーを可能な限り疎結合にしようとしていますが、マルチスレッド化に適した設計上の決定は何か疑問に思っています。現在、次の一連のアクションがあります。

• 起動 (作成) ->
• サーバー (クライアントをリッスンし、作成) ->
• クライアント (コマンドをリッスンし、期間データを送信)

ゲームの任意の時点での最大値であるため、平均 100 クライアントを想定しています。全体のスレッド化に関して正しい決定は何でしょうか? 私の現在の設定は次のとおりです。

• 新しい接続をリッスンするサーバー上の 1 つのスレッド。新しい接続でクライアント オブジェクトを作成し、再度リッスンを開始します。
• クライアント オブジェクトには 1 つのスレッドがあり、着信コマンドをリッスンし、定期的なデータを送信します。これは非ブロッキング ソケットを使用して行われるため、利用可能なデータがあるかどうかを確認し、それを処理してから、キューに入れられたメッセージを送信します。ログインは、送受信サイクルが開始される前に行われます。
• アーキテクチャ的に言えば、ゲーム自体の 1 つのスレッド (今のところ) は、クライアント サーバー部分全体とは別のものであると考えています。

これにより、合計 102 スレッドになります。クライアントに送信用と受信用の 2 つのスレッドを与えることも検討しています。これを行うと、レシーバー スレッドでブロッキング I/O を使用できます。つまり、スレッドは平均的な状況ではほとんどアイドル状態になります。

私の主な懸念は、これほど多くのスレッドを使用することでリソースを浪費することです。とにかく対処しなければならないことなので、競合状態やデッドロックについては心配していません。

私のデザインは、1 か 100 かに関係なく、すべてのクライアント通信に単一のスレッドを使用できるように設定されています。通信ロジックをクライアント オブジェクト自体から分離したので、書き直す必要なく実装できました。多くのコード。

主な質問は、アプリケーションで 200 を超えるスレッドを使用するのは間違っているのでしょうか? 利点はありますか？これをマルチコア マシンで実行することを考えていますが、このように複数のコアを最大限に活用できますか?

ありがとう！

これらすべてのスレッドのうち、ほとんどのスレッドは通常ブロックされます。接続が 1 分間に 5 回を超えるとは思わない。クライアントからのコマンドの受信頻度は低く、平均して 1 分間に 20 回程度です。

私がここで得た答えを見ていきます (コンテキストの切り替えは、私が考えていたパフォーマンス ヒットでしたが、あなたがそれを指摘するまで知りませんでした、ありがとう!)受信者、1 つの送信者、およびいくつかの雑多なもの ;-)

私が一緒に働いている開発チームの一部は、私たちの製品と統合するためのサーバーを作成するという課題を与えられました。C SDK を提供する低レベルのセンサー デバイスがいくつかあり、データを収集する人々が使用できるようにそれらをネットワーク経由で共有したいと考えています。シンプルですね。誰かが建物の一部にある自分のマシンにセンサー デバイスを接続し、サーバーを実行して、デバイスをネットワークの他の部分と共有します。次に、クライアントがアプリケーションを介してそのサーバーに接続し、デバイスからセンサーの読み取り値を収集します。

私は単純で言語にとらわれないネットワーク プロトコルと、Java での参照実装を作成しました。問題は、C で記述された SDK のみを提供するデバイスで動作する実装を作成することです。次のことを考えていました。

1. 接続されている各デバイスから最新の測定値を収集して保存するポーリング スレッドを作成します。
2. マルチスレッド サーバーを使用して、ワーカー スレッドへの各着信接続をスピンオフします。
3. ワーカー スレッドがセンサー読み取りの要求を受信すると、ポーリング スレッドによって収集された最新の値がクライアントに返されます。

これは、特に C では多くのスレッド化です。したがって、一般的な要件を確認すると、次のようになります。

• Windows XP/Vista、Linux、および OS X マシンで実行
• C または C++ で書かれており、私たちが持っている C SDK と対話します
• 可変数の同時接続 (ワーカー スレッド) を受け入れる
• フォークではなく、スレッドを使用する必要があります (IPC の別のレイヤーを処理したくない)

使用を開始するためのライブラリと、できればサンプルコードを提案できる人はいますか?

多層またはクライアント サーバー アプリケーションを作成するための現在のベスト プラクティスと見なされている Cocoa の方法はありますか?

私は経験豊富な Web 開発者で、Python が大好きです。私はココアに不慣れです。私が書いているアプリケーションは、大病院の患者管理システムです。システムは時間の経過とともに膨大な量のデータを保存することが予想されますが、1 回のセッションで転送されるデータは非常に軽量です (ほとんどがテキストのみ)。通信は、ローカル ネットワーク (有線または無線) 経由で行われると想定されています。もちろん、安全性が高い必要があります。

私が思いついた最善の方法は、Python REST Web サービスを作成し、Cocoa アプリを介して接続することです。おそらく、Python を使用して Cocoa アプリ自体をコーディングすることもあるでしょう。

Cocoa を見ると、Cocoa には CoreData のような非常に優れたテクノロジが見られますが、クライアント サーバー開発に類似したものは見つかりませんでした。何も見逃していないことを確認したいだけです。

どう思いますか？

実際の例は非常に高く評価されます。

前もって感謝します。

TCP 経由で通信するクライアント プログラムとサーバー プログラムがあります。代わりに POSIX メッセージ キューを使用しようとしています (もちろん、クライアントとサーバーが同じマシン上にある場合)。私の希望は、パフォーマンスが向上することです (具体的には、待ち時間の短縮による)。

私はそのほとんどを解決しましたが、「接続」を確立する方法が 1 つあります。サーバーは複数のクライアントからの接続を同時に受け入れるため、次のように TCP 接続確立プロセスをエミュレートしたくなります。

1. サーバーは既知の名前でキューを開き、そこから継続的に読み取ります ( select(2)TCP と同様に使用できます)。
2. クライアントは 3 つのキューを開きます。そのうちの 2 つは任意の名前 (衝突を避けるための PID などの一意性を含む) で、もう 1 つはサーバーで使用される既知の名前です。
3. クライアントは、クライアントのキュー名を含む「接続」メッセージをサーバーのキューに送信します (1 つはクライアントからサーバーへのトラフィック用に指定され、もう 1 つはその逆用に指定されます)。
4. サーバーは、クライアントの接続メッセージで指定されたキューを開き、クライアントからサーバーへのキューから読み取り (選択) を開始します。
5. クライアントは、既知の名前でサーバー キューを閉じます。双方向通信は、クライアントによって指定された 2 つのキュー (各方向に 1 つ) を使用して続行されます。

おそらく、この方式が一般的な TCP 方式に似ていることがお分かりいただけると思いますが、これは偶然ではありません。ただし、知りたいのは：

1. それを行うためのより良い方法を考えることはできますか？
2. 私の方法に潜在的な問題はありますか？
3. 同じマシンで TCP の代わりにメッセージ キューを使用すると実際にパフォーマンス (レイテンシ) が向上する可能性など、他に何か考えはありますか?

以前に POSIX メッセージ キューを使用したことがないことに注意してください (以前は IBM WebSphere MQ を使用していましたが、それはかなり異なります)。プラットフォームは Linux です。

クライアントとサーバーの同期パターンがそこにあるに違いないと感じています。しかし、私はグーグルアップに完全に失敗しました。

状況は非常に単純です。サーバーは中央ノードであり、複数のクライアントが接続して同じデータを操作します。データはアトムに分割できます。競合が発生した場合は、サーバー上にあるものは何でも優先されます (ユーザーが競合を解決しないようにするため)。データが大量になる可能性があるため、部分的な同期が推奨されます。

そのような状況のパターン/グッドプラクティスはありますか、または何も知らない場合は、どのようなアプローチをとりますか?

以下は、私が今それを解決するために考えている方法です: データと並行して、変更ジャーナルが保持され、すべてのトランザクションにタイムスタンプが付けられます。クライアントが接続すると、前回のチェック以降のすべての変更を統合形式で受け取ります (サーバーはリストを調べて追加を削除し、その後に削除を行い、各アトムの更新をマージするなど)。ほら、私たちは最新です。

代わりに、各レコードの変更日を保持し、データの削除を実行する代わりに、それらを削除済みとしてマークするだけです。

何かご意見は？

私はいくつかのクライアント/サーバー ソフトウェアを作成していますが、次の設計上の問題に直面しています。通常、私は VERIFY マクロを非常に寛大に使用します。ユーザーのマシンに何か問題がある場合、ソフトウェアが失敗し、エラーをログに記録して修正できるようにしたいと考えています。私はどんな種類のエラーも無視するのが好きではありませんでした。

しかし、私は今サーバーを書いています。サーバーが停止した場合、多くのクライアントがダウンするため、サーバーの停止はできるだけ少なくする必要があります。したがって、そうでなければ致命的な例外として扱ういくつかの条件を扱う方法がわかりません。

たとえば、ログインしていないユーザーからネットワーク パケットを受信したとします。これは起こるべきではありませんが、「不可能な」エラーが時々発生することを十分に経験しています。したがって、これらのケースで致命的なエラーが発生した場合、サーバーは最終的にクラッシュすることは間違いありません。一方、ログに記録してエラーを無視して続行することもできますが、この方法では一部のバグが検出されない可能性があります。

このような状況であなたはどうしますか？