Будет ли XMPP работать в среде NAT?
Сервер XMMP отправляет push-уведомления клиенту за NAT, используя общедоступную конечную точку (IP + порт), предоставленную NAT клиенту. Но как долго эта конечная точка назначается этому конкретному клиенту NAT, что произойдет, если NAT назначит ту же конечную точку другому клиенту ? Как эту проблему можно решить?
2 ответа:
XMPP использует стандартное TCP-соединение. Натс будет поддерживать связь до тех пор, пока связь жива (если только они не будут ужасно разорваны).
Update: последнюю часть моего заявления можно было бы немного расширить. Ужасно сломанные реализации NAT действительно существуют. Как правило, это небольшой процент, но многие (большинство?) популярный XMPP клиенты не обеспечить им отправить какое-то сообщение за неактивных соединений.
Есть три вида keepalive, которые вы можете использовать Я перечислю их здесь в порядке требований к пропускной способности / обработке:
TCP keepalives-это хороший легкий вариант, тем более что как только они включены, они автоматически обрабатываются ОС. Как включить их, будет зависеть от вашего языка и фреймворка, но на самом низком уровне вам нужно включить опцию
SO_KEEPALIVEв сокете.Есть две проблемы с TCP keepalives. Одна из них заключается в том, что вы не можете управлять ими из своего приложения (если только вы не пишете специфичный для платформы код). Вторая проблема заключается в том, что некоторые реализации NAT настолько сломаны, что они также будут игнорировать TCP keepalives! Но мы надеемся, что сейчас вы снизились до очень малого процента.
Таким образом, другой вариант - пробелы keepalives. Поскольку они включают данные, идущие через поток, вы должны быть в безопасности даже от сломанных NATs, которые игнорируют keepalives.
Сохранение пробелов просто включает в себя отправку символа пробела ( '' ) через поток XMPP в любое время, когда он простаивает. XML и XMPP допускает неограниченное количество пробелов между элементами, и получатель просто игнорирует его.
Наконец, вы можете использовать полноценныеXMPP pings (XEP-0199) . Они включают в себя окончание фактической строфы
Хорошо, я должен упомянуть, что есть еще худший класс NAT. Я видел Натс, которые будут просто "забудьте" о своем отображении по целому ряду причин, в том числе о том, что их таблица отображения заполнена, или сразу после таймера. Вы ничего не можете сделать, чтобы обойти их, они не работают с любыми долгоживущими TCP-соединениями. Лучшее, что вы могли бы сделать в этот момент, это использовать BOSH (по сути XMPP через HTTP).<iq/>" get " на сервер, который затем должен ответить. Это обеспечивает потоки данных в обоих направлениях и должно заставить даже самые сломанные реализации NAT поддерживать ваше соединение.Заключение: Если вы обеспокоены тем, что ваше приложение может работать за некоторыми из этих устройств, я предлагаю что-то вроде следующего алгоритма (точное время может будьте настроены, но я рекомендую их как минимальные значения):
- Если вы не отправляли никаких данных за 60 лет, отправьте один символ пробела.
- Если вы не получили никаких данных за 120s, отправьте XMPP ping на ваш сервер.
- если сервер не отвечает на пинг в течение разумного периода времени, повторите подключение.
Поскольку поведение сломанных устройств NAT выходит за рамки любой стандартной спецификации протокола, естественно, невозможно разработать идеальное решение. это будет работать со всеми ними, все время. Вы просто должны принять, что это небольшое меньшинство, и ничто из этого не имеет значения для работы устройств NAT (хотя есть и другие виды сетевых сбоев, которые могут сделать регулярные keepalives/pings хорошей идеей, в зависимости от потребностей вашего приложения).
Решение заключается в отправке сообщений keep alive для сохранения записи NAT. Обычно используется пробел XMPP. Отправляйте его, например, каждые десять минут, чтобы сохранить достижимость конечного клиента.
Вы должны иметь в виду, что NAT не является стандартизированной техникой. Таким образом, существуют различные реализации. Приведенные в комментарии выше РФЦ принадлежат рабочей группе BEHAVE.