Ошибки сетевого сокета Sparadic java [дубликат]

Вы должны тщательно проверить полную трассировку,

У меня есть приложение для подключения к серверу и исправлено случай java.net.SocketException: Connection reset.

В моем случае это происходит при чтении из clientSocket Socket, который по какой-то причине закрыл свое соединение. (Потеря сети, брандмауэр или крах приложения или предполагаемый конец)

На самом деле я восстанавливал соединение, когда получал ошибку при чтении с этого объекта Socket.

Socket clientSocket = ServerSocket.accept();
is = new BufferedReader(new InputStreamReader(clientSocket.getInputStream()));
int readed = is.read(); // WHERE ERROR STARTS !!!

Интересный вещь for my JAVA Socket, если клиент подключается к моему ServerSocket и закрывает его соединение, не отправляя ничего is.read() вызывает себя рекурсивно. Кажется, из-за того, что он находится в бесконечном цикле для чтения из этого сокета, вы пытаетесь читать из закрытого подключение. Если вы используете что-то вроде ниже для операции чтения,

while(true)
{
  Receive();
}

Затем вы получаете stackTrace что-то вроде ниже и на

java.net.SocketException: Socket is closed
    at java.net.ServerSocket.accept(ServerSocket.java:494)

. Я только что закрыл ServerSocket и обновил мое соединение и ожидание дальнейших входящих клиентских подключений

String Receive() throws Exception
{
try {                   
            int readed = is.read();
           ....
}catch(Exception e)
{
        tryReConnect();
        logit(); //etc
}


//...
}

Это восстанавливает мое соединение для неизвестного потерянного сокета клиента

private void tryReConnect()
        {
            try
            {
                ServerSocket.close();
                //empty my old lost connection and let it get by garbage col. immediately 
                clientSocket=null;
                System.gc();
                //Wait a new client Socket connection and address this to my local variable
                clientSocket= ServerSocket.accept(); // Waiting for another Connection
                System.out.println("Connection established...");
            }catch (Exception e) {
                String message="ReConnect not successful "+e.getMessage();
                logit();//etc...
            }
        }

Я не мог найти другого пути, потому что, как вы видите из ниже изображения вы не можете понять, потеряна ли связь или нет без try and catch, потому что все кажется правильным. Я получил этот снимок, пока я непрерывно получал Connection reset.

Сброс соединения означает, что был получен TCP RST. Это происходит, когда ваш одноранговый узел получает данные, которые он не может обработать, и для этого могут быть разные причины.

Самое простое, когда вы закрываете сокет, а затем записываете больше данных в выходной поток. Закрыв сокет, вы сказали своему коллеге, что вы закончили говорить, и он может забыть о вашем соединении. Когда вы отправляете больше данных об этом потоке, одноранговый узел отклоняет его с помощью RST, чтобы вы знали, что он не прослушивает.

В других случаях промежуточный брандмауэр или даже сам удаленный хост может «забыть» «о вашем TCP-соединении. Это может произойти, если вы не отправляете какие-либо данные в течение длительного времени (2 часа - общий тайм-аут), или потому, что сверстник перезагружен и потерял информацию об активных соединениях. Отправка данных по одному из этих несовместимых соединений вызовет также RST.

Обновить в ответ на дополнительную информацию:

Взгляните внимательно ваше обращение с SocketTimeoutException. Это исключение возникает, если превышен установленный тайм-аут при блокировке операции сокета. Состояние самого сокета не изменяется при вызове этого исключения, но если ваш обработчик исключений закрывает сокет, а затем пытается записать его, вы будете в состоянии сброса соединения. setSoTimeout() предназначен для того, чтобы дать вам чистый способ выйти из операции read(), которая в противном случае могла бы блокироваться навсегда, без грязных вещей, таких как закрытие сокета из другого потока.

Всякий раз, когда у меня были такие странные проблемы, я обычно сажусь с помощью инструмента, например WireShark , и просматриваю необработанные данные, передаваемые туда и обратно. Вы можете быть удивлены, когда что-то отключается, и вы только уведомлены при попытке прочитать.

У меня была такая же ошибка. Я нашел решение проблемы сейчас. Проблема заключалась в том, что клиентская программа заканчивалась до того, как сервер прочитал потоки.

У меня была эта проблема с SOA-системой, написанной на Java. Я работал как с клиентом, так и с сервером на разных физических машинах, и они отлично работали в течение длительного времени, затем эти неприятные сбрасывания соединений появились в журнале клиентов, и в журнале сервера не было ничего странного. Перезапуск клиента и сервера не помогло решить проблему. Наконец, мы обнаружили, что куча на стороне сервера была довольно полной, поэтому мы увеличили доступную память для JVM: проблема решена! Обратите внимание, что в журнале не было OutOfMemoryError: память была просто скудной, а не исчерпанной.

У меня также была эта проблема с программой Java, пытающейся отправить команду на сервер через SSH. Проблема заключалась в том, что машина выполнила код Java. У него не было разрешения на подключение к удаленному серверу. Метод write () выполнял все в порядке, но метод read () выбрал java.net.SocketException: Connection reset. Я исправил эту проблему, добавив ключ SSH клиента к известным ключам удаленного сервера.

Смущающе сказать это, но когда у меня возникла эта проблема, было просто ошибкой, что я закрывал соединение, прежде чем я прочитал все данные. В случаях, когда возвращаются маленькие строки, это сработало, но, вероятно, из-за того, что весь ответ был буферизирован до того, как я его закрыл.

В случае более длительного количества возвращаемого текста исключение было выбрано, так как больше назад возвращался буфер.

Вы можете проверить этот контроль. Помните, что открытие URL-адреса похоже на файл, обязательно закройте его (отпустите соединение) после его полного чтения.

Существует несколько возможных причин.

1. Другой конец намеренно перезагружает соединение, таким образом, что я не буду документировать здесь. Это редко, и, как правило, неверно для прикладного программного обеспечения, но это не является неизвестным для коммерческого программного обеспечения.
2. Чаще всего это связано с записью на соединение, которое другой конец уже закрыт нормально , Другими словами, ошибка протокола приложения.
3. Это также может быть вызвано закрытием сокета, когда в буфере приема сокета есть непрочитанные данные.
4. В Windows «программное обеспечение вызвало прерывание соединения ', который не совпадает с «сбросом соединения», вызван отправкой сетевых проблем с вашего конца. В этой статье есть статья базы знаний Microsoft.