Internal exception java net socketexception connection reset что делать windows 10 minecraft
Обновлено: 06.07.2024
Я получаю следующую ошибку при чтении из сокета. Я делаю readInt() на этом InputStream , и я получаю эту ошибку. Изучая документацию, можно предположить, что клиентская часть соединения закрыла соединение. В этом сценарии я являюсь сервером.
У меня есть доступ к файлам журнала клиента, и он не закрывает соединение, и на самом деле его файлы журнала предполагают, что я закрываю соединение. Кто-нибудь знает, почему это происходит? Что еще проверить? Возникает ли это, когда есть местные ресурсы, которые, возможно, достигают пороговых значений?
Замечу, что у меня есть такая строка:
непосредственно перед readInt() . Для этого есть причина (длинная история), но просто любопытно, есть ли обстоятельства, при которых это могло бы привести к указанной ошибке? У меня есть сервер, работающий в моей IDE, и я случайно оставил свою IDE застрявшей в точке останова, и затем я заметил, что те же самые ошибки начали появляться в моих собственных журналах в моей IDE.
В любом случае, просто упоминание об этом, надеюсь, не отвлекающий маневр. :-(
У вас есть следы стека с обеих сторон? Не могли бы вы немного подробнее описать сетевую архитектуру? (Через дикий Интернет? На одной машине? Где-то посередине?) Это происходит постоянно? Или с перерывами?Есть несколько возможных причин.
Другой конец намеренно сбросил соединение, что я здесь не буду описывать. Прикладное программное обеспечение делает это редко и, как правило, неправильно, но для коммерческого программного обеспечения это известно.
Чаще всего это вызвано записью в соединение, которое другой конец уже нормально закрыл. Другими словами, ошибка протокола приложения.
Это также может быть вызвано закрытием сокета, когда в приемном буфере сокета есть непрочитанные данные.
В Windows «программное обеспечение вызвало прерывание соединения», что не то же самое, что «сброс соединения», вызвано сетевыми проблемами при отправке с вашего конца. Об этом есть статья в базе знаний Microsoft.
@MattLyons Спасибо. Есть гораздо лучшие статьи MSDN, чем эта. Честно говоря, мне трудно в это поверить. Соединение даже не будет существовать, пока не будут установлены правильный исходный и целевой IP-адреса. В статьях MSDN, которые я видел, говорится о постоянных сетевых ошибках, связанных с задержкой соединения.Сброс соединения означает просто получение TCP RST. Это происходит, когда ваш партнер получает данные, которые он не может обработать, и для этого могут быть разные причины.
Самый простой - это когда вы закрываете сокет, а затем записываете больше данных в выходной поток. Закрывая сокет, вы сказали своему партнеру, что вы закончили говорить, и он может забыть о вашем соединении. Когда вы все равно отправляете в этот поток больше данных, одноранговый узел отклоняет их с помощью RST, чтобы вы знали, что он не слушает.
В других случаях вмешивающийся межсетевой экран или даже сам удаленный хост могут «забыть» о вашем TCP-соединении. Это может произойти, если вы не отправляете никаких данных в течение длительного времени (2 часа - обычный тайм-аут) или из-за того, что одноранговый узел был перезагружен и потерял информацию об активных соединениях. Отправка данных по одному из этих несуществующих соединений также вызовет RST.
Обновление в ответ на дополнительную информацию:
Внимательно посмотрите на то, как вы работаете с SocketTimeoutException . Это исключение возникает, если превышен настроенный тайм-аут при блокировании операции сокета. Состояние самого сокета не изменяется при возникновении этого исключения, но если ваш обработчик исключений закрывает сокет, а затем пытается записать в него, вы будете в состоянии сброса соединения. setSoTimeout() предназначен для того, чтобы дать вам чистый способ прервать read() операцию, которая в противном случае могла бы заблокироваться навсегда, без каких-либо грязных вещей, таких как закрытие сокета из другого потока.
Читайте также: