サーバーと定期的に通信する約 10 台のコンピューターを使用します。
パケットはあまりデータ集約的ではありません。(ゲームデータの更新) サーバーは postgres データベースに書き込みます
私の主な関心事は、クライアントによる同時アクセスです。クライアント要求のキューイングを処理するにはどうすればよいですか?
考えられる問題について、他の重点分野を提案できる人はいますか?
WCF を使用すると、何をしたいかによって、何を使用するかを非常に柔軟に選択できます。何を選択すべきかを知ることは、実験と経験から得られます。
Fiddler、Wireshark、ServiceTraceViewer などのツールを使用して、クライアントとサーバー間の会話を分析できます。これらのツールは、非効率的な会話を検出するために定期的に使用する必要があります。
中央サーバーを介してデータを通信する必要があるゲームを作成しています...したがって、おそらく、可能な限り効率的で待ち時間を最小限に抑えたいと考えています。
したがって、理想的には、できるだけ早く処理したいサーバーに着信するすべてのリクエスト...オーバーヘッドを最小限に抑えたいと考えています。
サーバーがメッセージを受信したことを保証する必要がありますか? その結果、返信を受信することが保証されます (つまり、信頼できる配信)?
メッセージは、送信されたのと同じ順序で処理する必要がありますか?
次に、サーバーを拡張する必要があるかどうかを検討してください。一度に少数のクライアントしか持っていませんか？あなたは 10 とおっしゃいましたか? ...これが 100 万に増えることはありますか?
次に、あなたの環境を考えてみましょう....あなたはLANについて言及しています...クライアントは常に同じLAN上にありますか...つまりイントラネットですか？その場合、IIS スタックを介さずに、TCP ソケットを使用してサーバーと直接通信できます。
netTCPBinding上記の WCF での特定の仮定により、バイナリ エンコーディングを使用するエンドポイントを選択でき、次を使用するサービスを使用できます。
[ServiceBehavior(InstanceContextMode = InstanceContextMode.PerSession)]
[ServiceBehavior(ConcurrencyMode = ConcurrencyMode.Single)].
これにより、クライアントとサーバーの間でセッションが確立され（セッションをサポートするバインディングを使用している限り）、複数のクライアントを並行して処理できるようになります（各クライアントは独自のサーバーインスタンスを取得してセッションを管理するため、スケーリングしません）。 、およびバイナリエンコーディングはデータサイズを「削減する可能性があります」(データが集中的ではないと言ったので、それを避けることを選択でき、バイナリは実際には小さなメッセージサイズにオーバーヘッドを追加する可能性があります)。
一方、サービスが無限にスケーリングし、応答時間を低く保つ機能を必要とする場合、メッセージが失われたり、別の順序で配信されたり、HTTP 経由で配信可能にする必要があるかどうかなどを気にしません。 ..次に、使用できる他の Bindings、InstanceContextModes、メッセージ エンコーディングなどがあります。また、本当に洗練されたものにしたい場合は、さまざまな方法で構成された複数のエンドポイントを公開するサービスを取得できます。クライアントは特定のレシピを好む可能性があります。
注: (IIS を使用して WCF サービスをホストし、使用している場合はnetTCPBinding、net.tcp プロトコルを有効にする必要があります。WCF サービスをセルフホストする場合は必要ありません)。
したがって、これは特定のシナリオで WCF を使用して行う「1 つの」方法です。
1 つの方法を試してみてください...そのメモリ使用量、待ち時間、回復力などを調べてください。必要が変わった場合は、使用するバインディング/エンコーディングを変更してください...それが WCF の美しさと悪夢です。
クライアントが HTTP および POST/GET リクエストを使用する必要がある場合は、HTTP フレーバーのバインディングを使用します。保証されたメッセージ配信が必要な場合は、信頼できるセッションが必要です。
サービスを無限に拡張する必要がある場合は、Windows Azure などのクラウドでサービスをホストすることを検討し始めるかもしれません。
http://blog.shutupandcode.net/?p=1085