Клиент / сервер Netty должен знать о разрыве канала в течение мс
В моем приложении есть сервер netty, а клиент netty - один из микросервисов. Для проверки работоспособности этой конкретной микросервиса клиент Netty (микросервис) устанавливает соединение с моим приложением и создает канал Netty. При первом подключении канала происходит незначительный обмен метаданными, а затем иногда происходит обмен данными. Канал помогает нам постоянно определять время безотказной работы микросервиса.
Проблема, с которой мы сталкиваемся: а. Что произойдет, если на сервере отключится электричество. Как быстро мой клиент узнает. Я хочу, чтобы это было в порядке мс и как? б. Что произойдет, если я вытащу сетевой кабель на сервере. Я хочу, чтобы клиент был проинформирован в течение миллисекунд, и как мы к этому подходим?
Обычно мы ожидаем, что сервер выйдет из строя и канал будет отключен, и клиент узнает об этом, однако клиент узнает об этом гораздо позже, что приведет к множеству проблем с точки зрения времени безотказной работы и подключения.
Есть ли способ, которым мой клиент netty узнает об этих двух отключениях в течение мс?
То же самое применимо и к серверу. то есть, если такая же деятельность выполняется на стороне клиента, и сервер должен знать немедленно.
P.S. Я не могу играть в пинг-понг между Netty Client и Netty Server
Ответы 1
Ваши требования невозможны без поддержки на уровне приложений. Это связано с особенностями конструкции самого TCP.
Характер принудительного отключения из-за выдергивания кабеля LAN или отключения электроэнергии означает, что это событие не отправляет пакеты по сети, поэтому это не может быть использовано для обнаружения этого.
Хотя существует пакет TCP с длиной 0, конечные точки не обязаны отвечать ACK на эти пакеты, поэтому на это также нельзя полагаться. (И даже если он поддерживается, вам все равно придется поддерживать надлежащую систему тайм-аута для защиты от краткосрочной потери пакетов (что не вредно в долгосрочной перспективе))
Лучше всего будет отправлять эти необработанные пакеты нулевой длины (не знаете, как это сделать с помощью Netty), и, если вам повезет, вы надеетесь, что один из маршрутизаторов на маршруте вернет «ICMP Destination not reachable», и создайте система повтора внутри вашего протокола.