Я разрабатываю приложение для macOS и хочу проверить состояние подключения. Я создал простой наблюдатель подключений, используя NWPathMonitor; Я использую его как объект среды:
@Observable
class ConnectivityMonitor {
private let queue = DispatchQueue(label: "ConnectivityMonitorQueue")
private let monitor = NWPathMonitor()
private(set) var isConnected: Bool = false
init() {
monitor.pathUpdateHandler = { [weak self] path in
DispatchQueue.main.async {
self?.isConnected = path.status == .satisfied
print("network path changed: ", path.status)
}
}
monitor.start(queue: queue)
}
}
Чтобы проверить различные состояния подключения, я использую префпанель Network Link Conditioner (я назову ее NLC), поставляемую Apple с дополнительными инструментами Xcode.
Я не знаю почему, но NWPathMonitor не реагирует на изменения профиля NLC.
Например; Я установил профиль NLC на 100% Потеря, что означает, что в сети вообще нет подключения к Интернету. Но NWPathMonitor pathUpdateHandler не вызывается.
Я что-то пропустил? Спасибо.





100% потеря — это не то же самое, что отключение. NWPathMonitor проверяет наличие маршрута. Под маршрутом я подразумеваю наличие локального сетевого интерфейса, который будет принимать пакеты, предназначенные для данного адреса.
Такой маршрут существует. Бывает, что каждый пакет отбрасывается, но монитор этого не знает и не может знать. Единственный способ узнать, будет ли пакет доставлен, — это отправить пакет и получить ответ. NWPathMonitor вообще не отправляет пакеты, поэтому не видит потери пакетов.
NLC также по своей конструкции не изменяет конфигурацию сети для 100% потери пакетов. Тестирование этой распространенной ситуации (подключение, но не доставка пакетов) чрезвычайно полезно и сложно сделать иначе. Проверить «действительно отключенное соединение» легко: выключите сеть. Но моделирование сетей, не подключающихся к Интернету (например, в аэропортах или других предприятиях, предлагающих Wi-Fi), является идеальным вариантом использования NLC.
Как правило, проверки «достижимости» имеют ограниченное применение. Они могут сказать вам, что система даже не попытается отправить пакет, потому что радио выключено, и они особенно хорошо подскажут вам, когда стоит повторить попытку неудачного соединения. Но они не могут сказать вам, что отправленные вами сообщения действительно будут доставлены. В конце концов, вам нужно отправить пакет и посмотреть, что произойдет.
Это не недостаток NWPathMonitor. Это основной факт о сетях. Они как почтовое отделение. Невозможно узнать, будет ли письмо, которое вы положили в свой почтовый ящик, действительно доставлено, и если да, то ответит ли другая сторона. NWPathMonitor говорит вам: «Да, на углу стоит почтовый ящик, и он не заперт». Если ваш почтовый оператор решил выбросить все письма в канаву (100% потеря пакетов), узнать об этом заранее невозможно.
Длинный опрос не сильно поможет, так как пакеты они отправляют не очень часто. Если соединение настроено с поддержкой TCP, пакеты могут отправляться каждые несколько минут или каждые пару часов. (Я не проверял значения по умолчанию в macOS.) Обычно они не очень полезны для обнаружения обрыва сети. Правильный подход обычно заключается в том, чтобы просто отправить данные и устранить ошибки, если они возникнут. Вы всегда должны это делать, потому что всегда могут возникнуть ошибки. Но если вы хотите опросить систему, обычным решением будет периодическая отправка контрольного сообщения на ваш сервер и проверка получения ответа.
Существует стандартный инструмент «сердцебиения» под названием ICMP Ping, но многие системы блокируют его, поэтому он бесполезен. Чаще всего вы создаете на своем сервере конечную точку HTTP, которая ничего не делает, кроме возврата 200. И вы пингуете ее каждый... ну, как бы часто вы ни хотели ее пинговать. Затем вам нужно решить, сколько промахов соответствует разрыву соединения. И тогда вам придется решить, что делать, когда это произойдет.
Еще раз спасибо за ваше время и заботу 🙏
Спасибо, что объяснили ситуацию, как идиоту :) И все же, в моем случае было бы здорово как-то знать, как работает почта в то время. У меня никогда не было случая, когда мне нужно было знать текущий статус подключения к Интернету. В целом NWPathMonitor/Reachability хватило. Вы отправляете запросы; они идут или нет, возможно, из-за результата, который вы показываете, или из-за всплывающего сообщения об ошибке. А как насчет длительного опроса под капотом? Я думаю, что это может удовлетворить мою потребность.