Задержка сокета Java продолжается

Question

Я отправляю ascii через сокет следующим образом:

outputStreamWriter(s + (char) 13);
outputStreamWriter.flush(); 

В поле может быть задержка от 10 до 30 секунд между flush () и данными, передаваемыми по сети (провереноиспользуя wireshark).

Чтобы проверить соединение с сокетом, я использую это:

public final boolean isConnected() {
  try {
    socket.sendUrgentData(32);
    return true;
  } catch (IOException e) {
    return false;
  }

Когда я избавляюсь от sendUrgentData и просто возвращаю true в isConnected (), задержка уходит.

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

Есть идеи?Спасибо, Андрей

Answer 1

Я посылаю ASCII через сокет, как это:

outputStreamWriter(s + (char) 13);

Нет, это не так. Этот код даже не компилируется.

Чтобы проверить соединение с сокетом, я использую это

Бесполезно. Это не проверяет сокет соединения. Это просто отправляет какой-то вывод. Он подвержен тем же проблемам, что и простая запись в выходной файл: буфер отправки сокета, повторные попытки, тайм-ауты, приемный буфер сокета получателя и окно приема. Это не говорит вам, является ли соединение все еще хорошим. Ничто не может, кроме простой записи в соединение и перехвата исключений IOException, что, безусловно, не произойдет при первой записи после отключения.

Другая проблема с отправкой пробела через произвольные интервалы состоит в том, что получатель должен понимать и игнорировать их. Есть ли это?

Answer 2

Вы можете попробовать отключить Nagle (Socket.setTcpNoDelay ()), однако эта задержка обычно составляет от 40 до 200 мс в зависимости от ОС.Я никогда не видел чего-то, что вызывает мультисекундную задержку (за исключением полного GC, причиной которого является сомнение)