У нас есть GPRS-шлюз (сервер) на базе apache mina. Иногда, обычно, когда соединение прерывается со стороны клиента грубо, например, из-за отключения кабеля питания или любого другого необычного отключения или какой-либо проблемы с сетью, оно не удаляется или не закрывается на стороне сервера. Он остается там, в бездействующем состоянии, ибо я не знаю, как долго (может быть, навсегда). Иногда мы сталкиваемся с проблемами при выключении сервера, MINA занимает слишком много времени, а иногда нам приходится в конце концов его убить. Мы подозреваем, что эта проблема связана с проблемой мертвого соединения.
На самом деле, эта мертвая связь имеет смысл. Так как соединение закрыто брутально и у мина нет возможности его проверить (так работает tcp сессия). В качестве обходного пути мы разработали решение, согласно которому мы закрываем сеанс, если он остается бездействующим (как для чтения, так и для записи), скажем, 30 минут (или любое настраиваемое время). Что нам не нравится по 2 причинам:
1- Это некрасиво выглядит.
2- Кроме того, у нас есть правило, согласно которому клиент устанавливает постоянное соединение с сервером. Таким образом, немного сложно установить «тайм-аут простоя», поскольку мы не можем просто закрыть любой сеанс, который простаивал в течение x минут/часов, поскольку это может быть допустимое соединение.
Итак, есть ли более приятный и безопасный (в нашем случае) способ обнаружить и очистить эти мертвые соединения в MINA?
Мертвые сессии в apache mina
Ответы (1)
В обоих случаях длительное неактивное соединение и потерянное соединение - отсутствие активности в канале должно привести к тайм-ауту после настроенного времени на каждом уровне модель OSI. Например. ваш брандмауэр/маршрутизатор/сервер может прервать запись неактивного соединения через 10 минут, тогда ваше соединение прикладного уровня также должно сделать это через 10 минут - ждать больше не имеет смысла.
Чтобы предотвратить тихие соединения из-за истечения времени ожидания, необходимо ввести протокол поддержания активности. Это может быть ping (не совсем ICMP) или другая форма периодического бездействия. Когда одноранговый узел активен, он должен ответить и, таким образом, обновить обратный отсчет тайм-аута на всех сетевых уровнях. После неудачной попытки, вызванной тайм-аутом или уровнем, сигнализирующим о разорванном соединении, вы можете предположить, что ваше соединение прикладного уровня также разорвано.
