3

これは、質問というよりも議論の対象になるかもしれません。

背景：
サーバー/クライアントのペアが2つあり、1つはJavaで記述され、もう1つはC＃で記述されています。両方のペアは同じことをしています。Java \ JavaとC＃\ C＃の組み合わせを使用している場合は問題ありません。Java \ C＃とC＃\Javaの組み合わせも機能させたいです。I \ Oに問題はありません。私は、XML形式の文字列を表すバイト配列を使用しています。私はTCPを使用する必要があります。

私は優雅な切断を気にする必要があります。Javaにはそのようなことはありません。クライアントのソケットを閉じると、サーバー側のソケットはパッシブクローズ状態のままになります。したがって、このソケットを処理するサーバースレッドはまだ存続しており、多くのクライアントの場合、何千もの不要なスレッドが発生する可能性があります。C＃では、TcpClient.Availableを呼び出して、バッファーにデータがあるかどうか、またはクライアントが閉じられているかどうか（SocketException）を判別するだけで十分です。Javaでは、2つのアプローチを考えることができます。

  1. 反対側がまだ開いているかどうかを実際にテストするには、ソケットの基になるストリームに何かを書き込む必要があります。
  2. 接続を閉じる前に、接続の片側を閉じていることを反対側に認識させる必要があります。これを実装しました。クライアントソケットを閉じる前に、0x04バイト（送信の終わり）を含むパケットをサーバーに送信しています。サーバーは、ソケットのサーバー側を閉じることでこのバイトに反応します。

残念ながら、どちらのアプローチでも、client \ serverのC＃\JavaとJava\ C＃のペアに関してはジレンマが発生しました。これらのペアが相互に通信できるようにする場合は、0x04バイトをC＃クライアントに送信するためのコードを追加する必要があります。もちろん、それを処理するコードをC＃サーバーに送信する必要があります。これは一種のオーバーヘッドです。しかし、私は不要なネットワークトラフィックで生きることができました。主な問題は、このC＃コードがコア通信ライブラリの一部であり、絶対に必要でない限り触れたくないということです。

質問：
Javaで正常に切断する他のアプローチはありますか？これは、ソケットの基になるストリームへの書き込みと結果のチェックを必要としないため、C＃コードでもこれを処理する必要はありませんか？使用済みライブラリに関してはフリーハンドです。JavaSE\EEだけを使用する必要はありません。

4

2 に答える 2

2

この回答では、この「優雅な切断」のトピックについて簡潔に説明しました（私が思うに）。お役に立てば幸いです。

両方の側が同じ優雅な切断パターンを使用する必要があることを忘れないでください。クライアントソケットを正常に切断しようとしていることに気づきましたが、サーバーはデータを送信し続けました（自身の側をシャットダウンしませんでした）。その結果、無限ループが発生しました...

于 2013-04-14T15:50:16.397 に答える
0

答えは明らかでした。C＃でもグレースフルディスコネクトのようなものはありません。それはTCPプロトコルコントラクトに関するものです。したがって、Javaと同じ問題がありますが、わずかな違いが1つありますが、特定の状況で回避策を講じることができます-> NetworkStreamを介して0バイトを送信し、TcpClient.Connected状態を確認すると、なんとか正しいです。しかし、私がインターネットで見つけたものから、これはC＃で接続をテストする方法の信頼性も好ましい方法でもありません。もちろん、私のC＃ライブラリでは使用されています。Javaでは、これをまったく使用できません。

したがって、クライアントが切断されたときに「送信終了」パケットをサーバーに送信するという私の解決策はしっかりしており、C＃ライブラリにも導入しました。今、私は最初のバグが現れるのを恐れて震えています...

最後に、クラッシュしたクライアントの処理スレッドをサーバー上で収集する何らかのメカニズムも実装する必要があります。同様のことをしている場合、クライアントが予期せず終了することはないということを覚えておいてください;）

于 2013-01-18T10:22:52.840 に答える