私は1つのアプリを持っています。「マネージャー」と「ワーカー」で構成されます。現在、ワーカーは常に接続を開始し、マネージャーに何かを伝え、マネージャーが応答を送信します。
Manager と Worker の間にはたくさんの通信があるので、両者の間でソケットを開いて通信を行うことを検討しています。また、マネージャーが必要なときにいつでもワーカーに何かを言うことができるように、両方の側から対話を開始したいと考えています。
しかし、「衝突」をどのように処理するかについて、私は少し混乱しています。たとえば、マネージャーがワーカーに何かを言うことに決め、同時にワーカーがマネージャーに何かを言うことにしました。何が起こるか？このような状況はどのように処理されるべきですか？
PS 実際の実装には Netty を使用する予定です。
「私はまた、マネージャーがいつでも従業員に何かを言うことができるように、双方から相互作用を開始したいと考えています。」
簡単な答え。しないでください。
既存のプロトコルから学ぶ: クライアントとサーバーを用意します。物事はうまくいくでしょう。Worker をサーバーに、Manager をクライアントにできます。マネージャーは多数の要求を行うことができます。ワーカーは、到着したリクエストに応答します。
ピアツーピアは複雑になる可能性があり、複雑さに対する真の価値はありません。
サーバーとクライアント間の永続的な双方向チャネルが必要です。
1 つのサーバーと1 つのクライアントしかない場合、衝突の問題はありません... サーバーが接続を受け入れる場合、それがクライアントであることを認識し、その逆も同様です。どちらも同じソケットで読み書きできます。
複数のクライアントがあり、サーバーが特にクライアント X にリクエストを送信する必要がある場合は、ハンドシェイクが必要です。
クライアントが起動すると、サーバーに接続します。この接続が確立されると、クライアントは自身がクライアント X であることを識別します (ハンドシェイク メッセージ)。サーバーは、クライアント X に対して開いているソケットがあることを認識し、クライアント X にメッセージを送信する必要があるたびに、そのソケットを再利用します。
幸運なことに、この正確な問題に関するチュートリアル (サンプル プロジェクトが含まれています) を書きました。ネッティーを使って！:)
リンクは次のとおりです。http://bruno.linker45.eu/2010/07/15/handshaking-tutorial-with-netty/
このソリューションでは、サーバーはクライアントへの接続を試行しないことに注意してください。サーバーに接続するのは常にクライアントです。メッセージを送信するたびにソケットを開くことを考えていた場合は、永続的な接続を再検討する必要があります。これは、接続確立のオーバーヘッドを回避し、結果としてデータ転送速度を N 倍高速化するためです。
ソケットについて読む必要があると思います....
この種の問題は実際には発生しません....受信と送信の両方を応答的に処理する方法以外に、通常、これは通信をスレッド化することによって行われます.アプリによっては、これに対していくつかのアプローチを取ることができます.
brunodecarvalho の応答で言及されている Handshake/Netty チュートリアルへの正しいリンクはhttp://bruno.factor45.org/blag/2010/07/15/handshaking-tutorial-with-netty/
です。これを彼の質問にコメントとして追加します。しかし、そうするために最低限必要な評判がありません。
車輪の再発明をしたいが、ミドルウェアを使いたくない場合...
要求に対する他のピアの応答が、他のピアからの要求と常に簡単に区別できるように、プロトコルを設計します。次に、ネットワーク I/O 戦略を慎重に選択してください。ソケットからの読み取りを担当するコードは、最初に、受信データが送信されたデータへの応答であるか、ピアからの新しい要求であるかを判断する必要があります (データのヘッダーを見て、要求を発行したかどうかを確認します)。近々）。また、ピアの要求に応答を送信するときに、発行する新しい要求から適切に分離されるように、適切なキューイングを維持する必要があります。