XMPP использует стандартное TCP-соединение. NAT будет поддерживать связь до тех пор, пока соединение будет живым (если только оно не будет ужасно нарушено).
Обновление: Последняя часть моего утверждения могла бы быть немного расширена. Существуют ужасно сломанные реализации NAT do . Как правило, это небольшой процент, но многие (большинство?) Популярных клиентов XMPP действительно гарантируют, что они отправляют какие-то сообщения поддержки активности через незанятые соединения.
Существует три вида поддержки активности, которые вы можете использовать. Я перечислю их здесь в порядке требований к пропускной способности / обработке:
TCP keepalive - хороший облегченный вариант, тем более что после включения они автоматически обрабатываются ОС. Как их включить, будет зависеть от вашего языка и структуры, но на самом низком уровне вам нужно включить опцию SO_KEEPALIVE в сокете.
Есть две проблемы с поддержкой активности TCP. Во-первых, вы не можете управлять ими из своего приложения (если вы не пишете код, специфичный для платформы). Вторая проблема заключается в том, что некоторые реализации NAT являются , поэтому сломаны, что они также будут игнорировать сообщения поддержки активности TCP! Но, надеюсь, сейчас у вас очень маленький процент.
Так что другой вариант - keepalive . Так как они включают данные, проходящие через поток, вы должны быть защищены даже от сломанных NAT, которые игнорируют сообщения активности.
Поддержка активности пробелов просто включает отправку пробела ('') через поток XMPP в любое время, когда он простаивает. XML и XMPP допускают неограниченное количество пробелов между элементами, и получатель просто игнорирует их.
Наконец, вы можете использовать полноценные XMPP-пинги (XEP-0199) . Это подразумевает завершение действительного раздела <iq/> get на сервер, который затем должен ответить. Это обеспечивает потоки данных в обоих направлениях, и даже самые нарушенные реализации NAT должны поддерживать ваше соединение в рабочем состоянии.
Хорошо, я должен упомянуть, что есть еще худший класс NAT. Я видел NAT, которые просто «забудут» о вашем отображении по ряду причин, включая заполнение таблицы сопоставления или сразу после таймера. Вы ничего не можете сделать, чтобы обойти их, они не работают с какими-либо долгоживущими TCP-соединениями. Лучшее, что вы могли бы сделать в этот момент, это использовать BOSH (по сути XMPP через HTTP).
Вывод: Если вы обеспокоены тем, что ваше приложение может работать за некоторыми из этих устройств, я предлагаю что-то вроде следующего алгоритма (точное время может быть изменено, но я рекомендую их как минимальные значения):
- Если вы не отправляли данные в течение 60 с, отправьте один пробел.
- Если вы не получили никаких данных в течение 120 секунд, отправьте пинг XMPP на ваш сервер.
- Если сервер не отвечает на пинг в течение разумного периода времени, переподключитесь.
Поскольку поведение сломанных устройств NAT выходит за рамки любой стандартной спецификации протокола, естественно, невозможно разработать идеальное решение, которое будет работать со всеми из них все время. Вы просто должны признать, что это небольшое меньшинство, и ничего из этого не имеет значения для работающих устройств NAT (хотя существуют другие виды обрывов сети, которые могут сделать регулярные сообщения поддержки активности / проверки связи хорошей идеей, в зависимости от потребностей вашего приложения).