ERROR GServerHandler - Java.io.IOException: Connection reset by peer
Java.io.IOException: Connection reset by peer
at Sun.nio.ch.FileDispatcher.read0(Native Method)
at Sun.nio.ch.SocketDispatcher.read(Unknown Source)
at Sun.nio.ch.IOUtil.readIntoNativeBuffer(Unknown Source)
at Sun.nio.ch.IOUtil.read(Unknown Source)
at Sun.nio.ch.SocketChannelImpl.read(Unknown Source)
at org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.Java:323)
at org.jboss.netty.channel.socket.nio.NioWorker.processSelectedKeys(NioWorker.Java:282)
at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.Java:202)
at Java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
at Java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at Java.lang.Thread.run(Unknown Source)
このログは、nettyを使用して実装されたゲームサーバーからのものです。この例外の原因は何ですか?
Java.io.IOException:ピアによる接続のリセット
反対側は、トランザクションの途中で突然接続を中止しました。これには、サーバー側から制御できない多くの原因があります。例えば。エンドユーザーは、サーバーとの対話中にクライアントをシャットダウンするか、サーバーを突然変更するか、クライアントプログラムがクラッシュしたか、エンドユーザーのインターネット接続がダウンしたか、エンドユーザーのマシンがクラッシュしたなどを決定しました。
BalusCの答えを拡張するために、ピアが読み取りを停止してソケットを閉じた後、送信者が書き込みを続けるシナリオは、この例外を生成します。ピアは、自身のソケット受信バッファーに未読データがまだある間に閉じます。つまり、アプリケーションプロトコルエラーです。たとえば、ピアが理解できないものをピアに書き込んで、抗議でソケットを閉じてから書き込みを続けると、ピアのTCPスタックはRST。送信者でこの例外とメッセージが発生します。
NettyのJava.io.IOExceptionは、ゲームサーバーがクライアントにデータを送信しようとしたが、そのクライアントがサーバーへの接続を閉じたことを意味します。
そして、その例外は唯一のものではありません!他にもいくつかあります。 Xitrumの BadClientSilencer を参照してください。これらのエラーがログファイルを混乱させないようにするために、それを追加する必要がありました。
Java.io.IOException:ピアによる接続のリセット
私の場合、問題はPUT要求にありました(GETおよびPOSTは正常に渡されていました)。
通信は、VPNトンネルとssh接続を経由しました。そして、PUTリクエストにデフォルトの制限があるファイアウォールがありました... PUTリクエストはサーバーに渡されていません...
IPアドレスのファイアウォールに例外が追加された後、問題は解決しました。