Как проверить размер буфера TCP в Spring Websocket (Jetty)?

Question

Как будет работать websocket, если клиент websocket работает слишком медленно?

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

Я хочу обнаружить медленного клиента в моем приложении springboot, проверив размер буфера TCP. Но я не знаю, как проверить размер в Spring Websocket (Jetty 9.2.x). Я не могу найти какой-либо интерфейс, связанный с буфером TCP в исходном коде веб-сокета Jetty.

Если я не могу, есть ли другой способ обнаружить медленного клиента?

Answer 1

Спасибо за @Joakim Erdfelt.

Но я обнаружил, что медленный клиент не будет вызывать обратный вызов, если клиент Chrome. Серверная сторона выдает ошибку «Сброс соединения по одноранговым узлам». Я думаю, сокет может быть закрыт на Chrome, когда буфер веб-сокета клиента заполнен.

Мое окончательное решение находится на уровне приложения.

Пользователь должен фиксировать смещение сообщения через некоторый интервал, и сторона сервера сравнивает зафиксированное смещение на стороне клиента с последним смещением сообщения на стороне сервера. Обнаружить медленного клиента по разрыву между этими двумя смещениями.

Answer 2

Извините, вы не можете получить доступ к буферу TCP.

Веб-сокет Jetty обязателен для сети Java.

Что вы хотите знать, так это результаты записи WebSocket в TCP перегрузка / обратное давление.

Чтобы сделать это, вы обращаете внимание на вызовы записи.

С блокировкой WebSocket это просто простой процесс выполнения записи, он не вернется, пока запись не завершится. завершено. Если он блокируется, запись, вероятно, перегружена по протоколу TCP, и вам следует отказаться от записи чего-либо еще.

При записи asyn c WebSocket вы обращаете внимание на результаты записи (либо из будущего, либо из Обратный вызов) и не пишите следующее сообщение, пока вы не подтвердите, что текущее сообщение успешно записано.

Невозможность обратить внимание на асинхронные обратные вызовы / фьючерсы c приводит к очереди сообщений (очередь не имеет верхний предел и будет увеличиваться, чтобы вместить всю доступную память).

Вам, как приложению, использующему websocket, решать, что делать при обнаружении этого сценария медленной записи.

закрыть соединение?
Вы отбрасываете некоторые сообщения?
Вы вообще ставите сообщения в очередь?

Если вы делаете сообщения в очереди, у вас есть приоритет или важность сообщения?
Если определенное число приоритетных сообщений не было отправлено, затем вы закрываете соединение?
Удерживаете ли вы эти приоритетные сообщения для повторной отправки, когда (если?) клиент переподключается?
У вас есть срок действия / время ожидания для сообщений в очереди?
Удаление сообщений, которые не были отправлены в течение X времени?