Когда "java.io.IOException: соединение reset by peer" выбрано?
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. Что может вызвать это исключение?
Ответы
Ответ 1
java.io.IOException: соединение reset с помощью peer
Другая сторона резко прервала соединение в середине транзакции. Это может иметь много причин, которые не контролируются со стороны сервера. Например. конечный пользователь решил закрыть клиент или внезапно изменить сервер, все еще взаимодействуя с вашим сервером, или программа клиента потерпела крах, или Интернет-соединение с конечным пользователем снизилось, или компьютер конечного пользователя разбился, и т.д. и т.д.
Ответ 2
Чтобы расширить ответ BalusC, любой сценарий, в котором отправитель продолжает писать после того, как одноранговый узел прекратил чтение и закрыл свой сокет, вызовет это исключение, равно как и закрывающий одноранговый узел, в то время как у него все еще были непрочитанные данные в его собственном приемном буфере сокета. Другими словами, ошибка протокола приложения. Например, если вы записываете что-то одноранговому узлу, который не понимает одноранговый узел, а затем он закрывает свой сокет в знак протеста, а затем продолжаете запись, стек TCP однорангового узла выдаст RST, что приведет к этому исключению и сообщению у отправителя.
Ответ 3
java.io.IOException в Netty означает, что ваш игровой сервер пытается отправить данные клиенту, но у этого клиента есть закрытое соединение с вашим сервером.
И это исключение не единственное! Есть несколько других. См. BadClientSilencer в Xitrum. Я должен был добавить это, чтобы эти ошибки не испортили мой файл журнала.
Ответ 4
java.io.IOException: сброс соединения по пиру
В моем случае проблема была с запросами PUT (GET и POST проходили успешно).
Связь проходила через VPN-туннель и ssh-соединение. И был брандмауэр с ограничениями по умолчанию для запросов PUT... Запросы PUT не передавались на сервер...
Проблема была решена после того, как исключение было добавлено в брандмауэр для моего IP-адреса.
Ответ 5
Для меня полезный код помог мне был http://rox-xmlrpc.sourceforge.net/niotut/src/NioServer.java
//Удаленный принудительно закрыл соединение, отменил
//клавиша выбора и закрыть канал.
private void read(SelectionKey key) throws IOException {
SocketChannel socketChannel = (SocketChannel) key.channel();
// Clear out our read buffer so it ready for new data
this.readBuffer.clear();
// Attempt to read off the channel
int numRead;
try {
numRead = socketChannel.read(this.readBuffer);
} catch (IOException e) {
// The remote forcibly closed the connection, cancel
// the selection key and close the channel.
key.cancel();
socketChannel.close();
return;
}
if (numRead == -1) {
// Remote entity shut the socket down cleanly. Do the
// same from our end and cancel the channel.
key.channel().close();
key.cancel();
return;
}
...
Ответ 6
Я думаю, что это должно быть java.net.SocketException, поскольку его определение указано для ошибки TCP.
/**
* Thrown to indicate that there is an error in the underlying
* protocol, such as a TCP error.
*
* @author Jonathan Payne
* @version %I%, %G%
* @since JDK1.0
*/
public
class SocketException extends IOException {
Ответ 7
Есть много факторов, сначала посмотрите, возвращает ли сервер результат, затем проверьте между сервером и клиентом.
сначала исправить их со стороны сервера, а затем проверить условия записи между сервером и клиентом!
серверная сторона исправляет тайм-ауты между сервером данных и сервером
с клиентской стороны исправить тайм-аут и количество доступных подключений!