TCP не знает о «статусе» перевода. Это проблема протокола приложения, а не проблема транспортного уровня.
Что касается состояния соединения TCP, то нет прямого запроса. Вместо этого вы узнаете статус при попытке чтения или записи данных. Результат read(...) или `write (...) для получения некоторой информации о состоянии соединения.
Если вызов read или write указывает, что он имеет читать или записывать ненулевое число байтов, тогда соединение, вероятно, живо.
Если read, который возвращает ноль байтов, указывает, что другой конец закрыл свою сторону записи связь. Однако мы не можем сказать, выполняло ли это удаленное приложение, это сделала удаленная ОС или что-то в сети инициировало закрытие.
Если read или write выдает исключение, тогда мы можем сделать вывод, что возникла проблема И соединение больше не является жизнеспособным. Исключения, которые возможны в этом контексте, включают:
SocketException - Типичные сообщения «сброс соединения» или «обрыв канала», которые обычно означают, что удаленный абонент сделал что-то неожиданное, или «закрытие сокета», что означает что приложение попыталось прочитать или записать соединение, которое оно закрыло. SocketTimeoutException - Обычно это происходит, если read заняло больше времени, чем настроенное время ожидания чтения для розетки. К сожалению, он не может ничего вам сказать о базовой причине для тайм-аута. ProtocolException - Теоретически это возможно для операции ввода-вывода через сокет, но обычно выдается это исключение по коду протокола приложения.
К сожалению, это означает, что предоставление пользователю вашего приложения четкой и точной информации о том, почему передача не удалась, затруднено. Но это присуще сетевым подключениям. Реальная проблема заключается в том, что простая / понятная диагностика c информации не доступна напрямую нигде .